I think the dolphin and RFM transit times are double-counted in this budget. As I understand it, all IPC transit times are already built in to the cycle time of the sending model. That is, the sending model is required to finish its computational work a little bit early, so there's time left to transmit data to the receivers before the start of the next cycle. Otherwise you get IPC errors. (This is why the LSC models at the sites can't use the last ~20 usec of their cycle without triggering IPC errors. They have to allow that much time for the RFM to get their control signals down the arms to the end stations.)

For instance, the delay measurement in elog 9881 (c1als to c1lsc via dolphin) shows only the c1lsc model's own 61 usec delay. If the dolphin transfer really took an additional cycle, you would expect 122 usec.

And in elog 10811 (c1scx to c1rfm to c1ass), the delay is 122 usec, not because the RFM itself adds delay, but because an extra model is traversed.

Bottom line: there may still be some DARM phase unaccounted for. And it would definitely help to bypass the c1rfm model, as suggested in 9881.

Now that both end transmission QPDs have the line filters, I aligned them.

I locked and aligned the IR using the ASS, then went to each end table and put the beam in the center of the QPD.

The SUS Drift Monitor screen has been updated:

• removed the old dead channels from the MEDM screen;
• updated the SUS models with new 'mute' channels where the expected values should be put;
• updated the MEDM screen with the new channels
• values are still 0 since I don't know what these expected values should be, at this time

Missing filter found. Labeled drawer OPHIR in control room - behind soldering station-  with spare battery and filter

I have added another block to the LSC screen (and made the corresponding sub-screen) to expose the analog settings for the DC photodiodes. 

Note that we have 2 open channels there, which are still called something like "PD2" and "PD3" from olden times.

If we ever chose to use those, we will probably want to change their names, in /cvs/cds/caltech/target/c1iscaux2/LSC_aux2.db and /cvs/cds/caltech/target/c1iscaux/LSC_aux.db

I have attached a photo of the ETMX table. The path of the 1064nm light rejected after the doubler and the green light are indicated for reference.

The fiber mount can only be mounted in the green space shown in the picture.

Calculating lens solutions for coupling the 1064nm light rejected after the doubler into the fiber, a lens of f=12.5cm should be placed at z=15.31cm (measured from the waist in the doubler crystal) gives the best ~80% coupling. This falls in the blue region where there is not enough space to mount a lens. 

The region marked in orange has enough room for a lens; but the lens solutions give a coupling <10% which means there will be light scattering everywhere.

I am open to any suggestions on how to go about this.

 We never, ever want to use ezcaservo to do this. IN fact, we twice have already deleted scripts where people have implemented these (sometimes) unstable servos. Also, since this change had never been committed to the SVN, I just deleted it and updated from the SVN to get back the script that doesn't use any servos.

I'm going to periodically delete locking scripts that are not committed to the SVN since anyone who is too lazy to use the SVN probably can't write code worth using.

I added UGF servos for the DRMI DoFs, after creating a library block for the servos. I also deleted the FMs before the phase rotation, since we can just do it afterwards in other existing FMs. I've only added the MICH and PRCL buttons to the LSC screen because in the end, I feel like a dropdown is better, but I just wanted to get it running quickly tonight. The LSC model and the UGF block have been committed to the svn. 

We were able to use the PRCL UGF servo successfully, as Jenne was exploring MICH offset space. 

[Jenne, EricQ, Rana]

Tonight we started prepping for an attempt at variable finesse locking. 

The idea is to put in a MICH offset and hold the lock with ASDC/POPDC (so that the offset can be larger than if we were just using RF signals).  This reduces the PRC buildup, which reduces / removes the double cavity resonance problems while reducing the CARM offset. 

• So.  Today, I pulled out the POP22 razor blade so that we can use the Thorlabs PD as POPDC, without the yaw coupling.  Our other option is to use the POP QPD SUM, but that would require some model changes and more importantly it's not a particularly low noise readout path.

• We re-set the analog whitening gains for ASDC and POPDC.
  • For ASDC, we want the half-fringe in the PRMI case to be not saturating.  We chose 18dB (it had been the default 0dB).
  • For POPDC, Rana and I saw that it was saturating all the time with the 33dB that it had when the carrier became resonant.  This was never really a problem in the past, but if we use it for normalization, we get glitches that knock us out of lock every time POPDC saturated.  So, now POPDC is at 0dB.  It still occasionally saturates when the PRMI is flashing, but we can't get lower than 0dB without going and putting an ND filter on the PD.
• We turned off the analog whitening filters and digital unwhitening for both ASDC and POPDC.  We can consider turning them back on later after we have acquired lock if we need them, but we need them off for acquisition.
• Locked MICH with ASDC/POPDC.  Good.  Stays locked even if PRM is flashing.
• Locked PRMI with PRCL on REFL33I and MICH on ASDC/POPDC.
• Locked arms, held off resonance with ALS, lock MICH with ASDC/POPDC. 
• Failed to lock PRMI with arms held off resonance, using the new scheme (no transition, trying to directly acquire)
• Locked PRMI on REFL33 I&Q with the arms held off resonance, and tried to transition MICH over to ASDC/POPDC, failed.
• Confusion about the relative phase between REFL33Q and ASDC.  It looks like it is ~45deg at 100 Hz, or ~90 deg at 375 Hz.  Why isn't it 0 or 180?
• Went back to PRMI-only, tried to map out fringe by changing MICH offset (tried while MICH was on both REFL33 and ASDC/POPDC).  Not really sure where we are on the fringe.

MICH locked on ASDC normalized by POPDC, PRM and ETMs (and SRM) all misaligned.

MICH offset of -20

MICH input = -0.04*ASDC normalized by 0.1*POPDC.

MICH gain = +5

MICH always triggered on (no triggering for DoF), but FM8 (CLP400) triggered to come on after lock (didn't write down the values).

PRMI locked with MICH on ASDC normalized by POPDC, PRCL on REFL33I, ETMs and SRM misaligned.

MICH offset of -10

MICH input = -0.04*ASDC normalized by 0.1*POPDC.

PRCL input = 1*REFL33I

MICH gain = +5

PRCL gain = -0.4 (factor ten times the regular value)

MICH always on, PRCL triggered on POP22.  MICH FM8 and PRCL FM1,2,6,9 triggered on.

Gives POPDC of about 20 counts, POP22 of about 12 counts, ASDC of about 500 counts.

Arms held at 3nm, MICH locked on ASDC/POPDC, PRM and SRM misaligned.

MICH offset of -10

MICH input = -0.04*ASDC normalized by 0.1*POPDC.

MICH gain = +5

MICH always on, PRCL triggered on POP22.  MICH FM8 and PRCL FM1,2,6,9 triggered on.

Arms held at 3nm, attempt at PRMI lock with MICH on ASDC/POPDC.

Failed.  Tried mostly same MICH gains as arms+mich, and PRCL at 10* normal gain.

Arms held at 3nm, PRMI locked with REFL 33 I&Q, attempt at transition to MICH on ASDC/POPDC.

Failed.  At first, I was putting in the TF line at ~375Hz, but we looked at the full transfer function between 100Hz and 1kHz, and there was a weird dip near 300Hz from PRCL-MICH loop coupling.  Here we were seeing that the phase between REFL33Q and ASDC was ~90 degrees.  What?

Tried putting the TF line at ~100 Hz (since MICH UGF is in the few tens of Hz anyway, so 100 is still above that), but still get weird relative phase.  Here it seems to be about 45 degrees when I inject a single line, although it didn't seem like a weird phase when we did the full swept sine earlier.  Maybe I was just not doing something right at that point??

Anyhow, no matter what values I tried to put into the input matrix (starting with REFL33I&Q, trying to get MICH to ASDC/POPDC), I kept losing lock.  This included trying to ramp up the MICH offset simultaneously with the matrix changing, which was meant to help with the PRCL gain change.  Q has since given us MICH and PRCL UGF servos.

Tomorrow:

• Why is there some weirdo phase between REFL33Q and ASDC at 100Hz?  Was I just being a spaz?
• With PRMI-only, figure out how to transition from REFL33 I&Q over to MICH on ASDC/POPDC.
• Then hold the arms off resonance, and do the same transition.  (First make sure we're at a good place on the fringe)
• Lower the CARM and DARM offsets, transition them to RF, engage CARM AO path.
• Reduce MICH offset, transition to RF.
• Celebrate (maybe).

I've installed the very fresh ELOG 3.0, for nothing else than the new built in text editor which has a LATEX capable equation editor built right in. 

Check out this sweet limerick: 

Here's a summary of the changes made to the D990511 serial 115 (formerly known as REFL 33), as well as a short procedure. It needed tuning to 29.5MHz and also had some other issues that we found along the way. 

So here's a picture of it as built:

The changes made are:

1. U11 and U12 changed from 5MHz LP to 10 MHz LP filters.

2. Resistors R8 and R9 moved from their PCB locations to between pins 1 (signal) and 3 (ground) of U11 and U12, respectively. These were put in the wrong place for proper termination so it made sense to shift them while I was already replacing the filters.

Also, please note- whoever labeled the voltages on this board needed an extra cup of coffee that day. There are two separate 15V power supplies, one converted from 24V, one directly supplied. The directly supplied one is labeled 15A. This does NOT mean 15 AMPS.

Transfer functions:

Equipment: 4395A, Signal generator (29.5 MHz), two splitters, one mixer

You can't take the TF from PD in to I/Q out directly. Since this is a demod board, there's a demodulating (downconverting) mixer in the I and Q PD in paths. Negligible signal will get through without some signal applied to the L input of the mixer. In theory, this signal could be at DC, but there are blocking capacitors in the LO in paths. Therefore, you have to upconvert the signal you're using to probe the board's behavior before it hits the board.  Using the 4395A as a network analyzer, split the RF out. RFout1 goes to input R, RFout2 goes to the IF port of the mixer. Split the signal generator (SG). SG1 goes to LO in, SG2 goes to the L port of the mixer. The RF port of the mixer (your upconverted RFout2) goes to PD in, and the I/Q out goes back to the A/B port of the 4395A - at the same frequency as the input, thanks to the board's internal downconversion. 

Phase measurement:

Equipment: Signal generator (29.5 MHz), signal generator (29.501 MHz), oscilloscope

Much simpler: 29.5 MHz to the LO input (0 dBm), 29.501 MHz to the PD input (0 dBm), compare the phases of the I/Q outputs on the oscilloscope. There are four variable capacitors in the circuit that are not on the DCC revision of the board - C28-31. On the LO path, C28 tunes the I phase, C30 tunes the Q phase. On the PD path, C29 and 31 appear to be purely decorative - both are in parallel with each other on the PD in Q path, I'm guessing C29 was supposed to be on the PD in I path. Fortunately, C28 and C30 had enough dynamic range to tune the I/Q phase difference to 90 degrees.

Before tuning:

After tuning:

The restored offset script used old tdsavg calls that our workstations can't do, and didn't include things like the transmon QPDs. I've written yet another offset script that uses cdsutils averaging to do the thing, and committed to the svn. 

The MEDM screen has been updated: the new buttons, one for each optic, call the scripts/general/SUS_DRIFTMON_update_reference.py script, which measures (and averages) for 30s the current values of the POS/PIT/YAW drifts, and then sets the average as the new reference value.

100 and 10 days trends of ETMX and ETMY_SUSPIT.  One can see clearly the earthquaks of Dec.30 and 31 on the 10 day plot. You can not see the two shakes  M3.0 & M4.3 of Jan. 3 

The long term plot looks OK , but   the 10 day plot show the problem of ETMX as it was shaken 4 times.

I worked around the PSL table today.

The Y+PSL output from the optical fiber module for FOL was fed to the input of the Thorlabs FPD310. 
200uW of incident light on the RFPD gave an RF signal of -70dBm as measured on a spectrum analyzer.

I swapped the beam splitter along the PSL path so that the incident power on the RFPD is ~1.5mW (Maximum incident power that the PD can tolerate is ~2mW).
This RF signal generated was - 43dBm which is still small for the input to the frequency counter module.

I checked this with a function generator and found that the frequency counter requires around -25 to -30 dBm at the input.

I plan to use the Minicircuits ZFL-1000ln that is on the IOO rack but not being used (This was used for green beatnote amplification but is not required/used anymore) to amplify the RF signal to the frequency counter.
If anyone has any objections to using this amplifier for the frequency counter, let me know.

Before starting to move things around the PSL table, I measured the ALS out of loop noise for reference. The noise spectrum showed excess noise around 30Hz.  The traces in blue were taken before I went in and those in red were taken after my work.

I also looked at the power spectrum of LSC-TRY_OUT to see if the noise is from the IR lock itself and there was nothing suspicious with it. 

Since the green transmission was 50% lower than the usual, I touched the steering mirrors for green at the Y end table to get a better transmission and beat signal. The noise still hasn't disappeared. 

I am not sure if this could be from our neigbors who have been running rock experiments since morning. We should check back to see if this noise disappears once they shut down.

DTT xml files are available in directory /users/manasa/data/150109/

A few hours ago I tweaked up the alignment to the PMC.  It was really bad in pitch, and the transmission was down to about 0.711.

We want to have some angular control of the arms during lock acquistion. 

In single arm lock, Diego and I shook the TMs and measured how the QPDs responded. (I would've liked to do a swept sine in DTT, but the user envelope function still isnt' working!)

For now, we can close simple loops with QPD sensor and ITM actuator, but, as Rana pointed out to Diego and me today, this will drive some amount of the angular cavity degree of freedom that the QPD doesn't sense. So, ideally, we want to come up with the right combination of ITM and ETM motion that lies entirely within the DoF that the QPD senses.

I created a rudimentary loop for Yarm yaw, was able to get ~20Hz for the upper UGF, a few mHz for the lower, but it was starting to leak into the length error signal. Further tweaking will be neccesary...

In order to know where we should try to make the transition from REFL##Q to ASDC for MICH, I did a quick Optickle simulation to see what the error signals will look like.

The idea is to try to lock the PRMI on a single REFL diode (ex. REFL33 I&Q) with some MICH offset, and then transition over to ASDC.  As soon as we have completed the transition, we can engage the normalization matrix to normalize ASDC by POPDC, and also increase the MICH offset if we want.  Unfortunately, we do not as yet have the ability in our model to independently normalize different error signals, and then blend them, so we have to turn on the normalization after we've transitioned.

Here is the situation for PRMI-only:

You can see that REFL33Q has a slightly wider range than REFL165Q.  It seems like we can perhaps try to make the transition around -15nm or so.  Note that the error signals are not quite symmetric about 0nm, so we can use that to help determine what + and - mean.  We expect that we need to add about 1nm offset to REFL33Q to get a true minimum in ASDC, so the sign of the digital offset that we need will tell us if there is a sign flip or not between the digital offset and this x-axis. 

After we get this to work (hopefully in the next hour or so....), we will want to try the same thing with the arms held off resonance. 

Usually we lock the PRMI at an offset of about 3nm:

However we could do it lower, perhaps around 1nm (which is where we currently are doing our CARM/DARM ALS->IR signals transitions):

At some point, we will arrive at 0nm CARM offset, when we'll want to transition back to RF signals (although probably we could jump straight to a 1f signal, not plotted):

The moral of the story here is that I'm not sure how we were ever successfully locking MICH on REFL165Q, unless my phase-setting in Optickle is way off.  Certainly it looks like we should be sticking with REFL33 for PRFPMI.  Also, since we have an offset in REFL33Q anyway (which we have seen and have commented on before), at 3nm CARM offset it looks like we could try to just do the jump without any extra digital offset.  Here's a zoom of the 3nm situation:

For several MICH offsets, I measured the response of REFL33Q, ASDC and the ratio ASDC/POPDC to a MICH EXC. It appears that there is no frequency-dependent effect. The plots for MICH_OFFSET = 0.0 and 2.0 are slightly lower in magnitude: the reason is they were the first measurements done, and after that a little realignment of BS was necessary, so probably that is the reason.

I've upgraded our cdsutils installation to v382; there have been some changes to pydv which will allow me to implement the auto y-scaling on our lockloss plots. 

After some brief testing, things seem to still work...

Chiara threw another network hissy fit. Dmesg was spammed with a bunch of messages like eth0: link up appearing rapidly. 

Some googling indicated that this error message in conjuction with the very ethernet board and driver that Chiara had in use could be solved by updating with an appropriate driver from the manufacturer.

In essence, I followed steps 1-7 from here: http://ubuntuforums.org/showthread.php?t=1661489

So far, so good. We'll keep an eye out to see how it works...

[Jenne, Diego, EricQ]

Hopefully there will be more later, but Chiara just went down (network? other?  Q is in there right now looking at it), so this is a so-far-tonight elog.

We have successfully transitioned MICH over from REFL33Q to ASDC in both the PRMI and PRFPMI configurations.  Next up is to start reducing the CARM offset.

Resetting the REFL demod phases

I have been unable to lock the PRMI for more than teeny blips since Thursday.  So, tonight I finally got it to lock with MICH on AS55Q and PRCL on REFL33I, and used that to set the demod phases. 

Setting the demod phases, I used an oscillation of 100 cts to PRM, at 400.123 Hz.

REFL 33 demod phase started at 148deg, now 133.2deg.

REFL165 phase started at -105.53, now -172.

No signal in REFL55????  Time series and spectra both look just like noise.  Need to check alignment of beam on PD, or if cables unplugged!!

REFL11 phase started at 16.75, now 18.9deg.

Was then able to lock on REFL 33 I&Q, like normal.

Transitioning PRMI from REFL33Q to ASDC

With the PRMI locked on REFL33 I&Q, I found that a MICH offset of -5 counts gives a minimum in ASDC.  From my earlier elog this evening (http://nodus.ligo.caltech.edu:8080/40m/10887), I expect the minimum to be at +1.4nm.  This is only one point though, so I don't know the calibration of the MICH offset yet (we should get this calib during the day by looking at MICH-only).  Anyhow, this informed which side was positive and negative relative to my Optickle plots, so I know that I wanted positive offset in the MICH servo.

I was able to comfortably hold lock at +20 counts.  Looking at a calibration line at 143.125 Hz, I determined that I wanted the matrix element for ASDC to be -0.05.  After I made that transition using ezcastep, I put the POPDC normalization in.  At the time, POPDC was about 151counts, so I put 1/151 in the POPDC->Mich matrix element.

So, here were the final lock parameters.  Note that in PRMI-only, you can acquire lock like this, and with a variety of MICH offsets:

Locking PRMI part of PRFPMI

Since the PRMI has been fussy, I'm including a brief note on the PRMI settings when the arms are held with ALS off by roughly 3nm.  To get to this point, we just ran the usual carm_cm_up script, and didn't let it run anymore when it asked for confirmation that PRMI was locked.

With MICH offset of -30 counts, AS port is pretty bright.  ASDC dark offset is set to -475.4 by the LSCoffsets script. with MICH offset = 0, ASDC_OUT is around 300counts.  But, with MICH offset = -30, ASDC_OUT is about 525 counts.  So, I put that 525 counts into the ASDC filterbank offset (so it is now the dark offset + this extra offset), so the ASDC offset is currently around -1,000.  This makes the ASDC signal roughly zero when I am ready to transition MICH over to it.  In principle I should probably set it so the average is the same as the MICH offset, but the noise is so high relative to that offset, that it doesn't matter.

After this, we engaged the CARM and DARM UGF servos.  MICH was gain peaking, so I think we might want to turn that one on too, rather than my by-hand turning down the gain.

The transition has been successful 4 or 5 times with the arms held off resonance at 3nm.  Once, we reduced the CARM offset as low as 1.7 (and had to lower the MICH gain to 1.5), but we were still hearing a woomp-woomp sound.  Not sure what that was from.  At this point, Chiara died, so we lost lock.  After that, we re-acquired lock a few more times, but MC keeps losing it.  We are still able to make the MICH to ASDC transition though, which is good.

The transition won't work if the PRCL UGF servo is not on.  The gain multiplier goes from about 1.1 up to 2.4, so the PRCL gain is certainly changing through the transition.

Diego has written up scripts for the individual UGF servos (look for an elog from him separately), so now the carm_cm_up script goes as far as locking the PRMI on REFL33 I&Q, and then it starts to transition.  PRCL UGF is engaged, MICH offset is set to -30 counts, MICH is transitioned to ASDC, POP normalization engaged, CARM UGF servo turned on, and DARM UGF servo turned on.  There are "read"s in the script before each step, so you can stop whenever you like.

Here's the final configuration for the PRFPMI while the arms are held at 3nm, with MICH on ASDC (so after the transition):

The transition for MICH to ASDC has been successful with the arms held off resonance several times tonight. It's all part of the carm_cm_up script now. I think that if we hadn't lost about an hour of time and our momentum, we would have gotten farther.  I have high hopes for tomorrow night!

I was looking into the status of IPC communications in our realtime network, as Chris suggested that there may be more phase missing that I thought. However, the recent continual red indicators on a few of the models made it hard to tell if the problems were real or not. Thus, I set out to fix what I could, and have achieved full green lights in the CDS screen. 

This required:

• Fixing the BLRMS block, as was found to be a problem in ELOG 9911 (There were just some hanging lines not doing anything)
• Cleaning up one-sided RFM and SHMEM communications in C1SCY, C1TST, C1RFM and C1OAF

The frontend models have been svn'd. The BLRMs block has not, since its in a common cds space, and am not sure what the status of its use at the sites is...

The above mentioned amplifier has been used to amplify the input to the frequency counter. The frequency counter is now getting an input that it can read.

I have done an edit to the ALS medm screen and the PSL and AUX Y laser beat frequency is now readable.

I'm super excited about this new frequency readback, but I'm not sure that it's reliable yet.  Without touching any settings, the readback is currently saying 78.6MHz, and is changing slightly (as is the FSS Slow Temp), so something is working.  However, the beatnote as measured on the spectrum analyzer is 158.2MHz.  So, either the calibration or the tracking or something isn't quite finished being tuned yet.

It's going to be super awesome when we have this though!!

As Jenne pointed out, this is still not fully tuned. 

For example, I found today that the frequency counter requires more power at the input >= -20dBm to measure frequency inputs < 40 MHz. Since the RFPD gives ~ -40dBm at its output, the ~20dB gain amplifier will not be enough to measure low frequencies in case the beat power at the PD drops (which is very much possible when the alignment drifts or things move around on the PSL table).  So I am shopping for an RF amplifier with higher gain to replace the current one. In the meantime, I will test the PID loop for set point frequency > 40MHz.

I have also observed the frequency difference between the measured frequencies on FC and the spectrum analyzer. I am not sure where this comes from as yet. 

At this point, the FC readout is only reliable enough to find a beatnote that is lost on the spectrum analyzer.

These are the parameters of the UGF servos we used last night:

Some tweaking of such parameters and the commissioning of the MICH servo will be done soon; an elog post about the UGF scripts/medm screens also will be done soon.

To use instafoton, right click an MEDM screen, open the Execute menu, and choose "Foton".  Then click on the EPICS channel of a filter module as displayed on the screen.

Here's how it was set up:

• Install instafoton.py in /opt/rtcds/caltech/c1/scripts; edit paths to localize for the 40m
• Add instafoton to the MEDM_EXEC_LIST environment variable, newly defined in /ligo/cdscfg/workstationrc.sh:
  export MEDM_EXEC_LIST="Edit this screen;medm &A &:Probe;probe &P &:Foton (Pick filter PV);/opt/rtcds/caltech/c1/scripts/instafoton.py &P &"

After recompiling medm with a patch for dumping screens (attached), I added a time machine to the right-click Execute menu.  It's installed under /cvs/cds/caltech/users/wipf/src/medm_time_machine. Dependencies include the python CA server module (pcaspy) and the latest nds2-client 0.11.2.  These were also installed under my users directory, to avoid interfering with other tools.

I show here the matrix formalism to calculate analytically the loop TF relationships for the IMC w/ both FSS actuators so that it would be easier to interperet the results.

The attached PDF shows the Mathematica notebook and the associated block diagram.

In the notebook, I have written the single hop connection gains into the K matrix. P is the optical plant, C is the Common electronic gain, F is the 'fast' NPRO PZT path, and M is the phase Modulator.

G is the closed loop gain matrix. The notation is similar to matlab SS systems; the first index is the row and the second index is the column. If you want to find the TF from node 2 to node 3, you would ask for G[[3,2]].

As examples, I've shown how to get the FAST gain TF that I recently made with the Koji filter box as well as the usual OLG measurement that we make from the MC servo board front panel.

[Jenne, Rana]

We tried locking with the variable finesse MICH offset technique again today. 

A daytime task tomorrow will be to figure out where we are in MICH and CARM offset spaces.  This will require some thinking, and perhaps some modelling.

We were using the UGF servos and checking out their step resonses, and had the realization that we don't want the gain multiplication to happen before the offsets are applied, in the case of MICH and CARM.  Otherwise, as the UGF servo adjusts the gain, the offset is changed.  I think this is what ChrisW and I saw earlier on in the evening, when it seemed like the CARM offset spontaneously zoomed toward zero even though I didn't think I was touching any buttons or parameters.  Anyhow, we no longer used the MICH and CARM UGF servos for the rest of the night.  We need to think about where we want the offset to happen, and where we want the UGF servo multiplication to happen (maybe at the control point, with a very low bandwidth?) such that this is not an issue.

Also, I'm no longer sure that the sqrt(I^2 + Q^2) instead of the usual demodulation is going to work for the UGF servos (Q made this change the other day, after we had talked about it).  When the numbers going into the I and Q servo banks are small (around 1e-5), the total UGF servo gets the answer wrong by a factor of 10 or so.  If I made the "sin gain" and "cos gain" 1000 instead of the usual 1, the numbers were of the order 1e-2, and the servo worked like normal.  So, I think we were perhaps running into some kind of numerical error somehow.  We first noticed this when we lowered the DARM excitation by a factor of 10, and the servo no longer functioned.  We should take out this non-linear math and go back to linear math tomorrow.

During the evening tomorrow, we should try locking the PRMI with a large MICH offset, and then leaving CARM and DARM on ALS, and seeing how far we can get.  Is it possible to just jump over to RF signals, since we won't have to worry about the detuned cavity pole?

Tonight, the locking procedure was the same as usual, but stopping the carm_up script before it starts to lower the CARM offset at all.  Only difference was that MICH triggered FMs were 2,3,7 rather than the usual 2,6,8. 

So, assuming you have the IFO with CARM and DARM on ALS held at +3 CARM offset counts (which we think is about 3nm), and the PRMI is locked on REFL33I&Q with no offsets, here's what we did:

• PRCL UGF servo on
• MICH offset goes to -20
• MICH transitions to ASDC (0.27*ASDC, then normalize by POPDC)
• DARM UGF servo on
• CARM offset to 1 (arms about 0.25)
• CARM transition to SqrtInvTrans
• Lower CARM gain to 4
• CARM offset to 0.6 (arms about 1)
• DARM transition to DC transmission
• Increase MICH offset to about -650 or -670
• Lower CARM offset, see what happens

Something else to think about:  Should we normalize our DC transmission signals by POPDC, so that the arm powers will change when we change the MICH offset (for a constant CARM offset)?

The best we got was holding for a few minutes at arm powers of 7.5, but since the MICH offset was large and the power recycling was low, this was perhaps pretty far.  This is why we need some calibration action.

Also, earlier today I copied the CARM and DARM "slide" filter module screens so that we have the same thing for MICH.  Now all 3 of these degrees of freedom have slider versions of the filter module screens, which are called from the ctrl_compact screen.

The UGF servos have been moved to the control point, are are once again totally linear!

The UGF servos were recommissioned today:

• suitable values of frequency, excitation, phases and gain were found;
• the phases were chosen in order to maximize the I signal and suppress the Q one;
• the servos seemed sufficiently stable when in a quiet state, but they didn't performed well in other cases;
• I also found out that DARM & CARM and MICH & PRCL are maybe too much coupled, but that could be actually due to the main loops rather than the UGF ones;
• however, after some weird rampings with no apparent reasons, and after some quite bad and glitchy step responses, I found out that the effect of the chosen phases vanished: the I and Q signals were of the same order of magnitude again, probably causing the bad performance;
• Jenne and I tried to increase che SINGAINs and COSGAINs (but keeping them equal to each other): this has the good effect of separating more the I and Q signals, but it's just a zoom effect: there still are mixing effects and, more important, some zero-crossings into negative values that cause the signal going into the servo to go crazy.

Our idea is that we need with some thinking about these servos and most of all try to figure out all this phase thing before we can start to trust the servos to be used for locking.

[Jenne, Diego]

Life would be easier with the UGF servos working.  As Diego already elogged, we aren't sure why the demod phases are changing, but that is certainly causing the I-signals to dip below zero, which the log function can't handle (there is a limiter before the log, so that the signal can't go below 1e-3).  Anyhow, this is causing the UGF servos to freak out, so we have not been using them for tonight's locking.

Our goal tonight was to see if we could introduce a nice big MICH offset, and then lower the CARM offset while keeping the arms locked on ALS.  We hope to see some kind of sign of a PDH signal in some RF PD. 

In the end, the highest we got to was -460 MICH offset counts, which we think is about 29nm (if our rough calibration is accurate). The MICH half fringe should be 188nm. With this offset, we got down to 0.3 CARM offset counts while locked on ALS.  We think that this is around 300pm, plus or minus a lot.  Note that while yesterday I had a pretty easy time getting to -660 counts of MICH offset, tonight I struggled to get past -200.  The only way we ended up getting farther was by lowering the CARM offset.  Although, as I type this, I realized that last night's work already had a lower CARM offset, so maybe that's key to being able to increase the MICH offset. 

We watched REFL11I and REFL11I/(TRX+TRY) on striptool, but we didn't see any evidence of a PDH signal.  We lost lock when I tried to transition CARM over to REFLDC, but I wasn't careful about my offset-setting, so I am not convinced that REFLDC is hopeless.

So.  Tonight, we didn't make any major locking progress (the MC started being fussy for about an hour, right after I ran the LSC offsets script, just before we started locking in earnest).  However, we have some ideas from talking with Rana about directions to go:

* Can we transition CARM over to REFL11I, and then engage the AO path?

* Then, while the MICH offset is still large, can we transition DARM over to POX or POY, actuating on a single arm?  If CARM is totally suppressed, this is DARM-y.  If CARM doesn't have the AO path yet, this is halfsy-halfsy, but maybe we don't care.

* Then, can we lower the MICH offset and transition back to a REFLQ signal?

* Separately, it seemed like we kept losing PRC lock due to PRC motion.  If the MICH offset is very large, are we sideband-limited at the POP port, such that we can use the POP DC QPD?  Is it even worth it?

MICH calibration:

A single mirror (ITM) moving by lambda/2, in the MICH-only situation is the full range, from bright to dark fringe.  So, half fringe should be lambda/4, or about 133nm.  If we are thinking about pushing on the BS, there's an extra factor of sqrt(2), so I think the half fringe should be at 188nm of BS motion.

When we had MICH locked on ASDC/POPDC, we put in a line at 143.125Hz, at 20 counts to (0.5*BS-0.2625*PRM), so a total of 10 counts to the BS at 143Hz.  Given the BS calibration in http://nodus.ligo.caltech.edu:8080/40m/8242, this is 10.1pm of actuation.  We saw a line in the error signal of 0.1 counts, so we infer that the MICH error signal of ASDC/POPDC has a calibration of 94pm/count. This number was invariant over a few different MICH offsets, although the ones I measured at were all below about 100 counts of MICH offset, so maybe this number changes as we start to get farther from the MICH dark fringe.

IFO left flashing (all mirrors aligned except SRM) in case anyone wants fresh data for that.

Something that kind of drives me crazy with our current LSC model setup is that I can't make "finished" error signals before blending them.  The blending happens before the normalization matrix, and there is no place to put an offset to help match a new error signal to the current offset.  So.  While I'm sure this is not going to be immediately popular, here's a cartoon of a proposed model change to the LSC. 

The most important difference between this and the ramping matrix that is used at the sites is that you can put in offsets before the blend.  Also useful is the fact that the normalization can happen before the blend.  This proposal would make the LSC input matrix  and the normalization matrix have twice as many rows, and add an extra "selector matrix" just before the triggering at the error point of the loops. 

I've only drawn one degree of freedom in my cartoon, but assume that they all have the same capability (maybe we don't have to do XARM, YARM and MC this way).  One row is currently being used for the error signal, while the other row is just used to prep a new singal.  For a first transition (say, ALS to DC transmission), maybe the ALS signals are on row 1, and the DC trans is on row 2.  Once the transition is complete, row 1 is available to prep for the next transition (such as AS55Q).

Thoughts?  Is there a better way to achieve what I'm going for here?

I have installed kerberos on Rossa, so that I don't have to type my name and password every time I do an svn checkin, since I'm making some modifications and want to be sure that everything is checked in before and afterwards. 

I ran sudo apt-get install krb5-user.  I didn't put in a default_realm when it prompted me to during install, so I went into the /etc/krb5.conf file and changed the default_realm line to read default_realm = LIGO.ORG. 

Now we can use kinit, but we must (as usual) remember to kdestroy our credentials when we're done.

As a reminder, to use:

> kinit albert.einstein

Password for albert.einstein@LIGO.ORG: (type your pw here)

When you're finished, run

> kdestroy

The end.

WARNING: since the workstations are all shared user, if you forget to kdestroy the next user can commit under your user ID.  It might be good to set the timeout to be something much shorter than 24 hours, like maybe 1, or 2.

Good call.  I added a line ticket_lifetime = 3600, which should make it destroy the credentials after an hour.

I've measured the sensing for each of the arms, by using our calibrated oplevs, in terms of QPD counts per micron. It is:

In the absence of a lens, the QPD would be significantly more sensitive to cavity axis translation than tilt, and thus about equally sensitive to ITM and ETM angle. However, there are lenses on the end tables. I didn't go out and look at them, but found some elogs from Annalisa that mentioned 1m focal length lenses. Back-of-the-envelope calculations convince me that this can plausibly lead to the above sensitivity ratios.

I used these quantities to come up with an actuation matrix for the ASC loops, and measured the effective plant seen by the FM, fitted it to some poles( looks like zpk([],-2*pi*[1.47+3.67i,1.47-3.67i],160); ), and designed a control servo. Here is the designed loop:

The servo works on both arms, both DoFs. A DTT measurement agrees with the designed loop shape, up to a few degrees, which are probably due to the CDS delay. The RMS of the QPD error signals goes down by about 20dB, and are currently dominated by the bounce mode, so maybe we can try to sneak in some resonant gain...?

Once we confirm that they work when locking, we can write up and down lines into the locking scripts...

PMC realigned again... The transmission was down to 0.70, and the MC was having a hard time trying to autolock.

Okay, it has taken me almost exactly 12 hours (with a dinner break), but I have implemented this change.

Everything was svn-ed before I did things, and then again afterward.

Here is the "before" screenshot of the LSC model:

And here is afterward:

If you look extra carefully, you will see that it matches my proposal from http://nodus.ligo.caltech.edu:8080/40m/10904 .  I have made the change for DARM, MICH, PRCL, SRCL and CARM.  I did not alter XARM, YARM or MC.  Also, the CESAR stuff was taken out of the CARM area, since this is now a more generalized version of the same thing.

I have also checked and modified all of the scripts that I could think of, as well as all of the ifoconfig burt .req and .snap files that I could think of.  I also ran the carm_cm_up.sh script once, and it seems to work fine.  All of the transition scripts that are listed below (which are the only ones used currently in the sequence) now use the new error signal blending scheme.

Scripts:

• Lock_ALS_CARMandDARM.py
• ALSfindIRresonance.py
• ALSwatch.py
• carm_cm_down.sh
• carm_cm_up.sh
• CheckPRMIlock.py
• Transition_MICH_REFL33Q_to_ASDC.py
• Transition_CARM_ALS_to_TransInvSqrt.py
• Transition_DARM_ALS_to_DCtrans.py
• UGFup.py
• UGFdown.py

Burts (listed are the .req files, but I also checked the .snap files, hand-editing the matrix element numbers where needed if I wasn't in the right config to do a save):

• C1configure_Yarm.req
• C1configure_YarmALS.req
• C1configure_Xarm.req
• C1configure_XarmALS.req
• C1configure_CARM.req
• C1configure_DARM.req
• C1configure_PRM_forCARMdarm.req
• C1configure_PRM_SBres.req
• C1configure_PRM_Carr.req
• C1configure_PRY.req
• C1configure_DRM.req
• C1configure_SRM.req

I also modified the screens for the input matrix and for the normalization matrix.  I created a new screen for the final blending matrices (which are all 2x1's), and I also modified the LSC_OVERVIEW screen. 

The input matrix and normalization matrix screens have colored bars that tell you whether a row is in use or not.  If the background to the row is the blue of the whole screen, that row is not being used.

The LSC screen has new hand-modified Kissel Buttons.  I wanted to show the total PD error signal that is being used, regardless of what row (A or B) it is on at that time.  So, I have collapsed the rows so that DARM_A and DARM_B are overlapped, even though they are actually rows 1 and 2 of the matrix.  The PD should only show up green on the LSC screen if that row is in use (so, if you are prepping a row, but aren't using it yet, you won't see those elements in the matrix).  Anyhow, the point is that the LSC overview part of things shouldn't look any different than before.

Brain not working anymore now that it's ~4am, but I need to rethink and recheck to make sure that the PD whitening triggering is still okay and working.  Or maybe we can remove it, and just include that in the scripts, as Rana has been suggesting for ages.  Thoughts for tomorrow.

UGF Servos' commissioning still going on, updates of today:

• on Rana's suggestion, we don't use anymore the Q-signal rejection at the level of Phase 1 and Phase 2; instead, a proper complex division is made between those two signals (with a check in case of zero); then the resulting signal is demodulated with a new Phase 3, which is the one used to select the I signal while zeroing the Q one; changes to the model and the screens have been made;
• a new evaluation of all the parameters for the four servos has been made; aside for the new phase, and the zeroing of the other phases (because they are not used anymore for the selection), the parameters are not dissimilar from the prevoius ones
• the PRCL and MICH servos seem sufficiently stable;
• CARM and DARM are stable only for a short amount of time; what usually happens is that one of the two starts drifting in one random direction, and usually the other one follows shortly after; it is not clear if there is a relation or if they stop being stable after a similar amount of time; I still noticed a few lowest limits appearing in the input signal, which should be avoided; I'll check the model again tomorrow;
• the weird thing about CARM and DARM is that at the same time when one of them starts drifting, its I and Q signals begin to be comparable; when the servo is shut off, they resume their normal state;
• an increase in the excitation gain improves the separation of I and Q and also reduces their variations, but a high peak in the loop due to this might not be a good idea.

EDIT: Sleepy Eric doesn't understand loops. The conditions for this observation included active oplev loops. Thus, obviously, looking at the in-loop signal after the ASC signl joins the oplev signal will produce this kind of behavior. 

After some talking with Rana, I set out on making an even better-er QPD loop. I made some progress on this, but a new mystery halted my progress. 

I sought to have a more physical undertanding of the plant TF I had measured. Earlier, I had assumed that the 4Hz plant features I had measured for the QPD loops were coming from the oplev-modified pendulum response, but this isn't actually consistent with the loop algebra of the oplev servos. I had seen this feature in both the oplev and qpd error signals when pushing an excitation from the ASC-XARM_PIT (and so forth) FMs. 

However, when exciting via the SUS-ETMX-OLPIT FMs (and so forth), this feature would not appear in either the QPD or oplev error signals. That's weird. The outputs of these two FMs should just be summed, right before the coil matrix. 

I started looking at the TF from ASC-YARM_PIT_OUT to SUS-ETMY_TO_COIL_1_2, which should be a purely digital signal routing of unity, and saw it exhibit the phase shape at 4Hz that I had seen in earlier measurements. Here it is:

I am very puzzled by all of this.  Needs more investigation.

Have we been running the PMC autolocker lately?  I can't remember, and I also can't find where it might be running.  It's not on megatron, either in the crontab or Q's new /etc/init place.  It's also not on op340m. 

Anyhow, what prompted this was that the PMC transmission has been incredibly fuzzy today.  On the StripTool it looks like it was fine until about -7 hours ago, when it lost lock.  Then Diego relocked it around -3 hours ago, and it's been fuzzy ever since. It was unlocked again for about 15 minutes about 45 minutes ago, and when I relocked it, it was even more fuzzy.

The FSS slow is almost exactly zero, the PMC's PZT is not at the edge of the range, the FSS PC drive RMS has been both high and low, and the PMC fuzz level has just been consistently high.  I was checking the parameters in the PMC phase shifter screen, and looked up the autolocker to see what the nominial values are supposed to be. 

For the RFADJ value, the autolocker sets it to 2.0, and after it locks increases it up to 4.5.  I found the value at 2.0, and the autolocker isn't running, which made me wonder if the autolocker died sometime after it set the value low, but before it could detect lock and reset the value to high.  (Actually, after lock it sets the value to whatever is in the channel C1:PSL-STAT_PMC_NOM_RF_ADJ, which is 4.5).

Anyhow, I manually set the RFADJ value to 4.5, and the PMC transmission immediately improved. 

EDIT, 8pm, JCD:  Rana reminded me that he attached a screenshot back on 30Dec2014 (http://nodus.ligo.caltech.edu:8080/40m/10849), which I had ignored earlier because the parameters weren't written in text.  My bad.  Anyhow, after the New Year's tune-up, the RFADJ should be 6.0.  I have set it so, and also changed the C1:PSL-STAT_PMC_NOM_RF_ADJ chan to be 6.0.

Was the screen modified directly on LSC_OVERVIEW.adl?
Even if so, that's OK. I'll incorporate the change to the screen making script once I'm back.

Nope, I used the script.

Yesterday's changes were mostly to the generateLSCscreen/C1LSC_OVERVIEW_INPUT_MATRIX.adl sub-screen.  The UGF servos were added earlier in the week to the LSC screen in the generateLSCscreen/C1LSC_OVERVIEW_SERVOS.adl sub-screen.

I found an error in the model of the UGF servos, I have now corrected it; for future reference, now the division between TEST2 and TEST1 is properly done with complex math: given

we have that TEST3:

TEST3 is the actual signal that is now phase rotated to select only the I signal while rejecting the Q one.

All the updates to the model, the screens and the script have been SVNed.

I have been playing with the IFO tonight.  Mostly, I wanted to make sure that all of the scripts for the carm_cm_up sequence were working, and they seem to all be fine. 

I also turned on all 4 UGF servos.  My big ah-ha moment for the night is that the excitation is multiplied by the gain multiplier.  This means that if the UGF servo is multiplying by a small number (less than 1), the excitation will get smaller, and could get small enough that it is lost in the noise.  Now the error signal for the UGF servo is very noisy, and can dip to zero.  Since we can't take the log of zero, there are limiters in the model, but they end up giving -80dB to the error point of the UGF servo.  This makes it all freak out, and often lose lock, although sometimes you just get a weird step in the UGF servo output. 

Anyhow, we need to be mindful of this, and offload the UGF servos regularly.  I think the better thing to do though will be to divide the excitation amplitude by the gain multiplier.  This will undo the fact that it is multiplied by that number, so that the number of counts that we put into the excitation amplitude box is what we expect.