40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 122 of 341  Not logged in ELOG logo
ID Dateup Author Type Category Subject
  6094   Fri Dec 9 14:33:16 2011 Alex IvanovUpdateAdaptive FilteringC1OAF

Quote:

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.

 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.

  6095   Fri Dec 9 15:14:41 2011 DenUpdateCDSrelease 2.4

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.

  6096   Fri Dec 9 15:49:24 2011 JenneUpdateIOOMC trans is way down

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.

Attachment 1: MCtrans_9Dec2011.png
MCtrans_9Dec2011.png
  6097   Fri Dec 9 17:08:41 2011 JenneUpdateRF SystemLots of current used in Rich's demod box

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.

  6098   Fri Dec 9 17:15:29 2011 JenneUpdateIOOMC trans is way down

Quote:

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.

 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.

  6099   Fri Dec 9 17:44:45 2011 KojiUpdateRF SystemLots of current used in Rich's demod box

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?

Quote:

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.

 

  6100   Fri Dec 9 17:53:31 2011 DenUpdateAdaptive FilteringC1OAF

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

  6101   Fri Dec 9 20:03:57 2011 ZachUpdateRF SystemLots of current used in Rich's demod box

D0902745-v5 (probably the AP1053's):

Screen_shot_2011-12-09_at_8.00.54_PM.png

Quote:

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?

Quote:

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.

 

 

  6102   Sat Dec 10 05:27:43 2011 kiwamuUpdateGreen Lockingstatus update of the Y arm green lock

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.
  6103   Sun Dec 11 17:28:36 2011 kiwamuUpdateGreen Lockingstatus update of the Y arm green lock

Quote from #6102

  + Recent goal : automation of the single arm green lock 

As reported in the previous elog entry #6102, the realtime model and screens have been modified.
Here is a summary about what are new in the realtime model.
 
(What are new ?)
  • 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.

 ALSscreens.png

  6104   Mon Dec 12 11:16:02 2011 JenneUpdateRF SystemFoam house on EOM

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

  6105   Mon Dec 12 11:34:40 2011 Leo SingerSummaryGeneralSome design parameters for a Stewart platform

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. 

 

 

 

 

 

Attachment 1: stewart.pdf
stewart.pdf stewart.pdf stewart.pdf stewart.pdf stewart.pdf stewart.pdf stewart.pdf
Attachment 2: stewart.nb
(* Content-type: application/vnd.wolfram.mathematica *)

(*** Wolfram Notebook File ***)
(* http://www.wolfram.com/nb *)

(* CreatedBy='Mathematica 8.0' *)

(*CacheID: 234*)
(* Internal cache information:
NotebookFileLineBreakTest
... 377 more lines ...
  6106   Mon Dec 12 13:02:08 2011 kiwamuUpdateCDSdaqd restarted

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

  6107   Mon Dec 12 15:24:21 2011 JenneUpdatePSLPMC and MC were both crappy - now realigned

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.

  6108   Mon Dec 12 16:30:17 2011 JenneUpdateComputersDid someone just do something to fb??

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!

  6109   Mon Dec 12 16:57:38 2011 JenneUpdateRF SystemRAMmon, 4 day trend

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:

EOM_tempSense_noFoam_noHeater_RAMmon_4days.png

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.

  6110   Tue Dec 13 01:20:38 2011 DenUpdateAdaptive FilteringModifications to LSC, RFM models, added OAF model

Quote:

[Jenne, Mirko, with supervision from Jamie]

We are starting to create the new OAF model, so that it works with the new CDS system. 

 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 * 104(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.

 

  6111   Tue Dec 13 11:34:32 2011 JenneUpdateRF SystemRAMmon, 5 day trend

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.

EOM_tempSense_RAMmon_5days_last_day_withFoam_noHeater.png

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.

EOM_tempSense_withFoam_noHeater_RAMmon_1day.png

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.

  6112   Tue Dec 13 11:51:33 2011 JamieUpdateComputersDid someone just do something to fb??

Quote:

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!

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.

  6113   Tue Dec 13 16:31:40 2011 ZachUpdateIOOPSL beam realigned into MC

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.

  6114   Tue Dec 13 18:56:23 2011 ranaUpdateIOOPSL beam realigned into MC

 

 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?

  6115   Wed Dec 14 01:35:06 2011 KojiUpdateIOOMC alignment craziness

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

Attachment 1: Untitled.png
Untitled.png
  6116   Wed Dec 14 12:18:11 2011 ZachUpdateRF Systemheater reengaged

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.

heater_reengaged_12_14_11.png

  6117   Wed Dec 14 12:22:00 2011 VladimirHowToComputersligo_viewer installed on pianosa

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

 

 

Attachment 1: ligo_viewer_40m2.png
ligo_viewer_40m2.png
  6118   Wed Dec 14 14:07:48 2011 KojiUpdateIOOMC alignment craziness

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

  6119   Wed Dec 14 14:30:43 2011 JenneUpdateRF SystemLO for new demod box

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

  6120   Wed Dec 14 14:40:53 2011 steveUpdateGreen Lockingdelay line bnc cable specs

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.

Attachment 1: rg58cu.jpg
rg58cu.jpg
Attachment 2: RG58-P.pdf
RG58-P.pdf
  6121   Wed Dec 14 16:19:46 2011 ZachUpdateRF SystemLO for new demod box

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.

Quote:

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

 

  6122   Wed Dec 14 18:06:39 2011 ZachUpdateRF SystemLO for new demod box

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. 

Quote:

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.

Quote:

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

 

 

  6123   Wed Dec 14 19:59:12 2011 JenneUpdateRF SystemLO for new demod box

Quote:

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. 

Quote:

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.

Quote:

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

 

 

 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.

  6124   Thu Dec 15 11:47:43 2011 jamieUpdateCDSRTS UPGRADE IN PROGRESS

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

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

  6125   Thu Dec 15 22:22:18 2011 jamieUpdateCDSRTS upgrade aborted; restored to previous settings

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.

  6126   Fri Dec 16 13:29:15 2011 kiwamuUpdateGreen LockingY arm noise budget : 60Hz line noise is killing us
Along with development of the automation script, my goals last night were :
 (1) Take a noise budget when the standard ALS configuration is applied
 (2) Take a beautiful time series to show how ALS brings the cavity to the resonance point
 
 However I gave up goal (2) because the resultant time series were very fluctuating at 60 Hz and it wasn't so beautiful enough.
As shown in the noise budget below, the 60 Hz line noise currently dominates the arm displacement.
 

Yarm_ALS_2011DEC16.png

       About Noise Budget       

 The spectra were taken when the arm length was kept at the resonance point using the ALS servo.
So the error signal was taken from the beat-note and was fed back to ETMY.
The servo UGF was at about 100 Hz and the fine frequency discriminator was used.
The red curve in the plot is the arm displacement observed by POY11, which is an out-of-loop sensor in this case.
From the plot it is apparent that the 60 Hz line noise raises the rms to few 100 pm level.
 

       How to improve it ?     

According to my quick calculation if we can exclude the 60 Hz line noise from the rms integration, the rms becomes about 70 pm, which is nice.
I somehow believe this line noise comes from the ALS servo and is injected to the coil-magnet actuator.
So I propose to lower the UGF and make it lower than 60 Hz such that
the servo doesn't react to the 60 Hz line noise and hence no 60 Hz noise injection to the arm displacement.
In any case lowering the UGF is better since our ALS sensor sees only noise above 40 Hz according to the previous noise measurement (#5970)
  6127   Sat Dec 17 00:00:03 2011 kiwamuUpdateGreen Locking60 Hz line nose gone

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.

It turned out that the line noise came from an oscilloscope.
The oscilloscope had been connected to a SR560, which amplifies the frequency-discriminated signal before the ADC as a whitening filter.
I still don't have a good explanation for it, but somehow connecting the oscilloscope made the line noise pretty high.
  6128   Sat Dec 17 01:56:16 2011 KojiSummarySUSHysteresis test

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

 

 -- EDIT by KI:
I found the ITMY watchdogs tripped around 2:40 AM and then re-engaged it.
  6129   Sat Dec 17 03:59:32 2011 kiwamuUpdateSUSAborted Hysteresis test

Quote from #6128

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

The hysteresis test has been aborted.

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

In fact the ITMX and ITMY mirrors started being stacked to their OSEMs.
The script process has been force-quit and I have restored all the DC biases to their nominal points.
They still look okay: MC can be locked at the 00 mode, DRMI fringe is visible at AS, the green beams are resonating the arm cavities
Need another trial.
  6130   Sat Dec 17 11:53:46 2011 ZachUpdateSUSAborted Hysteresis test

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

Quote:

Quote from #6128

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

The hysteresis test has been aborted.

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

In fact the ITMX and ITMY mirrors started being stacked to their OSEMs.
The script process has been force-quit and I have restored all the DC biases to their nominal points.
They still look okay: MC can be locked at the 00 mode, DRMI fringe is visible at AS, the green beams are resonating the arm cavities
Need another trial.

 

  6131   Sat Dec 17 12:41:46 2011 KojiUpdateSUSAborted Hysteresis test

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

  6132   Sun Dec 18 16:16:55 2011 kiwamuUpdateSUSAnother trial of Hysteresis test

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.

Quote from #6129

The hysteresis test has been aborted.

Need another trial.

  6133   Sun Dec 18 18:45:22 2011 kiwamuUpdateGreen LockingY arm ALS : time series and noise budget
As I said in the previous entry (#6126) my current goals were :
 (1) Take a noise budget when the standard ALS configuration is applied
 (2) Take a beautiful time series to show how ALS brings the cavity to the resonance point

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

    Time Series   

time_series.png

 The data starts from a point where the cavity is kept away from the resonance point by 200 kHz (in terms of the green laser's frequency).
Then 30 sec after, a cavity sweep started until the main laser becomes resonant for the arm cavity.
After 2.5 minutes the sweep was quit and the arm length was held at this point to show the
stability of the ALS servo.
 
         Noise Budget         

Yarm_ALS_2011DEC17.png

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

Note that the UGF was at about 100 Hz.
One of the improvements we made in the Friday was the removal of the 60 Hz line noise (#6127).
Currently the rms is dominated by two components:
     (1) A bump around 10 Hz, which is due to lack of the servo gain around there.
         => This can be improved by optimizing the servo filter shape
     (2) High frequency noise above 40 Hz.
         => This can be improved by either decreasing the noise itself or lowering the UGF.
  6134   Sun Dec 18 19:56:00 2011 kiwamuUpdateSUSAnother trial of Hysteresis test

The measurement finished at ~ 21:50 PT.

Quote from #6132

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.

  6135   Sun Dec 18 23:00:22 2011 kiwamuUpdateSUSoplve recenterd

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

  6136   Mon Dec 19 01:54:35 2011 kiwamuUpdateSUSanother trial of hystersis test

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.

Time record                       
   Start:  Dec/19 1:50 PST
   End :  Dec/19  5:30 PST
  6137   Mon Dec 19 17:17:02 2011 DenUpdateAdaptive Filteringfilter tap dependence

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.

OfflineAF.png

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

  6138   Mon Dec 19 23:50:23 2011 ZachUpdateRF SystemRAMmon

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

  6139   Tue Dec 20 15:49:21 2011 steveUpdatePEMoptical table top

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.

 

Attachment 1: 05150901.PDF
05150901.PDF
  6140   Wed Dec 21 03:38:14 2011 kiwamuUpdateGreen LockingY arm ALS : automation script 80 % done

Scripting of the single arm automated lock script is 80% done.

The remaining 20 % is not something immediately needed and I start decreasing the priority on the Y arm ALS.

(Remaining stuff)

  • Automated optimization of I/Q phases at the frequency discriminator's signal.
    • this part will be done after we install Jamie's new beat box
  • A routine function which checks if the beat note is within a reasonable bandwidth
    • This part can be done with the frequency-divided signal and the digital delay line frequency discriminator
    • Another approach is to install a frequency counter, which doesn't have to be so precise
  • A state bit which tells us how far the script goes
  • An exit handler.
    • This should run whenever the script is unexpectedly force-quite, to gently bring the ALS system down.
  • A servo which brings the beat frequency to exactly a point where the infrared light is on a resonance point
    • Currently this part is partially human-aided. I put a little bit of correction in the frequency offset by looking at time series
    • To automate this part, we need another LOCKIN system to shake the arm length and demodulates the transmitted light
  6141   Wed Dec 21 04:29:01 2011 kiwamuUpdateGreen LockingPower Recycled Single Arm

I made the first trial of locking a Power-recycled single arm.

 This is NOT a work in the main stream,

but it gives us some prospects towards the full lock and perhaps some useful thoughts.

 

      Optical Configuration         

  • Y arm and PRM aligned. They become a three-mirror coupled optical cavity
    • Power Recycling Cavity (PRC) is kept at anti-resonance for the carrier when the arm length is off from the resonance point
    • Hence bringing the arm length to the resonance point lets the carrier resonate in the coupled cavity
    • BS behaves as a loss term in PRC and hence results a low recycling gain
  • Everything else are misaligned, including ITMX, ETMX, SRM and BS
    • Therefore there are neither Michelson, X arm nor Signal Recycling Cavity (SRC)

   Lock Acquisition Steps    

  1. Misalign PRM such that there is only Y arm flashing at 1064 nm
  2. Do ALS and bring the arm length to the resonance point
  3. Record the beat-note frequency such that we can go back to this resonance point later
  4. Displace the arm length by 13 nm, corresponding to a frequency shift of 200 kHz in the green beat note
  5. Restore the alignment of PRM.
  6. Lock PRC to the carrier anti-resonance condition using REFL33I. At this point the arm doesn't disturb the lock because it is off from the resonance anyway
  7. Reduce the displacement in the arm and bring it back to the resonance

 

     Actual Time Series     

Below is a plot of the actual lock acquisition sequence in time series.

time_series.png

  • The data starts from the time when the arm length was kept at the resonance point by the  ALS servo.
    • At this point PRM was still misaligned.
  • At 120 sec, the arm length started to be displaced off from the resonance point.
  • At 250 sec, the alignment of PRM was restored and the normalized DC reflection went to 1.
    • Error signals of PRC showed up in both REFL33 and POOY11
  • At 260 sec, PRC was locked to the carrier anti-resonance point using the REFL33_I signal.
    • Both REFL33 and POY11 became quiet.
    • REFLDC started staying at 1, because the carrier doesn't enter to the cavities and directly goes back to the REFL port.
  • At 300 sec, the arm length started to be brought to the resonance point.
  • At 400 sec, the arm length got back to the resonance point.
    • The intracavity power went to 3.5 or so
    • REFLDC went down a bit because some part of the light started entering in the cavities
    • REFL33 became noisier possibly because the Y arm length error signal leaked to it.
  6142   Wed Dec 21 14:23:08 2011 ranaConfigurationSUSHysteresis in suspensions?

While discussing the suspension hysteresis measurements, Koji, Kiwamu, and I realized that the suspension wire standoff is aluminum, whereas the standoff for the LIGO LOS are using quartz.

Using a soft aluminum standoff is bad. The movement of the suspension will slowly wear the groove and produce opportunities for mechanical upconversion and hysteresis.

In fact, the wire standoff as well as the clamping block on the top should be made of sapphire or ruby to prevent any such wearing issues. Steve is hot on the case.

 

  6143   Wed Dec 21 14:41:22 2011 kiwamuSummaryGeneralminutes of 40m meeting : short-term plan

Here is the Gantt chart we discussed in the 40m meeting today.

Based on the discussions we had, I applied a little bit of corrections on the chart but the main stream remains the same.

40mproject.png

ELOG V3.1.3-