40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 163 of 348  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  6168   Wed Jan 4 09:06:50 2012 steveUpdateComputerspossible front-end timing issue



Is there a reason the framebuilder status light is red for all the front ends?

Also, I reenabled PRM watchdog.

Apparently there is a bug in the timing cards having to do with the new year roll-over that is causing front-end problems.  From Rolf:

For systems using the Spectracom IRIG-B cards for timing information, the code did not properly roll over the time for
2012 (still thinks it is 2011 and get reports from DAQ of timing errors (0x4000)). I have made a temporary fix for this
in the controller.c code in branch-2.3, branch-2.4 and release 2.3.1. 

I was going to check to see if the 40m is suffering from this. I'll be over to see if that's the problem.

 The problem is the same as yesterday.

Attachment 1: rtntstat.png
  6170   Wed Jan 4 16:22:30 2012 kiwamuUpdateLSCpower normalization in LSC : modification done

The dynamic power normalization system has been modified such that the normalization happen after the LSC input matrix.

The attached screen shot below tells you how the signals flow.
The red circled region in the picture is the place where the power normalization are performed.
The dynamic normalization will be activated once you put some numbers into the elements in the matrix.
Otherwise the error signals are always normalized by 1.

Quote from #6158

It turned out that the power normalization need a modification.

I will work on it tomorrow and it will take approximately 2 hours to finish the modification.


  6171   Wed Jan 4 16:40:52 2012 JamieUpdateComputersfront-end fb communication restored

Communication between the front end models and the framebuilder has been restored.  I'm not sure exactly what the issue was, but rebuilding the framebuilder daqd executable and restarting seems to have fixed the issue.

I suspect that the problem might have had to do with how I left things after the last attempt to upgrade to RCG 2.4.  Maybe the daqd that was running was linked against some library that I accidentally moved after starting the daqd process.  It would have kept running fine as was, but if the process died and was attempted to be started again, it's broken linking might have kept it from running correctly.  I don't have any other explanation.

It turns out this was not (best I can tell) related to the new year time sync issues that wer seen at the sites.

  6172   Thu Jan 5 09:08:48 2012 steveUpdateGeneralframebuilder is back

Dataviewer is recovered after heavy new year party.

Attachment 1: dataviewerisback.png
  6173   Thu Jan 5 09:59:27 2012 JamieUpdateCDSRTS/RCG/DAQ UPGRADE TO COMMENCE


I will be attempting (again) to upgrade the RTS, including the RCG and the daqd, to version 2.4 today.  The RTS will be offline until further notice.

  6174   Thu Jan 5 20:40:21 2012 JamieUpdateCDSRTS upgrade aborted; restored to previous settings; fb symmetricom card failing?

After running into more problems with the upgrade, I eventually decided to abort todays upgrade attempt, and revert back to where we were this morning (RTS 2.1).  I'll try to follow this with a fuller report explaining what problems I encountered when attempting the upgrade.

However, when Alex and I were trying to figure out what was going wrong in the upgrade, it appears that the fb symmetricom card lost the ability to sync with the GPS receiver.  When the symmeticom module is loaded, dmesg shows the following:

[  285.591880] Symmetricom GPS card on bus 6; device 0
[  285.591887] PIC BASE 2 address = fc1ff800
[  285.591924] Remapped 0x17e2800
[  285.591932] Current time 947125171s 94264us 800ns 
[  285.591940] Current time 947125171s 94272us 600ns 
[  285.591947] Current time 947125171s 94280us 200ns 
[  285.591955] Current time 947125171s 94287us 700ns 
[  285.591963] Current time 947125171s 94295us 800ns 
[  285.591970] Current time 947125171s 94303us 300ns 
[  285.591978] Current time 947125171s 94310us 800ns 
[  285.591985] Current time 947125171s 94318us 300ns 
[  285.591993] Current time 947125171s 94325us 800ns 
[  285.592001] Current time 947125171s 94333us 900ns 
[  285.592005] Flywheeling, unlocked...

Because of this, the daqd doesn't get the proper timing signal, and consequently is out of sync with the timing from the models.

It's completely unclear what caused this to happen.  The card seemed to be working all day today, then Alex and I were trying to debug some other(maybe?) timing issues and the symmetricom card all of a sudden stopped syncing to the GPS.  We tried rebooting the frame builder and even tried pulling all the power to the machine, but it never came back up.  We checked the GPS signal itself and to the extend that we know what that signal is supposed to look like it looked ok.

I speculate that this is also the cause of the problems were were seeing earlier in the week.  Maybe the symmetricom card has just been acting flaky, and something we did pushed it over the edge.

Anyway, we will try to replace it tomorrow, but Alex is skeptical that we have a replacement of this same card.  There may be a newer Spectracom card we can use, but there may be problems using it on the old sun hardware that the fb is currently running on.  We'll see.

In the mean time, the daqd is running rogue, off of it's own timing.  Surprisingly all of the models are currently showing 0x0 status, which means no problems.  It doesn't seem to be recording any data, though.  Hopefully we'll get it all sorted out tomorrow.

  6175   Fri Jan 6 01:00:56 2012 kiwamuUpdateCDSc1scx out of sync

Both the c1scx and its IOP realtime processes became out of sync.

Initially I found that the c1scx didn't show any ADC signals, though the sync sign was green.

Then I software-rebooted the c1iscex machine and then it became out of sync.

For tonight this is fine because I am concentrating on the central part anyway.

  6176   Fri Jan 6 11:49:13 2012 JamieUpdateCDSframebuilder taken offline to diagnose problem with symmetricom timing card

Alex and I have taken the framebuilder offline to try to see what's wrong with the symmetricom card.  We have removed the card from the chassis and Alex has taken it back to downs to do some more debugging.

We have been formulating some alternate methods to get timing to the fb in case we can't end up getting the card working.

  6177   Fri Jan 6 14:31:54 2012 JamieUpdateCDSframebuilder back online, using NTP time syncronization

The framebuilder is back online now, minus it's symmetricom GPS card.  The card seems to have failed entirely, and was not able to be made to work at downs either.  It has been entirely removed from fb.

As a fall back, the system has been made to work off of the system NTP-based time synchronization.  The latest symmetricom driver, which is part of the RCG 2.4 branch, will fall back to using local time if the GPS synchronization fails.  The new driver was compiled from our local checkout of the 2.4 source in the new to-be-used-in-the-future rtscore directory:

controls@fb ~ 0$ diff {/opt/rtcds/rtscore/branches/branch-2.4/src/drv/symmetricom,/lib/modules/}/symmetricom.ko
controls@fb ~ 0$ 

The driver was reloaded.   daqd was also linked against the last running stable version and restarted:

controls@fb ~ 0$ ls -al $(readlink -f /opt/rtcds/caltech/c1/target/fb/daqd)
-rwxr-xr-x 1 controls controls 6592694 Dec 15 21:09 /opt/rtcds/caltech/c1/target/fb/daqd.20120104
controls@fb ~ 0$ 

We'll have to keep an eye on the system, to see that it continues to record data properly, and that the fb and the front-ends remain in sync.

The question now is what do we do moving forward.  CDS is not supporting the symmetricom cards anymore, and have moved to using Spectracom GPS/IRIG-B cards.  However, Downs has neither at the moment.  Even if we get a new Spectracom card, it might not work in this older Sun hardware, in which case we might need to consider upgrading the framebuilder to a new machine (one supported by CDS).

  6178   Fri Jan 6 19:17:07 2012 Max De JongUpdateGeneralMounted projector

I mounted the new projector to the pipe where the old projector was attached. The mounting hardware wasn't designed for attaching to a pipe, but with Steve's help I mounted the projector. The projector is angled away from the area of the wall designated as the screen, and I am going to meet with Steve Monday to fix this.

  6179   Fri Jan 6 20:10:48 2012 ranaUpdateCDSframebuilder back online, using NTP time syncronization


 You (Jamie) should talk with Rolf and Alex to find out what framebuilder they will support for > 3 years. Then we should buy that along with the adapter card which allows us to use the same RAID we now have for the frames.

  6180   Mon Jan 9 08:47:35 2012 steveUpdateSUSETMX damping restored

ETMX sus damping restored

  6181   Mon Jan 9 13:19:09 2012 kiwamuUpdateSUSETMX damping restored

No we can't do that because the c1scx model is not working properly.

If you look into the real time controller screen you will find what I mean.

Quote from #6180

ETMX sus damping restored

  6182   Mon Jan 9 23:52:15 2012 kiwamuUpdateCDSSUS channels not accessible from dataviewer

[John / Kiwamu]

 We found that some of the suspensions channels (for example C1:SUS-BS_POS_IN1 and etc) were not accessible from dataviewer for some reasons.

So far it seems none of the channels associated with c1sus are accessible from dataviewer.

  6183   Tue Jan 10 00:09:33 2012 kiwamuUpdateLSCspike hunting in REFL33

[John / Kiwamu]

 We tried to figure out what is causing spikes in the REFL33 signal, which is used to lock PRCL.

No useful information was obtained tonight and it is still under investigation.



 One thing preventing us from doing smooth measurements of the noise budget and the sensing matrix is some sharp spikes in the LSC error signals.

For example when we lock PRMI with REFL33 and AS55 fedback to PRCL and MICH respectively, both the REFL33 and AS55 signals show some spikes in time series.

Those spikes then bring the noise spectra higher than how they should be.

So for the reason, taking the noise budget doesn't give us much information about the interferometer rather than there are spikes.

Also the sensing matrix measurement has been suffered from those spikes, which excite the impulse responses of the low pass filters in the LOCKIN detection systems a lot.


(What we did)

 We looked into the actual analog signals to see if there are indeed spikes or not before they are acquired to the ADCs.

But we didn't find any corresponding spikes in the signals that are after the mixers.

It maybe because the signals we looked into didn't have high enough SNR because they were coming out from the monitor lemo outputs on the demod boards.

 Then we thought the spikes are from the whitening circuits, due to some kind of saturation.

We decreased the gain of the whitening filters by a factor of 10, but it didn't help and the spikes were still there.

  6184   Tue Jan 10 09:17:23 2012 steveUpdatePhotosstrawman's visiters
Attachment 1: P1080491.JPG
Attachment 2: P1080492.JPG
  6186   Wed Jan 11 21:35:33 2012 Max De JongUpdateGeneralProjector

I finished mounting the new projector. The projector and computer monitor now display information.

  6187   Thu Jan 12 03:05:02 2012 kiwamuUpdateLSCOSA installed in AS

[John / Valera / Kiwamu]

 We installed a new weapon, an optical spectrum analyzer in the AS port.

Like we used to do in the old days, two BNC cables were newly laid down and they bring the output of the OSA to the control room to monitor the spectrum with an oscilloscope.


(Some notes)

The photo diode of the OSA was replaced by a Thorlab PDA100A to amplify the signals.

The carrier peak is at about 6.9 V and the f1 and f2 sidebands peaks are at about 40 mV when the beam is in straight shot (everything is misaligned except ITMY and BS).

According to a rough calculation, those numbers correspond to a modulation depth of about 0.16 or so.

The depth agree with what Mirko measured before (#5519)


  6188   Thu Jan 12 07:44:21 2012 steveUpdateSUSsapphire wire standoff quote

On Tue, Dec 20, 2011 at 11:37 PM, Rana Adhikari wrote:

We are thinking of replacing a few metal parts in the suspension with sapphire/ruby. We want to replace the standoff (which is Al) with sapphire and also the top plate where the wire is clamped.

For the top, we should make a cutout for a little plate in the existing crossbar. In the cutout would go a little mounting plate. Then the clamping plate (which is now steel) we would also replace with a Sapphire one.

I don't think it matters whether its sapphire or ruby, just has to be very hard.

Can you please get some quotes on the parts?


Attachment 1: standoff.PDF
  6190   Thu Jan 12 10:11:59 2012 steveUpdatePEMoptical table top with 1" wall


3/4 " thick colored acrylic material will be used in this air tight design. Surgical tubing for o-ring. We may have to put an o-ring into the bottom to have it really air tight.

Feedtrouhs: www.roxtec.com

The top drawing is not ready. It will have handle and industrial grade L-handle lock pin to hold cover down. There will be 2  one inch od post in the midle of the table to hold the cover and lock  the ball pin.

I'm waiting for your inputs, so I can send this preliminary design out for quote.


 The present plan to go with clear cast acrylic plexiglass 1" thick side wall  and  two  clear  1/2 thick top cover.

The inside would be lined with light braun YAG safety window sheets 0.14"  VLT ~25%  OD 4 @ 532nm & OD 5 @ 1064nm


Attachment 1: 101122012atc.PDF
  6191   Thu Jan 12 11:08:23 2012 Leo SingerUpdatePEMFunky spectrum from STS-2

I am trying to stitch together spectra from seismometers and accelerometers to produce a ground motion spectrum from Hz to 100's of Hz.  I was able to retrieve data from two seismometers, GUR1 and STS_1, but not from any of the accelerometers.  The GUR1 spectrum is qualitatively similar to other plots that I have seen, but the STS_1 spectrum looks strange: the X axis spectrum is falling off as ~1/f, but the Y and Z spectra are pretty flat.  All three axes have a few lines that they may share in common and that they may share with GUR1.

See attached plot.

Attachment 1: spectrum.jpg
  6194   Thu Jan 12 23:19:56 2012 KojiUpdateSUSc1iscex is fine now

c1iscex is working as before and the optic is damped.

What I checked

1. I went to the X-end rack. I found the io-chassis was turned off.

2. I shutdown c1iscex, turned off, and turned on everything. Again, we did not have any signal from the ADC into c1scx model.

However, I found that c1x01 indicates healthy ADC signals.
This means that the connection between the IOP and the c1scx model was wrong ==> Simulated Plant

3. Burtrestored X'mas eve snapshot. This restored the gains and matrices as well as C1:SCX-SIM_SWITCH
which switches the input between the real ADCs and simulated plant.

4. The signals came back to c1scx.

  6195   Fri Jan 13 00:51:40 2012 Leo SingerUpdateStewart platformFrequency-dependent requirements for Stewart platform

Below are revised design parameters for the Stewart platform based on ground motion measurements.

The goal is that the actuators should be able to exceed ground motion by a healthy factor (say, two decades in amplitude) across a range from about .1 Hz to 500 Hz.  I would like to stitch together data from at least two seismometers, an accelerometer, and (if one is available) a microphone, but since today this week I was only able to retrieve data from one of the Guralps, I will use just that for now.

The spectra below, spanning GPS times 1010311450--1010321450, show the x, y, and z axes of one of the Guralps.  Since the Guralp's sensitivity cuts off at 50 Hz or so, I assumed that the ground velocity continues to fall as f-1, but eventually flattens at acoustic frequencies.  The black line shows a very coarse, visual, piecewise linear fit to these spectra.  The corner frequencies are at 0.1, 0.4, 10, 100, and 500 Hz.  From 0.1 to 0.4 Hz, the dependence is f-2, covering the upper edge of what I presume is the microseismic peak.  From 0.4 to 10 Hz, the fit is flat at 2x10-7 m/s/sqrt(Hz).  Then, the fit is f-1 up to 100 Hz.  Finally, the fit remains flat out to 500 Hz.


Outside this band of interest, I chose the velocity requirement based on practical considerations.  At high frequencies, the force requirement should go to zero, so the velocity requirement should go as f--2 or faster at high frequencies.  At low frequencies, the displacement requirement should be finite, so the velocity requirement should go as f or faster.

The figure below shows the velocity spectrum extended to DC and infinite frequency using these considerations, and the derived acceleration and displacement requirements.


As a starting point for the design of the platform and the selection of the actuators, let's assume a payload of ~12 kg.  Let's multiply this by 1.5 as a guess for the additional mass of the top platform itself, to make 18 kg.  For the acceleration, let's take the maximum value at any frequency for the acceleration requirement, ~6x10-5 m/s2, which occurs at 500 Hz.  From my previous investigations, I know that for the optimal Stewart platform geometry the actuator force requirement is (2+sqrt(3))/(3 sqrt(2))~0.88 of the net force requirement.  Finally, let's throw in as factor of 100 so that the platform beats ground motion by a factor of 100.  Altogether, the actuator force requirement, which is always of the same order of magnitude as the force requirement, is

(12)(1.5)(6x10-5)(0.88)(100) ~ 10 mN.

Next, the torque requirement.  According to <http://www.iris.edu/hq/instrumentation_meeting/files/pdfs/rotation_iris_igel.pdf>, for a plane shear wave traveling in a medium with phase velocity c, the acceleration a(x, t) is related to the angular rate W'(x, t) through

a(x, t) / W'(x, t) = -2 c.

This implies that |W''(f)| = |a(f)| pi f / c,

where W''(f) is the amplitude spectral density of the angular acceleration and a(f) of the transverse linear acceleration.  I assume that the medium is cement, which according to Wolfram Alpha has a shear modulus of mu = 2.2 GPa and about the density of water: rho ~ 1000 kg/m3.  The shear wave speed in concrete is c = sqrt(mu / rho) ~ 1500 m/s.

The maximum of the acceleration requirement graph is, again, 6x10-5 m/s2 at 500 Hz..  According to Janeen's SolidWorks drawing, the largest principal moment of inertia of the SOS is about 0.26 kg m2.  Including the same fudge factor of (1.5)(100), the net torque requirement is

(0.26) (1.5) (6x10-5) (100) pi (500) / (1500) N m ~ 2.5x10-3 N m.

The quotient of the torque and force requirements is about 0.25 m, so, using some of my previous results, the dimensions of the platform should be as follows:

radius of top plate = 0.25 m,

radius of bottom plate = 2 * 0.25 m = 0.5 m, and

plate separation in home position = sqrt(3) * 0.25 m = 0.43 m.


One last thing: perhaps the static load should be taken up directly by the piezos.  If this is the case, then we might rather take the force requirement as being

(10 m/s2)(1.5)(12 kg) = 180 N.

An actuator that can exert a dynamic force of 180 N would easily meet the ground motion requirements by a huge margin.  The dimensions of the platform could also be reduced.  The alternative, I suppose, would be for each piezo to be mechanically in parallel with some sort of passive component to take up some of the static load.

  6196   Fri Jan 13 16:16:05 2012 Leo SingerUpdateStewart platformFlexure type for leg joints

I had been thinking of using this flexure for the bearings for the leg joints, but I finally realized that it was not the right type of bearing.  The joints for the Stewart platform need to be free to both yaw and pitch, but this bearing actually constrains yaw (while leaving out-of-plane translation free).

  6197   Fri Jan 13 17:40:38 2012 ZachUpdateRF Systemfoam box and temp controller taken off of PSL table

I stole the foam EOM box and the temperature controller circuit from the PSL table so that I could continue with the RAM measurements here at the ATF.

That is all.

  6199   Sun Jan 15 10:28:02 2012 DenUpdateAdaptive Filteringdelays

We can account for delays in the oaf system by compensating it in the adaptive path of the filter. But using only this procedure is not enough. Parameters mu and tau should be chosen accurately:

w = (1 - tau) * w;

w += mu * dw / norm;

NLMS algorithm without considering delays works well for mode cleaner length and gur1 seismometer signals, significantly reducing MC_F  with parameters mu=1, tau=0. These parameters are considered because nlms algorithm should converge with the highest speed when mu=1. However, if the system has a delay so at time moment n:

error_signal [n] = desired_signal [n] - filter_output [n-delay];

then the adaptive filter diverges for the same parameters mu=1 and tau=0 even for delay=1. For that reason we make the same calculations with tau = 1e-4 and tau = 1e-2 without reducing mu conserving the adaptation rate and get the same result as nlms algorithm without delays. Next figure shows MC_F signal, error after applying e-nlms filter with tau=1e-4 and tau=1e-2. "e-" is added to show that  a small number (epsilon) is added to the norm of the signal in order to prevent the filter from diverging in the beginning of the process when the norm is not well-determined yet.


The test was done offline with the sampling frequency 2048 Hz, without downsampling and any filters. We can see that tau=1e-4 is still not enough, tau=1e-3 or tau=1e-2 is as good as nlms without delays, tau=1e-1 and high are also bad.

Correctly choosing tau we have some freedom for delay compensation in the adaptation path. This is important as we do not know exactly what is the delay in the real system. We can measure it approximately. In order to figure out the range of reasonable delay errors we make a test with delay = 1, but to the adaptation path we give delays from 0 to 10. It turns out that adaptation path delays greater then 5 make the filter diverge, delays in the range 0-3 produce a reasonable error. In the figure below errors with adaptation path delays = 1 (correct) and 3 are presented.


  6200   Sun Jan 15 11:40:30 2012 DenUpdateAdaptive Filteringdownsampling

Here for the downsampling process we use a low-pass Bessel digital filter of order 6, normalized cut-off frequency = 0.1. In the plot presented below we compare the results with downsampling ratio = 1, 2, 4.


We can see that increasing the downsampling ratio, we increase the error of the filter. Moreover, the error at some particular frequency f seems to depend on the ratio f/Fs, where Fs - sampling frequency (2048 Hz) devided by downsampling ratio. Error is the same for all curves below 1 Hz but then begins to increase as we increase the sownsampling ratio. In order to figure out what the problem is - mistake in the filter code, inaccurate upsample algorithm or this is NLMS particularity, I've changed sampling frequency in the chans/daq/C1PEM.ini and C1IOO.ini files from 2048 Hz to 512 Hz for corresponding channels. Now, we compare the error from the filter working with 2048 Hz frequency, downsampling ratio = 4, low-pass filter = Bessel of order 6, normalized cut-off = 0.1 and filter working with 512 Hz sampling frequency, without downsampling and with corresponding Bessel low-pass filter with normalized frequency 0.4.


MC_F measurement at 2048 Hz was done during the day, for that reason red curved is slightly higher then green in the resonance frequencies. But still we can see that these two cases are very much alike. For this reason, it seems that NLMS filter works better with higher sampling frequencies.

  6201   Sun Jan 15 12:18:00 2012 DenUpdateAdaptive Filteringrunning time

 In order to figure out what downsampling ratio we can take, we need to determine the running time of the fxlms_filter() function. If the filter length is equal to 5000, downsampling ratio is equal to 1, number of witness channels is 1 then with ordinary compilation without speed optimization one call runs for 0.054 ms (milli seconds). The test was done on the 3 GHz Intel processor. With speed optimization flags the situation is better

-O1 0.014 ms, -O3 0.012 ms

However, Alex said that speed optimization is not supported at RCG because it produce unstable execution time for some reason. However, by default the kernel should optimize for size -Os. With this flag the running time is also 0.012 ms. We should check if the front-end machine compilers indeed use -Os flag during the compilation and also play with speed optimization flags. Flags -O3 and -Os together might also give some speed improvement.

But for now we have time value = 0.012 ms as running time for 5000 coefficient filter, 1 witness channel and downsample ratio = 1. Now, we need to check how this time is scaled if we change the parameters.

5000 cofficients - 0.012 ms

10000 coefficients - 0.024 ms

15000 coefficients - 0.036 ms

20000 coefficients - 0.048 ms

We can see that filter length scaling is linear. Now we check downsampling ratio

ratio=1 - 0.048 ms

ratio=2 - 0.024 ms

ratio=4 - 0.012 ms

Running time on the dependance of downsample ratio is also linear as well as on the dependence of the number of witness channels and degrees of freedom. 

If we want to filter 8 DOF with approximately 10 witness channels for each DOF, then 5000 length filter will make 1 cycle for ~1 ms, that is good enough to make the downsample ratio equal to 4.

Things get a little bit complicated when the code is called for the first time. Some time is taken to initialize variables and check input data. As a result the running time of the first cycle is ~0.1 ms for 1 DOF that is ~10 times more then running time of an ordinary cycle. This effect takes place at this moment when one presses reset button in the c1oaf model - the filter becomes suspended for a while. To solve this problem the initialization should be divided by several (~10) parts.

  6202   Tue Jan 17 01:02:07 2012 kiwamuUpdateLSCglitch hunting in REFL RFPDs : strange

A very strange thing is going on.

The REFL11 and REFL55 demod signals show high frequency noise depending on how big signals go to the POS actuator of PRM.

This noise shows up even when the beam is single-bounced back from PRM ( the rest of the suspensions are misaligned) and it's very repeatable.

Any idea ?? Am I crazy ?? Is PRM making some fringes with some other optics ??




 The most annoying thing in the central part locking is glitches showing up in the LSC error signals (#6183).
The symptom is that when the motion in PRCL at 3 Hz becomes louder, somehow we get glitches in both the MICH and PRCL error signals.
In the frequency domain, those glitches are mostly contribute to a frequency band of about 30 - 100 Hz.
Last Thursday Koji and I locked the half PRM (PRMI with either ITMX or ITMY misaligned) to see if we still have the glitches in this simpler configuration.
Indeed there were the same kind of glitches --a loud 3 Hz motion triggers the glitches.
It was shown particularly in the REFL11 signal but not so much in the REFL33 while AS55 didn't show any glitches.
(Still glitches even in the single bounce beam)
   We were suspecting some kind of coupling from a beam jitter, so that the 3 Hz motion somehow brings the beam spot to a bad place somewhere in the REFL paths.
I misaligned all the suspensions except for PRM such that the beam directly bounces back from PRM and go to the REFL port.
Indeed there still were glitches in the REFL11 and REFL55 demod signals. It showed up once per 30 sec or so and pushes up the noise floor around 30 - 100 Hz.
There might be a little bit of glitches also in the REFL33, but the ADC noise floor and the expected glitch noise level were comparable and hence it was difficult to see the glitches in REFL33.

(Glitch is related to the PRM POS actuation)

 In the single-bounce configuration I started shaking the PIT and YAW motions of PRM at 3 Hz using the realtime LOCKIN oscillator to see if I can reproduce the glitches.
However no significant glitches were found in this test.
Then I started shaking the POS instead of the angular DOFs, and found that it causes the glitches.
At this point it didn't look like a glitch any more, it became more like a stationary noise.
 The attached screen shot is the noise spectrum of the REFL11_I.
The red curve is the one taken when I injected the 3 Hz excitation in POS by the LOCKIN oscillator.
The excitation is at 3 Hz with an amplitude of 1000 counts.
As a comparison I plotted the same spectrum when no excitation was injected and it is plotted in pink.


It seems there is a cut off frequency at 100 Hz.
This frequency depends on the amplitude of the excitation -- increasing the amplitude brings the cut off frequency higher.
This noise spectrum didn't change with and without the oplevs and local damping.

(Possible scenario)

A possible reason that I can think of right now is : PRM is interfering with some other optics for some reason.
But if it's true, why I didn't see any fringes in the AS demod signals in the half PRM configuration ?

Quote from #6183

 We tried to figure out what is causing spikes in the REFL33 signal, which is used to lock PRCL.

No useful information was obtained tonight and it is still under investigation.

  6203   Tue Jan 17 02:27:49 2012 kiwamuUpdateLSCfringe tests : all the suspensions are innocent

I did a quick test to check a hypothesis that PRM is interfering with some other optics in the single bounce configuration.

I shook all the suspensions (except the MC mirrors) at 3 Hz in POS, PIT and YAW with an amplitude of 1000 counts.

No effects were found in the REFL demod signals.

So it is NOT a fringe effect caused by the other suspended mirrors.

Quote from #6202

The REFL11 and REFL55 demod signals show high frequency noise depending on how big signals go to the POS actuator of PRM.

Is PRM making some fringes with some other optics ??   


  6204   Tue Jan 17 02:44:59 2012 kiwamuUpdateCDSawg not working

AWG is not working. This needs to be fixed.

I could set the channel and the parameters in the AWGGUI screen, but it never inject signals to the realtime system.

  6206   Tue Jan 17 13:47:40 2012 kiwamuUpdateLSCdirty steering mirror in the REFL path

 Last night I found that there were many dust particles on the second steering mirror in the REFL path on the AS table.

Looking at it through an IR viewer, I saw the REFL beam hitting one of the biggest dust particles on that mirror.

This dust particle maybe causing the glitches or maybe not.

Anyway because it's always better to have clean mirrors, I will wipe the steering mirror in this evening and check the presence of the glitches again.

Quote from #6202

The REFL11 and REFL55 demod signals show high frequency noise depending on how big signals go to the POS actuator of PRM.

Is PRM making some fringes with some other optics ??

  6207   Tue Jan 17 16:09:20 2012 kiwamuUpdateCDSawg not working on the c1sus machine

Actually awg works fine without any problems when the excitation channels belong to the c1lsc machine.

It seems that the awg doesn't inject signals on the channels of the c1sus machine, for example C1:SUS-BS_LSC_EXC and so on.

Quote from #6204

AWG is not working. This needs to be fixed.

  6208   Tue Jan 17 19:07:47 2012 ranaUpdateLSCglitch hunting in REFL RFPDs : strange

 Another possibility is that there is some beam clipping of the REFL beam before it gets to the PD. Then there could be a partial reflection from that creating a spurious interference. Then it would only show the fringe wrapping if you excite the scatterer or the PRM.

  6209   Wed Jan 18 12:36:26 2012 kiwamuUpdateLSCwiped a steering mirror on the REFL path

I wiped both surfaces of the REFL second steering mirror.

However no improvements. The glitches still remain.


(Pic.1 before wiping, Pic.2 after wiping)


Quote from #6206

 Last night I found that there were many dust particles on the second steering mirror in the REFL path on the AS table.

  6210   Wed Jan 18 12:38:44 2012 steveUpdatePEMAcrylic plexiglass transmittance


Transparent- clear plexyglass from tree different sources were measured in 1064 and 532 nm light.

Samples: a, clear Acrylic-GP 0F00  from Ridout Plastics in thickness 0.7" ,  made by  Evonic Ind

                   b, clear cast acrylic from Mc Master Carr in thickness 0.94" , likely  made by Reynolds-Cast

                   c, clear cell cast  plexyglass from Delvie's Plastics - Utah in thickness  0.93" , maker not known

PMC reflected beam was used at 92 mW and 6 mm diameter at incident angle 0-25 degrees.

All tree samples agreed on Transmittance of ~90%, Reflectivity ~3-4% and calculated Adsorption ~6-7%


Transparent Colored Acrylic orange-amber #2422   from www.eplastics.com in 0.12" thickness gave  T 96%,  R 1% and  Ab-calc ~3% in the beam of 92 mW 1064  nm at 6 mm diameter.


Transparent , colored   Light Red #26 thin film filter   policarbonate-polyester   0.002" thick   from Roscolux measured T 81% of 115 mW 1064 nm


Now I changed power meter FieldMate to Ophir and the light source to laser pointer 2.2 mW  ~532 nm  with 1-2 mm beam diameter.

Orange - amber #2422  sample, 0.12" thick,  T 1% ,  R 4%  and  Ab-calculated ~95%, estimated visibility  ~50% It does cut out the green at this low power level.

 Light red #26  sample  T 0.5%  at 2.5 mW of 532 nm . The transparent green is not visible.  The softening point of this sandwiched polycarbonate-polyecter filter is 160C. Estimated VLT of this film ~40%



Clear and colored acrylics'  @ 1064 nm  transmittance 90% or higher  regardless of thickness. Softenig point 115 degrees C

Colored acrylic and colored policarbonate film are adsorbing the low power green and they  transmit the 1064nm beam.

Options to consider: a, acrylic laser safety shield liner of  0.125" thick inside of 1" thick clear acrylic  box, OD +5 @1064 and OD +4 @ 532nm,  amber color VLT 27%,  150$/sqft

                                      b, thin metal liner for 1" wall acrylic box, VLT 0%



Attachment 2: roscogel_red#26_film.pdf
  6211   Wed Jan 18 14:28:36 2012 kiwamuUpdateLSCestimation of optical length between PRM and scattering object

Assuming that PRM is interfering with some other optics, I have estimated the optical distance between PRM and an object that interferes with PRM.

The optical distance is estimated to be 9.5 +/- 0.5 m.

If we believe this number the object is most likely outside of the vacuum chambers.


 (The measurement)

  In order to estimate the optical length between PRM and a scattering body, I swept the frequency of the main laser by actuating on the MC length.
With the sweep, the laser frequency go across some fringes and basically it allows us to estimate the FSR of a very low finesse cavity formed by PRM and the scattering body.
Therefore we get the the optical distance based on the resultant FSR.
  The measurement goes as follows:
  1.  Preparation : calibration of the MC2 actuator as a frequency actuator (for more details, see the next section)
  2.  Set the interferometer to the single-bounce configuration such that the beam directly is reflected back from PRM
  3.  Take spectra of REFL11_I without driving any optics. This spectra tells us how quiet the noise normally is.
  4.  Drive MC2_POS at 10 Hz with an amplitude of 10000 counts so that we can see the high frequency up conversion noise
    • The frequency was chosen such that the excitation is out of the local damping bands
    • The amplitude was chosen to be as big as possible until the MC unlocked
    • With this drive, the laser frequency should change by 20 MHz peak-peak at 10 Hz.
  5.  Record the noisy spectrum when the MC2_POS was driven.
  6.  Drive PRM instead of MC2 at 10 Hz.
    • Adjust the amplitude of the excitation such that the cut-off frequency of the up conversion noise matches with that of the MC2 driven case.
    • The amplitude was found to be 1700 - 2000 counts, this uncertainty is currently limiting the precision of the optical distance estimation.
    • With this amount of the drive, PRM moves by 0.8 um peak-peak at 10Hz.
  7. Estimate the optical length based on the amount of the drives for PRM and MC2.
    • Estimate the FSR using the following relation df/FSR = dx/ (lambda/2). => FSR = 17 MHz
    • Since FSR = c/ (2L),  L = c/(2 FSR) = 9.5 m or so



(Calibration of the MC2 actuator)

 To do the measurement described above, the MC2 actuator must be calibrated in terms of a frequency actuator.
I did the same old technique (#4721): lock a cavity, adjust the UGF as low as possible, and shake an actuator of interest.
This time I used the half-PRM (PRM + ITMY) for this measurement.
The actuator responses are calibrated from that of displacement to frequency by using df/f = dx/L and assumed that L = 6.760 (#4585).
Also the PRM actuator was measured such that we can use this as a reference since we already know the response in displacement (#5637).
 The attached plot below is the actual responses that I measured yesterday. The y-axis is calibrated to Hz/counts.




Quote from #6202

Is PRM making some fringes with some other optics ??

  6212   Wed Jan 18 16:31:10 2012 kiwamuUpdateLSCestimation of optical length between PRM and scattering object

I searched for a scattering body in the REFL path.

According to the result the REFL path on the AS table is innocent.


The idea of the search method is given as follows:

  •   Put a 1/10 ND attenuator at the origin of the REFL path on the AS table.
  •   Of course this reduces the signal level by the same factor of 10 in the REFL11_I demod signal.
  •   If the scattering body is in the REFL path the up conversion noise will be smaller by a factor of 100 because the scattered light go across the attenuator twice.


 The attached plot below is the spectra of REFL11 with the 1/10 attenuator at the origin of the REFL path when the beam is single-bounced from PRM.
In the measurement PRM_POS was driven at 10 Hz with an amplitude of 1700 all the time. This is exactly the same situation as that explained in the previous elog entry (#6211).
You can see that the up conversion noise level also decreased by the same factor of 10, which suggests there are no scattering object in the REFL path.
Note that the data with the attenuator in place is intentionally scaled by multiplying a factor of 10 for comparison.

Quote from #6211

Assuming that PRM is interfering with some other optics, I have estimated the optical distance between PRM and an object that interferes with PRM.

The optical distance is estimated to be 9.5 +/- 0.5 m.

If we believe this number the object is most likely outside of the vacuum chambers.


  6213   Thu Jan 19 23:34:52 2012 kiwamuUpdateIOOPMC realignment and HEPA

I realigned the incident beam to PMC at 23:30. The transmitted light went up from 0.78 to 0.83.

Also I decreased the HEPA level down to 20 % for the night time locking.

  6214   Fri Jan 20 15:59:02 2012 kiwamuUpdateGreen LockingY arm ALS noige budget

One of my goals in this week is : measurement of the current best ALS noise budget.

Last night I took a new noise spectra of the Y arm ALS, which is shown in the attached figure below.

The displacement of the arm cavity observed from the IR PDH is at 66 pm in rms. In the measurement the arm length was stabilized with the ALS technique.




  6215   Fri Jan 20 16:24:50 2012 kiwamuUpdateGreen LockingY arm ALS : time series

Here is a new time series plot showing how stably ALS can control the arm length.

In the middle of the plot the cavity length was held at the resonance point for ~ 2 min. and then it passed through the resonance point to show the full shape of the PDH signal.

Apparently the PDH signal is now quieter than before (#6133)


Quote from #6214

One of my goals in this week is : measurement of the current best ALS noise budget.


  6216   Fri Jan 20 17:05:59 2012 ranaUpdateGreen LockingY arm ALS : time series

                        One of my goals this week is to get people to make plots with physical units:

That ALS plot would be 5x cooler if the POY11 signal could be in meters instead of counts or cubits.

  6217   Mon Jan 23 15:43:47 2012 JenneUpdateIOOPMC realignment


I realigned the incident beam to PMC at 23:30. The transmitted light went up from 0.78 to 0.83.

 Do we have PSL pos and ang QPD trends?  We should start watching them, because the PMC drifted back down to 0.76 transmission, ~3.5 days after Kiwamu realigned it (his elog is from last Thurs).  Not so awesome.

I walked through the control room just now and found both PMC and MC unlocked.  They're both locked now, but with PMC transmission 0.76, MC transmission ~24,500.

  6218   Mon Jan 23 23:12:00 2012 kiwamuUpdateIOOPMC realignment

I have realigned the beam pointing to PMC. The transmitted light increased from 0.74 to 0.83.

The misalignment was mainly in pitch.

  6220   Tue Jan 24 18:11:13 2012 kiwamuUpdateGreen LockingY arm ALS noise budget

I did some more stuff for the Y arm ALS and updated the noise budget:

After the works, the rms displacement improved a little bit, so it is now at 24 pm in rms.

Though, it turned out that the MFD's ADC is now limiting the noise in a frequency band of 200 mHz - 5 Hz.

So tonight I will increase the gain of the whitening filter to push down the ADC noise more.




(What I did)

 + added the DAC noise and comparator noise based on measurements.

 + redesigned the servo filter shape to suppress the seismic noise below 10 Hz.

 The attached plot below shows the newly designed open loop transfer function together with the old one for a comparison.

UGF is at 120 Hz and the phase margin is about 27 deg.


  • FM7 = resonant gain (17)
  • FM6 = resonant gain (3)
  • FM5 = zero(1) * pole(500)
  • FM4 = pole(1) * zero(40.) * 40.
  • FM3 = pole(1) * zero(40.) * 40.
  • FM2 = pole(0.001)*zero(1)*1000.
  6221   Wed Jan 25 02:59:46 2012 kiwamuUpdateGreen LockingY arm ALS noise budget

Surprisingly increasing the gain of the whitening filter didn't improve the noise curve.

It suggests that the ADC noise is not the limiting factor below 10 Hz.

Quote from #6220

Though, it turned out that the MFD's ADC is now limiting the noise in a frequency band of 200 mHz - 5 Hz.

So tonight I will increase the gain of the whitening filter to push down the ADC noise more.


  6223   Wed Jan 25 17:32:03 2012 steveUpdateGreen Lockinggeen pointing into y arm is misaligned

I  placed an other Y2-LW-1-2050-UV-45P/AR steering mirror into the beam path of the green beam launching in order to avoid the ~30 degrees use of the 45 degrees mirror. The job is not finished.

  6224   Thu Jan 26 05:40:10 2012 kiwamuUpdateLSCglitch in the analog demodulated signals

Indeed the glitches show up in the analog demodulated signals. So it is not an issue of the digital processing.

With an oscilloscope I looked at the I/Q monitor outputs of the LSC demodulators, including REFL11, REFL33, REFL55, POY11, AS55 while keep locking the carrier-resonant PRMI.

I saw some glitches in REFL11, REFL55 and AS55. But I didn't see any obvious glitches in REFL33 and PO11 because the SNR of those signals weren't good enough.


(some example glitches)

The attached plot below is an example shot of the actual signals when the carrier resonant PRMI was locked.

The first upper row is the spectrogram of REFL11_I, REFL55_I, REFL33_I and AS55_Q in linear-linear scale.

The second row shows the actual time series of those data in unit of counts.

The bottom row is for some DC signals, including REFLDC, ASDC and POYDC.



You can see that there are so many glitches in the actual time series of the demod signals (actually I picked up the worst time chunk).

It seems that  most of the glitches in REFL11, REFL33 and AS55  coincide.

The typical time scale of the glitches was about 20 msec or so.

Note that the PRMI was locked by REFL33 and AS55 as usual.

  6225   Thu Jan 26 06:09:52 2012 kiwamuUpdateGreen Lockingnoisy AS55

During the Y arm ALS I found that the noise of the AS55 demod signal was worse than that of POY11 in terms of the Y arm displacement.

There is a bump from 500 mHz to 100 Hz in the AS55 signal while POY11 didn't show such a structure in the spectrum.


The plot below is the noise spectra of the Y arm ALS. The arm length was stabilized by using the green beat-note fedback to ETMY.

In this measurement, POY11 and AS55 were served as out-of-loop sensors, and they were supposed to show the same noise spectra.

In the plot It is obvious that the AS55 curve is louder than the POY curve.


  6226   Thu Jan 26 08:36:38 2012 steveUpdateSAFETYevacuation drill

It started with fire alarm test yesterday at 14:50 All alarms are  functioning VERY loud and their flashers are bright. Evacuation drill followed. We assembled at north west corner of the 40m building and counted 6 heads.

Nobody was left sleeping inside. Bob carried the success report of the drill to PMA office immediately.

ELOG V3.1.3-