40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 11 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  15300   Tue Apr 7 15:30:40 2020 JonSummaryNoiseBudget40m noise budget migrated to pygwinc

In the past year, pygwinc has expanded to support not just fundamental noise calculations (e.g., quantum, thermal) but also any number of user-defined noises. These custom noise definitions can do anything, from evaluating an empirical model (e.g., electronics, suspension) to loading real noise measurements (e.g., laser AM/PM noise). Here is an example of the framework applied to H1.

Starting with the BHD review-era noises, I have set up the 40m pygwinc fork with a working noise budget which we can easily expand. Specific actions:

  • Updated the 40m fork to the latest pygwinc version (while preserving the commit history).
  • Added a directory ./CIT40m containing the 40m-specific noise budget files (created by GV).
  • Added an ipython notebook CIT40m.ipynb at the root level showing how to generate a noise budget.
  • Integrated our DAC and seismic noise estimators into pygwinc.
  • Marked the old 40m NB repo as obsolete (last commit > 2 yrs ago). Many of these noise estimates are probably stale, but I will work with GV to identify which ones can be migrated.

I set up our fork in this way to keep the 40m separate from the main pygwinc code (i.e., not added to as a built-in IFO type). With the 40m code all contained within one root-level directory (with a 40m-specific name), we should now always be able to upgrade to the latest pygwinc without creating intractable merge conflicts.

  15303   Tue Apr 14 23:50:06 2020 KojiUpdateGeneral40m power glitch recovery

[Koji / Gautam (Remote)]

Lab status

  • Gray Panel: The lab AC was off. Turned on all three (N/S, CTRL RM, E/W)
  • The control room AC was running.

Work stations

  • Control Room: All the control machines were running. We knew that nodus/chiara/fb were running
  • 1X6/7:
    • JETSTOR was making beeping sound. “Power #1 failed””power #2 failed”
    • Optimus & megatron were off -> turned on -> up and running now
  • 1X1/2:
    • Power cycled the netgear at the top of the IOO rack (maybe not necessary)
    • Turned on c1ioo -> up and running now
  • 1X4/5: Rebooted c1sus / c1lsc -> up and running now
  • 1X9: Rebooted c1iscex -> up and running now
  • 1Y4: Rebooted c1iscex -> up and running now

Vacuum status

  • Looked like everything was running as if it did not see the power glitch
  • TP1 normal: Set speed 33.6k rpm / Actual speed 33.6k rpm 
  • TP2 normal: 66k rpm / PTP2 16.0 mtorr
  • TP3 normal: 31k rpm / PTP3 45.4mtorr
  • P1 LOW / P2 1.7mtorr / CC2 1.1e-6 / P3 7.6e-2 / P4 LO
  • Annuli: 2.7~3torr
  • CC1 9.6e-6 / SUPER BEE 0.9mtorr

C1VAC recovery

  • c1vac was alive, but was isolated from the martian network
  • Checked the network I/F status with /sbin/ifconfig -a
    • eth0 had no IP
    • eth1 had the vac subnet IP (192.168.114.9)
  • Ran sudo /sbin/ifdown eth0 then  sudo /sbin/ifup eth0
  • The I/F eth0 started running and c1vac became visible from martian
  • Later checked the vacuum screen: The pressure values and valve statuses looked normal.
    The interlock state was “running”. The system state was “unrecognized”.

End RTS recovery 

  • The end slow machines (auxex and auxey) were already running
  • Restarting end RT models:
    • c1iscey -> rtcds start --all
    • c1iscex -> rtcds start --all
  • Confirmed that the models can dump the SUSs

Vertex RTS recovery

  • We wanted to use the reboot script. (/opt/rtcds/caltech/c1/scripts/cds/rebootC1LSC.sh)
  • c1susaux​​
    • To be safe, we wanted to bring c1susaux first.
    • c1susaux does not make the network I/Fs up automatically upon reboot.
      -> Connect an LCD display / keyboard / mouse to c1susaux
      -> Ran sudo /sbin/ifup eth0 and sudo /sbin/ifup eth1
    • Now c1susaux is visible from martian.
    • Login c1susaux and ran:  
      sudo systemctl start modbusIOC.service 
      -> c1susaux epics is up and running now
    • ...Meanwhile c1susaux lost its eth1 somehow. This made the slow values of 8 vertex sus all zero
      -> Ran sudo /sbin/ifdown eth1 and sudo /sbin/ifup eth1 again on c1susaux ->  this resolved the issue
  • c1psl
    • Login c1psl and ran:  
      sudo systemctl start modbusIOC.service 
      -> c1psl epics is up and running now
  • Prepared for the rebooting script
    • Ran /opt/rtcds/caltech/c1/scripts/cds/rebootC1LSC.sh
    • Rebooting was done successfully. All the suspensions looked free and healthy.
    • Burtrestored c1susaux (used Apr 12 21:19 snapshot)

Hardware

  • PSL laser / Xend AUX laser / Yend AUX laser were off -> turned on
  • The PMC was immediately automatically locked.
  • The main marconi was off -> forgot to turn on
  • The end temp controllers for the SHG crystals were on but not enabled -> now enabled

RTS recovery ~ part 2

  • FB: FB status of all the RTS models were still red
  • Timing: c1x01/2/3/5 were 1 sec behind of FB and c1x04 was 2 sec behind
  • -> Remedy:  https://nodus.ligo.caltech.edu:8081/40m/14349
    • Software rebooting of FB
    • Manually start the open-mx and mx services using
    • sudo systemctl start open-mx.service 
    • sudo systemctl start mx.service
    • Check that the system time returned by gpstime matches the gpstime reported by internet sources. e.g. http://leapsecond.com/java/gpsclock.htm
    • Manually start the daqd processes using
      sudo systemctl start daqd_*
  • This made all the FB(FE) indicators green!
  • Ran the reboot script again -> All green!

IMC recovery

  • The IMC status was checked
  • No autolocker, but it could be manually locked. i.e. MC1/2/3 were not so much misalignment
  • Autolocker/Slow FSS recovery along with https://nodus.ligo.caltech.edu:8081/40m/15121
    • sudo systemctl start MCautolocker.service
    • sudo systemctl start FSSSlow.service
  • Both of them failed to run
  • Note by Gautam: The problem with the systemctl commands failing was that the NFS mount points weren’t mounted. Which in turn was because of the familiar /etc/resolv.conf problem. I added chiara to the namespace in this file, and then manually mounted the NFS mount points. This fixed the problem.
    Now the IMC is locked and the autolocker is left running.

Burt restore

  • Used Apr 12 21:19 snapshot
  • c1psl
  • c1alsepics/c1assepics/c1asxepics/c1asyepics
  • c1aux/c1auxex/c1auxey/
  • c1iscaux/c1susaux
  • This made REFL and AS beams back to the CCDs. As has small fringes.
  • Y arm has small IR flashes as well as green flashes.

JETSTOR recovery

  • JETSTOR was beeping. 
  • Shutdown megatron
  • Followed the instruction https://nodus.ligo.caltech.edu:8081/40m/13107
  • This stopped beeping. Waiting for JETSTOR to come up -> In a minute, JETSTOR display became normal and all disks showed green.
  • Bring megatron back up again

N2 bottle

  • The left N2 bottle was empty. The right one had 1500PSI.
  • Replaced the left bottle with the spare one in the room.
  • Now the left one 2680PSI and the right one 1400PSI.

Closing

  • Closed PSL/AUX laser shutters
  • Turned off the lights in the lab, CTRL room, and the office.

Remaining Issues

  • [done] MCAutoLocker / FSSSlow scripts are not running
  • The PRM alignment slider has no effect (although the PRM is aligned…) -> SLOW DAQ frozen???
  • JETSTOR is not mounted on megatron [gautam mounted Jetstor on megatron on 4/18 at 2pm]
  2115   Mon Oct 19 11:00:52 2009 steveHowToSAFETY40m safety training

Kiwamu, Alex and Zach are practicing mandatory IR-safety scan at the 40m-PSL

40m specific safety indoctrination were completed.

Attachment 1: safety_10_2009.JPG
safety_10_2009.JPG
  5254   Wed Aug 17 12:14:27 2011 Josh SmithOmnistructureComputer Scripts / Programs40m summary page plans

Josh Smith, Fabian Magana-Sandoval, Jackie Lee (Fullerton)

Thanks to Jamie and Jenne for the tour and the input on the pages.

We had a look at the GEO summary pages and thought about how best to make a 40m summary page that would eventually become and aligo summary page. Here's a rough plan:

- First we'll check that we can access the 40m NDS2 server to get data from the 40m lab in Fullerton.

- We'll make a first draft of a 40m summary page in python, using pynds, and base the layout on the current geo summary pages.

- When this takes shape we'll iterate with Jamie, Jenne, Rana to get more ideas for measurements, layout.

Other suggestions: Jenne is working on an automated noisebudget and suggests having a placeholder for it on the page. We can also incorporate some of the features of Aidan's 40m overview medm screen that's in progress, possibly with different plots corresponding to different parts of the drawing, etc. Jenne also will email us the link of once per hour medm screenshots.

 

  6686   Fri May 25 19:13:10 2012 Duncan MacleodSummaryComputer Scripts / Programs40m summary webpages

40m summary webpages

 The aLIGO-style summary webpages are now running on 40m data! They are running on megatron so can be viewed from within the martian network at:

http://192.168.113.209/~controls/summary

At the moment I have configured the 5 seismic BLRMS bands, and a random set of PSL channels taken from a strip tool.

Technical notes

  • The code is in python depending heavily on the LSCSoft PyLAL and GLUE modules.
    • /home/controls/public_html/summary/bin/summary_page.py
  • The HTML is supported by a CSS script and a JS script which are held locally in the run directory, and JQuery linked from the google repo.
    • /home/controls/public_html/summary/summary_page.css
    • /home/controls/public_html/summary/pylaldq.js
  • The configuration is controlled via a single INI format file
    • /home/controls/public_html/summary/share/c1_summary_page.ini

Getting frames

Since there are no segments or triggers for C1, the only data sources are GWF frames. These are mounted from the framebuilder under /frames on megatron. There is a python script that takes in a pair of GPS times and a frame type that will locate the frames for you. This is how you use it to find T type frames (second trends) for May 25 2012:

python /home/controls/public_html/summary/bin/framecache.py --ifo C1 --gps-start-time 1021939215 --gps-end-time 1022025615 --type T -o framecache.lcf

If you don't have GPS times, you can use the tconvert tool to generate them

$ tconvert May 25
1021939215

The available frame types, as far as I'm aware are R (raw), T (seconds trends), and M (minute trends).

Running the code

The code is designed to be fairly easy to use, with most of the options set in the ini file. The code has three modes - day, month, or GPS start-stop pair. The month mode is a little sketchy so don't expect too much from it. To run in day mode:

python /home/controls/public_html/summary/bin/summary_page.py --ifo C1 --config-file /home/controls/public_html/summary/share/c1_summary_page.ini --output-dir . --verbose --data-cache framecache.lcf -SRQDUTAZBVCXH --day 20120525

Please forgive the large apparently arbitrary collection of letters, since the 40m doesn't use segments or triggers, these options disable processing of these elements, and there are quite a few of them. They correspond to --skip-something options in long form. To see all the options, run

python /home/controls/public_html/summary/bin/summary_page.py --help

There is also a convenient shell script that will run over today's data in day mode, doing everything for you. This will run framecache.py to find the frames, then run summary_page.py to generate the results in the correct output directory. To use this, run

bash /home/controls/public_html/summary/bin/c1_summary_page.sh

Configuration

Different data tabs are disabled via command link --skip-this-tab style options, but the content of tabs is controlled via the ini file. I'll try to give an overview of how to use these. The only configuration required for the Seismic BLRMS 0.1-0.3 Hz tab is the following section:

 

[data-Seismic 0.1-0.3 Hz]
channels = C1:PEM-RMS_STS1X_0p1_0p3,C1:PEM-RMS_STS1Y_0p1_0p3,C1:PEM-RMS_STS1Z_0p1_0p3
labels = STS1X,STS1Y,STS1Z
frame-type = R
plot-dataplot1 =
plot-dataplot3 =
amplitude-log = True
amplitude-lim = 1,500
amplitude-label = BLRMS motion ($\mu$m/s)

The entries can be explained as follows:

  1. '[data-Seismic 0.1-0.3 Hz] - This is the section heading. The 'data-' mark identifies this as data, and is a relic of how the code is written, the 'Seismic 0.1-0.3 Hz' part is the name of the tab to be displayed in the output.
  2. 'channels = ...' - This is a comma-separated list of channels as they are named in the frames. These must be exact so the code knows how to find them.
  3. 'labels = STS1X,STS1Y,STS1Z' - This is a comma-separated list of labels mapping channel names to something more readable for the plots, this is optional.
  4. 'frame-type = R' - This tells the code what frame type the channels are, so it can determine from which frames to read them, this is not optional, I think.
  5. 'plot-dataplotX' - This tells the code I want to run dataplotX for this tab. Each 'dataplot' is defined in it's own section, and if none of these options are given, the code tries to use all of them. In this configuration 'plot-dataplot1' tells the code I want to display the time-series of data for this tab.
  6. 'amplitude-XXX = YYY' - This gives the plotter specific information about this tab that overrides the defaults defined in the dataplotX section. The options in this example tell the plotter that when plotting amplitude on any plot, that axis should be log-scale, with a limit of 1-500 and with a specific label. The possible plotting configurations for this style of option are: 'lim', 'log', 'label', I think.

Other compatible options not used in this example are:

 

  • scale = X,Y,Z - a comma-separated list of scale factors to apply to the data. This can either be a single entry for all channels, or one per channel, nothing in between.
  • offset = X,Y,Z - another comma-separate list of DC offsets to apply to the data (before scaling, by default). DAQ noise may mean a channel that should read zero during quick times is offset by some fixed amount, so you can correct that here. Again either one for all channels, or one per channel.
  • transform = lambda x: f(x) - a python format lambda function. This is basically any mathematical function that can be applied to each data sample. By default the code constructs the function 'lambda d: scale * (d-offset)', i.e. it calibrates the data by removing the offset an applying the scale.
  • band = fmin, fmax - a low,high pair of frequencies within which to bandpass the data. Sketchy at best...
  • ripple_db = X - the ripple in the stopband of the bandpass filter
  • width = X - the width in the passband of the bandpass filter
  • rms_average = X - number of seconds in a single RMS average (combine with band to make BLRMS)
  • spectrum-segment-length = X - the length of FFT to use when calculating the spectrum, as a number of samples
  • spectrum-overlap = X - the overlap (samples) between neighbouring FFTs when calculating the spectrum
  • spectrum-time-step = X - the length (seconds) of a single median-mean average for the spectrogram

At the moment a package version issue means the spectrogram doesn't work, but the spectrum should. At the time of writing, to use the spectrum simple add 'plot-dataplot2'.

You can view the configuration file within the webpage via the 'About' link off any page.

Please e-mail any suggestions/complaints/praise to duncan.macleod@ligo.org.

  6687   Fri May 25 20:45:25 2012 Duncan MacleodSummaryComputer Scripts / Programs40m summary webpages

There is now a job in the crontab that will run the shell wrapper every hour, so the pages _should_ take care of themselves. If you make adjustments to the configuration file they will get picked up on the hour, or you can just run the script by hand at any time.

$ crontab -l
# m h  dom mon dow   command
0 */1 * * * bash /home/controls/public_html/summary/bin/c1_summary_page.sh > /dev/null 2>&1

  6883   Wed Jun 27 15:10:34 2012 JamieUpdateComputer Scripts / Programs40m summary webpages move

I have moved the summary pages stuff that Duncan set up to a new directory that it accessible to the nodus web server and is therefore available from the outside world:

/users/public_html/40-summary

which is available at:

https://nodus.ligo.caltech.edu:30889/40m-summary/

I updated the scripts, configurations, and crontab appropriately:

/users/public_html/40m-summary/bin/c1_summary_page.sh
/users/public_html/40m-summary/share/c1_summary_page.ini

 

  549   Fri Jun 20 08:30:27 2008 stivUpdatePhotos40m summer line up 2008
atm1: John, Alberto, Yoichi, Koji, Masha, and Sharon

atm2: surf students Max of CIT, Sharon of MIT, Masha of Harvard, Eric of CIT not shown
Attachment 1: P1020559.png
P1020559.png
Attachment 2: P1020560.png
P1020560.png
  15879   Mon Mar 8 12:54:54 2021 gautamUpdateEquipment loan40m-->Cryo
  1. Busby box
  2. SR554 transformer preamplifier
  2966   Fri May 21 11:56:34 2010 AlbertoUpdate40m Upgrading40mUpgrade Field Power and RF Power Spectrum at the ports. 38m/38.55m arm length issue.

I update my old 40mUpgrade Optickle model, by adding the latest updates in the optical layout (mirror distances, main optics transmissivities, folding mirror transmissivities, etc). I also cleaned it from a lot of useless, Advanced LIGO features.

I calculated the expected power in the fields present at the main ports of the interferometer.

I repeated the calculations for both the arms-locked/arms-unlocked configurations. I used a new set of functions that I wrote which let me evaluate the field power and RF power anywhere in the IFO. (all in my SVN directory)

As in Koji's optical layout, I set the arm length to 38m and I found that at the SP port there was much more power that I woud expect at 44Mhz and 110 MHz.

It's not straightforward to identify unequivocally what is causing it (I have about 100 frequencies going around in the IFO), but presumably the measured power at 44MHz was from the beat between f1 an f2 (55-11=44MHz), and that at 110MHz was from the f2 first sidebands.

Here's what i found:

RFPower_locked_38m.png

RFPower_unlocked_38m.png

FieldPower_locked_38m.png

FieldPower_unlocked_38m.png

 

I found that When I set the arm length to 38.55m (the old 40m average arm length), the power at 44 and 110 MHz went significantly down. See here:

RFPower_3855m.png

 FieldPower_3855m.png

I checked the distances between all the frequencies circulating in the IFO from the closest arm resonance to them.

I found that the f2 and 2*f2 are two of the closest frequencies to the arm resonance (~80KHz). With a arm cavity finesse of 450, that shouldn't be a problem, though.

40mUpgrade_distanceFromResonance_38m.png

 I'll keep using the numbers I got to nail down the culprit.

Anyways, now the question is: what is the design length of the arms? Because if it is really 38m rather than 38.55m, then maybe we should change it back to the old values.

  2968   Fri May 21 16:24:11 2010 KojiUpdateLSC40mUpgrade Field Power and RF Power Spectrum at the ports. 38m/38.55m arm length issue.

1. Give us the designed arm length. What is the criteria?

2. The arm lengths got shorter as the ITMs had to shift to the end. To make them longer is difficult. Try possible shorter length.

  2973   Mon May 24 10:03:14 2010 ranaUpdateLSC40mUpgrade Field Power and RF Power Spectrum at the ports. 38m/38.55m arm length issue.

 

 If you have a working 40m Optickle model, put it in a common place in the SVN, not in your own folder.

I can't figure out why changing the arm length would effect the RF sidebands levels. If you are getting RF sidebands resonating in the arms, then some parameter is not set correctly.

As the RF sideband frequency gets closer to resonating in the arm, the CARM/DARM cross-coupling to the short DOFs probably gets bigger.

  2974   Mon May 24 11:32:05 2010 ranaUpdateLSC40mUpgrade Field Power and RF Power Spectrum at the ports. 38m/38.55m arm length issue.

Quote:

 

 If you have a working 40m Optickle model, put it in a common place in the SVN, not in your own folder.

I can't figure out why changing the arm length would effect the RF sidebands levels. If you are getting RF sidebands resonating in the arms, then some parameter is not set correctly.

As the RF sideband frequency gets closer to resonating in the arm, the CARM/DARM cross-coupling to the short DOFs probably gets bigger.

I uploaded the latest iscmodeling package to the SVN under /trunk. It includes my addition of the 40m Upgrade model: /trunk/iscmodeling/looptickle/config40m/opt40mUpgrade2010.m.

I don't know the causes of this supposed resonances yet. I'm working  to try to understand that. It would be interesting also to evaluate the results of absolute length measurements.

Here is what I also found:

reflRFpowerVsArmLength.png

It seems that 44, 66 and 110 are resonating.

If that is real, than 37.5m could be a better place. Although I don't have a definition of "better" yet.  All I can say is these resonances are smaller there.

  2612   Thu Feb 18 10:10:43 2010 steveConfigurationGeneral480 V AC power turned off

Only the 40m cranes are running on 480VAC The electricians are rewiring this transformer on the mezzanine so it was shut down.

I tested all three cranes before the 480V power was turned off. The last thing to do with the cranes to wipe them down before use.

It will happen on next Tuesday morning.

  1414   Fri Mar 20 15:54:29 2009 steveOmnistructureGeneral480V crane power switch on MEZ

CES Mezzanine is beeing rebuilt to accommodate our new neighbor: the 20ft high water slide...& .jacuzzi

All our ac power transformers are up there. Yesterday we labelled the power switch of 480VAC on the mezz

that we need to keep to run the 3 cranes in the lab.

  6086   Thu Dec 8 00:45:13 2011 KojiUpdateRF System4ch demod is ready

I have tested the left 2ch of 4ch demod board.

The left most is for 11MHz, and the next one is for the 55MHz.

  6092   Thu Dec 8 22:44:55 2011 KojiUpdateRF System4ch demod test result

1) Linearity Test

LO input level was +10dBm. The LO freq was 11MHz and 55MHz for CH1 and CH2 respectively.
The IF frequency was fixed at 10kHz.

The amplitude of the RF input was swept from -50dBm to +15dBm.
Basically I and Q output of CH1 and CH2 was quite linear in this amplitude range.

2) Freqency Response

RF input was fixed at -20dBm and the IF frequency was swept from 1kHz to 1MHz.

The response was flat upto 100kHz, and have sensitivity upto 300kHz.

3) Output noise

Noise floor of the output is ~20nV/rtHz. All of the channels behave in the same way.
1/f start from 100Hz.

Attachment 1: RF_DEMOD_TEST_111208.pdf
RF_DEMOD_TEST_111208.pdf RF_DEMOD_TEST_111208.pdf RF_DEMOD_TEST_111208.pdf
  1653   Thu Jun 4 23:39:23 2009 peteUpdatePEM5 days, 20 days of accelerometers

Looks like yesterday was particularly noisy.  It's unclear to me why diurnal variation much more visible in MC1_Y, and why the floor wanders.

 

The first plot shows 5 days.  The second plot shows 20 days.

Attachment 1: acc_5day.png
acc_5day.png
Attachment 2: acc_20days.png
acc_20days.png
  754   Tue Jul 29 11:50:01 2008 JenneUpdateEnvironment5.6 Earthquake
Earthquake Details
Magnitude 5.6
Date-Time

* Tuesday, July 29, 2008 at 18:42:15 UTC
* Tuesday, July 29, 2008 at 11:42:15 AM at epicenter

Location 33.959N, 117.752W
Depth 12.3 km (7.6 miles)
Region GREATER LOS ANGELES AREA, CALIFORNIA
Distances

* 3 km (2 miles) SW (235) from Chino Hills, CA
* 8 km (5 miles) SE (127) from Diamond Bar, CA
* 9 km (5 miles) NNE (23) from Yorba Linda, CA
* 11 km (7 miles) S (178) from Pomona, CA
* 47 km (29 miles) ESE (103) from Los Angeles Civic Center, CA

Location Uncertainty horizontal +/- 0.3 km (0.2 miles); depth +/- 1.3 km (0.8 miles)
Parameters Nph=144, Dmin=8 km, Rmss=0.42 sec, Gp= 18,
M-type=local magnitude (ML), Version=1
Source

* California Integrated Seismic Net:
* USGS Caltech CGS UCB UCSD UNR

Event ID ci14383980

All the watchdogs tripped. I'll put them back after lunch, after the optics have had time to settle down.
  8557   Thu May 9 02:19:53 2013 JenneUpdateLocking50% BS installed in POP path

Koji had the good idea of trying to measure the motion of the POP beam, and feeding that signal to PRM yaw to stabilize the motion.  To facilitate this, I have installed a 50% beam splitter before the POP 110/22 PD (so also before the camera). 

Before touching anything, I locked the PRM-ITMY half-cavity so that I had a constant beam at POP.  I measured the POP DC OUT to be 58.16 counts.  I then installed a 1" 50% BS, making sure (using the 'move card in front of optic while watching camera' technique) that I was not close to clipping on the new BS.  I then remeasured POP DC OUT, and found it to be 30.63.  I closed the PSL shutter to get the dark value, which was -0.30 .  This means that I now have a factor of 0.53 less light on the POP110/22 PD.  To compensate for this, I changed the values of the power normalization matrix from 0.01 (MICH) to 0.0189, and 100 (PRCL) to 189.

After doing this, I restored the ITMX and am able to get several tens of seconds of PRMI lock (using AS55Q and REFL33I). 

I found several QPDs in the PD cabinet down the Y arm, but no readout electronics.  The QPD I found is D990272.  I don't really want to spend any significant amount of time hacking something for this together, if Valera can provide a QPD with BNC outputs. For now, I have not installed any DC PD or razor blade (which can be a temporary proxy for a QPD, enough to get us yaw information).

 

  574   Thu Jun 26 14:06:00 2008 MashaUpdateGeneral500mW INNOLIGHT NPRO info
Below is the placement of 500mW INNOLIGHT NPRO mephisto laser. It is set up on the Symmetric Port table.
  11490   Tue Aug 11 02:40:29 2015 ericqUpdateLSC50m delay lines - Rough calibrations

Jessica will soon ELOG about some measurements suggesting that the conductive connector-ized ALS delay line enclosure is the way to go, when considering crosstalk between the delay lines. It is currently mounted and hooked up on the LSC rack, though I need to make a bunch of new SMA cables now that I think a semi-permanent arrangement has been reached. 

I did a rough re-calibration of the phase tracker output, since the increased cable delay changes the degree/Hz gain. This was done by fitting a line to a slow sawtooth FM of the SRS DS345's (1Hz rate, 10kHz deviation, 30MHz carrier). This resulted in the following calibration updates

  • ALSX: 19230 -> 13051 Hz/count, 3.4dB more sensitive

  • ALSY: 19425 -> 12585 Hz/count, 3.8db more sensitive

Again, this is a rough calibration. Nevertheless, it is not so surprising we don't get the 50m/30m = 4.4dB increase we would expect just from the lengths; the (I presume) increased cable loss matters. Also, the loss' frequency dependance is an additional reason that the phase tracker calibration is not constant over all frequencies. 

I took spectra with the arms in IR lock, but didn't see any real improvement beyond a possible dip in the floor from 100-200Hz. This doesn't surprise me too much, however, since I don't believe that we are currently dominated by electronic noises that this gain increase would help overcome. 

Last week, Koji mentioned the ALS phase noise added due to the post-cavity table motion the arm-transmitted green beams experience before hitting the beat PD. I should estimate the size of this effect for our situation. 

  8057   Mon Feb 11 16:16:27 2013 SteveUpdateVAC55 days at atmoshere

CP Stat 100  sheet-covers were replaced by clean ones on open chambers BS, ITMX, ITMY and ETMY this morning.

Try to fold the sheets such way that the clean side is facing each other, so they do not accumulate dust.

 

Attachment 1: atm55d.png
atm55d.png
  11173   Wed Mar 25 18:48:11 2015 KojiSummaryLSC55MHz demodulators inspection

[Koji Den EricG]

We inspected the {REFL, AS, POP}55 demodulators.

Short in short, we did the following changes:

- The REFL55 PD RF signal is connected to the POP55 demodulator now.
Thus, the POP55 signals should be used at the input matrix of the LSC screens for PRMI tests.

- The POP55 PD RF signal is connected to the REFL55 demodulator now.

- We jiggled the whitening gains and the whitening triggers. Whitening gains for the AS, REFL, POP PDs are set to be 9, 21, 30dB as before.
However, the signal gain may be changed. The optimal gains should be checked through the locking with the interferometer.


- Test 1

Inject 55.3MHz signal to the demodulators. Check the amplitude in the demodulated signal with DTT.
The peak height in the spectrum was calibrated to counts (i.e. it is not counts/rtHz)
We check the amplitude at the input of the input filters (e.g. C1:LSC-REFL55_I_IN1). The whitening gains are set to 0dB.
And the whitening filters were turned off.

REFL55
f_inj = 55.32961MHz -10dBm
REFL55I @999Hz  22.14 [cnt]
REFL55Q @999Hz  26.21 [cnt]


f_inj = 55.33051MHz -10dBm
REFL55I @ 99Hz  20.26 [cnt]  ~200mVpk at the analog I monitor
REFL55Q @ 99Hz  24.03 [cnt]


f_inj = 55.33060MHz -10dBm
REFL55I @8.5Hz  22.14 [cnt]
REFL55Q @8.5Hz  26.21 [cnt]


----
f_inj = 55.33051MHz -10dBm
AS55I   @ 99Hz 585.4 [cnt]
AS55Q   @ 99Hz 590.5 [cnt]   ~600mVpk at the analog Q monitor

f_inj = 55.33051MHz -10dBm
POP55I  @ 99Hz 613.9 [cnt]   ~600mVpk at the analog I monitor
POP55Q  @ 99Hz 602.2 [cnt]

We wondered why the REFL55 has such a small response. The other demodulators seems to have some daughter board. (Sigg amp?)
This maybe causing this difference.

-----

- Test 2

We injected 1kHz 1Vpk AF signal into whitening board. The peak height at 1kHz was measured.
The whitening filters/gains were set to be the same condition above.

f_inj = 1kHz 1Vpk
REFL55I 2403 cnt
REFL55Q
2374 cnt
AS55I   2374 cnt
AS55Q   2396 cnt
POP55I  2365 cnt
POP55Q
  2350 cnt

So, they look identical. => The difference between REFL55 and others are in the demodulator.

  11596   Mon Sep 14 23:12:49 2015 ericqUpdateLSC55MHz modulation phase effect on PRMI

With the adjustable delay line box installed in the 55MHz modulation path, I've measured the PRMI sensing matrix as a function of delay / relative phase between the 11MHz and 55MHz modulations. The relative frequency difference of 44MHz tells us that this should be cyclical after ~23nsec of delay, but losses in the delay cable change this; see Koji's elogs about the modulation cancellation setup for details. 

TL;DR: Nothing really changes, other than REFL33 optical gain. MICH/PRCL angles remain degenerate.


The results aren't so surprising. The demod angles for the 55MHz diodes don't even change, since the same 55MHz signal is used for the modulator and demodulators, so delaying it before the split should go unnoticed. Most of these measurements were made during the same lock stretch, PRCL on REFL11 I and MICH on AS55Q.

The only signals we would expect to change much are ones that have significant contriubtions from field products influenced by both modulations. None of the 1F PDs are like this, nor is REFL165. REFL33 is the odd man out, where the +44MHz field produced as a -11MHz sideband on the +55MHz sideband beats with the +11MHz sideband (and the same with the signs flipped). I made a simulation for the 40m poster at the March 2015 LVC meeting, but I don't think it ever made it to the ELOG. 

So:

Here are the results for the 0ns and 4ns cases, as an illustration of what changes (REFL33), and what doesn't (everything else). Again, these are calibrated to Volts out of the analog demod boards per meter of DoF motion. 

 

So, since REFL33 is the only one really changing, let's just look at it by itself:

Qualitatively, the change in magnitude looks similar to the simulation result. The demod angles fall by some roughly linear amount. The angle difference is even more stationary than predicted there, though. 

Attachment 1: PRMI_CAR_0ns.pdf
PRMI_CAR_0ns.pdf
Attachment 2: PRMI_CAR_4ns.pdf
PRMI_CAR_4ns.pdf
Attachment 3: delaySweep_nominal.pdf
delaySweep_nominal.pdf
Attachment 4: 55delay_PRMI_REFL33.pdf
55delay_PRMI_REFL33.pdf
  12392   Wed Aug 10 15:34:24 2016 SteveUpdateSUS6 in-lbs torque driver for wire clamp screw

The 7.5 in-lb of Wiha seems at the upper end of torque range for a 4-40 SS screw

Wiha 28502 ordered with range 5 -10 in-lb for silver plated 4-40 screws

Do not trust the Venzo torque wrench under 2 Nm ! It miss lead me.

Recommended torque values for silver-plated fasteners are here. For aLIGO we use the guidelines in T1100066-v6, This doc is posted in 40m wiki under Mechanics also.

So, we'll use 6 in-lbs  on silver plated 18-8 stainless steel socket head cap screw 4-40 x 3/8 into SS tower bridge.

Please replace these clamp screws every time if they were tightened without a torque wrench.

Quote:

New Wiha 28504 torque wrench for SOS wire clamping. It's range 7.5  - 20 in-lb in 0.5 steps [ 0.9 - 2.2 Nm ] Audible and perceptible click when the pre-set torque has been attained at ±6% accuracy.  

The new ETMX sus wire torqued to ~ 11.5 in-lb [1.3 Nm ]

Quote:

Gautam and Steve,

The clamp's left side was jammed onto the left guide pin. It was installed slit facing left. Gautam had to use force to remove it. The clamp should move freely seating on the guide rods till torque aplied. Do not move on with the hanging of optic with a jammed clamp. Fix it.

Never use force as you are hanging - aligning optic. The clamp is in the shop for resurfacing and slit opening.

 

 

 

  11139   Fri Mar 13 03:10:35 2015 JenneUpdateLSC6+ CARM->REFL transitions, 1 DARM->AS transition

Much more success tonight.  I only started my tally after I got the CARM transition to work entirely by script, and I have 6 tally marks, so I probably made the CARM to RF-only transition 7 or maybe 8 times tonight in total.  Unfortunately, I only successfully made the DARM transition to AS55 once.    From the wall striptool, counting the number of times the transmitted power went high, I had about 40 lock trials total. 

The one RF-only lock ended around 1:27am.

I think 2 things were most important in their contributions to tonight's success.  I modified the bounceRoll filters in the CARM and DARM filter banks to eat less phase.  Also, using Q's recipe as inspiration, I started engaging the AO path partway through the CARM transition which makes it much less delicate. 


Bounce roll filter

Koji and I added a ~29Hz resonant gain in the bounce roll filter several months ago, to squish some noise that we were seeing in the CARM and DARM ALS error signals.  This does a lot of the phase-eating.  I'm assuming / hoping that that peak won't be present in the CARM and DARM RF error signals.  But even if it is, we can deal with it later.  For now, that peak is not causing so much motion that I require it.  So, it's gone. 

This allowed me to move the complex zero pair from 30 Hz down to 26 Hz.  Overall I think this gained me about 10 degrees of phase at 100Hz, and moved the low end of the phase bubble down by about 10Hz. 


Prep for REFL 11 I through the CM board and CM_SLOW

In order to use Q's recipe (elog 11138), I wanted to be able to lock CARM on REFL11 using the CM_SLOW filter bank. 

I did a few sweeps through CARM resonance while holding on ALS, and determined that the REFL1 input to the CM board needed a gain of -20dB in order to match the slope of CM_SLOW_OUT to CARM_IN (ALS), leaving all of Q's other settings alone.  Q had been using a REFL1 gain of 0dB for the PRY earlier today.

I needed to flip the sign in the input matrix relative to what Q had (he was using +1 in the CM_SLOW -> CARM_B, I used -1 there).  To match this in the fast path, I flipped the polarity of the CM board (Q was using minus polarity, I am using positive).

The CM_SLOW filter bank had a gain of 0.000189733.  I assume that Q did this so that the input matrix element could be unity.  I left this number alone.  It is of the same order as the plain REFL11I->CARM input matrix element of 1e-4 from Saturday night, so it seemed fine.

During my sweeps through CARM resonance, I also saw that I needed an offset to make CM_SLOW's average about 0.  With the crazy gain number, I needed an offest of -475 in the CM_SLOW filter bank.  As I type this though, it occurs to me that I should have put this in the CM board, since the fast path will have an offset that isn't handled.  Ooops. 


Trying Q's recipe for engaging AO path

I am able to get the MC2 AO gain slider up to -10dB (-7 is also okay).  If I increase the digital CARM gain too much, I see gain peaking at about 800Hz, so something good is happening.  (That was with a CARM_B gain of 2.0 and CARM_A gain of 0.  Don't go to 2.0)

I tried once without engaging his 300:80 1/f^2 filter in the CM_SLOW filter banks to start stepping up the CM REFL1 and MC AO gains together, but I only made it 2 steps of 1dB each before I lost lock. 

I tried once or twice turning on that 300:80 filter that Q said over the phone really helped his PRY locking, but it causes loop oscillations in CARM.  Also, I forgot to turn it off for ~45 minutes, and it caused several locklosses.  Ooops.  Anyhow, this isn't the right filter for this situation.


AS55 whitening problem

Twice I tried turning on the AS55 whitening.  Once, I was only partly transitioned from ALSdiff to AS55, the other time was the one time I made the full transition.  It caused the lockloss from the only RF-only lock I had tonight :(

Unfortunately I don't have the time series before the whitening filters (not _DQ-ed), but you can see a giant jump in the _ERR signals when I turn on the whitening, just before the arm power dies:

AS55whitening_lockloss_12March2015.pdf

The AS55 phase is -30, I has an offset of 28.2 and Q has an offset of 6.4.  Both have a gain of 1.  This should give us enough info to back out what the _IN1 signals looked like before I turned on the whitening if that's useful.


Other random notes

Ramp times for CARM_A, CARM_B, DARM_A and DARM_B are all 5 seconds.  This is set in the carm_cm_up script.

carm_cm_up script freezes the arm ASS before it starts the IR->ALS transition, to make it more convenient to run the ASS each lockloss.

carm_cm_up script no longer has a bunch of stuff at the bottom that we're not using.  It's all archived in the svn, but the remnants from things like variable finesse aren't actively  useful.

carm_cm_down script turns off the CM_SLOW whitening (which gets set in the up script)

carm_cm_down script clears the history of the ETM oplevs, in case they went bad (from some near divide-by-zero action?), but the watchdog isn't tripped. This clears away all the high freq crap and lets them do their job.

FSS Slow has been larger than 0.55 all night, larger than 0.6 most of the night, and larger than 0.7 for the last bit of the night.  MC seems happy.

both carm_cm_up and carm_cm_down are checked into the svn.  The up script is rev 45336 and the down script is 45337.

Some offset (maybe the fact that the fast AO path had an un-compensated offset?) is pulling the arm powers down as I make the transitions:


Recipe overview

  • Lock PRMI with arms held on ALS at 3nm CARM offset.  Bring CARM offset to 0.
  • Turn on CARM_B and DARM_B a little bit, then turn on their integrators
  • Lower the PRCL and MICH gains a little.
  • Increase the CARM_B gain a bit, then turn off FM1 for both CARM and DARM.
  • Increase CARM_B gain, lowering CARM_A gain.
  • Increase DARM_B gain, lowering DARM_A gain.  Now the power should definitely be stable (usually ends up around 80).
  • Partly engage AO path.
    • CM board REFL1 gain = -20dB
    • CM board AO gain = 0dB
    • MC2 board AO gain starts at -32dB, stepped up to -20dB
  • Increase CARM_B gain a bit
  • More AO path:  MC2 board AO gain steps from -20dB to -10dB
  • Increase CARM_B gain to 1.5, turn CARM_A gain to zero
  • CM_SLOW whitening on

After that, I by-hand made the DARM transition on the 6th successful scripted CARM transition, and tried to script what I did, although I was never able to complete the DARM transition again.  So, starting where the recipe left off above,

  • Turn off DARM's FM2 boost to win some more phase margin.
  • Increase DARM_B gain to 0.5, lower DARM_A gain to 0.

Since DARM doesn't have an analog fast path, it is stuck in the delicate filter situation.  I think that I should probably start using the UGF servo once the arm power is stable so that DARM stays in the middle of its phase bubble.

Rather than typing out the details of the recipe, I am attaching the up script.

Attachment 1: AS55whitening_lockloss_12March2015.pdf
AS55whitening_lockloss_12March2015.pdf
Attachment 2: MoreDARMB_powerWentDown_12March2015.png
MoreDARMB_powerWentDown_12March2015.png
Attachment 3: carm_cm_up_zip.sh.gz
  11140   Fri Mar 13 14:11:59 2015 ranaUpdateLSC6+ CARM->REFL transitions, 1 DARM->AS transition

Since the DARM_OUT signal is only 500 counts_peak, I don't see why AS55 whitening needs to be switched on.cool Maybe in a couple weeks after the lock is robust. In any case, its much better to do the switching BEFORE you're using AS55, not after.

  3103   Wed Jun 23 12:31:36 2010 GopalUpdateGeneral6.16.10-6.23.10 Weekly Update

Summary of This Week's Activities:

6/16: LIGO Orientation; First Weekly Meeting; 40m tour with Jenne; Removed WFS Box Upper Panel, Inserted Cable, Reinstalled panel

6/17: Read Chapter 1 of Control Systems Book; LIGO Safety Meeting; Koji's Talk about PDH Techniques, Fabry-Perot Cavities, and Sensing/Control; Meeting w/ Nancy and Koji

6/18: LIGO Talk Part II; Glossed over "LASERS" book; Read Control Systems Book Chapter 2; Literary Discussion Circle

6/21: Modecleaner Matrix Discussion with Nancy; Suggested Strategy: construct row-by-row with perturbations to each d.f. --> Leads to some questions on how to experimentally do this.

6/22: Learned Simulink; Learned some Terminal from Joe and Jenne; LIGO Meeting; Rana's Talk; Christian's Talk; Simulink Intro Tutorial

6/23 (morning): Simulink Controls Tutorial; Successfully got a preliminary feedback loop working (hooray for small accomplishments!)

 

Outlook for the Upcoming Week:

Tutorials (in order of priority): Finish Simulink Tutorials, Work through COMSOL Tutorials

Reading (in order of priority): Jenne's SURF Paper, Controls Book, COMSOL documentation, Lasers by Siegman.

Work: Primarily COMSOL-related and pre-discussed with Rana

  3142   Wed Jun 30 11:35:06 2010 Gopal UpdateGeneral6.23.10 - 6.30.10 Weekly Update

Summary of this Week's Activities:

6/23: LIGO Safety Tour; Simulink Controls Tutorial

6/24: Simulink Diagram for Feedback Loop; Constructed Pendulum Transfer Function; Discussion with Dr. Weinstein

6/25: Prepare for pump-down of vacuum chamber; crane broken due to locking failure; worked through COMSOL tutorials

6/28: Ran through Python Tutorials; Began learning about Terminal

6/29: Wrote Progress Report 1 First Draft

6/30: Began editing Progress Report 1

  3166   Wed Jul 7 11:35:59 2010 GopalUpdateWIKI-40M Update6.30.10 - 7.7.10 Weekly Update

Summary of this Week's Activities:

6/30: 2nd and 3rd drafts of Progress Report

7/1: 4th draft and final drafts of Progress Report; submitted to SFP

7/5: Began working through busbar COMSOL example

7/6: LIGO meeting and lecture; meeting with Koji and Steve to find drawing of stacks; read through Giaime's thesis, Chapter 2 as well as two other relevant papers.

7/7: Continued working on busbar in COMSOL; should finish this as well as get good headway on stack design by the end of the day.

  3752   Thu Oct 21 12:15:02 2010 ranaUpdatePEM6.9 Mag EQ in Gulf of California
Magnitude 6.9
Date-Time
Location 24.843°N, 109.171°W
Depth 10 km (6.2 miles) set by location program
Region GULF OF CALIFORNIA
Distances 105 km (65 miles) S of Los Mochis, Sinaloa, Mexico
125 km (75 miles) SW of Guamuchil, Sinaloa, Mexico
140 km (85 miles) NE of La Paz, Baja California Sur, Mexico
1200 km (740 miles) WNW of MEXICO CITY, D.F., Mexico
Location Uncertainty horizontal +/- 6.1 km (3.8 miles); depth fixed by location program
Parameters NST=187, Nph=187, Dmin=843.1 km, Rmss=1.17 sec, Gp=133°,
M-type=teleseismic moment magnitude (Mw), Version=6
Source
  • USGS NEIC (WDCS-D)
Event ID us2010crbl
  6127   Sat Dec 17 00:00:03 2011 kiwamuUpdateGreen Locking60 Hz line nose gone

Quote from #6126
As shown in the noise budget below, the 60 Hz line noise currently dominates the arm displacement.

 The 60 Hz line noise has gone away.

It turned out that the line noise came from an oscilloscope.
The oscilloscope had been connected to a SR560, which amplifies the frequency-discriminated signal before the ADC as a whitening filter.
I still don't have a good explanation for it, but somehow connecting the oscilloscope made the line noise pretty high.
  5657   Wed Oct 12 18:54:02 2011 KatrinUpdateGreen Locking60 Hz oscillation due to broken BNC cable

There was a 60 Hz and 120 Hz oscillation on the green PDH photo diode output. After a long search, I could identify that

the source was a broken BNC cable which was connected to the photo diode. I exchanged that BNC cable and the 60 Hz

and 120 Hz are gone :-)

With the new cable the PD output was less noisy so that it was easier to achieve a better alignment of the light to the cavity.

The reflected power could be reduced from 40% to 30%. For perfect alignment the reflected power would be 20%.

  3255   Wed Jul 21 11:57:59 2010 GopalUpdateWIKI-40M Update7.14.10-7.21.10 Weekly Update

Summary of this week's activities:

7/14: Analytical calculation of Viton spring constant; updated Viton values in models; experimental confirmation of COMSOL eigenfrequencies (single stack layer)

7/15: Extensions to 2-, 3-, and 4-layer stack legs. Eigenfrequency characterizations performed for each level. Meshing issues with 4-layer stack prevented completion.

7/19: Debugged the 4-layer stack. Turned out to be a boundary condition issue because of non-sequential work-plane definitions. Successful characterization of single-leg eigenfrequencies.

7/20: Prototype three-legged stack completed, but dimensions are incorrect. Read Sievers paper for details of triple-legged stack. Sorted through many stack design binders in efforts to distinguish IOC/OOC, BSC/ITMX/ITMY, MC1/MC3, and MC2 dimensions.

7/21: Researched frequency domain analysis testing in COMSOL. Attempting to first find transfer function of a single-layer stack --> currently running into some run-time errors that will need some more debugging in the afternoon.

  3307   Wed Jul 28 12:31:00 2010 GopalUpdateWIKI-40M Update7.21.10-7.28.10 Weekly Update

Summary of this week's activities:

7/21: Frequency Domain Analysis of rectangular bar; discussed with Koji how to convert complex eigenfrequencies into phase factors.

7/23: Created Wiki page about FDA; Journal Club

7/26: Recreated Stack_1234.mph due to boundary value issues; FDA for 1,2,3,4,5 Hz

7/27: Discovered MC2 logbooks for later design; ran the complete x-translational FDA for Stack_1234.mph

7/28: Finished y-translational FDA (posted previously); "Tapered Cantilever" COMSOL tutorial for gravity-load analysis.

  3363   Wed Aug 4 20:58:22 2010 GopalUpdateWIKI-40M Update7.28.10 - 8.4.10 Weekly Update

Summary of this week's activities:

7/28:    Finished Y-Translational 4-Stack Analysis

"Tapered Cantilever" COMSOL tutorial

Tried (and failed) isolating gravity from oscillation

7/29:    Developed tilt/rotation load combinations for torsional inputs and showed these to work in the model

Tried using Normal Vector mode on top plate to obtain output tilts; worked for the rectangular bar, but not for the full stack

Talked to Jan about a 1st-order alternative to gravity - requires Weak Form (only found in COMSOL 3.5 right now)

Began Z-Translational 4-Stack Analysis -- Ran Overnight

7/30:    Progress Report 1st Draft

Completed Z-Translational 4-Stack Analysis

8/1:      Progress Report 2nd Draft

8/2:      Progress Report 3rd Draft

Submitted Progress Report

8/3:      Finalized Eigenfrequency Analysis for MC1/MC3 Stack

24 Physical Eigenmodes plotted and recorded, as expected

Should be good enough for the final report --> focus on transfer function analysis for the remainder of the SURF

8/4:      Prescribed Displacement Tests on Simple Rectangular Block --> shown to better produce displacement-displacement transfer functions

X-to-X Transfer Function seems much better when plotted

Should now be able to do the Displacement portion of Transfer Function Analysis on MC1/MC3 for Translational Modes

(I apologize that this update is a little late)

  3219   Wed Jul 14 13:03:04 2010 Gopal UpdateWIKI-40M Update7.8.10 - 7.14.10 Weekly Update

Summary of this Week's Activities:

Wed. 7/7: COMSOL Busbar tutorials; began stack design; began base; Viton rubber research

Thurs. 7/8: Completed Viton rubber research; updated materials; finished designing the base layer

Fri. 7/9: Research model coupling papers; extensive eLog entry about base design and troubleshooting

Sun. 7/11: Played around with Busbar to find first eigenfrequency; continued crashing COMSOL

Mon. 7/12: Intrusions in COMSOL eLog tutorial entry; research eigenfrequency analysis; successfully got first eigenmode of rectangular bar

Tues. 7/13: Updated Poisson ratio of Viton and subsequently succeeded in running eigenfrequency tests on base stack layer. Systematic Perturbation Tests were documented in the most recent elog entry. Discussed results with Rana and decided this didn't make sense. Analytical study required.

Wed. 7/14: Went over to machine shop to experimentally extrapolate spring constant of Viton. Calculations to be done in the afternoon.

  7077   Thu Aug 2 04:58:00 2012 MashaUpdatePEM70 Meter Long Guralp 1 Cable

The parts Jenne and I ordered arrived today, so we made a long cable for Guralp 1 using a 24 + 1 wire 70 meter long cable, a female 37-pin DSub, and a 26-pin milspec. The pin map is the same as the one I specified in my previous E-log. I soldered both the milspec attachment and the DSub attachment, and used a Multimeter to check the connectivity of the cables. 20 of 20 connections worked (beeped), so I plugged  the cable into the Gurlap 1 seismometer and the Guralp box.

The time series comparison for the two cables

Old cable:

BeforeCable.png

New cable: (I had to move GUR 1, so it's still stabilizing in the X and Y time series)

 

 AfterCable.pngNew

The current signal spectrum

 

 NewCableFreq.png

The BLRMS on the seismic strip also look similar using the two cables - it's more visible on the wall, but I will include a StripTool picture:

New Cable BLRMS (similar to old cable BLRMS)

 NewCableStrip.png

  5619   Tue Oct 4 20:34:20 2011 KatrinUpdateGreen Locking7kHz Peak in servo input YARM

[Kiwamu, Katrin]

As reported earlier an oscillation around 7kHz is an the PDH error signal. The lower spectrum show that there is a peak from 6-7kHz.

This peak is somehow dependent on the modulation frequency. This means the peak can be shifted to a higher frequency when the modulation frequency is increased (see for comparsion f_mod=279kHz).

If the power supply for the green PD is switched of the peak vanishes. The same happens if the LO is switched of.

servoinput.png servoinput2.png

  12511   Wed Sep 21 09:04:57 2016 SteveUpdateGeneral8 hours recovery progress

Good 8 hours

Quote:

The misalignment wasn't as bad as I had intially feared; the spot was indeed pretty high on ETMX at first. Both transmon QPDs did need a reasonable amount of steering to center once the dither had centered the beam spots on the optics.

Arms, PRMI and DRMI have all been locked and dither aligned. All oplevs and transmon QPDs have been centered. All AS and REFL photodiodes have been centered. 

Green TM00 modes are seen in each arm; I'll do ALS recovery tomorrow. 

 

Attachment 1: 8hrs.png
8hrs.png
  3397   Wed Aug 11 11:51:45 2010 Gopal UpdateWIKI-40M Update8.5.10 - 8.11.10 Weekly Update

Summary of this Week's Activities:

Thursday, August 5:

X-Displacement Transfer Function Measurement

JPL Tour

Friday, August 6:

Y-Displacement Transfer Function Measurement

Z-Displacement Transfer Function Measurement

Monday, August 9:

Worked on COMSOL/MatLab Interface --> problems may be due to older version

Discussed with Koji options for calling our COMSOL sales representative

Jan and I decided that there is in fact something wrong with the installations on both my Mac and Kallo

Reinstalled on both machines, but the problem was not solved

Jan said we'd go see Larry tomorrow

Tuesday, August 10:

Attempted to figure out Time-Dependent Modal Analysis --> don't think it's what we need

Began reading the LiveLink for MatLab documentation --> even the directions in this produced issues

Discovered "Prescribed acceleration" option for gravity:

A test with it on the simplest stack eliminated the unwanted oscillation, which I guess is a partial success...

Trying the same thing with Koji on a simple pendulum, however, didn't produce the expected increase in resonant frequency

(Jan was unable to see Larry today, but we're meeting on Wednesday instead).

Wednesday, August 11 (morning):

Some background research on multiple-layer stack theory

Began working on presentations

 

 

 

  3879   Mon Nov 8 10:48:58 2010 kiwamuUpdateGreen Locking80MHz VCO : PLL open loop looks good

I measured the open loop transfer function of the 80MHz VCO's PLL while locking it to Marconi.

 This measurement is for a health check and a characterization of the PLL

The transfer function looks good, it agrees with the designed filter shape.

 


(measurement setup) 

vco_pll.png

 The frequency of Marconi is set to 79.5MHz which is the center frequency of the VCO.

The signal from Marconi is mixed down with the VCO signal at a mixer ZLW-3SH.

Then the demodulated signal goes to a 80MHz LPF to cut off high frequency components.

And it goes through a control filter which has 1Hz pole and 40Hz zero (see this entry).

The 80MHz LPF, the controls filter, the VCO and the RF amplifier are all built in the box.

 

 In order to measure the open loop transfer function I inserted SR560 before the 80MHz LPF.

Using T-splitters the input and the output of SR560 are connected to a spectrum analyzer SR785.

 

(results)

 VCO_PLL.png

 Exciting the system using a source channel of SR785, I measured the open loop transfer function.

The unity gain frequency was measured to about 20 kHz.

It agrees with the designed filter shape (though the gain factor is a little bit underestimated).

Apparently there is a phase delay at high frequency above 10kHz, but it is okay because the phase margin is quite acceptable up to 100kHz.

 

However I found that the control range was quite narrow.

The PLL was able to be kept in only +/- 1MHz range, this fact was confirmed by shifting the frequency of Marconi during it's locked.

I will post another elog entry about this issue.

 


 (notes)

 Marconi power = 6dBm

 VCO power after RF amp. = -0.6 dBm

 Marconi frequency = 79.5 MHz

 Phase detection coefficient = 0.4 V/rad (measured by using an oscillo scope)

 

  3881   Mon Nov 8 16:03:46 2010 kiwamuUpdateGreen Locking80MHz VCO : PLL open loop looks good

Quote:

I measured the open loop transfer function of the 80MHz VCO's PLL while locking it to Marconi.

 

Bad; there should be a passive ~1 MHz LP filter between the mixer and anything that comes after. The SR560 + mixer does not equal a demodulator.

  3896   Thu Nov 11 13:54:05 2010 kiwamuUpdateGreen Locking80MHz VCO : about PLL hold-in range

The hold-in range of the PLL must be greater than +/- 4MHz in order to bring the arm cavity to its resonance. 

(Hold-in range is the range of frequencies over which the PLL can track the input signal.)

However as I mentioned in the past elog (see this entry), the PLL showed a small hold-in range of about +/- 1MHz which is insufficient.

In this entry I explain what is the limitation factor for the hold-in range and how to enlarge the range.

 


(Requirement for hold-in range )

 We have to track the frequency of the green beat signal and finally bring it to a certain frequency by controlling the cavity length of the arm.

For this purpose we must be able to track the beat signal at least over the frequency range of 2*FSR ~ +/- 4MHz.

Then we will be able to have more than two resonances, in which both the end green and the PSL green are able to resonate  to the arm at the same time. 

And if we have just two resonances in the range, either one of two resonances gives a resonance for both IR and green. At this phase we just bring it to that frequency while tracking it.

 

  Theoretically this requirement can be cleared by using our VCO because the VCO can drive the frequency up to approximately +/- 5MHz (see this entry)

 The figure below is an example of resonant condition of green and IR. The VCO range should contain at least one resonance for IR.

(In the plot L=38.4m is assumed)

 

 range_green.png

 

(an issue) 

However the measured hold-in range was about +/- 1MHz or less. This is obviously not large enough.

According to a textbook[1], this fact is easily understandable.

The hold-in range is actually limited by gains of all the components such as a phase detector's, a control filter's and a VCO's gain.

Finally it is going to be expressed by,

                         [hold-in range] = G_pd * G_filter * G_vco

PLL.png

 

 At the PD (Phase Detector which is a mixer in our case) the signal does not exceed G_pd [V] because it appears as G_pd * sin(phi).

When the input signal is at the edge of the hold-in range, the PD gives its maximum voltage of G_pd to maintain the lock.

Consequently the voltage G_pd [V] goes through to G_filter [V/V] and G_vco [Hz/V].

This chain results the maximum pushable frequency, that is, hold-in range given above equation.

In our case, the estimated hold-in range was 

                      [hold-in range] ~ 0.4 [V] * 3 [V/V] * 1 [MHz/V]

                          = 1.2 [MHz]

This number reasonably explains what I saw.

In order to enlarge the hold-in range, increase the gain by more than factor of 5. That's it.

* reference [1]  "Phase-Locked Loops 6th edition" Rolan E. Best

  3898   Thu Nov 11 17:47:36 2010 kiwamuUpdateGreen Locking80MHz VCO : improve PLL hold-in range and put a boost

In order to enlarge the hold-in range I modified the control filter and increased the gain by factor of 25 in the PLL.

It successfully enlarged the range, however the lock was easily broken by a small frequency change.

So I put a low frequency boost (LFB) and it successfully engaged the PLL stiffer.

Now it can maintain the lock even when the frequency disturbance of about 1MHz/s is applied.

 


(enlargement of the hold-in range)

I modified the control filter by replacing some resistors in the circuit to increase the gain by factor of 25.

        - R18 390 [Ohm]  => 200 [Ohm]

    - R20 1000 [Ohm] => 5000 [Ohm]

    - R41 39 [Ohm] => 10 [Ohm]

 This replacement also changes the location of the pole and the zero

    - pole 1.5 [Hz] => 0.3 [Hz]

    - zero 40 [Hz] => 159 [Hz]

 Note that this replacement doesn't so much change the UGF which was about 20 kHz before.

It becomes able to track the input frequency range of +/- 5MHz if I slowly changes the frequency of the input signal. 

However the PLL is not so strong enough to track ~ 1 kHz / 0.1s frequency step.  

 

(make the PLL stiffer : a low frequency boost)

One of the solution to make the PLL stiffer is to put a boost filter in the loop.

I used another channel to more drive the VCO at low frequency. See the figure below.

 vco_pll.png

The 80MHz VCO box originally has two input channels, one of these inputs was usually disabled by MAX333A.

This time I activated both two input channels and put the input signal to each of them.

Before signals go to the box, one of the signal path is filtered by SR560. The filter has G=20000, pole=0.3Hz. So it gives a big low frequency boost.

VCO_lfb.png

Once the PLL was achieved without the boost, I increased the filter gain of SR560 to 20000 because locking with the boost is difficult as usual.

 

  3820   Fri Oct 29 06:20:20 2010 kiwamuUpdateGreen Locking80MHz VCO for green PLL : VCO calibration

 I calibrated the VCO frequency as a function of the applied input voltage.

The range is approximately +/- 5 MHz, which is large enough to cover the arm's FSR of 3.75MHz.

calibration.png 

======== measured parameters ======

center frequency: 79.5 MHz

VCO range: 74MHz - 84MHz

coefficient : 1.22MHz/ V (+/- 2V range)

nominal RF power: -0.66 dBm

(Note: The measurement was done by using Giga-tronics hand-hold power meter.)

Quote from #3803

Tomorrow I will check the VCO part, especially I am curious about the VCO range.

  3803   Thu Oct 28 03:07:53 2010 kiwamuUpdateGreen Locking80MHz VCO for green PLL : a health check

 I did a health check for a 80MHz VCO box. 

I started taking care with the black VCO box, which has been sitting on the SP table and will be used for converting the green beat signal from frequency to voltage.

The circuit in the box basically consists of three parts: low pass filters (LPFs), a VCO and RF amplifiers.

Today I checked the LPF stage. It looks pretty healthy.

Tomorrow I will check the VCO part, especially I am curious about the VCO range.

 


 (soldering)

 Since somebody ( surf students ?) removed some resistors, the VCO was just freely running without being applied any voltage.

I put some resistors back on the circuit board by soldering them.

Now the resistors are placed in the same configuration as the original schematic (link to LIGO DCC) except for the wideband signal path, which has a differential input.

I left the wideband path disconnected from the VCO.

 

(transfer function measurement)

The LPF part in 'external mod' path contains two stages in series:

one is for cutting off demodulated signals above fc=80MHz and the other one is for PLL servo with pole=1Hz, zero=40Hz.

In order to activate this path I shorted 10th pin of the analog switch: MAX333A.

During the transfer function measurement I injected signals to 'external mod' input and took the output signal from a test point pin TP7.

The plot below shows a fitting result of the measured transfer function of the whole LPF stage. I used liso for the fitting.

The measured filter's shape agreed with the design. (though I haven't checked 80MHz cut off)

VCO_LPF_fit.png

  4237   Wed Feb 2 03:27:20 2011 KojiSummaryGreen Locking85MHz Freq divider

The freq divider was built and installed in the beat detection path.

Attachment 1: Circuit diagram

  • Input stage:  Wideband RF amp with DC block at the input and the output. The gain is 10dB typ.
  • 2nd stage: Ultra fast comparator AD9696. Note: AD9696 is an obsolete IC and there are only a few extra at Wilson house.
    The output is TTL/CMOS compatible.
  • 3rd stage: 14bit binary ripple counter (fmax~100MHz.)

Note: I have added 7805/7905 regulators to the circuit as I could not find -5V supply on the 1X1/2 racks.

Attachment 2: Packaging

  • The box is german made Eurocard size box from Techno-Isel Linear Motion http://www.techno-isel.com/lmc/Products/EnclosureProfiles11055.htm
    The box is excellent but I didn't like the fixing bolts as they are self-tapping type. I tapped the thread and used #6-32 screws.
     
  • The prototyping board is BPS's (BusBoard Prototype System http://www.busboard.us/)  SP3UT. The card size is 160mm x 100mm.
    The other side is a ground plane and the small holes on the board are through holes to the ground plane.
    This particular card was not easy to use.
     
  • The input is SMA. Unfortunately, it is not isolated. The output is an isolated BNC.
     
  • The supply voltage of +/-15V is given by the 3pin D-connector. The supply voltages have been obtained from the cross connect of 1X1.

Attachment 3: Input specification

  • The input frequency is 10MHz~85MHz. At lower frequency chattering of the comparator against the multiple zero crossing of the (relatively) slow sinusoidal waves.
  • The input amplitude. There are no apparent degradation of the freq jitter when the input power was larger than -30dBm.

 

Attachment 1: freq_divider.pdf
freq_divider.pdf
Attachment 2: IMG_3816.JPG
IMG_3816.JPG
Attachment 3: IMG_3818.JPG
IMG_3818.JPG
  11685   Tue Oct 13 05:48:39 2015 ericqUpdateLSC:/

[ericq, Gautam]

Despite our best efforts, the grappa remains out of reach: the DRFPMI was not locked tonight. 

We spent a fair amount of time with the AUX X laser, as it was glitching madly again.

DRMI was finicky until I found some more reliable triggering settings; namely aquiring with AS110Q, but after that transitioning the trigger to the same POP22+POPDC combo as PRCL and MICH. With this in place, the DRMI lock seems really indefinite no matter what CARM seems to do; or at least, I always lost lock due to CARM shenanigans after this. 

The most frustrating part was the fact that I just couldn't cross over the AO path stably. It never "clicked" into high circulating power as it normally does (either in PRFPMI, or how it was last week). Various crossover filters and tweaks were attempted to no avail. Morning traffic starts soon, so we're calling it a night. 

ELOG V3.1.3-