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.

I have been looking at the swings in the RAMmon channels since the heater was reengaged, to compare them to the data from beforehand (with and without the foam box). With the large grains of salt that I will list after, it appears that the EOM temperature controller does in fact reduce the amplitude of the swings by a measurable factor.

Salt:

1. The reason I have not included any plots here is because the data suck. What we should ideally have is a continuous stream of RAMmon signals split into three chunks: 1) no foam, no heat, 2) foam, no heat, and 3) foam and heat. Instead, we have pieces of each kind of data on different days, before and after the MC has been realigned, some in old channels and some in new so that the calibration is different, etc. This piecemeal shit will not do.
2. I realized that the LF boost was not engaged on the heater when I turned it on most recently. For this reason, the EOM temperature has not been stabilized as well as it might have been on diurnal timescales, and so with the boost it could be that the noise reduction is greater. For posterity, the DC suppression level is ~20x without the boost.

It seems impractical to try and rope off essentially 3 straight days where nothign major can be done to the IFO just to take RAM data. Instead, I think we should figure out a way to mimic the diurnal temperature swings on ~hour timescales. The EOM can temperature follows PSL-FSS_RMTEMP almost exactly and with a very short delay, so we can probably even accomplish this by stepping the lab A/C temperature. If this won't work, we can use an incandescent lamp or something similar to heat up the area around the EOM by a noticeable amount.

I'll try to come up with a good way to do this so that we can get some reliable data...

Online filter diverges. I did offline simulations with current c-code. Offline filter also diverges, even in the simplest case 

witness = randn(1e6, 1); target = witness + 0.01*randn(1e6, 1);

I tried to create a new implementation of FXLMS algorithm as a c code. Then with this c code I did offline filtering with MCL and GUR signals and compared the error signals depending on the length of the filter.

One can see the code at the svn

adaptOnline - start here and choose algorithm

adaptive_filtering - Matlab implementation of AF

current_version.c - current version of the Filter (Matt's)

fxlms_filter.c - new version of the FXLMS filter

oaf.c - agent between Matlab and C (edited Matt's file)

Data samples can be found at nodus /users/den/wiener_filtering/data

Another hysteresis test has begun at 1:50 PT, Dec/19.

It will finish after 3 or 4 hours. During the measurement the PSL mechanical shutter will be kept closed.

I have recentered the oplev beams, including BS, ITMs and ETMs.

The measurement finished at ~ 21:50 PT.

Here are the latest plots that I have obtained from the Friday night:

    Time Series   

The residual motion in the arm displacements reached 70 pm in rms.

Koji has modified the script for the hysteresis measurement.

A new test started from 16:05 PT, Dec 18th and takes a couple of hours to finish the measurement.

Do not touch the suspensions until further notice.

The test was from: 2011-12-17 09:48 to 11:49 (UTC).
This corresponds to the period from 2011-12-17 01:48 to 3:49 (PST).

ZK: Thanks

Do you guys have timestamps for when you started/ended the test? I have been trying to take some long-term RAM data but keep getting foiled by stuff (this test, RTS upgrade, switching of RAMmon channels, etc.)

The hysteresis test has been aborted.

All of the suspensions have accumulated unexpectedly big DC biases of about 5 from their nominal points.

[Koji Kiwamu]

We wonder if the flakiness of MC2 comes from the suspension or not.

To test it, we are shaking all of the suspension biases +/-1.0 with a script.

The script is here:
/users/koji/111216/SUS_hysteresis.sh

For this test, we closed the mechanical shutter before the MC.

Also some amount of misalignment is anticipated.
Don't be surprised if you see nothing is working when you come to the lab in the weekend.

Quote from #6126

As shown in the noise budget below, the 60 Hz line noise currently dominates the arm displacement.

 The 60 Hz line noise has gone away.

As shown in the noise budget below, the 60 Hz line noise currently dominates the arm displacement.

       About Noise Budget       

Unfortunately, after working on it all day, I had to abort the upgrade and revert the system back to yesterday's state.

I think I got most of the upgrade working, but for some reason I could never get the new models to talk to the framebuilder.  Unfortunately, since the upgrade procedure isn't document anywhere, it was really a fly by the seat of my pants thing.  I got some help from Joe, which got me through one road block, but I ultimately got stumped.

I'll try to post a longer log later about what exactly I went through.

In any event, the system is back to the state is was in yesterday, and everything seems to be working.

I'm now in the middle of upgrading the RTS to version 2.4.

All RTS systems will be down until futher notice...

 Yeah, I looked and saw that it's a semiconductor mixer, so it doesn't have to be as perfect. 

Everything is plugged in now to the new demod board.  More details soonly...

The I & Q outs are plugged into whitening filter #3, channels 5-8.  11MHz I = chan 5, 11MHz Q = chan 6, 55MHz I = chan 7, 55MHz Q = chan 8.  These channels are probably already recorded, but I haven't checked yet.  Hopefully I'll have time tonight after I pack for my trip.  But Zach, can you look into it tomorrow just to check??  Backup plan is to just go back to using the AS11 and POP55 boards and channels if the new board isn't doing what it's supposed to.

I disconnected the 3rd and 4th channels of the demod box since they were drawing unnecessary current, and making the box hot.  Now the box is just warmish.

Actually, the LO inputs to the IQ boards have AP1053 (Cougar) amps on them. These are 10 dB amps and so putting 10 dBm in puts us on the very maximum of the LO range at 20 dBm.

I think the distribution box levels are fine. 

I'm not sure I agree with your conversions, BUT:

The IQ boards use a PE4140, fancy MOSFET array as the mixer, and according to Peregrine (manufacturer), they can be operated with 0-20 dBm LO drive. I'm not recommending we drive them at 0 dBm, but perhaps the numbers you mentioned are OK.

The existingly used used Pasternack Enterprices RG58 C/U cable lenght ~ 140 ft and the specs are here at Atm1

Atm2 The performance grade RG58-P coaxial cable specs.

The Rich demod box wants 10dBm for the local oscillator inputs, so I measured the values that we have coming out of the distribution box.  I'm using the "Spare 55MHz" and the "POP11" outputs, both of which had terminators so were not in use. 

The 55MHz had ~600mV peak, so between 5 and 6 dBm. 

The 11MHz had ~800mV peak, so about 8 dBm.

This is not enough dBm for either.  Going in search of RF amplifiers now...

[Kiwamu Koji]

To check if the MC alignment is OK or not, we tried to lock the Y-arm.

Once the alignment of Y-arm was restored, we saw the resonant peak of ~0.2 in TRY.
After a small tweak of PZT2, TRY has got improved up to 0.7.

Kiwamu made a small tweak on the problematic PZT1, then the full (1.0) TRY was recovered.

Thus we concluded the current MC alignment is good enough.

I made a test installation of ligo_viewer in /users/volodya/ligo_viewer-0.5.0c . It runs on pianosa (the Ubuntu machine) and needs Tcl/Tk 8.5.

To try it out run the following command on pianosa:

cd /users/volodya/ligo_viewer-0.5.0c/

./ligo_viewer.no_install

Press "CONNECT" to connect to the NDS server and explore. There are slides describing ligo_viewer at http://volodya-project.sourceforge.net/Ligo_viewer.pdf

Installation notes:

Use /users/volodya/ligo_viewer-0.5.0c.tgz or later version - it has been updated to work with 64 bit machines.

Make sure Tcl and Tk development packages are installed. You can find required packages by running

apt-file search tclConfig.sh

apt-file search tkConfig.sh

If apt-file returns empty output run apt-file update

Unpack ligo_viewer-0.5.0c.tgz, change into the created directory.

Run the following command to configure:

export CFLAGS=-I/usr/include/tcl8.5
./configure --with-tcl=/usr/lib/tcl8.5/ --with-tk=/usr/lib/tk8.5/

This works on Ubuntu machines. --with-tcl and --with-tk should point to the directories containing tclConfig.sh and tkConfig.sh correspondingly.

Run "make".

You can test the compilation with ./ligo_viewer.no_install

If everything works install with make install

If Tcl/Tk 8.5 is unavailable it should work with Tcl/Tk 8.3 or 8.4

I reengaged the heater this morning, to compare it with the free-wafting and passive box-covered data. In order to make the loop stable, I had to reduce the gain of the AD620 by 10. I have increased the TEMP_MON preamp gain by 10, so the calibration should still be ~3.5 V/K into the ADC (and in DV).

Below is a screenshot showing that the RAMmon signals are pushed to some (nonzero) value, and it appears that they stay there despite the changing PSL table temperature as measured by FSS_RMTEMP. My post from last week shows that without the heater servo the temperature of the EOM can follows RMTEMP almost exactly. So, it seems like the heater is working well at low frequencies, modulo sensor noise, which ought to be low for the thermistor. Since several things (MC, etc.) have changed since out baseline data, it migth be prudent to let this sit for a little while and then disconnect the heater to see what happens.

~11PM I came to the 40m and found the MC is repeating "LOCK->WFS ON->UNLOCK" sequence for ~2hours.

I checked the WFS spots on the QPDs and aligned them. No luck. I suspected the clipping of the beam in the chamber.

After I checked the trends of MC SUS OSEM values and IPPOS, I concluded that the input beam was aligned to somewhat misaligned MC.

The most noticable thing was that IPPOS (X, Y) indicated about (-0.5, 0) although the recent trend shows (-1, -0.5) is nominal.
In fact, the beam was about dropping from the diode. In addition, I found that the MC2 suspension showed a jump in the morning at around 8.30AM.|
This is consistent with what Jenne described.

This was a difficult situation as everything was moved.
I used the OSEM values to come back to the previous alignment of the suspensions, and started touching Zig-Zag before the MC.
After the alignment I ended up more clipping of the MC REFL. Also the spot on the IPPOS QPD was more dropping.

So, I have empirically used MC3 to misalign in Yaw to have better spot position on IPPOS. Then, the Zig Zag was aligned.
Then the spot on MC2 was adjusted while MCTRANS was kept maximized.

This helped the things back in the normal state.

Now the WFS servo is happily controlling the alignment.
MC REFL is 4.8 and 0.47 for unlocked and locked. (MCREFL_UNLOCK was 4.6 before my touch)
MCTRANS is 27000, which is close to the nominal.
IPPOS total, x, and y are 0.36, -0.97, and -0.47, respectively. They are about the nominal.

~1AM done

HOWEVER, we still don't know the position of the spot on MC1/MC3, and ITMY and ETMY.
I should consult with Kiwamu to check the spot positions tomorrow.

General lessons:
- If you find any reduction of MC transmission, check the suspensions to see if there is any slip.
- Before touching the input optics to recover the MC alignment, we should think what was moved.
- Before touching EOM alignment you must check the MC alignment WITHOUT WFS, so that you can recover the misalignment of EOM by the Zig-Zag steering.
- WFS is sensitive to clipping of the beam.
- We need a nifty indicator to tell how the MC transmitted beam is good.

 Of course, looking at the MC transmission os the important thing, but I wonder if maybe we should also monitor the beam before it goes into the MC just to see if its the fault of the MC-WFS or not. In the bad old MZ days, I remember that the MC mirror alignment would drastically change the post-MC RAM.

It requires another PD/demod set, but may be illuminating in the end. 

Also, can someone please add some channels to EPICS which calibrate the RAM channels into RAM units?

The MC coupling had become re-shittified. As we need transmitted MC light for the RAMmon, I realigned the input beam to the MC. (Jenne said that the MC mode itself should be well aligned, so I just used the zigzag on the PSL). MC_REFL is now ~0.5-0.6.

This happens on occasion, and I have reported it to the CDS guys.  Something apparently causes the framebuilder to crash, but I haven't figured out what it is yet.  I doubt this particular instance had anything to do with remote futzing.

Now we've got another day of data, with the foam box on for the last 24hrs.

First plot is a 5 day trend so you can see that the RAM has gotten a little bit smaller, as has the temperature drift, but not by a whole lot.

Second plot is the last 19 hours (so excluding much of the time while I was realigning beams on the PSL table yesterday), to zoom in on just the time when the foam box was installed.

After lunch Zach and I are going to engage the heater to temperature stabilize the system, to see how that affects things.

In other news, the MC looks like it was fine for a good long time, and ~3 hours ago it went bad.  The mode that's flashing is really bad in both pitch and yaw.  I don't know what happened, but something is not so awesome. Edit: Steve said that he opened the PSL table at some point this morning to look around but not touch, and also it's Janitor Day, and Kevin comes in around 8ish. That doesn't mean I know the actual cause, but those are the only things that happened in the IFO room this morning that anyone is aware of.

 Why did you place Matt's code inside the simulink library and use the same library for all DOFs? I think this won't work out. Inside the .c code there are static variables. If all DOF use the same ADAPT_XFCODE() function, it means that they all mess there signals and coefficients with each other! Or the RCD during the compilation creates a copy of the function with the name of a library name in front? For example, ADAPT_MCL_ADAPT_XFCODE(). But then in the RCG manual it is claimed to name the .c file the same.

This problem can be fixed by creating .c files with proper names for each DOF. But here a memory question may arise. For 1 DOF we now have 28 witness channel. If we have a several minute filter, we use 28 * 10⁴(filter length) * 3 (FIR coefficients, adapt input, corr input) * 8 (number of bytes in 1 double)  = 6.7 Mb / DoF. For 8 DOF we'll allocate ~55 Mb of memory in the kernel. The c1lsc cache size is 6 Mb per cpu. So we are definitely out of cache and it will take some time for a processor to communicate with ram. I wonder if it is OKEY for us to allocate this amount of memory as static arrays inside the kernel.

Now we use 6.7 Mb of memory because it seems to be a mistake with placing the same function for all DOF and we actually allocate for 1.

EOM was aligned to minimize the 11 and 55 MHz peaks in the RAMmon PD the other day (elog 6089), and was left with just the temperature sensor attached, no heater, no foam box.

Here is a 4 day trend:

I don't have a whole lot to say about this, other than there's a lot of stuff going on.  The craziness at the end is me realigning the PMC and MC since, as you can see, MC trans was way down.  The foam box was put on earlier today (elog 6104), so we'll see how that changes things over night.

Dataviewer couldn't connect to the framebuilder, so I checked the CDS status screen, and all the fb-related things on each model went white, then red, then computer-by-computer they came back green.  Now dataviewer works again.  Is someone secretly doing shit while not in the lab???  Not cool man!

PMC trans was only ~0.79, where it should be ~0.84 something.  The MC was also not stellar. 

I aligned the beam to the PMC, and am now getting PMC trans 0.837 .

Then I aligned the PSL zigzag to the MC, and got MC Refl down to ~0.6 . 

I then aligned the WFS to the unlocked MC, and the MC Trans QPD to the locked MC.

Things seem good.  MC axis is still in a good place, since we get good michelson fringes at the AS port.

I have restarted the daqd process at 1:01 PM since I have added some new ALS's daq channels.

At the suggestion of Rana and Koji, I have worked out some design parameters for a Stewart platform to be used as a vibration isolation device or as a platform for characterization of suspensions.  I have made some initial guesses about the following design requirements:

• linear travel: 40 microns peak to peak (based on SOS design requirements in LIGO-T950011)
• angular travel: 3 mrad peak to peak (based on SOS design requirements in LIGO-T950011)
• payload mass: 5 kg (wild guess of mass of loaded SOS)
• payload moment of inertia: 0.01 kg m^2 (wild guess)
• bandwidth: 500 Hz (suggestion of Rana and Koji: ~kHz)

From these assumptions, I have worked out:

• peak actuator force: 0.88 kN
• minimum radius of top platform: 15 cm
• minimum radius of bottom platform: 30 cm
• minimum height: 26 cm

The combination of high force, high speed, and ~micron travel limits seems to point to piezoelectric actuators.  PI's model P-225.80 would meet the peak push-pull force requirement, but I have not yet determined if it would meet the bandwidth requirement.  Apparently, typical piezoelectric actuators can exert a greater push force than pull force; wonder if one could use an actuator with a smaller force range than the P-225.80 if the actuator is biased by compression.  (Is this what is meant by a "preloaded" actuator?) 

I have attached a PDF explaining how I worked out the actuator force and platform dimensions.  (I'll try to dice up this PDF and put the contents in the Wiki.)  I also have a plant model in MATLAB with which I have been playing around with control schemes, but I don't think that this is ready to show yet.

Here are some tasks that still remain to be done for this preliminary case study:

• select sensing technologies: integrated linear encoders and/or strain meters, inertial sensing, optical levers, etc.
• study joints: Koji and Rana suggest flexures; I need to propose the joint geometry and material
• study internal modes of the platforms and actuators themselves
• build noise budget

I'd like to ask for input principally on:

• appropriateness of my design assumptions
• piezo actuators currently in use in the lab

 Edit: I also added a Mathematica notebook with the inverse kinematics (mapping from platform state to leg lengths) of the platform. 

Foam house installed on EOM a few min ago.  We'll leave it until ~tomorrow, then try out the heater loop.

• The top name of the channels has been changed from GCV to ALS      
  => Although the model name itself is still C1GCV to keep the current relations between other computers.

• I and Q signals on each sensor.
• LOCKIN modules to detect the sign of the error signals by shaking suspensions.
• Offset adjusters, which are combination of a controllable epics value and a low pass filter, to allow a smooth length scan.
• Input matrix. This branches the input signal to the DOFs as well as the LOCKIN modules.
• Output matrix to allow some combination of actuation (e.g. DARM, CARM, MCL, etc.,)
• Output switch to enable/disable any feedbacks to the suspensions
• Output filters before the suspensions. These filters will be usually flat, but enable us to inject some signals and enable some limiters.
   
  Here is the latest medm screen for the modified realtime controller.
  It gives you the idea of how the latest model works.

Status update of the Y arm green lock:

  + Recent goal : automation of the single arm green lock

(Things done)

• Implementation of some realtime LOCKIN modules to detect the sign of the error signals.
• Modification of the realtime control model to accommodate the I/Q MFD signals, which will be available in the near future. (Of course the model file in the svn has been also updated)
• Update of the medm screens.
• Scripting of the auto-lock has been 30 % done.
• Succeeded in automation of closing the ALS loop. (I have tried several times and no failure was observed so far)

(Things to be done)

• Scripting a routine to detect the sign of the fine sensor signals.
• Development of a clever length scan algorhythm.
• Scripting handing off routines.
• Implementation of some lock-success binary bits to define the ALS state.
• Implementation of fail-safes.

D0902745-v5 (probably the AP1053's):

[Jenne, Den]

AA filters for witness channels are added to the oaf model. It is working now and the number of memory used is not critical.  NO SYNC is not present any more.

Those asymmetric currents are same as what I saw with the table top +/-18V supply. If you really don't like it, there could be an option to disconnect CH3/4 in the box.

In any case, this could be a good long-run test of the demod box, couldn't it?

 Kiwamu and I discussed, and looking at the AS camera with the PRM and SRM misaligned, but MCWFS engaged, things look good.  This means that it's probably the MC that has drifted, and we want to align the MC back to the PSL beam.

I checked the power regulators on the Rich demod box (according to the schematic, D1000217).  The positive one is LM2941CT, and the negative one is LM2991T.  Both accept input voltage up to +26V or -26V respectively.  So my use of +\- 24V to be regulated down to +\- 15V isn't too crazy.  It's a little crazy, but not too crazy.  They recommend having only a 3V difference between the input and output voltages.  We don't have any 18V or 20V power supplies in the regular LSC power supply rack, so Rana suggested using the 24's. 

When I plug in and turn on the Rich box, the current on the +24V power supply goes up by about 0.8A, and the -24V supply goes up by about 0.3A.  That seems like kind of a lot.  Is that too much?  Do I need to find a better plan that involves +\- 18V?  Thoughts?

For now, the Rich box is off, just in case.

I was looking at the trends from the RAMmon, since I did the EOM alignment yesterday, and wanted to compare them to the MC trans, just to make sure the MC was locked during the times I'm examining.  I was dismayed to discover that the MC has lost its oomph, starting around 11:30 this morning.  Den was the only person in the lab to my knowledge at that time, and he claims that he didn't touch the MC until well after lunch.  As you can see from the 8 hour trend attached, we went from normal ~26000 counts to ~15000, and we're slowly decaying from there.

MC refl looks pretty bad on the camera, particularly in YAW.  Investigations are beginning now....

Edit, ~10min later...  I enabled the WFS (I don't know why they were off...when the MC fell out of lock and relocked itself, the WFS didn't come on), and things went basically back to how they should be.  However, the sans-WFS alignment is still totally crappy, so the PSL beam probably needs to be aligned to the MC.  I don't really want to touch the alignment though without an okay from Kiwamu, so I'll wait for him to come in and confirm that he's happy with the current MC.

Alex has created a 2.4 branch of the RCD. Jamie, we can try to compile and install it. As a test a did it for c1oaf, it compiles, installs and runs once variables SITE, IFO, RCD_LIBRARY_PATH are properly defined. As we do not want to run one model at 2.4 code and others at 2.1, I recompiled c1oaf back to 2.1. Jamie, please, let me know when you are ready to upgrade to 2.4 release.

 I have a feeling we are not fitting into pre-allocated memory space in the shared memory between the front-end process and the epics process. Filter module data is overwriting some other data and that's why we are not getting a sync light. I suggest we upgrade to 2.4 code first and then we will figure out a way to expand memory areas to fit 856 filters.

I tried to figure out why red NO SYNC label became present in the C1OAF_GDS_TP screen after I added AA filters to the C1OAF model.

C1OAF model contains 8 libraries C1OAF_ADAPT for 8 DOF. I changed C1OAF_ADAPT library to C1OAF_ADAPT_AA library where I added 28 AA filters for 28 witness channels. It turns out that if I use this library for all 8 DOF then I see NO SYNC label, if only for one DOF (MCL) then I see green IOP label. This means that using AA filters for each DOF too much channels of filters are created for online system to operate. I think there is some number inside the code that one can not exceed. Analyzing compilation output after "make c1oaf" I figured out that without using AA filters we have 632 filters and using AA we have 856 filters.

For now I'll use AA filters for MCL only.

1) Linearity Test

LO input level was +10dBm. The LO freq was 11MHz and 55MHz for CH1 and CH2 respectively.
The IF frequency was fixed at 10kHz.

The amplitude of the RF input was swept from -50dBm to +15dBm.
Basically I and Q output of CH1 and CH2 was quite linear in this amplitude range.

2) Freqency Response

RF input was fixed at -20dBm and the IF frequency was swept from 1kHz to 1MHz.

The response was flat upto 100kHz, and have sensitivity upto 300kHz.

3) Output noise

Noise floor of the output is ~20nV/rtHz. All of the channels behave in the same way.
1/f start from 100Hz.

Since the c1lsc machine became frozen I restarted the c1lsc machined and daqd.

Then I burtrestored c1lsc, c1ass and c1oaf to this evening. They seem running okay.

So far:

* New demod box has been placed in the LSC rack.

* An extra set of +\- 24V has been prepared at the terminal block where all the Crates get their power on the LSC rack.  The grounds were all connected up, but the hot wires weren't.  So there were extra spots available, but none that were pre-wired with my voltages.

     * To do this I turned off all the power supplies in the short rack, since I decided to be a live chicken rather than a dead duck.  After hooking up the new terminal block slots, I turned on the power supplies.

 * Make a power cable to go from the terminal block to the box

Still to do:

 * Connect the spare 55MHz LO and the POP (or POX or POY) unused 11MHz LO to the back of the box

 * Move the PD inputs to the new demod box rather than the borrowed AS11 and POP55 boards

 * Plug the I & Q outs for each freq into some spare ADC channels - must first make sure we have 4 open channels.

 * See if it works.