40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 222 of 344  Not logged in ELOG logo
ID Date Author Type Category Subject
  6165   Wed Jan 4 02:43:40 2012 ranaUpdateGeneralActuators for Stewart platform

Quote:

 I checked on the two single-axis shakers that are present at the 40m that Steve pointed out:

  • Brüel & Kjær type 4809, rated for 45 N peak, and
  • Brüel & Kjær type 4810, rated for 10 N peak.

Neither of these meet the force requirement of 2.04 kN peak.

 Time to lower your expectations!

Do we really need 40 microns at 500 Hz? Or perhaps should there be a frequency dependent displacement requirement?

  6164   Wed Jan 4 00:43:06 2012 kiwamuUpdateIOOMC became flaky

I don't know what exactly is going on, but MC became flaky and it's been frequently unlocked.

I have turned off the MC WFS servo to check if the WFSs are doing something bad. But it still tends to be unlocked without the WFS servo.

Right now it doesn't stay locked for more than 10 min.

  6163   Tue Jan 3 20:42:05 2012 Leo SingerUpdateGeneralActuators for Stewart platform

 I checked on the two single-axis shakers that are present at the 40m that Steve pointed out:

  • Brüel & Kjær type 4809, rated for 45 N peak, and
  • Brüel & Kjær type 4810, rated for 10 N peak.

Neither of these meet the force requirement of 2.04 kN peak.

  6162   Tue Jan 3 18:40:08 2012 AidanSummaryComputer Scripts / Programsmedm directory clean-up

 I moved the following old and obsolete MEDM directories to an archive /cvs/cds/rtcds/caltech/c1/medm

  • c1vga
  • c1vgl
  • c1gpt
  • c1gpv
  • c1nio
  • c1spy
  • c1spx

None of these models were present in /cvs/cds/rtcds/caltech/c1/target

  6161   Tue Jan 3 17:46:38 2012 Updated Stewart platform design requirementsUpdateGeneralUpdated design requirements for a Stewart platform

I updated the design requirements for the Stewart platform.  I weighed the unloaded "dirty" SOS that was sitting on the workbench in the control room; its mass is 11 kg.  Steve suggested that the OSEMs (not installed on this model) would add another 0.5 kg.  From the specs in the final SOS design document, LIGO-T970135, I added 0.25 kg for the optic itself; I am therefore taking the total payload mass to be 11.75 kg.  (Now, the upper stage of the Stewart platform itself will likely add a nontrivial amount, but I am not worrying about this yet.)

I have e-mailed Janeen Romie to obtain the actual center of mass and principal moments of inertia of the platform.  I also cooked up a simple scheme to measure both quantities, should this information not be available.  It would involve rigidly mounting the dirty SOS to a rigid bar hung from a pivot.  By translating the mount point in two dimensions and measuring the period of the pendulum, I ought to be able to find the center of mass and moments of inertia by multilinear regression.  However, this elaborate scheme is not necessary to just compute some ballpark figures; it could wait until a later stage in the design.  For the time being, I just rescaled the moment of inertia proportional to the increase in mass, such that the torque-to-force ratio is unchanged.

As such, the design requirements are now 

  • 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: 11.75 kg (measured unloaded mass, plus educated guesses about combined mass of OSEMs and optic)
  • payload moment of inertia: 0.0232 kg m^2 (wild guess)
  • bandwidth: 500 Hz (suggestion of Rana and Koji: ~kHz)

From these assumptions, the revised actuator requirements and dimensions are:

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

See the attached PDF document.

It appears that the actuator that I had originally nominated, PI's model P-225.80, would very nearly meet the actuator force requirement.  Steve also pointed out the following single-axis shakers that are already in use in the 40m:

  • Brüel & Kjær type 4809
  • Brüel & Kjær type 4810

I want to find out if either of these would meet the present need, but I'm waiting on a response from the manufacturer to get access to the data sheets.

 

Attachment 1: stewart.pdf
stewart.pdf stewart.pdf stewart.pdf stewart.pdf stewart.pdf stewart.pdf stewart.pdf stewart.pdf
  6160   Tue Jan 3 17:25:27 2012 KojiUpdatePSLFound the laser was off

I found the PSL laser has been off for four hours. Nobody seemed to know why.

I just turned it on and it is now providing about 10% lower power compared with one before the shutdown.
Let's keep the eyes on the power if it can recover as the housing gets warm.

  6159   Tue Jan 3 15:49:27 2012 JamieUpdateComputerspossible front-end timing issue

Quote:

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.

  6158   Tue Jan 3 15:48:39 2012 kiwamuUpdateLSCpower normalization in LSC

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.

 

     Concept of Power Normalization         

Koji pointed out that the dynamic power normalization, which I have installed(#6156),  should be placed after the LSC input matrix rather than before the matrix.
Now let us review the concept of the power normalization to avoid some confusions.
We will need two kinds of power normalizations as follows:
  1.  Static power normalization, which should be placed before the input matrix.
  2.  Dynamic power normalization, which should be placed after the input matrix.
 The static power normalization will be applied to each I and Q signals in all the LSC signals and also DCPD signals.
This normalization is supposed to cancel the effects from the incident laser power and depths of the phase modulations.
Because the variations in the laser power and modulation depth are expected to be relatively slow, we will apply static normalizations.
 
 The dynamic power normalization will be applied to the DOFs error signals, for example C1:LSC-DARM_IN and so on.
This normalization is supposed to cancel the effect of the internal states of the interferometer, for example alignments.
In addition to it, this dynamic normalization can expand the linear range of the error signals.

Quote from #6156

Now a power normalization is doable for the LSC error signals.

 

  6157   Tue Jan 3 15:45:04 2012 JenneUpdateComputersFB?

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

Also, I reenabled PRM watchdog.

  6156   Fri Dec 30 22:05:16 2011 kiwamuUpdateLSCpower normalization in LSC

Now a power normalization is doable for the LSC error signals.

It is working fine, but at some point we may want to have some kind of a saturation filter or limiter to avoid dividing a signal by a small number.

 

 (How to set the normalization)

  •   Click a small matrix panel on the LSC OVERVIEW window (shown in the attached screen shot below).
    •     This will give you a pop-up-window, which shows a matrix to route the normalization signals
POW_NORM_MTRX.png
  •   Choose a numerator channel, which you want to divide, and choose denominator channels, which you want to use as a power normalization factor.
  •   Put some number in the corresponding matrix elements.
  •   Once you put a non-zero element in the matrix, the corresponding numerator channel will be divided by the specified denominator channels.
    •     Otherwise the static normalization factors (e.g. C1:LSC-AS55_POW_NORM, etc.,) will be used for the denominator.
  6155   Fri Dec 30 02:16:48 2011 kiwamuUpdateGreen LockingYarm ALS : high frequency noise reduced

The high frequency noise, which has been a dominant noise above 30 Hz in the Y arm ALS (#6133), decreased by a factor of 5.

This reduction was done by increasing the modulation depth at the Y end PDH locking. Now the noise floor at 100 Hz went to 0.2 pm/sqrtHz.

However the noise source is not yet identified and hence it needs a further investigation.

 

 The attached figure is the sensor noises, which were taken from the beat-note signal while the arm was locked by the IR-PDH.
The orange curve is the one before I changed the modulation depth and the red curve is the one taken after I increased the modulation depth.
The high frequency noise went down from 1 pm/sqrt Hz to 0.2 pm/sqr tHz at 100 Hz.
 
Yarm_ALS_2011Dec29.png

 (Increasing the modulation depth)

  Actually I was going to check the RAM noise at the Y end PDH locking as I planed (#6143).
During some preparation for it, I found that there had been a 20 dB attenuator in the modulation LO path.
The reason we have kept it is that somehow a big modulation depth made the reflected DC light noisier.
For curiosity I removed it to see what will happen and took the noise spectra. Then the noise decreased as shown in the plot above.
It means the noise source was like a kind of sensor noise, whose level depends on the responsivity of the sensor.
As far as I can tell, it is not the dark noise or shot noise according to some quick measurements.
  6154   Wed Dec 28 14:13:16 2011 kiwamuUpdateGreen LockingALS feedback on MC2

I added an ALS feedback path on the MC2 suspension and this path will enable us to stabilise the MC length using the ALS scheme.

  The actual digital signal is transmitted from the c1gcv realtime controller to the c1mcs realtime controller through the c1rfm realtime process.
Or in terms of the machines, the signal is transmitted from C1IOO to C1SUS via the reflective memory network.
 
The attached figure is a screen shot of the MC2 position controller screen.  The new ALS path is emphasized by a purple circle in the figure.
MC2_ALS.png

Quote from #5888

Leaving a note on the ALS feedback before I forget:

The MC2 suspension needs to have an input for the ALS feedback in the realtime model like ETMs.

 

  6153   Tue Dec 27 23:03:56 2011 kiwamuUpdatePSLPMC realigned

I have realigned the steering mirrors for PMC because the transmitted light had been at ~ 0.741

After the alignment it went back to ~ 0.850.

  6152   Tue Dec 27 22:17:56 2011 kiwamuUpdateLSCmultiple-LOCKIN new screens

Some new screens have been made for the new multiple-LOCKIN system running on the LSC realtime controller.

The medm screens are not so pretty because I didn't spend so long time for it, but it is fine for doing some actual measurements with those new screens.

So the basic works for installing the multiple-LOCKIN are done.

 

 The attached figure is a screen shot of the LOCKIN overview window.

As usual most of the components shown in the screen are clickable and one can go to deeper levels by clicking them. 

Untitled.png

Quote from #6150
The multiple LOCKIN module has been newly added on the LSC realtime model.
I will make some MEDM screens for this multiple-LOCKIN system.

  6151   Tue Dec 27 16:56:15 2011 kiwamuUpdateLSCScmitt trigger installed
The old trigger system has been replaced by Schmitt triggers in the c1lsc realtime model.
They seem working correctly.
  

      An example              

Here below is a picture of time series showing how the Schmitt trigger works as an example.
trigger_time_series.png
 
 In order to check the new trigger, I injected a fake sine signal into the TRY path to simulate lock acquisition of the Y arm with TRY used as a trigger.
Then I monitored the trigger signal, called C1:LSC-YARM_TRIG_MON.
This variable is a boolean, and hence it returns zero when the trigger is off and one when it is on.
I set the upper and lower thresholds to be 0.6 and 0.2 respectively.
As shown in the picture, the trigger became on when the TRY sine curve crossed the upper threshold of 0.6.
After that the TRY signal then crossed the lower threshold of 0.2 and the trigger became off.
 

      How to set the thresholds         

The setting procedure is the same as before.
  1. Open the trigger matrix window, which is accessible from the C1LSC overview screen as usual.
  2. Then type the desired upper and lower thresholds into the column.

The below is a screenshot of the trigger matrix screen. The thresholds column is pointed by a big white arrow.

 trig_mat.png

Of course, DO NOT set the upper threshold value to be smaller than that of the lower threshold. Otherwise it won't correctly work.

Also if you want to have the usual trigger rather than the Schmitt trigger, simply put the upper and lower thresholds at the same values.

 

 

      Details         

 Here I explain how the new trigger exactly work.
The attached screen shot below is the actual c1lsc simulink model, zoomed in the blocks of the MICH trigger.
model_trigger_edit.png
 
    The signal flows from the left hand side to the right hand side and the resultant output is always either zero or one.
There are two variables, which you can control via EPICS: TRIG_THRES_ON and TRIG_THRES_OFF.
Those two variables correspond to the upper and lower thresholds respectively.
   An important thing is that there are two key components: "UnitDelay" and "Choice" blocks.
First of all the code checks whether the trigger used to be ON or OFF at the "Choice" block by looking at the TRIG_MON data which is from the past.
The "Choice" block is configured such that if the TRIG_MON value used to be True, it lets the TRIG_THRES_OFF signal go through.
And if the TRIG_MON used to be False, then it lets the TRIG_ON signal go through.
Therefore this procedure breaks the situation into two cases : trigger used be ON and OFF, and depending on the situation it returns a proper threshold.
     After this check, the code does the usual triggering.
The proper threshold from the "Choice" block will be compared with an LSC signal at ">" block.
If the LSC signal is greater than the threshold value then it gives one and enables the feedback.
 
  6150   Mon Dec 26 14:01:45 2011 kiwamuUpdateLSCmultiple-LOCKIN newly added
The multiple LOCKIN module has been newly added on the LSC realtime model.
The purpose is to demodulate ALL the LSC sensors at once while a particular DOF is excited by an oscillator.
So far the model has been successfully compiled and running okay.
I will make some MEDM screens for this multiple-LOCKIN system.
 

(Some details)

The picture below is a screen shot of the LSC real time model, zoomed in the new LOCKIN part.

multiple-lockin.png

The LOCKIN module consists of three big components:

  1. A Master oscillator
    • This shakes a desired DOF through the LSC output matrix and provides each demodulator with sine and cosine local oscillator signals.
    • This part is shown in the upper side of the screen shot.
    • The sine and cosine local oscillator signals appear as red and blue tags respectively in the screen shot.
  2. An input matrix
    • To allow us to select the signals that we want to demodulate.
    • This is shown in the left hand side of the screen shot.
  3. Demodulators
    • These demodulators demodulate the LSC sensor signals by the sine and cosine signals provided from the master oscillator.
    • With the input matrix fully diagonalized, one can demodulate all the LSC signals at once.
    • The number of demodulators is 27, which corresponds to that of available LSC error signals (e.g. AS55_I, AS55_Q, and etc.).
    • This part is shown in the middle of the screen shot.
  6149   Mon Dec 26 12:04:41 2011 kiwamuUpdateCDSc1gcy.ini hand edited

I have edited c1scx.ini by hand in order to acquire some green locking related channels.

Somehow c1sus.ini, c1mcs.ini, c1scx.ini and c1scy.ini are not accessible via the daqconfig script.

As far as I remember it had been accessible via daqconfig a week ago when I edited c1scy.ini.

Anyway I had to edit it by hand. They need to be fixed at some point

  6148   Fri Dec 23 15:55:12 2011 ranaSummaryComputer Scripts / ProgramsCONLOG: not working since Oct 1

Often people say "I don't use conlog because its real slow". Its a little like not driving because your car has no gas.

I looked into what's going on with conlog. No one has fixed its channel list in ~1 year so it didn't make much sense. Also since Oct 1 of this year, it expired the leap seconds epoch and has been waiting for someone to look at the log file and update the list of leap seconds.

Some issues:

  • Don't use the phrases like OUTPUT, OUTMON, OUT16, or INMON as the usual part of a channel name. These are filter modules words which use to exclude channels from conlog. Please fix ALL of the LOCKIN screens to get rid of the OUTPUT filter banks.
  • If you use an EPICS channel in a servo so that its getting changed 16 times a second, make sure to add it to the conlog exclude list.

There are a bunch of bad channels which are screwing up various tools (DV, DTT, etc.):

Examples: C1:LSC-Subsystem_NPRO_SW1, C1:-DOF2PD_MTRX_0_0_SW1, C1:BAD-BAR_CRAZY_2_RSET, C1:C1L-DOF2PD_MTRX_3_14_SW2, C1:DUB-SEIS_GUR2_Z_LIMIT, etc.

  • There are a bunch of old, unused directories in c1/medm/. EVERYONE take a look in there and delete the OLD dead ones so that we don't keep recording those channels.

 To fix up some of these issues, I have deleted several MEDM directories which I thought were old (there are several extras left from Aidan's Green time). I also have put a bunch of exclude variables into the conlog 'scan_adls' script to prevent it from adding some of the new worthless channels. Finally, I have started this command

../bin/strip_out_channels '.*STAT.*','.*_ALIVE.*','C1:PEM.*','.*_Name.*','C1:UCT.*','C1:MCP.*','C1:SP.*','C1:DU.*','C1:RF.*','C1:NIO.*','C1:TST.*','C1:SUP.*','C1:X.*','C1:FEC.*','.*_LFSERVO.*','.*FSS_SLOWDC.*','C1:LSC-LA_MTRX_21','C1:LSC-PD.*OFFSET','C1:LSC-ETM.*OFFSET' conlog*.log

which should strip lots of the excess conlog data out of the conlog directory. The only downside is that its setting all of the timestamps of the .log files to today instead of the historical times but I don't think we'll care about this too much. Hopefully it will speed things up to have less than 450 GB of conlog files...

update: 12 hours later, its still running and has removed ~100 GB so far. It will probably take the rest of the weekend to finish.

  6147   Fri Dec 23 01:07:41 2011 kiwamuUpdateGreen Lockingrearrangement of PSL green optics part II

After I did a fine alignment of the X green beam path on the PSL table, the X arm beat-note was also obtained.

Here is a picture of the latest setup. The blue lines represent S-polarizing green beams.

newLayout.png

During I was working on the PSL table HEPA was at 80 %, and after the work I brought it to 20 %.

Quote from #6145
 I will do a fine alignment of the X arm path on the PSL table and try obtaining the X arm beat-note tonight.

  6146   Thu Dec 22 20:49:33 2011 KojiUpdateIOOLimitter activated for WFS servos

I set the limitters of the MC WFS servos not to inject the feedback more than 2000.

The residual of the WFS shakes the MC SUSs at every lock loss.

  6145   Thu Dec 22 19:15:22 2011 kiwamuUpdateGreen Lockingrearrangement of PSL green optics
 As planed (#6143), rearrangement of the PSL green setup has begun.
It required to move approximately half of the green optics on the PSL table
and I finished displacing and installing the necessary optics coarsely.
So far I just have recovered the Y arm beat-note between the PSL green light.
 
 I will do a fine alignment of the X arm path on the PSL table and try obtaining the X arm beat-note tonight.
  6144   Wed Dec 21 16:55:30 2011 kiwamuUpdateGreen LockingPower Recycled Single Arm
 I did some brief parameter checks for the power-recycled single arm which I have done yesterday.
The purpose is to make sure that the interferometer and I weren't crazy.
So far the measured quantities look reasonable.
  

         Assumptions on the parameter estimations          

   No losses.
   Tprm = 0.05637
   Titm =0.01384
   Tetm = 15 ppm
   Tbs = 0.5
 
        Parameter estimations and comparison with measurement      
   Recycling gain G = Tprm / (1 - ritm * rprm * Tbs) = 0.21 
   Amplitude reflectivity of the arm rarm =   (retm - ritm) / (1 - ritm * retm) = 0.99785
   Effective ITM's amplitude reflectivity ritm' = ( ritm + rprm * Tbs) / (1 + ritm * rprm * Tbs) = 0.9976
   Arm finesse = pi * sqrt (ritm' * retm) / (1 - ritm' * retm) = 1298
 
  + Power build up from single arm to power-recycled arm = G / Tprm = 3.73
      => measured value is 3.8 at maximum
 
  + Reflectance of the coupled cavity R = ( rprm -  rarm * Tbs )2 / (1 - rprm * rarm * Tbs  )2 =  0.841
     => measured value was about 0.85 at minimum
 
 
  + Cavity full linewidth = lambda / arm_finesse / 2 = 0.41 nm
     => narrower than that of the usual single arm by factor of 2.9
     => I guess this was the reason why the intracavity power looked more fluctuating after everything was locked

Quote from #6141

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

 

  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

  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.

 

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

  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

  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
  6135   Sun Dec 18 23:00:22 2011 kiwamuUpdateSUSoplve recenterd

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

  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.

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

  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

  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.

 

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

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

  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.

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

 

 

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

 

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

  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.

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

ELOG V3.1.3-