40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 123 of 344  Not logged in ELOG logo
IDup Date Author Type Category Subject
  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.

 

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

  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.

  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.

  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

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

  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.

  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.

 

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

  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.

 

  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.

  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.

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

  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.

  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.

  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?

  6166   Wed Jan 4 03:03:24 2012 kiwamuUpdateLSClocking activity tonight and beyond
Last night and tonight, I was doing a kind of rehabilitation -- locking PRMI and DRMI with the new trigger system.
Although MC wasn't so awesome (#6164), I confirmed that the DRMI can stay locked with the conventional RFPD combination (#4760).
Additionally I have modified the IFO configure scripts, such that they also automatically restore the thresholds values for triggering.
The scripts are available in the C1IFO_CONFIGURE screen as usual.

 

       Locking plan            

Here is a plan in my mind and these are basically the details of the gantt chart (#6143):

  • (1 day task) Measurement of the recycling gains of the RF sidebands with the PRMI and DRMI configuration, using POP22/110 RFPD.
    • I need to have confidence that I am really locking the DRMI with SRC resonating to 55 MHz.
    • Also those values will enable us to estimate losses and mode matching again (maybe ?).
  • (3-4 days task) Measurement of the sensing matrix using the multiple-LOCKIN system.
    • Write a script to automatically measure the sensing matrix. This must be easy.
      • The results will enable us to diagonalize the input matrix and therefore it eventually gives more solid lock of the DRMI
      • Also it will give us the optical gains of 3f signals. So this is actually a step toward the 3f signal check.
  • (3-4 days task) Noise budgeting on the 3f signals
    • This is a very important part of the DRMI characterization because the results will tell us whether we can hold the DRMI lock with a sufficient SNR or not.
    • If it turns out that they don't have good SNRs, we then have to come up with some ideas to improve the SNRs.
  • (Extra fun task depending on schedule) 3f DRMI lock + Y arm ALS
    • If the beat-box electronics are not available by the time when the work above are completed, I will do this fun task.
    • Probably it is better to start preparing the common mode servo electronics because it will be needed anyway.

 

  6167   Wed Jan 4 05:02:58 2012 kiwamuUpdateLSCSidebands measurement at POP
Just a quick report:
I did the first attempt to measure the recycling gains of the sidebands in the DRMI configuration (sidebands resonant condition)
by looking at the output of the POP22/110 RFPD.
Because this time what I measured is some absolute values of the sidebands power,
it doesn't tell us anything quantitatively until we calibrate it or compare it with similar data.
So I need to measure the same things in some different configurations (e.g. PRMI, SRMI, etc.)
in order to extract some useful information from the measurement.
 
The attached picture is the display of a power spectrum analyzer looking at the output of the POP22/110 broadband RFPD
while the DRMI (in the sideband resonant condition) was kept locked.
You can see that 111 MHz (twice of 55 MHz) is prominent. Also there are several peaks at 11, 22, 44 and 66 MHz.
SB_DRMI.png
  6168   Wed Jan 4 09:06:50 2012 steveUpdateComputerspossible front-end timing issue

Quote:

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.

 The problem is the same as yesterday.

Attachment 1: rtntstat.png
rtntstat.png
  6169   Wed Jan 4 11:47:08 2012 JamieSummaryComputer Scripts / Programsmedm directory clean-up

Quote:

 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

Remember that we don't use /cvs/cds/rtcds anymore.  Everything should be in /opt/rtcds now.

  6170   Wed Jan 4 16:22:30 2012 kiwamuUpdateLSCpower normalization in LSC : modification done

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

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

Quote from #6158

It turned out that the power normalization need a modification.

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

 

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

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

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

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

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

Dataviewer is recovered after heavy new year party.

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

RTS/RCG/DAQ UPGRADE TO COMMENCE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

ETMX sus damping restored

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

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

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

Quote from #6180

ETMX sus damping restored

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

[John / Kiwamu]

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

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

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

[John / Kiwamu]

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

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

 


(Background)

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

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

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

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

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

 

(What we did)

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

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

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

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

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

  6184   Tue Jan 10 09:17:23 2012 steveUpdatePhotosstrawman's visiters
Attachment 1: P1080491.JPG
P1080491.JPG
Attachment 2: P1080492.JPG
P1080492.JPG
  6185   Wed Jan 11 14:06:28 2012 Leo SingerHowToComputer Scripts / ProgramsHowTo for getting data from NDS off site

 This may or may not be general knowledge already, but Jamie and I added a HowTo explaining how to retrieve channel data from the frame builder via NDS, but off site on one's own computer.  See the Wiki page:

https://wiki-40m.ligo.caltech.edu/How_To/NDS

  6186   Wed Jan 11 21:35:33 2012 Max De JongUpdateGeneralProjector

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

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

[John / Valera / Kiwamu]

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

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

 

(Some notes)

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

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

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

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

 

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


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

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

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

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

Can you please get some quotes on the parts?

rana

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

Quote:

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

Feedtrouhs: www.roxtec.com

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

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

 

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

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

 

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

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

See attached plot.

Attachment 1: spectrum.jpg
spectrum.jpg
  6192   Thu Jan 12 21:22:16 2012 Leo SingerConfigurationWIKI-40M UpdateUnable to create Wiki page

 I can't create a new page on the 40m wiki.  The page that I was trying to create is

http://blue.ligo-wa.caltech.edu:8000/40m/Stewart

I get this message when I try to save the new page:

Page could not get locked. Unexpected error (errno=13).

  6193   Thu Jan 12 23:13:42 2012 KojiConfigurationWIKI-40M UpdateUnable to create Wiki page

Quote:

 I can't create a new page on the 40m wiki.  The page that I was trying to create is

http://blue.ligo-wa.caltech.edu:8000/40m/Stewart

I get this message when I try to save the new page:

Page could not get locked. Unexpected error (errno=13).

This address for wiki is obsolete. Recently it was switched to https://wiki-40m.ligo.caltech.edu/
Jamie is working on automatic redirection from the old wiki to the new place.

The new one uses albert.einstein authentication.

 

  6194   Thu Jan 12 23:19:56 2012 KojiUpdateSUSc1iscex is fine now

c1iscex is working as before and the optic is damped.


What I checked

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

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

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

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

4. The signals came back to c1scx.

ELOG V3.1.3-