40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 198 of 341  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  11692   Thu Oct 15 04:14:14 2015 ericqUpdateLSCDRFPMI Locked for 20 sec

Fast ALS was still a problem tonight. I don't think high frequency ALS noise saturating the PC drive is the issue; I put two 10k poles before the CM board (shooting for just 2-3kHz bandwidth), and the PC drive levels would be stable and low up until the lockloss, which was always conincident with a step in the AO gain.

After working with that for a few hours, we turned back to our more standard locking attempts. First, we dither aligned the PRMI, and then centered the REFL beam on REFL11. It's hard to say for certain, but we may have been a little close to the edge of the PD. The only other thing that differed from Monday's attempts was using 6dB less AO gain when trying the up the overall gain. 

The script now reliably breaks through to stable high powers, we had a handful of pure-RF locks tonight. The digital DARM gain needs tuning, and the CARM bandwidth still isn't at its final state, but these are very tractable. Off the top of my head, the way forward now includes:

  • Set proper final DARM loop shape
  • Set final CARM loop shape
  • Take full sensing matrix
  • Make 1F handoff
  • Set up the CAL model to produce (at least roughly) calibrated spectra
  • measure noise couplings and other fun stuff

Unrelated: I feel that the PRC angular FF may have deteriorated a bit. I'm leaving the PRC locked on carrier to collect data for wiener filter recalculation. 

  11694   Thu Oct 15 14:39:58 2015 ericqUpdateComputer Scripts / Programsnodus web apache simlinks too soft

None of the links here seem to work. I forgot what the story is with our special apache redirect frown


The story is: we currently don't expose the whole /users/public_html folder. Instead, we are symlinking the folders from public_html to /export/home/ on nodus, which is where apache looks for things

So, I fixed the links on the Core Optics page by running:

controls@nodus|~ > ln -sfn /users/public_html/40m_phasemap /export/home/

  11698   Mon Oct 19 15:23:22 2015 ericqUpdateLSCLonger DRFPMI lock

Here is a longer lock, about 100 seconds RF only, from later that same night. The in-loop CARM and DARM error signals have the order of magnitude of 1nm per count. 

From ~-150 to -103, we were fine tuning the ALS offsets to try and get close to the real CARM/DARM zero points then blending the RF CARM signal. 

At -100, the CARM bandwidth increases to a few kHz and stabilizes the arm powers. By -81, the error signals are all RF. At -70, I turned on the transmon QPD servos, which brought the power up a bit. 

If I recall correctly, lock was lost because I put waaaay too big of an excitation on DARM with the goal of running its UGF servo for a bit. The number I entered was appropriate for ALS, but most certainly too huge for AS55...

  11699   Mon Oct 19 16:16:01 2015 ericqUpdateCDSC1ALS crashes

Gautam was working on his digital frequency counter stuff when the c1als model crashed. I had trouble bringing it back until I realized that, for reasons unknown to me, the safe.snap file that the model looks for at boot had been deleted. (This file lives in /target/c1als/c1alsepics/burt). I copied over this morning's version from Chiara's local backup. 

At the sites, these files are under version control in the userapps svn repository, presumably symlinked into the target directory. We should definitely do something along these lines. 

  11700   Mon Oct 19 16:20:52 2015 ericqUpdateLSCGreen beatnote couplers installed

Last Friday, I installed some RF couplers on the green BBPDs' outputs, and sent them over to Gautam's frequency divider module. At first I tried 20dB couplers, but it seemed like not enough power was reaching the dividers to produce a good output. I could only find one 10dB coupler, and I stuck that on the X BBPD. With that, I could see some real signals come into the digital system.

I don't think it should be a problem to leave the couplers there during other activities.

  11701   Tue Oct 20 11:24:29 2015 ericqHowToLSCHow to DRFPMI

Herein, I will describe the current settings and procedures used to achieve the DRFPMI lock, cobbled together from scripts, burts and such. 

Initial Alignment

  1. With arms POX/POY locked, run dither alignment servos. Set transmon QPD offsets here
  2. Restore "PRMI Carrier" configuration, run BS and PRM dither alignment servos simultaneously. (Note: this sacrifices some X arm alignment for better dark port alignment. In practice no appreciable loss of TRX is observed)
  3. Misalign PRM, align SRM and tune SRM alignment by eye while looking at AS camera. 
  4. Restore POX/POY arm lock, lock green to arms, check that powers are high enough and align if neccesary.

Initial Configuration


For CARM and DARM, the A channels are used for the ALS signals, whereas the B channels are used for blending the RF signals. 


  • BEATX and BEATY, I and Q channels: +0dB Whitening Gain, Whitening Filters ON
  • Green beatnotes somewhere between 20-80MHz, following sign convention of temperature slider UP makes beat freq go UP.  Check spectrum of PHASE_OUT_HZ vs references in ALS_outOfLoop_Ref.xml. The locking script automatically sets the correct phase tracker gain, so no need to adjust manually.
  • CARM_A = -1.0 x ALSX + 1.0 x ALSY, G=1.0
  • DARM_A = 1.0 x ALSX + 1.0 x ALSY, G=1.0


  • CM Board: REFL11 I daugher board output -> IN1, IN1 Enabled, -32dB input gain, 0.0V offset, all boosts off, AO polarity positive, AO gain +0dB
  • MC Board: IN2 disabled, -32dB input gain
  • CM_SLOW: +0dB Whitening Gain, Whitening ON, LSC-CM_SLOW_GAIN = -5e-4 (Though, it would be good to reallocate this gain to the input matrix element)
  • CARM_B = 1.0 x CM_SLOW, FM4 FM10 ON, G=0 (FM4 = LP700 for AO crossover stability, FM10 = 120:5k for coupled cavity pole compensation)
  • AS55: +9dB Whitening Gain, Whitening filters manual, Demod angle -37.0
  • DARM_B = -1e-4 x AS55 Q, G=0


For the DRMI, the A channels are used for the 1F signals, whereas the B channels are used for the 3F signals. The settings for transitioning to 1F after locking the DRFPMI have not yet been determined. 

These settings are currently saved in the DRMI configurator, but the demod angles are set for DRFPMI lock, so the settings don't reliably work for misaligned arms. 

  • REFL33: +30dB Whitening Gain, Whitening filters trigger on DRMI lock, Demod angle: 136.0
  • REFL165: +24dB Whitening Gain, Whitening filters trigger on DRMI lock, Demod angle: -111.0
  • POP22: +15dB Whitening Gain, Whitening filters OFF, Demod angle: -114.0
  • AS110: +36dB Whitening Gain, Whitening filters OFF, Demod angle: -116.0
  • POPDC: +0dB Whitening Gain, Whitening filters OFF (used as a supplemental trigger signal when CARM and DARM are buzzing and POP22 fluctuates wildly)
  • MICH_B = 6.0 x REFL165Q, offset = 15.0
  • PRCL_B = 5.0 x REFL33I, offset = 45.0
  • SRCL_B = -0.6 x REFL165I + 0.24 x REFL33 I, offset=0

The REFL33 element in SRCL_B is to reduce the PRCL coupling, was found empirically by tuning the relative gains with the arms misaligned and looking at excitation line heights. The offsets were found by locking the DRMI on 1F signals with arms misaligned, and taking the average value of these 3F error signals.  

Servo filter configuration

The CARM and DARM ALS settings are largely scripted by scripts/ALS/Transition_IR_ALS.py, which takes you from arms POX/POY locked to CARM and DARM ALS locked. The DRMI settings are usually restored from the IFO_CONFIGURE screen. 

  • CARM: FM[1, 2, 3, 5, 6] , G=4.5, Trigger forced on, no FM triggers, output limit 8k
  • DARM: FM[1, 2, 3, 5, 6] , G=4.5, Trigger forced on, no FM triggers, output limit 8k
  • MICH: FM[4, 5], G= -0.03, Trigger POP22 I x 1.0 [50, 10], FM[2, 3, 7] triggered [50, 10], output limit 20k
  • PRCL: FM[4, 5], G= -0.003, Trigger POP22 I x 1.0 [50, 10], FM[1, 2, 8, 9] triggered [50, 10], output limit 8k
  • SRCL: FM[4, 5], G= -0.4, Trigger AS110 Q x 1.0 [500, 100], FM[2, 7, 9] triggered [500, 100], output limit 15k

Actuation Output matrix

  • MC2 = -1.0 x CARM
  • ETMX = -1.0 x DARM
  • ETMY = 1.0 x DARM
  • BS = 0.5 x MICH
  • PRM = 1.0 x PRCL - 0.2655 MICH
  • SRM = 1.0 x SRCL + 0.25 MICH (The mich compensation is very roughly estimated)

Locking Procedure

When arms are POX/POY locked, and the green beatnotes are appropriately configured, calling scripts/DRFPMI/carm_cm_up.sh initiates the following sequence of events:

  • Turn ON MC length feedforward and PRC angle feedforward
  • Set ALS phase tracker UGFs by looking at I and Q magnitudes
  • Set LSC-ALSX and LSC-ALSY offsets by averaging, ramp CARM+DARM gains up, XARM+YARM gains down, engage CARM+DARM boosts, now ALS locked
  • Move CARM away from resonance, offset = -4.0 (DRMI locks quicker on this side for whatever reason)
  • Restore PRM, SRM alignment. Set DRMI A FM gains to 0, B FM gains to 1.0. Enable LSC outputs for BS, PRM, SRM
  • When DRMI has locked, add POPDC trigger elements to DRMI signals and transition SRCL triggering to POP22I. NB: In the c1lsc model, the POPDC signal incident on the trigger matrix has an abs() operator applied to it first. 
    • MICH Trig = 1.0 x POP22 I + 0.5 x POPDC, [50, 10]
    • PRCL Trig = 1.0 x POP22 I + 0.5 x POPDC, [50, 10]
    • SRCL Trig = 10.0 x POP22 I + 5 x POPDC, [500, 100]
  • Reduce POX, POY whitening gains from their nominal +45dB to +0dB, so there aren't railing channels making noise in the whitening chassis and ADCs
  • DC couple ITM oplevs (average spot position, set FM offset, turn on DC boost filter, let settle)
  • With an 8 second ramp, reduce CARM offset to 0 counts. 
  • MANUALLY adjust CARM_A and DARM_A offsets to where CARM_B_IN and DARM_B_IN are seen to fluctuate symetrically around their zero crossing.
    • Note: Last week, this adjustment tended to be roughly the same from lock to lock, unlike the PRFPMI which generally didn't need much adjustment. Also, by jumping from CARM offset of -0.4 to 0.4, it could be seen that the zero crossing in  CARM_B aka CM_SLOW aka REFL11 had some offset, so CARM_B_OFFSET was set to 0.005, but this may change. 

When CARM and DARM are buzzing around true zero, powers maximized:

  • CARM and DARM FM1 (18,18:1,1 boosts) OFF
  • CARM_B_GAIN 0.0 -> 1.0, FM7 ON (20:0 boost)
  • DARM_B_GAIN 0.0 -> 0.015, FM7 ON (20:0 boost) 
  • MC servo board IN2 ENABLE, IN2 gain -32dB -> -16dB
  • Turn ALL MC2 violin filters OFF (smoothen out AO crossover)
  • If stable, CM board IN1 gain -32dB -> -10dB (This is the overall CARM gain, the arm powers stabilize within the last few dB of this transition)
  • CARM_A_GAIN 1.0 -> 0.7
  • CARM_A FM9 ON (LP1k), sleep, FM 1 ON (1:20 deboost), sleep, FM 2 ON (1:20 deboost), HOLD OUPUT, CARM now RF only
  • DARM_B_GAIN 0.015 -> 0.02, sleep, DARM_A_GAIN 1.0 -> 0.0 (This may not be the ideal final DARM_B gain, UGF hasn't been checked yet)

IFO is now RF only!

  • Turn on transmon QPD servos.
  • Adjust comm/diff QPD servo offsets to correct any problems evident on AS/REFL cameras. This usually brings powers from ~100-120 to ~130-140. 

This is as far as we've taken the DRFPMI so far, but the CARM bandwidth is still only at a few kHz. Based on PRFPMI locking, the next steps will be:

  • CM BOARD +12dB or so additional IN1 gain, more AO gain may be needed to get crossover to final position of ~100Hz
  • MC2 viollin filters back on
  • CM boost(s) on
  • AS55 whitening on
  • Transition DRMI to 1F
  11702   Tue Oct 20 15:51:44 2015 ericqUpdateSUSMC2 F2P tuned

Using a modified version of Hang's deMod_deCoup scripts, I tuned the MC2 coil output matrix to minimize the appearance of POS drive in the SUSPIT signal at 28Hz. Up until now, there was no F2P compensation. This reduced the force to pitch coupling at 28Hz by 8dByes

Old: POS -> 1 x UL, 1 x UR, 1 x LL, 1x LR

New: POS -> 1.1054 x UL, 1.1054 x UR, 0.8946 x LL, 0.8946 LR

I checked the MCL spectrum before and after this change with OAF on, this did not spoil the feedforward length subtraction in any noticible way. 

The script lives in userapps/release/isc/c1/scripts/decoup, but I've symlinked it to /opt/rtcds/caltech/c1/scripts/decoup.

The script modification I made had to do with how the I and Q data is collected. Before, it was sporadically probing the I and Q FM output monitor EPICS values; I changed it to use the avg function of cdsutils, which calculates the mean and std from the 16kHz data and have seen it improve results by 1dB or so. I've been in touch with Jenne to propagate this to the sites. 

  11703   Tue Oct 20 16:27:04 2015 ericqUpdateVACvacuum VME machines rebooted

[ericq, Gautam, Steve]

Following roughly the same procedure as ELOG 11354, c1vac1 and c1vac2 were rebooted. The symptoms were identical to the situation in that ELOG; c1vac1 could be pinged and telneted to, but c1vac2 was totally unresponsive. 

The only change in the linked procedure was that we did not shut down the maglev. Since I unwittingly had it running for days without V4 open while Steve was away, we now know that it can handle shorter periods of time than that...

Upon reboot, many channels were readable again, unfortunately the channels for TP2 and TP3 are still blank. We were able to return to "Vacuum normal state," but because of unknowned communication problems with VM1's interlock, we can't open VM1 for the RGA. Instead we opened VM2 to expose the RGA to the main IFO volumn, but this isn't part of the "Normal" state definite, so things currently read "Undefined state".

  11716   Tue Oct 27 03:46:26 2015 ericqUpdateSUSMC2 F2P mis-tuned

D'oh. Good point.

Reverted for now; I'm thinking about doing laser pointer->MC2 QPD...

  11718   Tue Oct 27 03:56:52 2015 ericqUpdateLSCDRFPMI work

A handful of DRFPMI locks tonight, longest one was ~7 minutes. 

EPICS/network latency has been a huge pain tonight. The locking script may hang between commands at an unstable place, or fail to execute commands altogether because it can't find the EPICS channel. This prevented or broke a number of locks. 

I made some CARM OLG and crossover measurements, and found the AO gain for the right crossover freq (~100Hz) to be ~8dB different than what's in the PRFPMI script, which is weird. Right now, the CARM bandwidth / ability to turn on boosts is limited by the gain peaking in the IMC CLG due to the high-ish PC/PZT crossover frequency we're using. 

Gautam turned on some sensing excitations during the last couple of locks, but they weren't on for very long before the lock loss. Hopefully I can pull out at least some angles from the data. 

I'm also more convinced that the PRC angular FF needs retuning; there is more residual motion on the cameras than I'm used to seeing. I've taken more data that I'll use to recalculate a wiener filter tomorrow. 

The PMC, ALSX beat and ITMX oplev all needed a reasonable pitch realignment tonight. 

  11721   Wed Oct 28 17:06:30 2015 ericqUpdateASCNew PRC Angular FF filters installed

I've installed new filters for the T240 -> PRM static online angular feedforward that were trained after some of the recent changes to the signal chain of the relevant signals (i.e. the counts->velocity calibration that Rana did for the seismometers, and fixing the improper dewhitening of the POP QPD channels used as the Wiener target.)

Quickly trying them out now shows about the same level of performance as the previous ones, but the real performance I care about is during after-hours locking-time, so I'll take more measurements tonight to be posted here. 

  11722   Thu Oct 29 03:25:49 2015 ericqUpdateLSCDRFPMI work

[ericq, Gautam]

The length of DRFPMI lock did not increase much tonight, but we got a ~80 second sensing matrix measurement, and got the CARM bandwidth up to 10k with two boosts on. 

NB: I did not measure the CARM loop gain at its excitation frequency, so the plotted sensing element is supressed by the CARM loop. However, this is still useful for gauging the size of the PRCL signal vs. the residual CARM fluctuations. The excitations are fairly closely spaced between 309 and 316 Hz. 

For comparison, I'm also re-plotting the DRMI sensing measurement from a few weeks back taken at CARM offset of -4. We can see some change in the PRCL sensing, likely due to the CARM-coupled path. MICH/PRCL sadly looks pretty degenerate, but REFL55 looks more reasonable. 


I think the main limitation tonight was SRC stability. Even before bringing CARM to zero offset, we would see occasional sharp dives in AS110 power. One lockloss happened soon after such an occurance, but I checked the values, and it was not sufficient to trigger the Schmitt trigger down; instead it may have been a real optical loss of signal. The SRCL OLTF looks sensible. 

Random notes:

  • Aux X laser was glitching yet again, twiddled laser current to 1.90A from the 1.95A that I twiddled it to on Monday from the nominal 2.0A. 
  • When aligning the PRMI, I saw both ITMs' oplevs shift by a few urad in both pitch and yaw when engaing/breaking the lock, but this was not repeatable.
  • I reduced the AS110 whitening gain by 9dB, since the DC values were a few thousands, and I wanted to make sure there were no stray ADC saturations. This didn't change lock stability though. 
Attachment 1: DRFPMI.pdf
Attachment 2: DRMIarms.pdf
  11726   Tue Nov 3 03:12:46 2015 ericqUpdateLSCDRFPMI work

Tonight was kind of a wash. 

We spent some time retaking single arm scans with Gautam's frequency counting code to confirm the linewidths he measured before his most recent round of code improvements. During this, ETMX was being its old fussy self, costing us gentle realignment time. For the time being, we started actuating on ITMX for single arm locks. Also, out of superstition, I changed the static position offset that had been at +1k for the last N months to -1k. 

ETMX broke us out of a few DRFPMI lock trials as well, as did poor SRM alignment. I finally set up dither alignement settings for SRM in DRMI though, which helped (even in the arms-held-off-resonance situation). I still prefer doing the PRM/BS dither alignment in a carrier PRMI lock, because I think the SNR should be better than DRMI. 

We know that the ETMX excursions can happen without length drive exciting them, but also that length drives certainly can excite them. For future locks, I'm going to try out avoiding ETMX drive altogether; the sites use a single ETM for their DARM actuation and let the CARM loop take care of the resultant cross coupling, so hopefully we can do the same without angering the mode cleaner.

Anyways, we didn't really ever make it far enough to do anything interested with the DRFPMI tonight frown

  11729   Wed Nov 4 14:44:00 2015 ericqUpdateSUSETMX oplev servo disabled

I've turned the ETMX oplev servos off for the time being. (At the input side, so that no scripts will accidently turn it on).

Thus, only the local damping is being applied, let's see if we see any kicks...

  11731   Wed Nov 4 16:12:07 2015 ericqUpdateCDSOPTIMUS

There is a new machine on the martian network: 32 cores and 128GB of RAM. Probably this is more useful for intensive number crunching in MATLAB or whatever as opposed to IFO control. I've set up some of the LIGO analysis tools on it as well. 

A successor to Megatron, I dub it: OPTIMUS

  11733   Wed Nov 4 22:42:02 2015 ericqUpdateSUSETMX oplev servo disabled

During this time period, it looks like there was maybe one excursion. Here are the individual OSEM signals, which I think to be calibrated to microns. 

When I'm doing other things, I'm going to intentionally leave the watchdog tripped, and see if anything happens. 

  11742   Mon Nov 9 15:59:06 2015 ericqUpdateLSCFSR and linewidth measurements with phase tracker

- modulation depth = 0.390 +/- 0.062

There are two modulation frequencies that make it to the arm cavities, at ~11MHz and ~55MHz. Each of these will have their own modulation depth indepedent of each other. Bundling them together into one number doesn't tell us what's really going on. 

  11744   Mon Nov 9 23:22:18 2015 ericqUpdateSUSETMX oplev servo disabled

During a ETMX kick that just occured, with only local damping on, the slow VMon channels didn't show any noticable change. 

  11758   Thu Nov 12 10:47:17 2015 ericqUpdateSUSETMX oplev servo disabled

By looking at the oplev and Vmons before and after a step of 90 counts in SUS-ETMX_PIT_OFFSET, I observe:

  • UL: +1.53mV / urad
  • UR: -1.94mV / urad
  • LR: -1.54mV / urad
  • LL: +1.92mv / urad

The random error associated with these measurements is ~0.02mV

So, the ~7urad urad shift seen in my earlier post would mean a change of around 10mV in the Vmon signals, which isn't evident in the traces. So, this is possibly a piece of evidence in favor of a real mechanical shift, rather than an electronic glitch. 

  11759   Thu Nov 12 16:00:55 2015 ericqUpdateIOOPSL Laser turned back on

We found the PSL laser switched off. Looking at the wall StripTool, it looks like this happened about 4 hours ago. Gautam was working at and around the PSL table, and I suspect he accidently ran into the Big Red Button. 

We turned the laser back on.

  11770   Tue Nov 17 00:57:21 2015 ericqUpdateSUSITMX UL calmed?

After running dither alignment for all mirrors, all oplevs were recentered. (Except ETMY, since we did that earlier today.)

Looking at Koji's template for OSEM signals, the ITMX UL sensor noise floor seems more in line with the LL sensor, though there continues to be more noise than in other mirrors. 


Trending the sensor signals over the past 7 days, Koji's measurement looks to have been taken during a time when the UL sensor voltage had jumped down. Did someone squish the satellite box cable? I have not done so. 

I think that the step right at the end is due to a new POS offset of -2k counts, which I think Koji put into place earlier today. 

According to the wiki, the Vmax/2 values and the current values are: 



















Attachment 1: TM_nov17.pdf
  11772   Tue Nov 17 14:31:25 2015 ericqUpdateCDS16Hz frame writing temporarily disabled

To test the effect on EPICS latency, I've restarted daqd with modified ini files which disable all frame writing of 16Hz channels. 

This happened at GPS:1131835955 aka Nov 17 2015 22:52:18 UTC

Last night, I started running a script written by Dave Barker that monitors a specified EPICS channel (in this case C1:IOO-MC_TRANS_SUM), to look for seconds in which it does not update the expected number of times. This is still running, so I will be able to compare the rate of EPICS slowdowns before and after this change. 

I will revert back to the nominal state of things in a few hours, or until someone asks me to. 

  11777   Tue Nov 17 20:57:43 2015 ericqUpdateCDS16Hz frame writing running again

Back to nominal FB configuration at 1131857782, aka Nov 18 2015 04:56:05 UTC.

Weirdly, during this time, the script watching MC_TRANS_SUM from pianosa saw tons of freezes, but another instance  watching LSC-TRY_OUT16 on optimus saw no freezes. 

  11778   Wed Nov 18 10:10:53 2015 ericqUpdateCDSc1iscey IO chassis missing brackets

Steve and I inadvertently discovered that the c1iscey IO chassis doesn't have brackets to secure the cards where the ADC/DAC cables are connected, making them very easy to knock loose. All other IO chassis have these brackets. Pictures of c1iscey and c1lsc IO chassis to compare:

  11786   Wed Nov 18 23:18:07 2015 ericqUpdateComputer Scripts / Programsnodus /boot cleared up

The /boot partition was filling up with old kernels. Nodus has automatic security updates turned on, so new kernels roll in and the old ones don't get removed. 

I ran apt-get autoremove, which removed several old kernels. (apt is configured by default to keep two previous kernels around when autoremoving, so this isn't so risky)

Now: /dev/sda1                    236M   94M  130M  42% /boot

In principle, one should be able change a setting in /etc/apt/apt.conf.d/50unattended-upgrades that would do this cleanup automatically, but this mechanism has a bug whose fix hasn't propagated out yet (link). So, I've added a line to nodus' root crontab to autoremove once a week, Sunday morning. 

  11789   Thu Nov 19 15:16:24 2015 ericqUpdateCDSc1iscey IO chassis now has brackets

[Steve, ericq]

Brackets for the c1iscey IO chassis cards have been installed. Now, I can't unseat the cards by wiggling the ADC or DAC cable. yes

  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. 

  11803   Mon Nov 23 23:42:56 2015 ericqUpdateLSCALSY recovered

[ericq, gautam]

Gautam couldn't observe a Y green beatnote earlier, so we checked things out, fixed things up, and performance is back to nominal based on past references. 

Things done:

  • Marconi carrier output switched back on after Koji's excellent RF maintence
  • BBPD power supplies switched on
  • Removed a steering mirror from the green beatY path to do near/far field alignment. 
  • Aligned PSL / Y green beams 
  • Replaced mirror, centered beam on BBPD, moved GTRY camera to get the new spot.
  • POY locked, dither aligned, beatnote found, checked ALS out-of-loop noise, found to be in good shape. 
  11825   Mon Nov 30 14:12:14 2015 ericqUpdateLSCLO level check for the LSC RF distribution box

I checked the RF levels at the LSC LO distribution box, with the agilent scope and a handful of couplers. This was all done with the Marconi at +13dBm. 

I only checked the channels that are currently in use, since the analyzer only measures 3 channels at a time, and rewiring involves walking back and forth to the IOO rack to make sure unpowered amps aren't driven, and I was getting hungry. 

For the most part, the LO levels coming into the LSC demod boards are all around +1.5dBm (i.e. I measured around -18.0dBm out of the ZFDC-20-5 coupler, which has a nominal 19.5dB coupling factor)

The inputs piped over from the IOO rack, labeled as "+6dBm" were found to be 4.7dBm and 2.9dBm for 11Mhz and 55MHz, respectively. 

The 2F signals were generally about 40dB lower, with two exceptions:

  • REFL165's ~332MHz signal was around -18dBc
  • POP22 had many more visible harmonics than any other LO signal
    • 11MHz: -32 dBc
    • 33MHz: -32 dBc
    • 44Mhz: -15dBc 

Here are the raw numbers I measured out of the couplers, all in dBm:

  • 11MHz in: -14.8
  • 55MHz in: -16.6
  • POX11:    -18.7
  • POY11:    -18.0
  • REFL11:   -18.0
  • REFL33:   -18.3
  • POP110:   -17.9
  • AS110:    -18.1
  • POP22:    -19.9
  • REFL165:  -18.5
  • AS55:     -18.6
  • POP55:    -18.8 (this port is used as the REFL55 LO)
  11827   Mon Nov 30 16:33:06 2015 ericqUpdateLSCstrange behavior of ASDC

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

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

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

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

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

  11836   Wed Dec 2 03:34:30 2015 ericqUpdateLSCSRCL OLG weirdness

[gautam, ericq]

Since ETMX seems to have been on good behavior lately, we tried to fire the IFO back up. 

We had a fair amount of trouble locking the DRMI with the arms held off resonance. For reasons yet to be understood, we discovered that the SRCL OLG looks totally bananas. It isn't possible to hold the DRMI for very long with this shape, obviously. 

With the arms misaligned and the DRMI locked on 1F, the loop shape is totally normal. I haven't yet tried 3F locking with the arms misaligned, but this is a logical next step; I just need to look up the old demod angles used for this, since it wasn't quickly possible with the 3F demod angles that are currently set for the DRFPMI. 

Attachment 1: weirdSRCLG.pdf
  11837   Wed Dec 2 15:08:41 2015 ericqUpdateComputer Scripts / ProgramsDonatella sudo problem resolved

Somehow, the controls user account on donatella lost its membership to the sudoers group, which meant doing anything that needs root authentication was impossible. 

I fixed this by booting up from a Linux install USB drive, mounting the HD, and running useradd controls sudo

  11848   Fri Dec 4 13:12:41 2015 ericqUpdateCDSc1ioo Timing Overruns Solved

I had noticed for a while that the c1ioo frontend model had much higher variability than any of the other other 16k models, and would run longer than 60us multiple times an hour. This struck me as odd, since all it does is control the WFS loops. (You can see this on the Nov17 Summary page. (But somehow, the CDS tab seems broken since then, and I'm not sure why...))

This has happily now been solved! While poking around the model, I noticed that the MC2 transmission QPD data streams being sent over from c1mcs were using RFM blocks. This seemed weird to me, since I wasn't even aware that c1ioo had an RFM card. Since the c1sus and c1ioo frontends are both on the Dolphin network, I changed them to Dolphin blocks and voila! The cylce time now holds steady at 21usec. 

Update: I think I figured out the problem with the CDS summary pages. Looking at the .err files in /home/40m/public_html/summary/logs on the 40m LDAS account showed that C1:FEC-33_CPU_METER wasn't found in the frame files. Indeed, this channel was commented out in c1/chans/daq/C0EDCU.ini. I enabled it and restarted daqd. Hopefully the CDS tab will come back soon...

  11854   Mon Dec 7 00:45:28 2015 ericqUpdateCDSdaqd is mad

I glanced at the summary pages and noticed that, since Friday around when we first loaded up the new BLRMS parts, daqd has crashing very frequently (few times per hour). 

I'm going to comment out the c1pem lines from the daqd master file for tonight, and see if that helps. 

  11856   Mon Dec 7 10:45:21 2015 ericqUpdateCDSdaqd is mad

Since removing c1pem from the daqd master file, daqd has not crashed. I suppose we're running into the stability issue that motivated us to disable some of the other models (IOPs, RFM, etc.) during the RCG upgrade. 

A question to Jamie: although the new framebuilder prototype still had the same problem with trend writing, can it handle this higher testpoint/DQ channel load?

  11862   Tue Dec 8 15:18:29 2015 ericqUpdateComputer Scripts / ProgramsNodus security

I've done a couple things to try and make nodus a little more secure. Some have worried that nodus may be susceptible to being drafted into a botnet, slowing down our operations. 

1. I configured the ssh server settings to disallow logins as root. Ubuntu doesn't enable the root account by default anyways, but it doesn't hurt.

2. I installed fail2ban. Function: If some IP address fails to authenticate an ssh connection 3 times, it is banned from trying to connect for 10 minutes. This is mostly for thwarting mass brute force attacks. Looking at /var/log/auth.log doesn't indicate any of this kind of thing going on in the past week, at least.

3. I set up and enabled ufw (uncomplicated firewall) to only allow incoming traffic for:

  • ssh
  • ELOG
  • Nodus apache stuff (svn, wikis, etc.)

I don't think there are any other ports we need open, but I could be wrong. Let me know if I broke something you need!

  11880   Mon Dec 14 16:46:42 2015 ericqUpdateWienerFilteringNoise Subtraction Puzzler

Here's something to ponder.

Our online MCL feedforward uses perpendicular vertex T240 seismometer signals as input. When designing a feedforward filter, whether FIR Wiener or otherwise, we posit that the PSD of the best linear subtraction one can theoretically achieve is given by the coherence, via Psub = P(1-C). 

If we have more than one witness input, but they are completely uncorrelated, then this extends to Psub = P(1-C1)(1-C2). However, in reality, there are correlations between the witnesses, which would make this an overestimate of how much noise power can be subtracted. 

Now, I present the actual MCL situation. [According to Ignacio's ELOG (11584), the online performance is not far from this offline prediction]

Somehow, we are able to subtract much more noise at ~1Hz than the coherence would lead you to believe. One suspicion of mine is that the noise at 1Hz is quite nonstationary. Using median [C/P]SDs should help with this in principle, but the above was all done with medians, and using the mean is not much different.

Thinking back to one of the metrics that Eve and Koji were talking about this summer, (std(S)/mean(S), where S is the spectrogram of the signal) gives an answer of ~2.3 at that peak at 1.4Hz, which is definitely in the nonstationary regieme, but I don't have much intution into just how severe that value is.

So, what's the point of all this? We generally use coherence as a heuristic to judge whether we should bother attempting any noise subtraction in the first place, so I'm troubled by a circumstance in which there is much more subtraction to be had than coherence leads us to believe. I would like to come up with a way of predicting MISO subtraction results of nonstationary couplings more reliably.

Attachment 1: subpuzz.pdf
  11881   Mon Dec 14 23:49:03 2015 ericqUpdateOptical LeversCalibration of oplevs for ITMX/ETMX

Based on calibration measurement I have done (elog 11785, 11831), I updated calibration factors of oplevs on medm screen as follows. Not to change loop gain oplev servo, I also changed oplev servo gain.

After making sure that the upper UGFs were properly in place, I saved these settings to the SDF files. Thanks Yutaro!

  11882   Mon Dec 14 23:56:29 2015 ericqUpdateCDSc1pem reverted

To get C1PEM data back into the frames, I removed the new BLRMS blocks, recompiled, reinstalled, re-enabled it in daqd, restarted.

We still really want more headroom in our framebuilder situation. 

  11888   Wed Dec 16 23:15:28 2015 ericqUpdateGreen LockingGreen beat channels temporarily set up as IR beat channels

With the IR beats going to the nominal ALS channels as Gautam left them, we're able to measure the free running frequency noise of the end AUX lasers. 

Specifically, the end shutters are closed, leaving the AUX lasers free running. The IR beats then consist of this free running light beating with the PSL light, and the ALS phase trackers give a calibrated frequency noise spectrum. I've stabilized the PSL light by locking the laser to the Y arm via MC2 acutation, so the free running AUX laser noise should dominate by a lot above the suspension resonances. This also has the benefit of giving me the use of the CAL'd Y arm displacement as a sanity check. 

At this point in time, it looks like the X laser is close to 10x noisier than the Y laser, though it does seem to be at the rule-of-thumb "10kHz/rtHz at 100Hz" level. 

Attachment 1: 2015-12-16_AUXfreerunning.pdf
  11889   Thu Dec 17 01:55:16 2015 ericqUpdateLSCUncooperative AUX X

[ericq, Gautam]

We were not able to fix the excess frequency noise of the AUX X laser by the usual laser diode current song and dance. Unfortunately, this level of noise is much too high to have any realistic chance of locking.  angry

We're leaving things back in the IR beat -> phase tracker state with free running AUX lasers, on the off chance that there may be anything interesting to see in the overnight data. This may be limited by our lack of automatic beatnote frequency control. (Gautam will soon implement this via digital frequency counter). I've upped the FINE_PHASE_OUT_HZ_DQ frame rate to 16k from 2k, so we can see more of the spectrum.

For the Y beat, there is the additional weird phenomenon that the beat amplitude slowly oscillates to zero over ~10 minutes, and then back up to its maximum. This makes it hard for the phase tracker servo to stay stable... I don't have a good explanation for this. 

  11893   Sun Dec 20 23:23:54 2015 ericqUpdateALARMRats.

A small rat / large mouse just ran through the control room. Ugh.

  11894   Mon Dec 21 02:29:49 2015 ericqUpdateLSCAUX X RIN measurements

I'll finish up the beat / frequency noise parts of the diagnosis tomorrow later, but I've done some investigation of the AUX X laser RIN. 

I placed a PDA255 at one of the rejected beams from the PBS on the downstream side of the IR faraday, making sure the power didn't saturate the PD. I measured the RIN on a SR785, and simultaneously looked at the signal on a 100MHz scope. 

The RIN has a very strong dependence on the laser diode current, and no noticable dependence on the crystal temperature or the presence of the PDH modulation / temperature control cables. Here are some traces, note that "nominal" current up until recently was 2.0A. 

When adjusting the diode current, a peak beings to appear in the tens of kHz, eventually noticible in the DC power trace on the scope. The point at which this occurs is not fixed.

At all times, I saw a strong intensity fluctuation at around 380-400kHz on the scope whose amplitude fluctuated a fair amount (at least 75mVrms over Vdc=6.5V, but would often be 2 or 3 times that).

I didn't look at the frequency noise while doing this, because the WiFi at the X end was too slow, I'll do more tomorrow in the daytime. 

Attachment 1: auxXRIN.pdf
  11908   Tue Jan 5 02:54:38 2016 ericqUpdateLSCAUX X Freq Noise attempt

[ericq, Gautam]

We set out to lock a marconi to the IR fiber beat of PSL + AUX X to measure some frequency noise, and failed.

In short, the Marconi's 1.6MHz max external FM isn't enough oomph to stabilize the PLL error signal. It's actually evident on the Agilent that the beat moves around a few times more than that, which I should've noticed sooner... We could briefly "lock" the PLL for a few tenths of a second, but weren't able to get a spectrum from this.

We also tried using the digital phase tracker temperature servo for some help at ~DC; this worked to the extent that we didn't have to twiddle the Marconi carrier frequency to stay on top of the fringes as the beat wandered, but it didn't otherwise stabilize the beat enough to make a difference in locking the PLL.

I suppose one more thing to try is to lock the PSL laser itself to each AUX laser in turn via PLL, and look for different / excess noise.

The Green and IR beat electronics are a in a little bit of disarray at the moment, but it's not like anyone else is going to be using them for the time being...

  11912   Tue Jan 5 16:33:45 2016 ericqUpdateLSCAUX X Freq Noise attempt

Turning on the MCL path (in addition to the MCL FF we always have on) let me lock the PLL for multiple seconds, but low frequency excursions still break it in the end. I was able to briefly observe a level of ~50Hz/rtHz at 1kHz, which may or may not be real. Tomorrow we'll send the PLL control signal to MC2, which should lock it up just fine and give us time to twiddle laser diode current, measure the PLL loop shape, etc. 

  11916   Wed Jan 6 16:40:49 2016 ericqUpdateGeneralNew WiFi router

The new wifi router, a Netgear R6400, has been installed, next to the old one which is disconnected (but not yet removed). 

Same SSID, and I've added only the wireless MAC addresses of viviana, paoloa and asia, the three thinkpads inside.

Qualitatively, dataviewer at the X end seems pretty snappy. I'll do some more quantitative comparison of the two routers at some point soon. I will update the wiki, too.

  11917   Thu Jan 7 04:28:39 2016 ericqUpdateLSCAUX X Freq Noise measured

[ericq, Gautam]

Brief summary of tonights work:

  • Locked Marconi to AUX X vs PSL beat at around 320MHz, PSL shutter closed (i.e. both lasers free running)
  • Measured control signal spectrum at various laser diode currents, crystal temperatures. Oddly, spectra remained consistent across these variables. 
  • Measured OLG of PLL to calibrate into open-loop frequency noise of the beat, found UGF ~30kHz

Our "requirement" for the end laser is as follows: We expect to (and have in the past) achieved ALS sensitivity of 1Hz/rtHz at 100 Hz. If the end PDH loop is 1/f from 100Hz-10kHz, then we have 40dB of supression at 100Hz, meaning the free running AUX laser noise should be no more than 100Hz/rtHz at 100Hz.

So, if we expect both the PSL and AUX lasers to have this performance when free running, we would get the green curve below. We do not. frown

I'll post more details about the exact currents, temperatures and include calibrated plots for the >30kHz range later. Here's the OLG for kicks. 

Attachment 1: PLLspec.pdf
Attachment 2: PLL_OLG.pdf
  11918   Thu Jan 7 15:29:54 2016 ericqUpdateWienerFilteringNoise Subtraction Puzzler

The puzzle continues...

I found some reference for computing "multicoherence," which should properly estimate the potential MISO subtraction potential in situations where the witness channels themselves have nontrivial coherence. Specifically, I followed the derivations in LIGO-P990002. The underlying math is related to principal component analysis (PCA) or gram-schmidt orthogonalization. 

This produced the following results, wherein the Wiener subtraction is still below what the coherences predict. 

I've attached the data and code that produced this plot. 

Attachment 1: subpuzz2.pdf
Attachment 2: puzzle.zip
  11919   Thu Jan 7 16:52:32 2016 ericqUpdateLSCAUX X Freq Noise measured

Here is some of the promised data. As mentioned, changing diode current and crystal temperature didn't have much effect on the frequency noise spectrum; but the spectrum itself does seem too high for our needs. 

At each temperature, we started measuring the spectrum at 1.8A, and stepped the current up, hoping to reach 2.0 A.

At 47.5 C, we were able to scan the current from 1.8 to 2.0 A without much problem. At 49.0C, the laser mode would hop away above 1.95A. At 50.4C it would hop away above 1.85A. The spectra were not seen to change when physically disconnecting the PZT actuation BNC from the rear of the laser. 

The flattening out at the upper end is likely due to the SR560 output noise. I foolishly neglected to record the output spectrum of it, but with the marconi external modulation set to 3.2MHz/V, the few Hz/rtHz above 20k translates to a signal on the order of uV/rtHz, which seems reasonable. 

Data and code attached. 

Attachment 1: AUXfreqnoise.pdf
Attachment 2: auxXmeasurements.zip
  11921   Fri Jan 8 14:47:33 2016 ericqUpdateLSCAUX Y Freq Noise measured

Here are some results from measuring the PSL / AUX Y beat. 

With the Y end laser, I was able to lock the PLL with a lower actuation range (1.6MHz/V), and with the PSL in both the free-running and MCL locked configurations. (In the latter, I had to do a bit of human-turning-knob servo to keep the control signal from running away). I also took a spectrum with the marconi detuned from the beat frequency, to estimate the noise from the PD+mixer+SR560. 

It looks like the AUX X laser is about 3 times noisier than the Y, though the Y laser looks more like a 10^5 noise-frequency product, whereas I thought we needed 10^4. 

Gautam is investigating the PSL / AUX PSL beat with Koji's setup now. 

Attachment 1: AUX_freqnoises.pdf
Attachment 2: AUXY_Jan8.zip
ELOG V3.1.3-