40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 154 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  198   Tue Dec 18 23:27:36 2007 AndreyConfigurationComputer Scripts / ProgramsNew overnight measurements (this night from Tue to Wed)

I am making overnight measurements in XARM tonight.

This is the third night of measurements in XARM, but tonight I am scanning the narrower region between values of damping gain 1.00 and 4.50 with the smaller step 0.25. (for comparison, during two previous measurements the region was between 1.0 and 7.0 with the step 0.5).

I have relocked the XARM before the start of the measurements.

I started running the program at 9.30PM, and it should collect all the data by 9.00AM wednesday morning.

Below are explanations why I chose these different parameters for the interval and step:

I am going to put the results of previous night measurements into the next ELOG entry, and it we be pretty obvious from those graphs that results in XARM from the two previous (different) nights agree well with each other, and the approximate positions of minima and areas of "big growth" of the surfaces are pretty obvious from those graphs. It is clear that RMS are too big for the values of the damping gain bigger than 4.0, and that minima are somewhere near the values of 2.0. But those graphs were too rough to locate a somewhat precise value for the minima. Therefore, I am studying tonight the interval of gains between 1.00 and 4.50 with a smaller step.

A short note how I estimate time that is necessary to collect the experimental data.

there are 15 experimental points for each ETMX and ITMX suspension gains in the interval between 1.00 and 4.50 with the step 0.25. They are: 1.00, 1.25, 1.50, 1.75, 2.00, ..., 3.75, 4.00, 4.25, 4.50. As I am changing both ETMX and ITMX gains, I have an array of 15*15=225 elements.
It takes 3 minutes for each point to collect the data (I wrote the program that way). Therefore, the total time it takes to run the program is: 225*3=675 minutes, or 675/60=11.25 hours, almost 11 and a half hours.
  205   Thu Dec 20 02:04:09 2007 AndreyUpdateComputer Scripts / ProgramsNew overnight measurements in XARM and their results

I ran in the daytime/evening time my program, changing the damping gains in suspension "position" degree of freedom for ETMX and ITMX
in the interval from 1.00 to 3.75 with the step 0.25 (see entry # 201).

Now I am running overnight (from 2AM till 9AM) the program changing the gains in the interval from 1.3 to 3.5 with the step 0.20,
12 X 12 = 144 experimental points. I started so late because I fell asleep after my Wednesday evening dinner, then woke up half an hour ago and hurried to the lab.

BELOW: RESULTS OF MEASUREMENTS WERE ADDED ON THURSDAY EVENING, DEC. 20.

All the meaning of the attachments 1-3, 4-6, 7-9, 10-11 is the same as in previous ELOG entries # 195, # 199, # 202, see in those entries which graph corresponds to which coordinate axes orientation.
Attachment 1: RMS-08Hz-Top-View.png
RMS-08Hz-Top-View.png
Attachment 2: RMS-3Hz-Top-View.png
RMS-3Hz-Top-View.png
Attachment 3: RMS-broadband-Top-View.png
RMS-broadband-Top-View.png
Attachment 4: RMS-08Hz-Side_View.png
RMS-08Hz-Side_View.png
Attachment 5: RMS-3Hz-Side_View.png
RMS-3Hz-Side_View.png
Attachment 6: RMS-broadband-Side_View.png
RMS-broadband-Side_View.png
Attachment 7: RMS-08Hz-Q_I-Q_E-Axes.png
RMS-08Hz-Q_I-Q_E-Axes.png
Attachment 8: RMS-3Hz-Q_I-Q_E-Axes.png
RMS-3Hz-Q_I-Q_E-Axes.png
Attachment 9: RMS-broadband-Q_I-Q_E-Axes.png
RMS-broadband-Q_I-Q_E-Axes.png
Attachment 10: Accelerometer-ETMX.png
Accelerometer-ETMX.png
Attachment 11: Accelerometer-ITMX.png
Accelerometer-ITMX.png
  15554   Thu Sep 3 00:00:57 2020 gautamUpdateBHDNew patch cable installed
  • 10m PM1064 cable was installed. I tried a double shielding approach (photos tmrw here), but I suspect the real weak point is where the fiber is plugged into the collimator - it's hard to imagine we can stabilize this sort of arrangement to better than 100um absolute length over long periods of time, I'd think thermal/mechanical strains in the fiber will modulate the length by ~mm (?). Anyways, let's see what the heterodyne measurement tells us.
  • This work required (i) realignment at the input coupler and (ii) change of position of mode matching lenses in the LO path on the AS table to see any interference with the IFO beam. This indicates something was seriously wrong with the old patch cable, as the collimator should set the mode. The MFD of the two fibers may have been different, but I don't know if that alone can account for it.
  • As of now, I have fringes between the ITM single bounce and the LO, but the fringe pk-pk is only 10% of the theoretical pk-pk based on DC values of the LO and AS beams. So the mode matching can be improved significantly (I preivously had ~60%).

To be continued tomorrow. I think it's a good idea to let the newly installed fiber relax into some sort of stable configuration overnight.

  286   Wed Jan 30 13:09:55 2008 AndreyUpdateSUSNew results for XARM (pdf)

See attachments: pdf-presentation with plots in "true" axes Q_ETMX and Q_ITMX, and seismic backgound measurement.

Results that were shown a week ago turned out to be not sad at all!
Attachment 1: New_Results_XARM.pdf
New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf
Attachment 2: Accel-Seismic_10AM.pdf
Accel-Seismic_10AM.pdf
  11065   Wed Feb 25 11:01:05 2015 manasaUpdateComputer Scripts / ProgramsNew screen for FOL PID loop

Created a new medm screen C1ALS_FOL_PID.adl for FOL PID loop control in /medm/als/master/

This is not currently linked to the sitemap screen.

  5792   Wed Nov 2 22:02:39 2011 JenneUpdatePhotosNew screen snapshot script written!

After lots of trial and error, and a little inspiration from Koji, I have written a new script that will run when you select "update snapshot" in the yellow ! button on any MEDM screen. 

Right now, it's only live for the OAF_OVERVIEW screen.  View snapshot and view prev snapshot also work. 

Next on the list is to make a script that will create the yellow buttons for each screen, so I don't have to type millions of things in by hand.

The script lives in:  /cvs/cds/rtcds/caltech/c1/scripts/MEDMsnapshots, and it's called....wait for it....... "updatesnap".

 

  2729   Mon Mar 29 15:26:47 2010 MottHowToComputersNew script for controlling the AG4395A

I just put a script in the /cvs/cds/caltech/scripts/general/netgpibdata/ directory to control the network analyzer called AG4395A_Run.py .   A section has been added to the wiki with the other GPIB script sections (http://lhocds.ligo-wa.caltech.edu:8000/40m/netgpib_package#AG4395A_Run.py)

  2738   Wed Mar 31 03:45:49 2010 MottHowToComputersNew script for controlling the AG4395A

 

I took data for the 2 NPRO PLL using the script I wrote for the AG4395, but it is very noisy above about 1 MHz.  I assume this is something to do with the script (since I am fairly confident we don't have 600 dB response in the PZT), so I will go in tomorrow to more carefully understand what is going on, I may need to include a bit more latency in the script to allow the NA to settle a bit more.  I am attaching the spectrum just to show the incredibly high noise level, 

Attachment 1: noisy_spec.png
noisy_spec.png
  13299   Wed Sep 6 01:09:11 2017 johannesUpdateComputer Scripts / ProgramsNew set of loss measurements

I stumbled upon a faster way to stream data from the TDS3014 oscilloscopes to disk, which speeds the loss measurements up by a lot:  ftp://sprite.ssl.berkeley.edu/pub/sharris/MAVEN_LPW_Preamp/109_TDS3014B_control/tds3014b.py
This convenient(!) set of scripts contains a function that parses the scope's native binary format, for which the acquisition of 1 screenful of data takes <1s as opposed to ~20s, into readable data. I tested it for a bit and concluded that it does what it actually claims to do, but there's one weirdness: It get's the channel offset wrong. However this doesn't matter in our measurement because we're subtracting the dark level, which sees the same (wrong) offset. Other than that it seems okay.

So I started a new set of armloss measurements, and since the data acquisition is now much faster, I was able to squeeze a set of 20 individual measurements for each arm into ~30 minutes. This is the procedure I follow when I take these measurements for the XARM (symmetric under XARM <-> YARM):

  1. Dither-align the interferometer with both arms locked. Freeze outputs when done.
  2. Misalign ETMY + ITMY.
  3. ITMY needs to be misaligned further. Moving the slider by at least +0.2 is plentiful to not have the other beam interfere with the measurement.
  4. Start the script, which does the following:
    1. Resume dithering of the XARM
    2. Check XARM dither error signal rms with CDS. If they're calm enough, proceed.
    3. Freeze dithering
    4. Start a new set of averages on the scope, wait T_WAIT (5 seconds)
    5. Read data (= ASDC power and MC2 trans) from scope and save
    6. Misalign ETMX and wait 5s
    7. Read data from scope and save
    8. Repeat desired amount of times
  5. Close the PSL shutter and measure the PD dark levels

I will write a more comprehensive post describing the data acquisition and processing, let's just look at the results for now: The "uncertainties" reported by the individual measurements are on the order of 1-2 ppm (~1.9 for the XARM, ~1.3 for the YARM). This accounts for fluctuations of the data read from the scope and uncertainties in mode-matching and modulation depths in the EOM. I made histograms for the 20 datapoints taken for each arm: the standard deviation of the spread is a little over 2ppm. We end up with something like:

XARM: 49.3 +/- 2.1 ppm
YARM: 20.3 +/- 2.3 ppm

 

    

Attachment 1: XARM_20170905.pdf
XARM_20170905.pdf
Attachment 2: YARM_20170905.pdf
YARM_20170905.pdf
  4380   Mon Mar 7 17:22:39 2011 josephbUpdateCDSNew simulated plant work

[Joe, Jamie]

We modified the c1scx model to have a switch to go between simulated and real plants.  The channel is currently C1:SCX-SIM_SWITCH. 

When this channel is zero, the simulated plant channels are going to the ADCs and zeros  are going out to the real DACs.  When this channel is one, the real ADCs are coming in, and real data is going out to the DACs.

Jamie will be adding a big green/red light to the suspension screens which indicate the state of the simulated plant.  We will also eventually add this to the overall status screen.

A control screen for the simulated plant is located at /opt/rtcds/caltech/c1/medm/c1spx/master/C1SUP_ETMX.adl.  These are currently a work in progress.

  11166   Tue Mar 24 15:22:12 2015 manasaUpdateComputer Scripts / ProgramsNew slow channels for FOL

[Koji, Manasa]

I have created new slow channels for FOL. To do so, I have edited the fcreadout.db file in Domenica and the C0EDCU.ini file in /chans/daq

Domenica and frame builder were restarted after the edits.

Koji has moved the following files from /opt/rtcds/caltech/c1/chans/daq/ to /opt/rtcds/caltech/c1/chans/daq/trash  as they are not being used anymore.

C0EDCU1.ini
C1EDCU_X00.ini
C1EDCU_X10.ini
C1EDCU_X14.ini
C1X00.ini
C1X10.ini
C1X99.ini

  11799   Mon Nov 23 14:45:39 2015 ericqUpdateComputer Scripts / ProgramsNew software

COMSOL 5.1 has been installed at: /cvs/cds/caltech/apps/linux64/comsol51/bin/comsol

MATLAB 2015b has been installed at: /cvs/cds/caltech/apps/linux64/matlab15b/bin/matlab 

This has not replaced the default matlab on the workstations, which remains at 2013a. If some testing reveals that the upgrade is ok, we can rename the folders to switch. 

  3251   Tue Jul 20 15:06:48 2010 josephb, bobOmnistructureGeneralNew speakers in ceiling in control room

After the crane training, Bob attached speakers to the ceiling right next to the projector, for use with presentations.

  12124   Fri May 20 17:36:06 2016 gautamUpdateLSCNew stands for TransMon/Oplev QPDs

As we realized during the EX table switch, the transmitted beam height from the arm is not exactly 4" relative to the endtable, it is more like 4.75" at the X-end (yet to be investigated at the Y-end). As a result, the present configuration involves the steering optics immediately before the Oplev and TransMon QPDs sending the beam downwards at about 5 degrees. Although this isn't an extremely large angle, we would like to have things more level. For this purpose, Steve has ordered some Aluminium I-beams (1/2 " thick) which we can cut to size as we require. The idea is to have the QPD enclosures mounted on these beams and then clamped to the table. One concern was electrical isolation - but Steve thinks Delrin washers between the QPD enclosure and the mount will suffice. We will move ahead with getting these machined once I investigate the situation at the Y end as well.. The I beams should be here sometime next week...

  12142   Wed Jun 1 09:06:38 2016 SteveUpdateLSCNew stands for TransMon/Oplev QPDs

Machined from I-beam 6061 T6 Aluminum 5" x 0.5 x 3.25

Quote:

As we realized during the EX table switch, the transmitted beam height from the arm is not exactly 4" relative to the endtable, it is more like 4.75" at the X-end (yet to be investigated at the Y-end). As a result, the present configuration involves the steering optics immediately before the Oplev and TransMon QPDs sending the beam downwards at about 5 degrees. Although this isn't an extremely large angle, we would like to have things more level. For this purpose, Steve has ordered some Aluminium I-beams (1/2 " thick) which we can cut to size as we require. The idea is to have the QPD enclosures mounted on these beams and then clamped to the table. One concern was electrical isolation - but Steve thinks Delrin washers between the QPD enclosure and the mount will suffice. We will move ahead with getting these machined once I investigate the situation at the Y end as well.. The I beams should be here sometime next week...

Atm2, version 2 "pdstand" will allow you to clamp from any direction ( Koji was right )

Attachment 1: pdIb.PDF
pdIb.PDF pdIb.PDF
Attachment 2: pdstand.pdf
pdstand.pdf
  11448   Mon Jul 27 17:51:06 2015 EveUpdateSummary PagesNew summary page tabs and other improvements

The summary pages can still be found at https://nodus.ligo.caltech.edu:30889/detcharsummary/ (EDIT: in an older version of this post I listed an incorrect url). They are operational and include data from some channels for intermittent periods of time.

 

Motivation: to make the summary pages more informative and useful for all

 

What I did:

I have added tabs for ALS, ASC, and LSC subsystems. While there is currently no data on the plots, I plan on checking all channels with DataViewer to set appropriate axis ranges so that we can actually see the data.

I altered which channels are used to represent spectra for OpLev systems to more appropriately provide PSDs.

I've changed the check code status page to include "warning" labels. Previously, when the summary pages ran, resulting in a warning message, the check code status page would list this as an "error", implying that the summary pages were not properly produced.

 

Results:

All features were implemented, but I need to investigate some of these channels to understand why we aren't seeing many channels in the plots. I am working on some other changes to the summary pages, including providing a Locked status which will only show data in a timeseries for a selected period of time.

  7815   Wed Dec 12 14:59:49 2012 ManasaConfiguration40m UpgradingNew tip-tilts layout in BSC

I have updated the BSC layout to include the new tip-tilts. The bigger footprints of the tiptilts are on in the way of the existing PRM oplev path. So I have recalculated new PRM oplev paths. The proposed layout requires a new oplev mirror to be included.

 

bs.png

  4679   Tue May 10 16:42:49 2011 josephbUpdateCDSNew upconversion model (c1uct)

[Ryan, Joe]

Ryan added the c1uct (upconversion tester) model to the c1ioo machine.   It is DCU_ID 32, CPU 6.  The relevant wiki page has been updated. It has been added to /diskless/root/etc/rtsystab on the fb machine and automatically comes up when the c1ioo computer is turned on. 

Joe still needs to add its status to the status screen.

It is soft linked from:

/opt/rtcds/caltech/c1/userapps/trunk/CDS/c1/models/c1uct.mdl

Ryan will expand upon its uses later.

  16367   Thu Sep 30 14:09:37 2021 AnchalSummaryCDSNew way to ssh into c1teststand

Late elog, original time Wed Sep 29 14:09:59 2021

We opened a new port (22220) in the router to the martian subnetwork which is forwarded to port 22 on c1teststand (192.168.113.245) allowing direct ssh access to c1teststand computer from the outside world using:

                                                                       

                                                                                    
 

Checkout this wiki page for unredadcted info.

  13170   Mon Aug 7 22:50:57 2017 KojiUpdateGeneralNew wifi router for the GC network installed

I have replaced the old 11n wifi router (CISCO / Linksys) for the GC network with a new one with 11ac technology.

The new one is a 3band wifi router. Thus it has one 2.4GHz (11n) SSID and two 5GHz (11ac) SSIDs. All these have been set to be hidden. Just come to the 40m and find the necessary info for the connection.

Note that the user id / password for the admin tool have been changed from the default values.

  3889   Thu Nov 11 01:34:27 2010 JenneUpdateSUSNew-Old ETM towers assembled

[Suresh, Jenne]

We have put together the new-old ETM towers.  These are the ones which were hanging out on the flow bench down the arm for years and years, and have recently been re-baked.  Interestingly, these are predominantly steel, whereas the newer ones are mostly aluminum.  This caused momentary drama while we scrounged for the correct screws (we needed more silver-plated screws than anticipated, since we were screwing into steel and not aluminum), however the miscellaneous clean hardware collection came to the rescue.  We did however use up all of the 1/4-20 3/4" silver plated screws, so hopefully no one else needs more later...

We only found 5 (enough for one of the two towers) spring plungers which are used to hold the OSEMs in place.  Suresh is sending an email to Steve to ask him to buy some more, so we can get them cleaned in time for use.  This is important, but not super urgent, since we have ~ 2 weeks before the ETMs will be ready for installation. 

Koji has not yet had a chance to inspect the ETM data sheets and choose for us which pair of ETMs to use (ATF sent the 4 ETMs in matched pairs).  So we will not begin the "arts and crafts" until tomorrow-ish.

  9020   Fri Aug 16 21:15:04 2013 ranaUpdateCDSNew/old CDS laptop for X-End

I took the "aso-laptop" and made it into Ubuntu a couple months ago. Today I added it to the Martian network and then moved it to the X End.

I followed the instructions in (https://wiki-40m.ligo.caltech.edu/Network) and added it to the files in /var/named/chroot/var/named on linux1 and did the "service named restart".

The router already had his MAC address in its list (because Yoichi was illegally using his personal laptop on the Martian). The new laptop's name is 'asia'. This is a legal name according to our computer naming conventions and this Wikipedia page (http://en.wiktionary.org/wiki/Category:Italian_female_given_names). It has been added to the Name Pool on the wiki.

The terminal on the laptop still calls itself 'aso-laptop' so I need some help in fixing that. It successfully connects to 40MARS and displays a MEDM sitemap after sshing in to pianosa.

I use 'ssh -X -C' since I find that compression actually helps when the laptops are so far from the router.

  9297   Sat Oct 26 22:48:55 2013 ranaUpdateCDSNew/old CDS laptop for X-End

  I made the Yoichi laptop into a CDS laptop called 'asia' a few months ago. Somehow I mistakenly gave it the IP address of our little Acer laptop which is called 'farfalla'. This makes farfalla's network not work. I put the old Dell Aldabella by the PMC where farfalla was and am now upgrading farfalla from CentOS to Ubuntu 10.04 LTS 32-bit. I have updated the hostable on linux1 to give farfalla the 230 IP address and let 'asia' keep 225.

  11442   Thu Jul 23 21:12:14 2015 IgnacioUpdateGeneralNewer accelerometer huddle test data + detrending

In the last post concerning the self noise of the accelerometers, I mentioned the differences between the two data sets I was playing with. In order to give a more concrete analysis of the accelerometers self noise, we came to the conclusion that data taking time should be the same.

The plots below show the analysis for the following two datasets:

Old Data:  6 accelerometers, no cables clamped, no box, 55 mins worth of data.

Newer data: 3 accelerometers, cables clamped, foam box put on placed and completely sealed, 57.66 mins worth of data, (we had 20 mins of data in the previous data set).

Filter parameters were kept the same in all calculations, the only change that was added to the analysis was the detrending of the signals using the detrend function on Matlab, this improved the results as the plots show. I also plotted the error bars for the Wiener filtered result for reference as well as the manufactures claimed self noise.

   

After detrending the data and taking a longer dataset we can see the improvement brought upon by the foam box in the low frequency band of 0.5 - 10 Hz, as shown in the bottom left plot. There is a lot of noise that needs to be cancelled out from 10 Hz and on, which brings to our attention the plot on the bottom right corner. This plot uses the old data but uses all six accelerometers as witnesses, it also improved overall after having detrended the data, but what is peculiar about this plot is the fact that it manages to mitigate the higher frequency 10 - ~100 Hz band noise. 

 

Attachment 1: old_data_1.png
old_data_1.png
Attachment 2: old_data_2.png
old_data_2.png
Attachment 3: new_data.png
new_data.png
Attachment 4: six_old_data.png
six_old_data.png
  11450   Tue Jul 28 09:31:35 2015 IgnacioUpdateGeneralNewest accelerometer huddle test

I downloaded new accelerometer huddle test data from last night and analyzed it. This new data set is ~55 mins and uses the same Wiener filter parameters as previous huddle test analysis, the main difference being six accelerometers used in the Wiener filter and the improved experimental set up.

After computing the ASD for the self noise for each of the six accelerometers, (being witnessed by the remaining five), we get,

Now computing the mean of the above signals and the corresponding error bars gives the following result,

Comparing to prevoius huddle tests, I can note two trends on the Wiener subtraction:

1) When using six accelerometers, the subtraction above ~8 Hz drastically improves.

2) When using three accelerometers, there is better cancellation in the 1-5 Hz region, see http://nodus.ligo.caltech.edu:8080/40m/11442. This might have to do with how much more closer the accelerometers are to each other? 

Attachment 1: selfnoise_allsix_miso_newest.png
selfnoise_allsix_miso_newest.png
  12704   Thu Jan 12 02:45:53 2017 JohannesUpdateGeneralNext armloss steps

As stated in elog 12618, using an oscilloscope to average the reflected powers and thus circumventing all filtering yielded much better results than before:

XARM: 21 +/- 35 ppm
YARM: 69 +/- 45 ppm

We can probably decrease the measurement uncertainty further by using a larger photodiode that is more suited for DC measurements. It will be placed in the AS pathtemporarily. If we get below 10 ppm systematic errors will begin to matter. To get those under control I will have to re-determine the visibility in the arm cavities and the modulation indices. The numbers to match from an estimate via the power recycing gain are <= 50 ppm arm average from elog 12586. Once the measurement scheme is up and running, we can proceed to generate ETM lossmaps. ITM will still be tricky but let's see what we can do.

Following Yutaro's approach, we can move the beams on the optcs in a deterministic way by several mm on the ETMs. Moving the beam is achieved by introducing offsets into the ASS auto alignment. As an example, the Yaw dither for ETMY is shown:

Each of the 8 test mass rotational degrees of freedom is driven by a particular frequency, and 2 signals are digitally demodulated in the real-time system: The arm transmission ("T") and the LSC arm length feedback signal to the ETM (L). The T signal feeds back to the input pointing, aka Tip Tilts and BS. This maximizes the transmission for a given test mass orientation. The L feedback controls the beam position on the mirrors in the arms. It minimizes the coupling of the dither to the length feedback, which is achieved when the beam goes through the axis of the rotational motion. This is where we introduce the offset:

The signal C1:ASS-YARM_ETM_YAW_L_DEMOD_I_OFFSET (for this example) moves the locking point of the dither-to-length coupling and thus moves the beam around on the ETM. This is true for the PIT and YAW of all test masses except ITMX. In the current configuration the TTs optimize the alignment into the YARM, and for the X we only have the BS, which is why the beam spot on ITMX cannot be independently controlled as-is. We could, however, for the sake of this measurement, temporarily temporarily give TT authority to the XARM feedback to control the ITMX beam position. I imagine something like dither-aligning with ASS the normal way, and then run a customized script in which the XARM is treated as the YARM, feecback to the BS is cut, and the YAW signals are inverted due to the reflection on BS.

Knowing the angle of the offset gives us a way to calculate the beam spot displacement with the cavity geometry. For best results I want to make sure our OpLev calibration is still good (laser power decay, although last time this was done was only about a year ago), which would be analogous to elog 11831.

As for ITM beam position, this scheme only works partially, because it would require the beam to steer further off its axis than in the ETM case. This is problematic because of the spacing between tip tilts and ITMs. I summarize:

  1. Place larger DCPD in AS path
  2. Confirm mode-matching and mod-indices
  3. Assess loss in center with zero offsets
  4. Uncertainty low enough? If not get better.
  5. Calibrate OpLevs
  6. Introduce calibrated offsets in dither alignment
  7. Wander beam on test masses, recording arm losses
  8. ???
  9. Profit
Attachment 1: ass_illustration.pdf
ass_illustration.pdf
  4155   Fri Jan 14 12:29:57 2011 KojiUpdateLockingNext steps for the green

These are the next steps for a better operation of the arm locking. They are suitable for the day time activities

Reconfiguration of the X-End table

- End transmission power monitor (CDS model exists, need to configure the PD)

- IR steering mirror for the transmon

- Restore/align end green beam

- Relocate the end trans CCD

- Connect the video output cable for the X-end CRT monitor

LSC Whitening

- LSC Whitening binary IO connection

 


They are not urgent but also good things to do

MC servo characterization

- Error signal: frequency noise

- Loop characterization

Arm cavity characterization with cavity sweep

- Arm finesse for 1064nm and 532nm

- Arm FSR measurement with 1064 (and optionally with 532nm simultaneously)

- Arm g-factor for 1064nm and 532nm

  12367   Wed Aug 3 15:36:57 2016 SteveUpdateSUSNi plated magnets & epoxy ordered

Ni plated SmCo magnets with specification of LIGO-C1103521-v2 for SOS ordered from Electron Energy Corp 

100 pieces of Ni- Platted magnets are in 9-27-2016 They are stored at clean cabinet S15

EP30-2 epoxy  1/2 pt kit 250 ml of part A and 25 ml of part B should be here in 7 days. These can packed epoxy is much more economical than the double barrel cartridges.

Spare SOS wire clamps will be out of the machine shop next week.

  5757   Fri Oct 28 15:33:06 2011 JenneUpdateComputersNifty screen generator

Suresh showed me a cool script that Mirko made, but didn't elog about.

You tell the script what filter banks you want, and it creates a screen for each with a bunch of different filter module display formats.  Then you can copy the format you like into the actual screen you're modifying. 

Currently PEM, LSC and IOO (and maybe others?) have "fmX" folders inside their medm/c1.../master folders.  For each subsystem, we need to copy this folder, and modify the generic .adl file so that it puts in the correct subsystem letters.  Once this is done, you can just run the generateFMscreens.py after putting in your filter bank names.

  5758   Fri Oct 28 15:45:52 2011 MirkoUpdateComputersNifty screen generator

Quote:

Suresh showed me a cool script that Mirko made, but didn't elog about.

You tell the script what filter banks you want, and it creates a screen for each with a bunch of different filter module display formats.  Then you can copy the format you like into the actual screen you're modifying. 

Currently PEM, LSC and IOO (and maybe others?) have "fmX" folders inside their medm/c1.../master folders.  For each subsystem, we need to copy this folder, and modify the generic .adl file so that it puts in the correct subsystem letters.  Once this is done, you can just run the generateFMscreens.py after putting in your filter bank names.

 Wasn"t me.

  6751   Tue Jun 5 00:49:28 2012 JenneUpdateGreen LockingNightly update

[Yuta, Jenne]

Vaguely chronological order:

Found a beat peak, thought it was puny, went to realign Ygreen at end table.

Noticed that beam out of faraday was clipping on the last lens before the steering optics.  We adjusted the mirror directly before the faraday, making sure the power transmitted (measured by the Ophir) didn't go down. Now we're roughly centered on both the lens directly after the faraday, and the lens before the steering optics.

This, of course, meant that we had to completely realign the Ygreen beam to find the TEM00 resonance.  We did that.  Actually, this took us a really long time. We ended up putting a temporary CCD camera on the PSL table to look at the transmitted green light.  This helped a lot, but the resonant modes were just totally wacky.  We finally were able (after 30+ minutes, using the camera) to get to TEM01.  Then Yuta adjusted ITMY a teeny bit, and green was happy to resonate.  We then removed the CCD camera so that we could move on to beat stuff.

Yuta decided it's faster to sweep the PSL temp, rather than the end laser temp, since we don't have to watch that the arm maintains lock.  So we set the end laser temp (T+) to 34.049C, which gave a measured temperature at the back of 34.68C (with an offset of 29425)

We then swept the SLOW adjust on the FSS screen to change the PSL temp.  We went all the way, starting at 0, to +10, back to 0, then on to -10, in steps of 0.01 .

We found a puny peak at -0.96, and pretty good peak at -9.48.  Height of the pretty good peak, after optimizing PSL table beat alignment was -50dBm. At this time, the PSL temp is 33.81C, while the Yend is still measured at 34.68C.

I checked the cabling, and it looks like the beat setup is still as it should be, using the old-school, non-beatbox stuff.  We plugged the beat PD into the beat detection setup, removing it from the spectrum analyzer.  As mentioned in my self-reminder elog, I changed the gains on the top 2 SR560's down by a factor of 2 so they weren't overloading. 

We aren't really sure that we're getting any real signals into the ALS model though.  C1:ALS-BEATY_COARSE_I_MON seems to be the same whether or not the arm is locked on green, therefore it seems to be the same ~500 or 600 counts whether or not there is a beat.  Hmmmm. We used the offset option of the OFFSETTER2 to send an offset to the beat signal that gets sent to the ETMY.  We confirmed that signals are going out to ETMY from the ALS model, but we're not sure if they are correct / non-insane signals.  One symptom that we're seeing is even though we have the Yarm locked on green, and the ALS system engaged, the arm is still flashing in IR, which means the green is mostly just following the arm.  We're not actually holding the arm in place.

Also, TRY and TRX are not recorded channels, so I went into the .ini file to have them acquire (uncommented them, set acquire=1, set the data rate to 2048), saved the ini file, and restarted the fb's daqd process.  The new TRY_OUT_DQ channel is digital zeros, and is red in dataviewer.  Also, the lsc model is no longer happily connected to the framebuilder.  I then decided to try Joe's old .daqconfig script (in the scripts directory) which provides a gui for acquiring channels.  Restarted the daqd process, same story.  I then went back to comment out the TRY_OUT_DQ lines, set acquire=0, set data rate back to 16384.  Joe's program put a bunch of spaces into the .ini file, but I don't think they do anything bad.  Except that now when I restart daqd, lsc still won't connect to the framebuilder.  Yuta setup pynds to save the data, if we were able to get anything useful.

We couldn't make awg, tdssine, or DTT write anything to the OFFSETTER2_EXC.  This is annoying, because this is how (once we figure everything else out) we need to sweep (with a ramp or triangle) the beat signal.

Moral of the night: we learned some stuff, but ultimately failed.

  15344   Fri May 22 10:14:47 2020 JordanUpdateGeneralNitrogen Replacement

I was in the lab for Clean and Bake activities and I replaced an empty N2 tank. Left tank is at 2600 psi right tank at ~1300 psi.

  16808   Mon Apr 25 14:19:51 2022 JCUpdateGeneralNitrogen Tank

Coming in this morning, I checked on the Nitrogen tanks to check the level. One of the tanks were empty, so I went ahead and swapped it out. One tank is at 946 PSI, the other is at 2573 PSI. I checked for leaks and found none.

  16809   Mon Apr 25 14:49:02 2022 KojiUpdateGeneralNitrogen Tank

For your (and mine) info:

N2 pressure can be monitored on the 40m summary page: https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20220425/vacuum/
(you need to hit "today" to go to the current status)

 

  8766   Thu Jun 27 17:04:49 2013 JenneUpdatesafetyNitrogen bottle too hot - overpressured

All of us in the control room / desk area heard a sudden whoosh of air a few minutes ago.  It kind of sounded like a pressure washer or something.  We determined that the northmost nitrogen bottle outside the front door was letting out all its gas. 

It's a gazillion degrees outside (okay, only 91F, according to a google of "Caltech Weather"), and those bottles are in direct sun all day.

We are leaving the bottle as-is, since it seems like its has finished, and nothing else is happening.

  576   Thu Jun 26 18:27:04 2008 ranaUpdateComputer Scripts / ProgramsNo Dataviewer No Cry
Dataviewer was hanging. It would open the Grace window but then not plot anything. Since DTT was working
fine we diagnosed this as a DV only problem. It turned out that there was a boatload of messages in the
dataviewer queue. You can check for extra messaages using the command 'ipcs -q' and then use 'rmq' to remove them.

Dataviewer is working now.

Here's the screen dump from op440m:
op440m:~>ipcs -q
IPC status from <running system> as of Thu Jun 26 18:19:32 PDT 2008
T         ID      KEY        MODE        OWNER    GROUP
Message Queues:
q        400   0x1a51     -Rrw-rw-rw- controls    staff
q          1   0x501      -Rrw-rw-rw- controls    staff
q          2   0x512      -Rrw-rw-rw- controls    staff
q        103   0x553      -Rrw-rw-rw- controls    staff
q          4   0x574      -Rrw-rw-rw- controls    staff
q          5   0x18be     --rw-rw-rw- controls    staff
q         56   0x1d9f     -Rrw-rw-rw- controls    staff
q          7   0x1e56     -Rrw-rw-rw- controls    staff
q          8   0x1efd     -Rrw-rw-rw- controls    staff
q        109   0x2044     -Rrw-rw-rw- controls    staff
q         10   0x207a     -Rrw-rw-rw- controls    staff
q         11   0x24c4     -Rrw-rw-rw- controls    staff
q         12   0x24d7     -Rrw-rw-rw- controls    staff
q         13   0x251b     -Rrw-rw-rw- controls    staff
q         14   0x2fe8     -Rrw-rw-rw- controls    staff
q        115   0x3a65     -Rrw-rw-rw- controls    staff
q        116   0x967      -Rrw-rw-rw- controls    staff
q         17   0x98e      -Rrw-rw-rw- controls    staff
q        118   0x456c     -Rrw-rw-rw- controls    staff
q        669   0x194      -Rrw-rw-rw- controls    staff
q        620   0xe70      -Rrw-rw-rw- controls    staff
q         71   0x15d0     -Rrw-rw-rw- controls    staff
q        222   0x3586     -Rrw-rw-rw- controls    staff
q        173   0x5e37     -Rrw-rw-rw- controls    staff
q        624   0x5e4d     -Rrw-rw-rw- controls    staff
q        475   0x10d7     -Rrw-rw-rw- controls    staff
q        176   0x5ee3     -Rrw-rw-rw- controls    staff
q        277   0x4e22     -Rrw-rw-rw- controls    staff
q        428   0x25f3     -Rrw-rw-rw- controls    staff
q         29   0x3354     -Rrw-rw-rw- controls    staff
q        180   0x368f     -Rrw-rw-rw- controls    staff
q        131   0xb0f      -Rrw-rw-rw- controls    staff
q         82   0x47a5     --rw-rw-rw- controls    staff
q         83   0x4b83     -Rrw-rw-rw- controls    staff
q         34   0x4f6d     -Rrw-rw-rw- controls    staff
q         85   0x4539     -Rrw-rw-rw- controls    staff
q         86   0x67a1     --rw-rw-rw- controls    staff
q         37   0x4b7      -Rrw-rw-rw- controls    staff
q         38   0xd37      -Rrw-rw-rw- controls    staff
q         39   0x156c     -Rrw-rw-rw- controls    staff
q         40   0x2b62     -Rrw-rw-rw- controls    staff
op440m:~>rmq
---------------------------------------------------------------
Deleting message queues which are owned by user: controls ....
---------------------------------------------------------------
      Deleted message queue: 400
      Deleted message queue: 1
      Deleted message queue: 2
      Deleted message queue: 103
      Deleted message queue: 4
      Deleted message queue: 5
      Deleted message queue: 56
      Deleted message queue: 7
      Deleted message queue: 8
      Deleted message queue: 109
      Deleted message queue: 10
      Deleted message queue: 11
      Deleted message queue: 12
      Deleted message queue: 13
      Deleted message queue: 14
      Deleted message queue: 115
      Deleted message queue: 116
      Deleted message queue: 17
      Deleted message queue: 118
      Deleted message queue: 669
      Deleted message queue: 620
      Deleted message queue: 71
      Deleted message queue: 222
      Deleted message queue: 173
      Deleted message queue: 624
      Deleted message queue: 475
      Deleted message queue: 176
      Deleted message queue: 277
      Deleted message queue: 428
      Deleted message queue: 29
      Deleted message queue: 180
      Deleted message queue: 131
      Deleted message queue: 82
      Deleted message queue: 83
      Deleted message queue: 34
      Deleted message queue: 85
      Deleted message queue: 86
      Deleted message queue: 37
      Deleted message queue: 38
      Deleted message queue: 39
      Deleted message queue: 40
---------------------------------------------------------------
op440m:~>
  14286   Fri Nov 9 15:00:56 2018 gautamUpdateIOONo IFO beam as TT1 UL hijacked for REFL55 check

This problem resurfaced. I'm doing the debugging.

6:30pm - "Solved" using the same procedure of stepping through the whitening gains with a small (10 DAC cts pk) signal applied. Simply stepping through the gains with input grounded doesn't seem to do the trick.

Attachment 1: REFL55_wht_chk.png
REFL55_wht_chk.png
  10652   Thu Oct 30 01:21:37 2014 JenneUpdateLSCNo MICH in REFL165

[Koji, Jenne, Diego]

Summary:  We really don't have any MICH signal in REFL 165.  Why is still a mystery.

We made several transfer function measurements while PRMI was locked on REFL33 with the arms held off resonance, and compared those to the case where the ETMs are misaligned.  We fine-tuned the REFL165 demod phase looking at the transfer function between 10-300 Hz (using bandpassed white noise injected in the MICH FF filter bank and looking at REFL165Q), rather than just a single line.  We did that at CARM offset of 3 counts (ALS locked), and then saw that as we reduced the CARM offset, the coherence between MICH injection and REFL165Q just goes down.  Any signal that is there seems to be dominated by PRCL. 

So, we're not sure why having the arms eats the MICH 165 signal, but it does.  Everyone should dream tonight about how this could happen. 

Koji suggested that if the signal is just lost in the noise, perhaps we could increase our modulation depth for 55MHz (currently at 0.26, a pretty beefy number already).  Alternatively, if instead the problem is that the MICH signal has rotated to be in line with the PRCL signal, there may be no hope (also, why would this happen?).

Anyhow, we'd like to understand why we don't have any MICH signal in REFL165 when the arm cavities are involved, but until we come up with a solution we'll stick with REFL33 and see how far that gets us. 

The only really worthwhile plot that I've got saved is the difference in these transfer functions when PRMI-only locked and PRMI+arms locked.  Green is PRMI-only, with the demod phase optimized by actuating on PRM and minimizing the peak in the Q signal.  Blue is PRMI with the arms held off resonance using the ALS signals, with the demod phase set again, in the same way.  We were expecting (at least, hoping) that the blue transfer function would have the same shape as the green, but clearly it doesn't.  The dip that is around 45 Hz can be moved by rotating the demod phase, which changes how much PRCL couples into the Q phase.  Weird.  At ~3nm we had somewhat reasonable coherence to RELF165Q, and were able to pick -102deg as the demod phase where the dip just disappears.  However, as the CARM offset is reduced, we lost coherence in the transfer functions.

MICH_to_REFL165_29Oct2014.pdf

  1425   Wed Mar 25 01:37:35 2009 rana, yoichiSummaryIOONo Reference Cavity Required
We were wondering if we need to have a reference cavity. One possible reason to have one is to reduce the free running
frequency noise by some level so that the MC can handle it. According to my manifesto,
the free running noise of the laser is (10 kHz / f) Hz/rHz. The mode cleaner loop gain is sufficient to reduce this to
0.001 Hz/rHz everywhere below 1 kHz - radiation pressure noise and coating thermal noise limit the mode cleaner below
these levels.

So, since it seems like the reference cavity is superfluous (except for the 1 - 10 kHz band), we unlocked it and locked the
MC by feeding back directly to the laser.

In the old set up, the low frequency feedback is to MC2 and the high frequency to the VCO which actuates the FSS which
drives the NPRO PZT and the Pockel cell.

In this new way, we take the MC board's output to the VCO (the TNC monitor point) and send that to the TEST IN1 of the FSS
box. The FSS box then splits the drive to go to the PZT and the PC path. We also turned off the 40:4000 filter in the MC
board and inverted the sign of the MC FAST path.
Good settings for acquisition:
MC INPUT GAIN = 6 dB
40:4000        Disable
FAST polarity  MINUS
VCO Gain       -3 dB
MC LIMITER     Disable

FSS TEST1      TEST
FSS CG         -3 dB
FSS FG         13 dB

After our initial locking success, we realized that the new MC-FSS loop is conditionally stable: the old loop relied on
the 40 kHz refcav pole to make it stable. The new loop has a 4 kHz pole and so the phase lag in the MC-PZT path is too
much. We need to build a passive lead filter (40 kHz : 4 kHz) in a Pomona box to compensate.

There are several more issues:

- I think this will make the whole CM servo handoff easier: there is no more handoff.

- This will make the lock acquisition fringe velocity higher by a factor of the arm/mc length (40 m / 13 m) since
the frequency will be slewing around along with MC2 now. However, Jenne's FF system ought to take care of that.

- Having the laser frequency stabilized to the MC during lock acquisition will make all of the error signals quieter
immediately. This can only be good.

- If we can make this work here, it should translate to the sites directly since they have exactly the same electronics.
  1451   Wed Apr 1 23:18:07 2009 rana, kojiSummaryIOONo Reference Cavity Required
Koji sent us a note about our "No Reference Cavity Required" entry. I thought that it nicely summarizes the
whole shebang and so I post it here for its pedagogical value.

Generally, frequency stabilization is a comparison of the two
frequency references.

1. In the conventional case you are comparing the NPRO stability with
the RC stability. The NPRO cavity is short and probably placed in a
less stable environment than that of the RC. Therefore, the PDH
signal only feels the frequency fluctuation of the NPRO, resulting
in the laser PZT fast feedback dominated by the NPRO stability. As
the MC length at low frequency is controlled by the mass feedback,
the resulting laser stability through the MC is virtually limited
by the RC stability.

2. On the other hand, you are comparing the stabilities of the NPRO
crystal and the MC cavity in the direct control configuration. The
stability of the MC at high frequency is better than that of the
NPRO. It is opposite at low frequency, of course, because of the
pendulum motion. The resulting laser stability through the MC is
limited by the MC stability.

3. In the CM servo, the length of the MC is stabilized such that the
arm stability is duplicated to the MC. As a result, your MC servo
compares the stability between the NPRO and the arm cavity. Again
at around 1Hz, the arm cavity is noisier than the NPRO. (This is
true at least TAMA case. I am quite unsure about it in the LIGO
long arm cases.)

One useful consequence is that in those configurations, the laser PZT
feedback at around 1Hz represents the stability of the NPRO, the MC,
and (possibly) the arm cavity, respectively. It was clearly seen
Yoichi's e-log entry 1432. At TAMA we call this signal as "MCPZTfb"
and use this for the diagnostic purposes of the suspended cavities. As
the laser fast PZT is rarely replaced and considered as a stable
actuator, this signal is considered as a good reference at low
frequency which is consistent across various configurations
(e.g. before/after replacement of the suspensions etc). Once the
response and the coefficient are calibrated you can easily convert
this signal to the length displacement.

Another remark: In the direct configuration, the frequency stability
of the beam goes through the MC is determined by the MC stablity. It
means that the beam to the arm has essentially worse stability than
the arm stability by factor of L_arm/L_MC. In the 40m case this factor
is just 3 or so. This is ok. However, for the LIGO 4km arm, the factor
becomes something like 300. This means that if you have 1um_rms of the
MC length fluctuation, the arm PDH feels 300um_rms. (Maybe some extent
less because of the common mode rejection of the MC suspensions.)

Yes, the actuator to the MC length is very strong this time, and
should be able to stop this amount of fluctuation easily... if the
things are all linear. I am not certain whether you can acquire the
lock even by this strong actuator when the arm is crazily swinging,
the PDH signals are ringing all the way, etc, etc...Particularly in
the recycling case!

One possible remedy is a technique developed by the German
necromancers, as always. They used the NPRO cavity as a reference
cavity. They actuate the MC length at low frequency. But I don't know
the exact configuration and how they accomplished the CM hand-off. We
have to ask Hartmut.

The other possibility is your adaptive stabilization of the MC by the
FIR technique. So far I don't know how much stability you can improve
in the LIGO 4km case.

There would be many possibilities like feedforward injection from the
green arm locking signal to the MC length, etc, etc.
  4509   Mon Apr 11 13:30:04 2011 josephb, JamieUpdateCDSNo Wiper script - Frames full over weekend

Problem:

The daqd process was dying every minute or so when it couldn't write frame.  This was slowing down the network by writing a 2.9G core dump over NFS every minute or so. (In /opt/rtcds/caltech/c1/target/fb/).

The problem was /frames/ was 100% full.

Apparently, when we switched the fb over to Gentoo, we forgot to install crontab and a wiper script.

Solution:

We will install crontab and get the wiper script installed.

  7685   Wed Nov 7 19:07:45 2012 JenneUpdateCamerasNo beam seen on external camera views

I have written some scripts which collect photos, then average them together, and subtract out an averaged background (as Rana described in elog 7678). 

I am not seeing any beam spots on any of the resulting pictures. 

 

The script to get 500 pictures is

.../scripts/general/videoscripts/videocapture50

and it's inputs are {name of camera} {folder to save in} {noBeam or withBeam}, where noBeam and withBeam indicate whether or not the PSL shutter is closed.  For the saved photos to work nicely with the Matlab script, the folder to save in should be in the format (Month_day_year/CAMERA).  So today's ITMYF pics, for example, are in Nov_7_2012/ITMYF/ .

So, you run it once with the shutter open, and once again with the shutter closed.

 

To create the new picture, open ImageBkgndSubtractor.m in the same .../scripts/general/videoscripts folder, edit the top few lines (month, day, year, camera name).  Run it, and it will read through all the pictures and supply a background-subtracted output, and save the output (as well as a version where every pixel value is multiplied by 3) in the same folder as the 500 pictures.

The pictures are all saved in

/opt/rtcds/caltech/c1/scripts/general/videoscripts/photos

so really, for my example above, it would be /opt/rtcds/caltech/c1/scripts/general/videoscripts/photos/Nov_7_2012/ITMYF/, with 2 subfolders, noBeam and withBeam, and the final pictures are saved in /opt/rtcds/caltech/c1/scripts/general/videoscripts/photos/Nov_7_2012/ITMYF/ .

 

In other, semi-unrelated news, the ITMXF camera has been not working for a while.  The bottom right quad on the test mass tv has been dark for at least a week or two.  Steve, when you have a chance (after the oplevs are all taken care of), can you see if there's something obvious that's wrong?

Here are the background subtracted photos that I've taken today:

BS_PRM_7Nov2012_SpotImage_pixelsTimes3.png

ETMXF_7Nov2012_SpotImage_pixelsTimes3.png

ETMYF_7Nov2012_SpotImage_pixelsTimes3.png

ITMYF_7Nov2012_SpotImage_pixelsTimes3.png

MC2F_7Nov2012_SpotImage_pixelsTimes3.png

MC2F is included, even though you can see the spot usually, just to prove that I'm not trying to subtract away the spot!  You just can't see it in any other picture.

  9951   Wed May 14 02:37:58 2014 JenneUpdateLSCNo big locking news

Tonight was mostly cleaning up some scripts, including the re-writing the restore and align scripts for the optics. 

The new script is in the same folder as the old one (/opt/rtcds/caltech/c1/medm/MISC/ifoalign/NewAlignSoft.py), but is not yet called from the align screen.  However, I'm using it in the carm up and down scripts, and it works nicely for the PRM.  I need to check that the offset value is okay for all the other optics (i.e. are they getting misaligned enough?), but then I'll have the new script called from the screen.  The new script, per Rana's suggestion, does not touch the bias sliders.  Rather, it puts an offset in the pitch filter banks in the coil driver output matrix-of-filter-banks.  Then the misalign routine turns the offset on, and the restore routine turns the offset off.  This way we have a nice ramp time, but don't have to do the weird calculation of number of steps to take as is done in the current script.  Also, the "save" functionality will be obsolete, since we're never touching the bias sliders except for actual alignment needs.

I'm not sure what changed, other than the HEPA being on lower, but the Xarm ALS was much better behaved tonight.  I was able to hang out around arm powers of ~1 for as long as I wanted. 

I didn't try to hand over to digital REFLDC, but I was trying a few times to engage the AO path.  With the CM board set to Plus, I hear hooting when MC IN2 is about 4dB.  With the CM board set to Minus, I didn't hear hooting, but I lost lock when I went from 13dB to 14dB. 

Also, I put the cables for the SR785 back to the "A" set of test points and excitation, so that I could take a closed loop transfer function.  However, I don't know where the latest working scripts to make a remote measurement are, so maybe we can take some loop measurements tomorrow.

The carm_cm_up script is good (for tonight) up to the prompt "Press enter to indicate that it is okay to turn on MC2 LSC FM8".  There are "read"s every step of the way, so it goes nice and slow, but it'll do everything for you except any last tweaks of the PRM alignment after the PRMI is locked.

  4793   Tue Jun 7 11:39:27 2011 JamieUpdateSUSNo binary output module in ETMY
Quote:

1) The FM1 files in the XXSEN modules should switch the analog shadow sensor whitening. I found today that, at least on ETMY and ETMX, they do nothing. This needs to be fixed before we can use the suspensions.

Joe discovered today that ETMY in fact has no binary output module at all, so there is actually no digital control of the whitening filters at ETMY.

We suspect that the ETMY binary output module was maybe harvested to put in the LSC rack, but we're not sure.

We found a spare binary output adapter pcb, which I will try to assemble into a module to install in ETMY.

This does not explain what's going on with ETMX, though.  ETMX has a binary output module, that appears to be properly hooked up.  I'll try to debug what's going on there as well.

In the mean time, I've removed the ETMX binary output module to use as a reference for putting together another identical module for ETMY.

  14554   Fri Apr 19 11:36:23 2019 gautamUpdateSUSNo consistent solution for output matrix

Ther isn't a consistent set of OSEM coil gains that explains the best actuation vectors we determined yesterday. Here are the explicit matrices:

  1. POS (tuned to minimize excitation at ~13.5 Hz in the Oplev PIT and YAW error signals): \begin{bmatrix} \text{UL} & \text{UR} & \text{LL} & \text{LR} \end{bmatrix}\begin{bmatrix} 0.98 \\ 0.96 \\ 1.04 \\ 1.02 \\ \end{bmatrix}
  2. PIT (tuned to minimize cross coupled peak in the Oplev YAW error signal at ~10.5 Hz): ​\begin{bmatrix} \text{UL} & \text{UR} & \text{LL} & \text{LR} \end{bmatrix}\begin{bmatrix} 0.64 \\ 1.12 \\ -1.12 \\ -0.64 \\ \end{bmatrix}
  3. YAW (tuned to minimize cross coupled peak in the Oplev PIT error signal at ~13.5 Hz): \begin{bmatrix} \text{UL} & \text{UR} & \text{LL} & \text{LR} \end{bmatrix}\begin{bmatrix} 1.5 \\ -0.5 \\ 0.5 \\ -1.5 \\ \end{bmatrix}

There isn't a solution to the matrix equation \begin{bmatrix} \alpha_1 & \alpha_2 & \alpha_3 & \alpha_4 \end{bmatrix} \begin{bmatrix} 1 & 1 & 1 \\ 1 & 1 & -1 \\ 1 & -1 & 1 \\ 1 & -1 & -1 \end{bmatrix} =\begin{bmatrix} 0.98 & 0.64 & 1.5 \\ 0.96 & 1.12 & -0.5 \\ 1.04 & -1.12 & 0.5 \\ 1.02 & -0.64 & -1.5 \end{bmatrix}, i.e. we cannot simply redistribute the actuation vectors we found as gains to the coils and preserve the naive actuation matrix. What this means is that in the OSEM coil basis, the actuation eigenvectors aren't the naive ones we would think for PIT and YAW and POS. Instead, we can put these custom eigenvectors into the output matrix, but I'm struggling to think of what the physical implication is. I.e. what does it mean for the actuation vectors for PIT, YAW and POS to not only be scaled, but also non-orthogonal (but still linearly independent) at ~10 Hz, which is well above the resonant frequencies of the pendulum? The PIT and YAW eigenvectors are the least orthogonal, with the angle between them ~40 degrees rather than the expected 90 degrees.

Quote:

So we now have matrices that minimize the cross coupling between these DoFs - the idea is to back out the actuation coefficients for the 4 OSEM coils that gives us the most diagonal actuation, at least at AC. 

  14557   Fri Apr 19 15:13:38 2019 ranaUpdateSUSNo consistent solution for output matrix

let us have 3 by 4, nevermore

so that the number of columns is no less

and no more

than the number of rows

so that forevermore we live as 4 by 4 

Quote:

I'm struggling to think

  3121   Fri Jun 25 15:22:45 2010 JenneOmnistructureSAFETYNo entry to the 40m LVEA until further notice!

                                                                                                                                                                                                                                                                               

The 40m corner station crane is out of order, and it's stuck in a way that prohibits entry to the 40m LVEA / IFO room for safety.  The crane has been locked out / tagged out. 

Until further notice, absolutely no one may enter the 40m LVEA.  Work is permitted in the desk / control room areas.

Signs have been posted on all doors into the LVEA.  Please consider those doors locked out / tagged out.

                                                                                                                                                                                                                                                                               

  7715   Thu Nov 15 03:09:08 2012 JenneUpdateAlignmentNo good progress, many options
I didn't make any concrete progress today. AS and REFL cameras are in place, and Manasa has put ND 0.5 filters on both. I used a 
camera to look at the back of the Faraday, and aligned PRM such that it was retroreflecting, and then tried to align ITMY to have once 
fringes with the PRM at that place. I failed in this, since the AS beam on the AS table was starting to dall off the first mirror on the table. 
I then restored all the suspensions to where they were before I started touching them today. 

I moved ETMY face camera so that it is looking at the front of the black glass, but it's hard to tell where the beam is.  I was thinking 
about setting up a temporary camera to look at the back of ITMY to help guide PZT steering, but I haven't done this yet. 

Koji and I then talked about the several different options I have for references, and how many different knobs I  can turn. I'm sleeping 
on it for now, and hopefully I'll have more insight on what to do tomorrow. 
  816   Fri Aug 8 13:29:54 2008 YoichiUpdateSUSNo groove in the stand-off ... wait, it is not even a stand-off !
Yoichi, Steve, Seiji

We took magnified pictures of the stand-offs of the PRM.
Attm1: North side stand-off.
Attm2: South side stand-off.
Attm3: Zipped file of the full pictures.

We found no groove in the south side stand-off.
After some discussion, we concluded that it is actually a guide rod. You can see it from the size difference (the magnification is the same for the two pictures).
The stand off on the south side is missing (fell off, ran away, evaporated or whatever ...).
Also we noticed that the guide rod on the north side is missing.

We have to find a stand-off and place it on the south side.
Seiji suggested that it is better to put a guide rod next to the north side stand-off, otherwise the stand-off itself is too weak to hold the load.
He also said that the PRM was installed after he left, so it was not his fault.
Attachment 1: north-standoff-preview.jpg
north-standoff-preview.jpg
Attachment 2: south-standoff-preview.jpg
south-standoff-preview.jpg
Attachment 3: No-groove.zip
  817   Fri Aug 8 15:10:35 2008 YoichiUpdateSUSNo groove in the stand-off ... wait, it is not even a stand-off !
I tried to find the missing stand-off and the guide rod in the BS chamber, but I couldn't.
ELOG V3.1.3-