40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 328 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  5882   Sat Nov 12 02:46:13 2011 DenUpdateAdaptive Filteringstacks and ground

We measured the coherence between the seismometer near the MC2 stack and accelerometers on the vacuum tank where MC2 is. Because accelerometers produce small signals at low frequencies, which are comparable with adc noise, we  amplified the accelerometer signal by a factor of 20. We could not do it more because though adc has 40 V range, the black box that follows the channel sockets can transmit only 2.5 V max amplitude signal. Probably, this was done because old adc accepted 2 V max amplitude.

ground_stack.jpg

ground_stack_coherence.jpg


We were able to found some coherence at 0.1-1 Hz though the accelerometer signal is rather noisy. So to consider stack as a noise source is still possible. This measurement should be better done with two seismometers, one on the floor, the other on the stack. From the figure we can also see that tilt affects the x and y seismometer signals from 0.1 Hz. Green line (z-component) is much lower that red and blue lines (x and y). Tilt affects on horisontal axes of the seismometer much more than on vertical.

What we also think about is that at low frequencies mirrors start to move approximately the same and seismometers can help us to figure out small reletive displacement of the mirrors which form the MC length. We can estimate the critical frequency by presenting the ground motion as interference of surface waves with different velocities and amplitudes. For only 1 wave we have for the relation of MC length to the seismometer read out  ~sin (2*pi*f/v*L). f - frequency of the wave, v -speed, L - length between the mirrors. We can see that below 1 Hz we have ~sin (f/2). At this point seismometer signal could lose coherence with MC length signal. We could try to subtract seismometer signals from corresponding axes, but gur1 and sts1 has different calibrations. Moreover, the noise floor of the seismometers might not allow us to measure the differential signal. We'll try to simulate this scenario and find seismometer calibration or measure it. We are basicly interested only in the ratio of calibraion fucntions of 2 seismometers.

  3704   Wed Oct 13 09:35:41 2010 ranaUpdateelogstart script edited

The existing elog restart script was running the kill process in the background using the '&' symbol before starting new elog process. This is a BAD idea since there's no way to make sure that the background process has actually worked before the new one tries to start.

That's why you sometimes had to run the script twice. I've removed all of the background "cleverness" so now it will take ~2s more for the script to run - however, it now actually works. We may also upgrade from v2.7.5 to 2.8 today.

  4311   Thu Feb 17 11:20:04 2011 josephbUpdateCDSstart scripts no longer need sudo

I've modified the rc.local file to run the IOC codes as controls, which means they no longer write root permission log files on startup.

The awgtpman, which was the other permission issue with the start scripts, is started by a run script now.  This new version seems to be content to keep the permissions of the current log file, which is set to controls.

This should prevent the issue of sudo wiping your path environment variable for just that command. (Try "sudo which burtwb" versus "which burtwb" for example).  This apparently a security feature of sudo.

If you should happen to use sudo to run a start script, the easiest solution to fix the permissions is just got to the target directory (type "target") and run "sudo chown controls:controls -R *" on one of the workstations (the front ends don't handle the groups properly at the moment).

This should allow the scripts to properly use burtrb and burtwb to write and backup burt files.

  4935   Sun Jul 3 21:18:06 2011 ranaUpdateComputer Scripts / ProgramsstatScreen scripts dead since Feb 4 / now revived

This CSHRC mangling on Feb 4 did more than re-arrange FB binaries.

It broke the path to MEDM for the 32-bit machines in the lab (e.g. mafalda) and stopped the MEDM snapshots from being posted onto our MEDM Status Web Page.

This is because, in addition to the paths mentioned in the above elog, the paths to the EPICS directories were also commented out. I've re-inserted them into our

.cshrc file in the 32-bit section; the statScreen CRON that Yoichi set up is now back in business.

 

* for some reason, the 'cronjob.sh' script is wiping out its own log file. It would be great if someone who understands stderr output re-direction can fix it so that the log-file from each run is retained until the next time cron runs.

  7497   Sun Oct 7 23:39:10 2012 DenUpdateModern Controlstate estimation

I've applied online state estimation technique using Kalman filter to LQG controller. It helps to estimate states that we do not measure. I've considered MC2 local damping, we measure position and want to estimate velocity that we need for control. We can either differentiate the signal or apply state estimation to avoid huge noise injection at high frequencies. In state estimation we need to know noise covariance, I've assumed that LID sensor noise is 0.1 nm. Though covariance can be calculated better.

In the time-domain figure C1:SUS-MC2_SUSPOS_IN1 = MC2 postion, C1:SUS-MC2_SUSPOS_OUT = MC2 velocity obtained by differentiation, 2 other channels are estimations of position and velocity.

Attachment 1: est_time.png
est_time.png
Attachment 2: est_freq.pdf
est_freq.pdf
  7499   Mon Oct 8 09:51:30 2012 ranaUpdateModern Controlstate estimation

 

 I guess that the estimated state has the same low pass filter, effectively, that we use to low pass the feedback signal in SUSPOS. I wonder if there is an advantage to the state estimation or not. Doesn't the algorithm also need to know about the expected seismic noise transmission from the ground to the optic?

  7503   Mon Oct 8 12:34:52 2012 DenUpdateModern Controlstate estimation

Quote:

 

 I guess that the estimated state has the same low pass filter, effectively, that we use to low pass the feedback signal in SUSPOS. I wonder if there is an advantage to the state estimation or not. Doesn't the algorithm also need to know about the expected seismic noise transmission from the ground to the optic?

 I think state estimation and optimal control are two different techniques that are often used together. Sometimes (as for pendulum) we can use LQG without state estimation as we need only position and velocity. But for more complex systems (like quad suspension) the states of all 4 masses can be reconstructed in some optimal way using information from only one of them if the dynamics is sufficiently well known. When current system states are measured/estimated we can apply control where all our filters are hidden.

 The algorithm needs to know about expected seismic noise transmission from the ground to the optic, but it might be not very precise. I gave it some rough estimate, there are better ways to do it. I think that we'll understand whether we need state estimation or not when we'll move to more complex systems. Brett uses a similar approach for his modal control. Interesting if these methods + seismometer readings will be able to say if one of your sensors is noisier then others.

 

 

 

 

 

 

 

 

 

  6492   Fri Apr 6 10:31:07 2012 DenUpdateAdaptive Filteringstatic and adaptive

I've run static and adaptive filters simultaneously. AA32 filters rotate the phase of the witness signals GUR1X and GUR1Y and now the performance of the static filter is worse. Next time I'll recalculate Wiener filter coefficients taking this into account. But still 2 filters together can deal with a stack better.

static_oaf.pdf

  6493   Fri Apr 6 11:14:34 2012 JenneUpdateAdaptive Filteringstatic and adaptive

Quote:

I've run static and adaptive filters simultaneously. AA32 filters rotate the phase of the witness signals GUR1X and GUR1Y and now the performance of the static filter is worse. Next time I'll recalculate Wiener filter coefficients taking this into account. But still 2 filters together can deal with a stack better.

static_oaf.pdf

 This is super awesome!  I'm totally excited!!

  6491   Fri Apr 6 09:57:24 2012 DenUpdateAdaptive Filteringstatic starts to work

I made static filter to work to evaluate the actuator TF.. Here is the result of static filtering:

static1-crop.pdf

 What I did:

 I did offline simulation of the MC_F Wiener filtering using 2 witness signals - GUR1X and GUR1Y. I've downsampled the data from 2048 to 128 Hz and applied the Wiener filter with 10000 for each witness channel:

wiener_filtering.pngcoeffs.png

                                            Result of the filtering                                                                                     Filter coefficients for gur1x and then gur1y

xTF.pngyTF.png

                                         Gur1x -> MC_F transfer function                                                                          Gur1y -> MC_F transfer function

Then using vectfit I approximated obtained transfer functions in the region 0.5 - 20 Hz. I used a window function and then weights to get a more precise result in this range using only 8 poles and zeros.

xfitting.pngyfitting.png

I obtained the zpk-model for each witness channel and entered it into the FOTON splitting it into 2 parts before that because FOTON does not like too long filters. These zpk-models are at the C1:OAF-STATIC_STATMTX_8_8 and C1:OAF-STATIC_STATMTX_8_9 filter banks.

GUR1X:

z =

  7.527339430029315 +31.603999069997801i
  7.527339430029230 -31.603999069997823i
 27.897703898191267 + 0.000000000000071i
 -6.437806394766186 + 9.893955654289517i
 -6.437806394766159 - 9.893955654289510i
  1.114401249545640 + 5.479278396987240i
  0.176877296954015 + 0.000000000000006i
  1.114401249545616 - 5.479278396987245i


p =

 -0.407251778925379 + 6.263247012022007i
 -0.407251778925379 - 6.263247012022007i
 -0.230672968859081 + 6.846868757063707i
 -0.230672968859081 - 6.846868757063707i
 -2.871419857491615 +13.707864827517826i
 -2.871419857491615 -13.707864827517826i
 -2.134260618362721 +18.319129999777648i
 -2.134260618362721 -18.319129999777648i


k =

     4.113285626223658e-04

GUR1Y

z =

 17.961416874092624 +13.631821252434328i
 17.961416874092642 -13.631821252434353i
 -8.788634771726304 + 7.653357335975781i
 -8.788634771726285 - 7.653357335975777i
 -0.037906973323273 + 5.133348020858679i
 -0.164348392996182 + 3.588803405511463i
 -0.164348392996187 - 3.588803405511474i
 -0.037906973323277 - 5.133348020858679i


p =

 -0.027577318242359 + 5.174655410828068i
 -0.027577318242359 - 5.174655410828068i
 -0.500384298611703 + 6.310552036591990i
 -0.500384298611703 - 6.310552036591990i
 -0.237055716999485 + 6.881204941979009i
 -0.237055716999485 - 6.881204941979009i
 -1.408223271160550 +14.874570175309771i
 -1.408223271160550 -14.874570175309771i


k =

    -2.723835471763049e-04

 Then I approximated the reversed actuator TF  and placed it to the C1:OAF-SUS_MC2_OUT filter bank. The gain to the static filter output is -1.

P.S. Also the static matrix was filled with 1 for some reason. Here is the script to fix it if if will be bad again

for i in {1..8}
do
    for j in {1..28}
    do
        element="C1:OAF-STATIC_STATMTX_"$i"_"$j"_GAIN"
        ezcawrite $element 0
    done
done

 

 

  6296   Sat Feb 18 17:01:26 2012 DenUpdateAdaptive Filteringstatic variables

In order to prevent different DOF from redetermining static variables in the adaptive code, I've created a separate code for each DOF with the name ADAPT_XFCODE_{$DOF}.c

I've provided the links for these files in the c1oaf.mdl, compiled and run it. Now there are no conflicts between DOFs.

  3999   Tue Nov 30 16:02:18 2010 josephbUpdateCDSstatus

Issues:

1) Turns out the /opt/rtcds/caltech/c1/target/gds/param/testpoint.par file had been emptied or deleted at one point, and the only entry in it was c1pem.  This had been causing us a lack of test points for the last few days.  It is unclear when or how this happened.  The file has been fixed to include all the front end models again.  (Fixed)

2) Alex and I worked on tracking down why there's a GPS difference between the front ends and the frame builder, which is why we see a 0x4000 error on all the front end GDS screens. This involved several rebuilds of the front end codes and reboots of the machines involved. (Broken)

3) Still working on understanding why the RFM communication, which I think is related to the timing issues we're seeing.  I know the data is being transferred on the card, but it seems to being rejected after being red in, suggesting a time stamp mismatch. (Broken)

4) The c1iscex binary output card still doesn't work.  (Broken)

Plan:

Alex and I will be working on the above issues tomorrow morning.

Status:

Currently, the c1ioo, c1sus and c1iscex computers are running with their front ends. They all still have 0x4000 error.  However, you can still look at channels on dataviewer for example.  However, there's a possibility of inconsistent timing between computer (although all models on a single computer will be in sync).

All the front ends where burt restorted to 07:07 this morning.  I spot checked several optic filter banks and they look to have been turned on.

  3681   Fri Oct 8 17:35:24 2010 josephbUpdateCDSstatus of c1ioo, c1sus and rfm

RFM is still not working.  I can see data on a filter just before it reaches the RFM sending code, but I see only zeros on the receiving side.

c1sus machine and c1x02, c1sus, c1mcs, c1rms are running.  At the moment, the c1mcs model is running at about 42 microseconds for USR time and 56 microseconds for CPU MAX, which is close to the 61 microsecond limit.  This is with MC filters on.  So far it has not been late, but its not clear to me if its going to stay that way.  So far I haven't been able to isolate why it sometimes slows down after a few minutes.  Also, it was running faster earlier in the day (around 30-ish microseconds) and I believe it has slowed down slightly in the last hour or two.

c1ioo machine and c1x03, c1ioo are running. However its not doing very much good as I can't get any data transferred from it to any of the optic suspensions. I need to spend some more time debugging this and then grab Alex I think.

  1302   Fri Feb 13 16:30:49 2009 steveConfigurationGeneralstatus quo is disturbed

I have been getting ready for the annual safety inspection in the past 2-3 days.

Meaning cleaning up and disturbing the status quo on the floor  mostly under the optical tables and their surroundings.
For example: pd power supplies, He/Ne laser ps. and their positions.
BNC cables and ac power line positions can be different.
The new rule: no electronic equipment on the floor.
 
All electronic equipment were moved-placed into a plastic dish or tray.
  4917   Thu Jun 30 03:26:40 2011 kiwamuUpdateABSLstatus update

Status update of the absolute length (ABSL) measurement:

 - To accommodate the ABSL stuff, the AS path was relocated on the AP table.

     (In this evening Jenne was able to lock MICH with AS55, so it's working fine.)

 - On the AP table all of the necessary items, including the NPRO, a Faraday, some mirrors and etc., were in place

 - The mode matching was coarsely done. The Rayleigh range looked reasonably long.

 - Fine alignments will be done tomorrow

 - Also a picture of the setup will be uploaded in the morning.

  4694   Wed May 11 22:52:55 2011 kiwamuUpdateLSCstatus update and plan

Rana forced me to write this entry for summary because he didn't come to the 40m meeting today.

Status update :

    Interferometer Input Beam alignment with the PZTs.

     60 % done. The rest of the 40 % is to make the procedures automated.

     The beam spots on ITMY and ETMY are centered within ~1 mm accuracy.

     PRM, BS, ITMX, & ITMY actuator calibrations and PRC/MICH error calibrations

    Ongoing: First we will do it by hand, then some scripts will be made for the calibraion and resultant noise budget.

     F2A Suspension filter calculations.

      ETMY and ITMY are done. Need volunteer for ETMX, ITMX, BS, PRM, & SRM !!

      Bounce-Roll notch filters

      Leo is working on it. 25% complete...

     DC signal from RFPDs

      The RFPDs have a local SMA DC output as well as a DC output from their PD Interface cards in the LSC rack. We have hooked up some of the PD Interface DC outputs to the LSC ADCs but not tested??

Next steps:

  Installation of a temporary (Thorlabs) DCPD on either POY to see the intra-cavity power in the PRC. It would be ridiculous to put detectors on POX or POP since they're still clipped.

  D-phase and amplitude imbalance adjustment of the demod baords.

          make a script which uses pynds.

  Alignment of the full interferomter, starting from the X arm

  Loss measurements for the arms

  Schnupp asymmetry measurement

  

  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

  4174   Thu Jan 20 04:43:28 2011 kiwamuUpdateGreen Lockingstatus update: PLL connected to ADC

 I connected the PLL signal to the ADC on c1ioo. 

So now we are able to take the data into the digital world, and will be able to feedback signals to the suspensions.

 The output signal from the VCO box goes to a black beakout board on 1X2 rack though a BNC cable.  

Then the signal comes out from the back side of the board with DB39 style, so I put a DB39 to SCSI adapter so that we can take it to the IO chasis.

Now the SCSI is connected to ADC_1 (the second ADC card) on the IO chasis at 1X1. 

 

  Additionally I modified the green locking simulink model, C1GCV, in order to pick the right ADC channels.

A medm screen for green locking is now under the construction. I put a link on the sitemap screen, so anyone can look at the half-baked green locking screen.

Any comments and suggestions are really welcome.

  4176   Thu Jan 20 15:15:39 2011 kiwamuUpdateGreen Lockingstatus update: PLL connected to ADC

I realized that the black AA board I mentioned on the last entry has the same range issue as Valera reported before (see #3911)

Basically our ADC card has +/- 10V input range, but on the other hand the AA board is already limited by approximately +/- 2V.

We have to fix it.

Quote: #4174

  The output signal from the VCO box goes to a black beakout board on 1X2 rack though a BNC cable.  

Then the signal comes out from the back side of the board with DB39 style, so I put a DB39 to SCSI adapter so that we can take it to the IO chasis.

Now the SCSI is connected to ADC_1 (the second ADC card) on the IO chasis at 1X1. 

  7089   Mon Aug 6 10:53:32 2012 steveUpdateVACstatus: vauum normal

 

 The power outage did not have any effect on the vacuum system.  I had to open VM1 to the RGA because of flaky CC1 cold cathode gauge fluctuations.

We are running on the vertically positioned CC1 again.

Note: rga scans with closed VM1 are back ground scans.

Attachment 1: CCgauges.png
CCgauges.png
  7682   Wed Nov 7 15:17:15 2012 SteveUpdateAlignmentsteering option with pico motor?
We have two ready for vacuum 1.5" mirror mounts with pico motors in our hands. 


 
Attachment 1: IMG_1795.JPG
IMG_1795.JPG
  9187   Thu Oct 3 00:01:59 2013 rana, jenneHowToLSCsteps to full IFO

In moving now to full IFO locking, there are a number of sub-states to diagnose:

  1. PRMI + 1 arm
  • Measure sensing matrix as arm is scanned into resonance. Compare time series of sensing matrix elements with New LoopTickle simulation. But first, we need more than 1 LOCKIN screen in the LSC! That will allow us to measure all of the elements of front_matrix.jpg simulataneously.
  • Measure 3f PRMI noise spectra as a function of arm position. Look for trouble.
  1. DRMI + 1 arm
  • Same as PRMI above.
  • Want to find why this is unstable sometimes. Make stable for t > 10 minutes.
  • Maybe add some QPD->ASC for SRC angular control, but how? Will this still work after the arms are resonant or will it be swamped by carrier contrast defect? Will Berlusconi ruin all of the Italian gelateria? Only time can tell...
  1. FPMI (non optically recombined) for ALS diagnosis
  2. PRFPMI (iLIGO configuration)
  • this ought to be easier than DRFPMI
  • will let us tell if our ALS is good enough to handle the coupled cavity pole
  1. DRFPMI (aLIGO style)

Which to do first and in what order?

  9189   Thu Oct 3 01:18:57 2013 KojiHowToLSCsteps to full IFO

I vote on PRMI+1arm -> PRFPMI

  6678   Thu May 24 16:39:47 2012 steveUpdateGeneralsteve's webpage example

3 strip charts monitoring on 24 hours time scale: Vac,  PSL-IFO,  SUS and 10 channel video monitoring inside - outside  of 40m lab

Attachment 1: 05241201.PDF
05241201.PDF
  1777   Wed Jul 22 11:18:49 2009 robConfigurationComputerssticky sliders

Quote:

Quote:

Quote:

Quote:

All suspentions are kicked up. Sus dampings and  oplev servos turned off.

c1iscey and c1lsc are down. c1asc and c1iovme are up-down

 The computers and RFM network are up working again. A boot fest was necessary.Then I restored all the parameters with burtgooey.

The mode cleaner alignment is in a bad state. The autolocker can't get it locked. I don't know what caused it to move so far from the good state that it was till this afternoon.  I went tuning the periscope but the cavity alignment is so bad that it's taking more time than expected. I'll continue working on that tomorrow morning.

 I now suspect that after the reboot the MC mirrors didn't really go back to their original place even if the MC sliders were on the same positions as before.

 Alberto, Rob,

we diagnosed the problem. It was related with sticky sliders. After a reboot of C1:IOO the actual output of the DAC does not correspond anymore to the values read on the sliders. In order to update the actual output it is necessary to do a change of the values of the sliders, i.e. jiggling a bit with them.

 I've updated the slider twiddle script to include the MC alignment biases.  We should run this script whenever we reboot all the hardware, and add any new sticky sliders you find to the end of the script.  It's at

 

/cvs/cds/caltech/scripts/Admin/slider_twiddle

  1359   Thu Mar 5 01:09:29 2009 rana, albertoUpdateDMFstill not working
We tried to run DMF on mafalda, but it didn't work. I tried to compile it using Rob's elog instructions.
On mafalda, I started matlab and ran the mdv_config.m to set up mDV. I tested that the seisBLRMS.m
script ran and correctly produced changes in the seisBLRMS strip tool. but when I tried to compile it I got:
>> mcc -v -m -R -nojvm seisBLRMS.m
Warning: Duplicate directory name: /cvs/cds/caltech/apps/linux/matlab/toolbox/local.
Compiler version: 4.6 (R2007a)
Processing /cvs/cds/caltech/apps/linux/matlab/toolbox/matlab/mcc.enc
Processing /cvs/cds/caltech/apps/linux/matlab/toolbox/signal/mcc.enc
Processing /cvs/cds/caltech/apps/linux/matlab/toolbox/control/mcc.enc
Processing /cvs/cds/caltech/apps/linux/matlab/toolbox/filterdesign/mcc.enc
Processing /cvs/cds/caltech/apps/linux/matlab/toolbox/shared/controllib/mcc.enc
Processing /cvs/cds/caltech/apps/linux/matlab/toolbox/ident/mcc.enc
Warning: an error occurred while parsing class FilterDesignDialog.AbstractEditor:
Undefined function or variable 'DAStudio.Object'.

> In /cvs/cds/caltech/apps/linux/matlab/toolbox/shared/filterdesignlib/@FilterDesignDialog/@CoeffEditor/schema.p>schema at 9
Warning: an error occurred while parsing class FilterDesignDialog.CoeffEditor:
Invalid superclass handle.

Processing /cvs/cds/caltech/apps/linux/matlab/toolbox/fixedpoint/mcc.enc
terminate called after throwing an instance of 'ApplicationRedefinedException*'
Abort (core dumped)
"/cvs/cds/caltech/apps/linux/matlab/bin/mcc" -E "/tmp/fileRnU5Qj_31324": Aborted
??? Error executing mcc, return status = 134.

In the meantime, I've started up a green terminal on allegra which is ssh'd into megatron.
On megatron there is a regular matlab session which is running seisBLRMS.m as a matlab script
and the seis DMF channels are getting updated.
  12183   Wed Jun 15 11:21:51 2016 jamieUpdateCDSstill work to do to transition to new configuration/code

Just to be clear, there's still quite a bit of work to fully transition the 40m to this new system/configuration.  Once we determine a good configuration we need to complete the install, and modify the setup to run the two binaries instead of just the one.  The data is also being written to a raid on the new fb1, and we need to decide if we should use this new raid, or try to figure out how to move the old jetstor raid to the new fb1 machine.

  4789   Mon Jun 6 17:28:31 2011 steveUpdateComputersstill, no PEM channels

Quote:

AA filter box was removed and modified at 1Y7 today. The -5V power supply was current limited when I plugged it back in. It was removed for medical attention.

NO PEM channels available! because of this.

 

 D68L8EX-850Hz filter chips were removed and bypassed-shorted as Rana's entry on March 17, 2006 in old elog.

This unit is still has a short somewhere.

Attachment 1: P1070846.JPG
P1070846.JPG
  5361   Wed Sep 7 18:19:37 2011 steveHowToVACstop pump down for overnight

Quote:

Jamie and Steve

We closed ITMX and ITMY chambers and started pumping around 11am

What we did before:

1, turned off AC power  to PZT Jena HV ps

2, checked jam nut positions

3, cheched  single o-ring shims

4, closed psl out shutter

 We are at 30 Torr of 7 hours of pumping with 2 roughing pumps.

Kiwamu will take over the rest of the roughing today. He will keep an eye on  the pumping speed to be  ~1-2 Torr/min  and open up the manual RV1 valve if needed.

The present status is #3023 of  "chamber open to vacuum open" mode and waiting the P1 pressure to drop to 500 mTorr

He will do the following to stop pumping at P1 = 500 mTorr

1, close V3

2, close RV1 with torque wheel

3, turn off PR1 & 3

4, disconnect metal hose between RV1 and PR3

 I will start the Maglev tomorrow morning.

  3854   Wed Nov 3 16:49:31 2010 steveUpdateGeneralstorage cabinet is in place

The south end of IFO room 104 was reshuffled. The flow bench was moved all the way to the south end to create more room for the crane reach. The old  large drawing cabinet  was moved under the vacuum tube.

The new clear view through  Acrylic-plexyglass cabinet is anchored. It has powder finished coating so it will not out-gas too much.The back side shelf mounting holes are sealed off with kapton tape. The doors still needs some gaskit seals.

Attachment 1: P1070018.JPG
P1070018.JPG
  6045   Tue Nov 29 22:19:26 2011 DenUpdatedigital noisestraight line

 I tried to understand what part of the signal is corrupted while passing through a digital straight line without any filters. From here we can figure out what precision is used.

I analysed coherence between C1:SUS-MC3_LSC_EXCMON and C1:SUS-MC3_LSC_OUTMON without any filters between them. 

real_coherence.jpg

I did the simulation in Matlab using single and double precision. Basically, I took a random signal, made some operations with it to obtain some digital error:

signal1 = randn(1e6, 1);          signal2 = randn(1e6, 1);         signal3 = signal1+signal2;          signal4 = signal3 - signal2;

Then I plotted coherence between signal1 and signal4 that are actually the same signal but signal4 has some digital error. This was done both for single (left red plot) and double (right blue plot) precision.

float_coherence.jpg        double_coherence.jpg

From here we make a conclusion that C1:SUS-MC3_LSC_EXCMON and C1:SUS-MC3_LSC_OUTMON has single precision. The signal might be converted from double to single in the dtt tools but if dtt works with double precision then the problem is with signals.

  4728   Mon May 16 17:11:28 2011 steveUpdateElectronicsstrain relieved 1X1

1X1 is strain relieved in the back. I will use similar approach on the rest of the racks .

Attachment 1: P1070724.JPG
P1070724.JPG
  4475   Thu Mar 31 11:30:51 2011 steveConfigurationGeneralstrain relieved rf cables

I strain relieved RF cables labeled 33 MHZ LO and 166 MHZ to EOM at 1X2  This is a temporary setup for the 11 MHZ

The coax N  bulkheads connectors are mounted on the plastic front panel now.

Attachment 1: P1070491.JPG
P1070491.JPG
  4036   Thu Dec 9 12:24:46 2010 kiwamuUpdateSUSstrange ETMX suspension

[Koji, Osamu and Kiwamu]

We found that the ETMX free swinging spectra showed a strange resonant frequencies.

We are going to inspect the suspension today.

 


(resonant frequencies)

In a ideal case the SOS (Small Optic Suspension) is supposed to have the following resonant frequecies.

(Although we didn't carefully identify which corresponds to which)

  f_POS ~ 0.98 Hz

 f_PITCH ~ 0.66 Hz

 f_YAW ~ 0.8 Hz

 f_SIDE ~ 0.99 Hz

However ETMX showed the following resonant frequencies.

  f_POS ~ 0.91 Hz

 f_PITCH ~ 0.7 Hz

 f_YAW ~ 0.93 Hz

 f_SIDE ~ 1.0 Hz

Especially f_YAW looks pretty high. Also the others are not at the right frequencies.

So we are suspicious that something wrong is happening on the ETMX suspension.

 

ETMX_spectr.png

  658   Fri Jul 11 00:30:24 2008 robMetaphysicsComputersstrange SUS controllers

rob, johnnieM

We were hampered early tonight by the fact that someone sneakily turned off the HP RF Ampflier on the AS table.

After that, we were hampered further by mode cleaner strangeness. It would occasionally spontaneously unlock & blow its watchdogs. It never made it through the ontoMCL script (putting DC-CARM onto the MCL). After some investigation, we found that c1susvme1 and c1susvme2 were running stochastically late (SYNC_FE != 0), even though their computation times never got above 61. Also, the end SUS controllers were never late.

Weird.

After rebooting the vertex SUS controllers and the c1lsc, things appear to be working again.
  11815   Wed Nov 25 23:17:34 2015 yutaroUpdateLSCstrange behavior of ASDC

[yutaro, Koji]

I noticed that ASDC level changes depending on the angle of ITMY when trying to take some data for loss map of YARM. We finally found that ASDC level behaves strangely when the angle of ITMY in yaw direction is varied, as you can see in Attachment 1. Now, AS port recieved only the reflection of ITMY. 

NOTE: This behavior indicates that angular motion could couple to length signal in AS port.      

Koji suggested that this behavior might be caused by interference at SR2 or SR3 between main path light and the light reflected by the AR surface. By rough estimation, we confirmed that this scenario would be possible. So it would be better to measure AR reflection of the same mirror to ones used for SR2 and SR3 in term of incident angle.     

Ed by KA: This senario could be true if the AR reflection of teh G&H mirrors have several % due to large angle of incidence. But then we still need think about the overlap between the ghost beam and the main beam. It's not so trivial.

Attachment 1: 14.png
14.png
  11827   Mon Nov 30 16:33:06 2015 ericqUpdateLSCstrange behavior of ASDC

One possible explanation of this behavior is simply poor centering of the AS beam on AS55 (whose DC level provides ASDC, if memory serves me correctly).

I misaligned ETMY, and moved ITMY through its current nominal alignment while looking at the POYDC and ASDC levels. 

In both pitch and yaw, the nominal alignment is fairly close to the "plateau" in which the AS beam is fully within the PD active surface. I.e. it doesn't take much angular motion to start to lose part of the beam, and thus introduce a first order coupling of angle to power. (Look at the plateaus at around -2min and -0.5min, and where the rapidly changing oplev trace crosses zero)

Furthermore, POYDC seems to be in some weird condition where it is actually possible to increase the reported powerwhen misaligning in pitch, but somehow there is more angular coupling in this state. 

In any case, I would advise that the POY11 and AS55 RFPDs have their spots recentered with optics in their nominal aligned states. In fact, given how we found REFL11 alingment to be less-than-ideal not so long ago, all of the RFPDs could probably use a checkup. 

  11829   Mon Nov 30 18:27:30 2015 KojiUpdateLSCstrange behavior of ASDC

It wasn't fully mentioned in ELOG 11814.
We checked the PD first and this behavior didn't change after the realignment of the AS55PD.
Yutaro confirmed that this effect is happening in the vacuum chamber.

  11870   Thu Dec 10 12:33:04 2015 yutaroUpdateLSCstrange behavior of ASDC

I did additional tests for the strange behavior of ASCD. ETMY, ETMX and ITMY were misaligned so that only light reflected by ITMX went into AS port. I had done similar measurement before with ITMY YAW varied.

Attachment 1 shows how ASDC level changed when ITMX PIT varied.

Attachment 2 shows how ASDC level changed when ITMX YAW varied.

Attachment 3 shows how the power of light measured by a power meter just after the AS view port varied when ITMX YAW varied.

 

Comparing 1 & 2, we can say that this behavior is not unique to YAW direction.

From 2 & 3, we can say something strange is happening inside the chamber.   

 

Attachment 1: 07.png
07.png
Attachment 2: 28.png
28.png
Attachment 3: ASDC.png
ASDC.png
  11871   Thu Dec 10 19:53:22 2015 yutaroUpdateLSCstrange behavior of ASDC

To check if the strange behavior of ASDC is caused by SR2/SR3 or not, I did the following measurement:

ASDC measures the power of the light reflected by ITMX. POXDC measures the power of the light reflected by ITMX and SRM successively. Then I varied the angle of ITMX in YAW direction and compared the behaviors of ASDC and POXDC.

The results are shown in Attachments 1-3.

As you can see in these figures, the strange up-and-down behavior appeared ONLY in ASDC. Therefore, the cause of this behavior exists between AS table and SRM (I had confirmed that the angle of SRM did not affect ASDC).

And this behavior is fringe-like, as can be seen in the figures (there seems to be 3 "peaks" and 2 "valleys"), so the cause could be interference between main path and not good AR reflection at a mirror after SRM before AS table (I suspect a mirror is flipped mistakenly).   

Attachment 1: 30.png
30.png
Attachment 2: 11.png
11.png
Attachment 3: 49.png
49.png
  13132   Sun Jul 23 15:00:28 2017 JamieOmnistructureVACstrange sound around X arm vacuum pumps

While walking down to the X end to reset c1iscex I heard what I would call a "rythmic squnching" sound coming from under the turbo pump.  I would have said the sound was coming from a roughing pump, but none of them are on (as far as I can tell).

Steve maybe look into this??

  6184   Tue Jan 10 09:17:23 2012 steveUpdatePhotosstrawman's visiters
Attachment 1: P1080491.JPG
P1080491.JPG
Attachment 2: P1080492.JPG
P1080492.JPG
  2650   Tue Mar 2 12:20:54 2010 kiwamuUpdatePSLstray beam

In order to block stray beams, I have put some beam dumps and razor blades on the PSL  table.

There were three undesired spots in total. I found two spots on the south side door of the PSL room, close to Mach-Zehnder.

Another spots was on the middle of the north door. Now they all are blocked successfully.

  6698   Tue May 29 00:48:51 2012 DenUpdatePEMsts readout box

STS readout box seems to be partly broken. I've terminated inputs from the seismometer and measured the output. I could not do this for vertical channel because it outputs 7 V DC + 500 mV AC signal. All the switches work fine, 5 V DC is indeed shown when auto zero, calibration, 1 sec resp, sig select are enables. The box has AC power supply that seems to work ok, all measured DC values are equal to the labels. Something is wrong with amplification.

 

sts_box.png

 

  6427   Sun Mar 18 00:29:24 2012 DenUpdatePEMsts-2

I've turned off the power of the STS-2 readout box as it provides outputs with ~10 Volts DC offset! AA filter box works in the range -2 +2 Volts, so we do not have any useful information anyway. I'll adjust the mass positions in the seismometer.

  6747   Sun Jun 3 01:30:07 2012 DenUpdatePEMsts-2 and guralp in isolation box

We have 2 sts-2 readout box - pink and blue. Pink outputs 12 DVC - this a problem of amplifier. This box has a rectifier (the box works from AC power) and an amplifier for velocity channels. Mass positions, calibration channels are connected by a wire from input to output. The amplifier for velocity channels does not work properly, so I connected velocity channels directly to the output - the signal from sts-2 is large enough even without amplification. When I plugged sts-2 to pink readout board, on the velocity output I saw ~4 VDC. Sts-2 was needed to be recentered. I pressed AUTOZERO command, but this did not work out. Before I had checked that this readout box indeed gives an autozero logical signal - 5VDC for ~2 sec. I think it does not provides sts-2  with enough current, seismometer needs 0.1 A in autozero regime.

Blue readout box after switching it to 1 sec regime and zeroing sts-2 started to output reasonable signal for gains = 10. I tried gains = 100, X velocity channel started to output noise. Now the gain is 10 and the response is 120 sec. But at least this box works. Still performance is not clear as well as noise level. To determine this I've put sts-2 to isolation box.

DSC_4315.JPG                    DSC_4319.JPG

After I've put Guralps in the isolation and waited for a couple of days, Guralp noise has been improved a little more.

lin_box_noise.png                 mcl_gur.png

  6818   Thu Jun 14 21:37:37 2012 yutaUpdateGreen Lockingsucceeded in 1FSR mode scan

[Jenne, Yuta]

We couldn't scan the Y arm for 1FSR last night because the ALS servo breaks while sweeping.
We thought this might be from the amplitude fluctuation of the beat signal. The amplitude of the beat signal goes into the beatbox was about -5 dBm, which is not so enough for the beatbox to get good LO. So, we put an amplifier (and attenuators) and the amplitude became +1 dBm. The range beatbox can handle is about -3 dBm to +3 dBm, according to our calculation.

This increased stability of the lock, and we could scan the arm for 1FSR. Below is the plot of scanned ALS error signal (blue), Y arm IR PDH signal (green) and TRY (red).

YarmScan20120614.png

For each slope, we can see two TEM00 peaks, some higer order modes(may be 01, 02, 02) and sidebands (large 11MHz, small 55MHz?).

We couldn't scan for more. This is still a mystery.

Also, we need to reduce residual Y arm length fluctuation more because we get funny TRY peak shape.

Scan speed:
  For C1:ALS-BEATY_COARSE_I_IN1, 1 count stands for 0.21 nm(see elog #6817). We sweeped 4000 peak to peak in 50 sec. So, the scan speed is about 17 nm/sec.
  This means it takes about 0.06 sec to cross resonant peak.
  Cavity build up time is about 2LF/(pi*c) ~ 40 usec. So, the scan is quasi-static enough.
  Characteristic time scale for the Y end temperature control is about 10 sec, so Y end frequency is following the Y arm length change with temperature control.

  Currently, sampling frequency of DQ channels are 2048 Hz. This means we have 100 points in a TRY peak. I think this is enough to get a peak height.

Next step:
  - Reduce RMS. We are trying to use a whitening filter.
  - Find why we can't scan more. Why??
  - ETMY coil gains may have some unbalance. We need to check
  - Characterize Y end green frequency control. Koji and I changed them last week (see elog #6776).
  - Calculate positions of RF SBs and HOMs and compare with this result.

  5985   Wed Nov 23 00:30:55 2011 ZachUpdateelogsucks

Tried the script 3 times and it didn't come back. Pkill'd and then scripted. That worked.

  255   Wed Jan 23 11:41:06 2008 steveUpdatePEMsulfur smell in 40m
Led - acid car batteries were overcharged in the machine shop next door
and sulfuric acid smell is coming over to the ifo room.

Entry room 103 is specially bad.
ELOG V3.1.3-