Hmmmm, yup.  I forgot to pay attention to what the UGFs of our LSC loops are when I was picking a low-noise region.  Since they're (currently, at least) around 100Hz, I want to find a frequency in the few hundred Hz region.  Masayuki has the IFO right now for ALS diagnostics, so I'll pick new frequencies later.   If we decide to omit the bandpass filters, it's even easier to change frequencies on the fly (although we'll always still have to make the servo notch filters match).

 The PMC refl is bad in pitch today, and the transmission is only 0.76, rather than our usual 0.83ish.

I did a quick, rough tweak-up of the alignment, and now we're at 0.825 in transmission.

After staring and thinking, I remembered that there is a limit to the number of characters that a channel name can have.  So, I removed the "_LOCKIN" part of the names, and recompiled, and everything seems to work.  I modified the screens that I had made, and they show all the appropriate things now.  

The symptoms were that the numbers in the filter banks (for example, INMON) were white with the usual black background.  The numbers are supposed to be green with a black background.  After I recompiled, all the numbers were green.

This also means I need to re-put in the low pass filters. 

Plots:

PRCL Open Loop Transfer Function.  PRMI locked on REFL 165 I&Q, Xarm held on IR resonance using ALS, ETMY misaligned:

MICH Open Loop Transfer Function.  PRMI locked on REFL 165 I&Q, Xarm held on IR resonance using ALS, ETMY misaligned:

 Time series data during our PRMI + 2 arm attempt:

 I worked today some more on the new Sensing Matrix situation.  I have added stuff to the CAL model, so that the sensing matrix elements come out calibrated to W/m, with phase in degrees.  The idea is that we can see time series of the calibrated lockin outputs, so that we have minimal post-processing to do, since these are things that will be interesting to look at live.

The first step is to go from I and Q to magnitude and phase.  Each "sensor" (ex. REFL55Q) is demodulated with a lockin part, which outputs sub I and Q channels (so, something like REFL55Q_I and REFL55Q_Q).  We are only interested in the _I component of the lockin.  But, REFL55I also has a _I and _Q.  Again, we only take the _I part.  Now, we have REFL55I_I and REFL55Q_I.  We call these the I and Q components of the sensors (this is exactly what we normally call them, but it can get confusing since the lockins also have _I and _Q before we discard the _Q part).  Now, we want to take these I and Q components, and transform them to a magnitude and phase. After we do that, we want to calibrate the magnitude to "Watts per meter" from "counts sensed per counts driven".  I also converted the phase to degrees, since that's the unit we usually use when talking about the sensing matrices. 

To go from the I and Q components to Mag and Phase, I wrote a little block of c-code, which is in /opt/rtcds/caltech/c1/userapps/release/isc/c1/src/MagPhaseFromIQ.c . Since we can't use the arctan function, I approximated it using equation 17 from Full Quadrant Approximations for the Arctangent Function [Tips and Tricks] from IEEE.  (I used x -> y/x in equation 17, so that I had a 2D situation).  I also have an "if / else if" cascade to determine what quadrant I'm in.  Since the formula in the paper is from [0,pi/2), I just needed to add pi, subtract the answer from pi, or negate the answer to get to the other quadrants.  Also, note that they are using a "normalized" arctan function, so equation 17 is really from [0,1), and you have to remember to multiply by pi/2 on your own.

To get from drive counts to drive meters, I put in an EPICS variable for the optic's actuation constant (ex, PRM's constant can be found in elog 8255).  Right now, we have to transfer the oscillation frequency from the oscillator part's _FREQ variable to a new EPICS variable, but Zach and Joe just today made a new oscillator part that makes it easier to access the frequency and amplitude of the drive within the front end.  See LLO aLog 9139 for details on this new part.  I had trouble compiling with their new part, but once I get that figured out, I won't need to do this transfer of information.  Anyhow, the drive calibration is (optic actuation constant)/[(drive frequency)^2]. 

Then the total calibration of the magnitude is Mag in cts/m = 2 * mag / [(drive amplitude) * (drive calibration)] .  The factor of 2 comes from the fact that the lockin output is a factor of 2 smaller than the true sensing matrix element.  The lower case "mag" in the formula is the output of the c-code. 

After this, there is yet another EPICS variable, to hold the calibration for the photodiode, to get from counts sensed to Watts of power at the actual port.  By "actual port", I mean the true IFO port, taking into account any optical elements between the port and the photodiode, like beam splitters and dumps, or loss from the imperfect reverse isolation of the input Faraday.

The code all compiles and runs fine, although I haven't done any explicit testing yet.

Still to-do for Sensing Matrix:

* Find all of the numbers for all of the EPICS variables.  In particular, I need to get the ratio of the power hitting each photodiode to the power at that port. 

* Write a script to do a burt-restore with all the correct settings, and turn on the dither lines.

* Put the lowpass filters back in the demodulators, now that they have new (shorter) names.

* Try it, and compare with the optickle model, and previous measurements.

* Copy Anamaria's script to look at the error statistics for my measurements.

Koji reminded me that we should also save the data from the PRMI+Xarm, just in case we want to look at it later.

Here is the time series, in which you can see us finding the Xarm IR resonance, moving the arm off resonance, locking PRMI, and bringing the arm back into resonance.  At the very end, the arm is still held on resonance, but I had disabled the LSC locking, so we see very large flashes at TRX (of order 40, rather than 1).

The data is in the same folder as the 2arm data: /users/jenne/PRCL/PRMI_Xarm_ALS_16Oct2013/

The text files have been differentiated, so that the 2arm data has "_2arms" at the end of the filename, while the Xarm data had "_Xarm" appended to the filename. Since we left the cavities locked for many minutes (during which transfer functions were taken), the data set for the PRMI+Xarm is very long.

I locked the PRMI, and tried to turn on the ASS, but this caused PRMI to lose lock. 

Since this is similar to what happened the other night (see elog 9243, 2nd big paragraph), I looked into it a little further.  I noticed that the POP QPD pitch was very close to the edge of the QPD, so I went out and (while PRMI was locked) recentered the POP QPD.  After doing so, I was able to run the PRM ASS, and it worked very nicely, just as it has before.  So, it looks like something drifted, such that the optimal PRM alignment caused the POP beam to not be fully on the QPD.  Since the ASC loop is triggered by PRMI lock, and is constantly on, falling off the QPD causes lockloss.

While I was out there, I tweaked up the PMC pitch alignment yet again.  The FSS numbers all looked reasonable, however PMC transmission was ~0.75 .  I did a tiny bit of work in pitch, and now we're back to 0.83 transmission. 

I locked PRMI, and (after fixing the POP QPD situation, noted in elog 9249) took power spectra of all the REFL RFPDs.  It looks like the area above 500 Hz is pretty clean and flat for all the signals, so I'm going to use 560Hz, 562Hz, 564Hz, 566Hz and 568Hz for my 5 sensing matrix frequencies.

Also, I'm not sure what is going on with REFL11, but there's a weird dip between 630 Hz and 660 Hz in both I and Q.  I recentered this guy not too long ago (elog 9218), but it clearly needs some more looking-at.

The PMC was unlocked for a little over an hour.  I relocked it, and the MC locked itself.  Today, it looks like PMC yaw alignment is bad, and maybe pitch isn't so good either.  Transmission is 0.77

We have now watched the ETMY computer situation for a little over 150 minutes, and have seen one 'event' where the CPU time of the scy model hit 62 microseconds, and a glitch in the ETMY OSEM sensors happened at the same time.  We also see no such glitches at any other time, which makes sense with our latest hypothesis, since this event was the only time that the CPU time reported being greater than 61 microseconds.  (1/16384 Hz = 61.1696 microseconds). 

I have now restarted the c1tst model, to see if that increases the rate of glitches (assuming that running another model heats up the whole computer a bit more, and that makes things run a little bit slower).

Wed Oct 23 21:05:28 2013 

RXA: It looks like there was a real effect. Its between -2.5 and 0 on the plot below.

I've stopped the process of c1tst again to make it get better. At 9:20, I also went and opened the front rack door (the back one was already open). One reason its hot may be that the exhaust vents on the top of c1iscey are blocked by one of the custom multi-pin adaptor boxes. In the morning, we should drop the computer down by 1 or 2 notches in the rack so that it can air cool itself better. Make sure to poweroff the computer from the terminal before moving it though.

I checked the cabling somewhat. The fat grey cable which comes out of the old Sander Liu AA chassis was connected to the blue adaptor box but the strain relief screws were not being used. I tightened them (we need to buy a set of small screwdrivers for the toolboxes at each end). While doing this, the Cat6 cable in the back labeled 'c1iscey' popped out and the screen went white. This cable has a broken latch on it so it doesn't stay put - needs to be replaced too during the computer move.

As you may recall, Den designed some nice seismometer stations for us with the help of Steve. The granite base was installed : elog 8461. The point of these is to have nice solid bases for our seismometers to sit on, rather than the flimsy linoleum flooring.  Also, they are covered (and will be insulated) to help prevent air currents and temperature fluctuations from affecting our seismometer measurements.  Even though these seismometer stations have been in place for a few months, we are not yet taking advantage of them.  This is a status elog, so that we know what needs to be done.

Recently, Den finished up the design for, and Steve ordered, and we received, the small aluminum plates that go on the side of the granite slabs, so that we can feed the connectors for the seismometer through the baseplate, in an airtight way. 

The current plan is to use one Guralp at each end station, and the Trillium at the vertex.  As of this moment, we have 1 Guralp at ETMY, 1 Guralp at ITMX, and a Streckeisen at ETMX, and the Trillium is sitting to the south of the POX table.

Most of the work that's left to do is just to place the seismometers on the new stations, and to make cables.

I have taken an inventory of all the things that I think we need to buy (or I need to find in the lab) in order for us to finish this project up.

We need to buy a LEMO connector for the T-240 plate. 

We need to buy 6 O-rings:  3 to go between each aluminum plate and the granite slabs, the other 3 between the plate and the milspec connectors for the seismometer cables.

We need to buy or confirm that we have screws to attach the plates to the granite slabs.

We need to buy or confirm that we have screws to attach the milspec connectors to the plates.

I need to confirm that I have another 37-pin dsub for the Xarm Guralp cable, and a 25-pin dsub for the Trillium.

Assuming that I am reusing the existing Yarm Guralp cable, we have all the milspec connectors necessary.

I have a 30m long spool of 19-pair cable that I will use to make the Trillium cable.  I have a long cable, formerly a Streckeisen cable, that I will cut the ends off of, and make into a Guralp cable.  (We had 3 of these incredibly long, maybe ~50m cables - one became the Yarm Guralp cable, one is waiting to be the new Xarm Guralp cable, and the 3rd one is connected to the Streckeisen that we still have).

Work to be done:

* Make long cables for Xarm Guralp and Vertex Trillium.  Check pinouts for the milspec -> dsub connections on each cable.

* Make small cables that go inside of the granite and seismometer station.  These are to connect the sensor to the aluminum plate, and then the long cables go from the plate to the readout box.  Unfortunately, the holes in the granite are not large enough to pass a connector through, so these will have to be soldered in-situ. 

* Plug in the Trillium readout box and confirm that it's working / makes sense.

Longer term modifications and add-ons:

* Lemo connector with wiring for temperature and pressure sensors inside the vertex station.  I believe that Den was looking into what sensors we might want.

* Needle valve for slow pressure equalization on vertex station (all stations should have this, but only the Trillium plate has a hole for this). 

Is there anything else that I'm forgetting??  Please reply with thoughts.

I have modified the Sensing Matrix I,Q to Mag, Phase library part in the new sensing matrix system.

I had forgotten that in the c-code, I convert from radians to degrees, and so was doing the conversion again in the model.  As it turns out, this gives you a nonsense number.  I removed the multiplication by 180/pi in the model, and just use the output of the c-code, which is already in degrees.

I also put in some "choice" blocks just before the divisions in the calibration section of this library part.  If it's about to divide by zero, divide by one instead.

The last modification so far today was adding the _PHASE_DEG and _MAG_WPERM (watts per meter) channels to a DAQ channels block, so that they are saved.

The RCG was very unhappy with me having 2 channels, with no data rate after them (doing this is supposed to imply that both should be saved at the default data rate), however after I put in "2048", it was happy.  The symptom was a little tricky:  The channel names in Dataviewer showed up red, even though the model compiles and runs.  An indicator that you have a problem is a note in the model's "GDS" screen (the details screen that you can click to from the CDS front end overview screen).  The channel name is "C1:FEC-50_MSGDAQ" (where the number 50 is specific to the c1cal model).  After restarting the model, but before restarting the framebuilder's daqd process, this channel said "Error reading DAQ file!", rather than the date and time of the last successful read.   At this point, before restarting the daqd process on the framebuilder, all of the fb statuses are green and good.  However, after restarting the daqd process on the framebuilder, I got status "0x2000".  Anyhow, after trying many different things, I determined that I could have 1 channel, without a specified rate, but if I wanted more than one channel, I needed to specify the rate for both.

[Masayuki, Jenne, Rana]

We have, for the past hour and a few minutes, had PRMI + 2 arms locked.  Yup, that's right, we did it! (We never gave control of the arms to the IR LSC system, so it's kind of cheating, but it was still cool.)

A little after midnight, we felt that the Yarm was behaving well enough that we could give PRMI + 2 arms a try.  So we did.  Probably around 1am-ish, or maybe a little bit before, we had the system locked. 

How did we do it?

* Locked arms in IR to help find green beatnotes.

* Misalign ETMs, lock and align PRMI.

* Misalign PRM.

* Restore ETMs, find arm resonances, then step away (I did +3 counts, which is 29 kHz).

* Restore PRM, lock PRMI.

* Brought Xarm back close to resonance using ALS (-3 counts). It seems like this may not actually have gotten us back to perfect resonance, but that actually made bringing in the other arm easier.

* Brought Yarm back close to resonance using ALS (-3 counts). 

* Turned on Sensing Matrix notches and oscillators (10,000 counts for MICH, actuating on BS and PRM at 562.01 Hz, 200 counts for PRCL actuating on PRM at 564.01 Hz). 

* Stepped arms back and forth to see how things responded.

Notes:

During this process, particularly during the various arm steps, the PRMI lost lock many times.  However, the ALS system never lost lock for either arm, for an hour and a half or so.  Good work, ALS team!!  The PRMI would reaquire lock (sometimes we'd have to undo whatever arm step we just took, to get farther away from resonance) without any intervention.  It seemed that as we came closer to full arm resonance, we were never able to hold PRMI locked.  This is what is instigating some of our investigations for tomorrow.

Also, Rana reported to me that he turned the c1tst model back off, and opened the door(s?) to the ETMY rack to allow more air flow sometime before midnight, which seems to have reduced the rate of the CPU going over 61 microseconds, as well as reduced the number of times the ETMY suspension glitches.  We definitely need to make some changes so that we're not so close to the edge.  This may have been one of the big things that allowed our success tonight.

The transmission PDs at the ends of the arms are saturating around 50 counts (they have gains of 2e-3 so that they are roughly normalized to 1 being the max power in a single arm).  We need to commission the end transmission QPDs. 

All of the signals looked a little ratty, and we heard lots of noise - Rana suggests that we recommission our CARM servo.

ALS beat info:  [Xarm  40.9 MHz,  -11.4 dB], [Yarm  50.5 MHz,  -17.7 dB]

Things to look at tomorrow:

Data!  I should be able to extract sensing matrix information, even though my sensing matrix software isn't totally ready yet.  I know what the oscillators were doing, and I can look at the PD error signals.  We also save the Offsetter numbers, so I can kind of tell what the PRMI+arms situation was. 

Can we tell by looking at the end laser PZT feedback signals whether we're making our arms longer or shorter?  So that we can tell if we're putting on DARM or CARM offsets.

Spectrum and time series of REFL 165 (our PRMI LSC locking PD) to see if we're saturating while we bring the arms into resonance.  Basically, does anything bad happen, particularly since the PD is not a resonant PD, so there are some 1f signals floating around in addition to the 3f signals.  We want to put in a directional coupler after the PD, before the demod board, and send that signal to a spectrum analyzer and a 'scope.  Hopefully we can use the power of the internet to not need to sit in the IFO room saving data as we move the arms around.  Do we need to put bandpass filters on the PD signal before it goes to the demod board?

Optickle model of 1f vs. 3f signals in the different ports, as the CARM offset is reduced.

Violin notches for the arms - should be put into ALS and LSC models.  It looks like the modes are around 631 Hz, but we should check. 

Hardware for end low gain transmission QPDs.

Software (schmidt triggering) for end transmission QPDs.

Modifying / preparing a matrix in the ALS system so that we can give CARM and DARM offsets conveniently.

 I have modified the ETM suspension models to include a schmidt triggering block, so that we can choose between using the high gain low power Thorlabs PD and the low gain high power QPD. 

The Thorlabs high gain PD signal is used as the signal to trigger on, so we need to put appropriate thresholds in.

If things are "triggered", that will imply that the Thorlabs PD is seeing a lot of power, so we should be using the QPD SUM channel instead.  There is a "choice" block after the trigger block, to do this switching.

Since the LSC model will only see the output of this choice block, the gain that is currently in C1:LSC-TR[X or Y]_GAIN should be moved to the end SUS model.  We also need to find the correct gain for the QPD sum channels so that they are also normalized to "1" for single arm full power so that we can smoothly go between the 2 diodes.

Rana has promised to make screens, and write scripts for the switching stuff.

We were locking the PRMI, but it is very rumbly today.  I reduced the MICH servo gain from -0.8 to -0.4 , and things seem to be better.  Now my MICH UGF is about 60Hz.

 Neither of these computers were listed in the Martian Host Table in the wiki, so I put them on there.  It's handy to keep this updated, so that we know what IP addresses are available.

Masayuki was concerned that some LSC channels were giving him all zeros.  After seeing the error in the terminal window running dataviewer (it said something like 'daqd overloaded'), I checked the lsc model, and sure enough, all the test points were used.

So, I found an entry by Jamie (elog 8431) where he reminds us how to clear the test points.  I followed the instructions, and now we're seeing real data (not digital zeros) again.

As we are meditating on things to look at for PRMI + 2 arms, Rana brought up the question of the demod board situation. 

We then found this table on the wiki (LSC demod boards) that indicates that all of the demod boards were originally given lowpass filters, no matter the demodulation frequency.  Back in September, I switched out the low pass filter for a bandpass filter in POP110, and put in the same bandpass when putting together AS110 (elog 9100).  So, the 11MHz diodes are probably okay with lowpasses, and the 110 diodes are okay, but we need to think about all the other ones. 

We should probably do a first guess by putting in a bandpass filter, but then simulate and measure to figure out what our requirements are for attenuation at the non-demodulation frequencies for each board.

The SXBPs from Minicircuits look pretty good, but there are lots of options on their website.

For tonight, Rana has put a coax 100 MHz highpass filter on the input to the REFL165 demod board.

 This of course changes our demod phase.  Rana plotted a 4th order elliptic filter in Matlab, and from the plot determined that we should expect around 60 degrees of difference in our phase. 

To actually set the phase, I locked PRMI on AS55Q and REFL33I (MICH gain = -8.0, PRCL gain = +0.05, with 1's in the matrix elements).  I then turned on the PRCL oscillation notch (564 Hz), and turned on the sensing matrix's drive at that frequency, and looked at the spectrum of REFL165. 

The previous REFL165 demod phase was 96 degrees, so I was looking around either 36 degrees or 156 degrees.  The phase that minimized the peak in the Q signal while driving PRCL was 37.5 degrees.  Good work Matlab/Rana.

I then looked at the transfer functions between REFL33 and AS55 and REFL165, to see if there were any sign flips that happened.  There were not.  As expected, it was just a little extra phase delay.

I was able to lock PRMI with REFL 165 again after this phasing, and I am now taking transfer functions of the MICH and PRCL loops to make sure that we have the gains about right.

 I have set the PRCL UGF to be about 180Hz, and the MICH UGF to be about 70 Hz. 

This is with locking on REFL165 I&Q, with MICH gain of -2.0 and PRCL gain of 0.70 . 

The PRCL loop only has about 30 degrees of phase margin, and is not near the top of its phase bubble.  During the day, I need to look at why we don't have more phase near 200 Hz.

The MC (mostly MC2) decided a few minutes ago to move, so I put the SUSPIT and SUSYAW numbers back where they were, and the tweaked up the alignment from there to get a low MC REFL DC number.  Now the MC is staying locked again, after 20 minutes of not.

Masayuki was able to hold both arms off-resonance with ALS long enough for me to lock the PRMI (arms still held off resonance), and take a set of transfer functions.

MICH gain is still -2.0, PRCL gain is still 0.070, which, with the ETMs misaligned, gave me UGFs of 70 for MICH and 180 for PRCL.

Now, however, with the ETMs aligned, but arms held off resonance with ALS, the UGFs have been lowered by a factor of 2 in frequency!  What is doing this??  MICH is now 40 Hz, and PRCL is now 80 Hz.

We measured the MICH and PRCL loops for several arm powers, and there was no change, at least until the arms were both resonating with powers of ~4 . 

After misaligning the ETMs, I remeasured the loops, and the UGFs went back up to where they started.

 I'm not sure if Steve bumped something, or if it was just a fluke, but the MC didn't come back very nicely after Steve finished re-installing the shutter.

Earlier today, after Steve locked the PMC, MC trans looked good for over an hour (according to the striptool plot on the wall).  Then, the MC was unlocked for about an hour, presumably while Steve was working, he had the light blocked.  When he finished, the MC transmission was around 5,000 while usually it is around 17,000.  The reflection was around 3.4, rather than a best of below 0.5 (unlocked refl is 4.5).

Using Rana's ezcaservo trick to get the suspensions back to where they were at last good lock usually works (I used to do it by hand though).  However, today, it only got the reflection down to about 2.0.  So, I did the rest of the alignment by hand. 

After I did this, the reflection is down to 0.48.  Engaging the WFS makes the MC much more noisy, so I have them disabled currently. 

I have measured the spots, and if I compare them to the measurements that (I think it was Manasa) took last week, they look pretty bad. 

I think that we need to swap out the 2nd zigzag mirror, and then do a careful MC realignment.  It's certainly not worth doing the work, and then re-doing it after we swap out the zigzag mirror.

5:31pm - This is still a work in progress, but I'm going to submit so that I save my writing so far. I think I'm done writing now.

First, a transcription of some of the notes that I took last Tuesday night, then a few looks at the data, and finally some thoughts on things to investigate.

MICH and PRCL Transfer Functions while arms brought in to resonance (both arms locked to ALS beatnotes):

This is summarized in elog 9317, which I made as we were finishing up Tuesday night.  Here's the full story though.  Note that I didn't save the data for these, I just took notes (and screenshots for the 1st TF).

POP22I was ~140 counts, POP110I was ~100 counts.

MICH gain = -2.0, PRCL gain = 0.070. 

First TF (used as reference for 2-10), PRMI locked on REFL165, Xarm transmission = 0.03, Yarm transmission = 0.05 (both arms off resonance).  MICH UGF~40Hz, PRCL UGF~80Hz.

2: X=off-res (xarm not moved), Y=0.13, no change in TF

3: X=off-res (xarm not moved), Y=0.35, no change in TF

4: X=off-res (xarm not moved), Y=0.60, MICH high freq gain went up a little, otherwise no change (no change in either UGF)

5:  X=off-res (xarm not moved), Y=0.95, same as TF#4.

6: X=0.20, Y=1.10 (yarm not moved), same as TF#4

7:  X=0.40, Y=1.30 (yarm not moved), same as TF#4

8:  X=0.70, Y=1.55 (yarm not moved), same as TF#4

9: X=1.40, Y=2.20 (yarm not moved), same as TF#4

10: X=4.0, Y=4.0 (yarm not moved), PRCL UGF is 10Hz higher than TF#4, MICH UGF is 20Hz lower than TF#4.

11: (No TF taken), Xarm and Yarm transmission both around 20!  To get this, MICH FMs that were triggered, are no longer triggered to turn on.  Also, MICH gain was lowered to -0.15 and PRCL gain was increased to 0.1

12: (No TF taken), Xarm and Yarm transmissions both around 40!  The peaks could be higher, but we don't have the QPD ready yet.

After that, we started moving away from resonance, but we didn't take any more transfer functions.

OpLev spectra for different arm resonance values:

We were concerned that the ETMs and ITMs might be moving more, when the arms are resonating high power, due to some optical spring / radiation pressure effects, so I took spectra of oplevs at various arm transmissions.

I titled the first file "no lock", and unfortunately I don't remember what wasn't locked.  I think, however, that nothing at all was locked.  No PRMI, no arm ALS, no nothing.  Anyhow, here's the spectrum:

I have a measurement when the Yarm's transmission was 1, and the Xarm's transmission was 1.75.  This was a PRMI lock, with ALS holding the arms partially on resonance:

Next up, I have a measurement when Yarm was 0.8, Xarm was 2.  Again, PRMI with the arms held by ALS:

And finally, a measurement when Xarm was 5, Yarm was 4:

Just so we have a "real" reference, I have just now taken a set of oplev spectra, with the ITMs, ETMs and PRM restored, but I shut the PSL shutter, so there was no light flashing around pushing on things.  I noticed, when taking this data, that if the PSL shutter was open, so the PRFPMI is flashing (but LSC is off), the PRM oplev looks much like the original "no Lock" spectra, but when I closed the shutter, the oplev looks like the others.  So, perhaps when we're getting to really high powers, the PRM is getting pushed around a bit?

Conclusions from OpLev Spectra:  At least up to these resonances (which is, admittedly, not that much), I do not see any difference in the oplev spectra at the different buildup power levels.  What I need to do is make sure to take oplev spectra next time we do the PRMI+2arms test when the arms are resonating a lot. 

Time series while bringing arms into resonance:

I had wondered if, since the POP 22 and 110 values looked so shakey, we were increasing the PRCL RIN while we brought the arms into resonance.  You can see in the above time series that that's not true.  The left side of the plot is PRMI locked, arms held out of resonance using ALS.  First the Yarm is brought close to resonance, then the Xarm follows.  The RIN of the arms is maybe increasing a little bit as we get closer to resonance, but not by that much.  But there seems to be no correlation between arm power and RIN of the power recycling cavity.

Alternatively, here is some time series when the arm powers got pretty high:

Possible Saturation of Signals:

One possibility for our locklosses of PRMI is that some signal somewhere is saturating, so here are some plots showing that that's not true for the error and control signals for the PRMI:

Here, for the exact same time, is a set of time series for every optic except the SRM.  We can see that none of the signals are saturating, and I don't see any big differences for the ITMs or ETMs in the times that the PRMI is locked with high arm powers (center of the x-axis on the plot) and times that the PRMI is not locked, so we don't have high arm powers (edges of the plot - first half second, and last full second).  You can definitely see that the PRM moves much more when the PRMI is locked though, in both pitch and yaw. 

DCPD signals at the same time:

NB:  These latest 3 plots were created with the getdata script, with arguments "-s 1067163405 -d 7".  It may be a good idea to take some spectra starting at, say 1067163406, 1 second in, and going for ~2 seconds. (It turns out that this is kind of a pain, and I can't convince DTT to give me a sensible spectrum of very short duration....we'll just need to do this live next time around).

Things to think about and investigate:

Why are we losing lock? 

On paper, is the (will the) optical spring a problem once we get high resonance in the arms? 

Spectra of oplevs when we're resonating high arm power.

What is the coupling between 110MHz and 165MHz on the REFL165 PD?  Do we need a stronger bandpass? 

Why are things so shakey when the arm power builds up?

Why do PRCL and MICH have different UGFs when the arms are controlled by ALS vs. ETMs misaligned?

Does QPD for arm transmissions switching work?  Can we then start using TRX and TRY for control?

What is the meaning of the similar features in both transmission signals, and the power recycling cavity?  Power fluctuation in the PRC due to PRM motion? 

Gabriele and I talked for a while on Wednesday afternoon about ideas for transitioning to IR control, from ALS. 

I think one of the baseline ideas was to use the sqrt(transmission) as an error signal.  Gabriele pointed out to me that to have a linear signal, really what we need is sqrt( [max transmission] - [current transmission] ), and this requires good knowledge of the maximum transmission that we expect.  However, we can't really measure this max transmission, since we aren't yet able to hold the arms that close to resonance.  If we get this number wrong, the error signal close to the resonance won't be very good.

Gabriele suggested maybe using just the raw transmission signal.  When we're near the half-resonance point, the transmission gives us an approximately linear signal, although it becomes totally non-linear as we get close to resonance.  Using this technique, however, requires lowering the finesse of PRCL by putting in a medium-large MICH offset, so that the PRC is lossy.  This lowering of the PRC finesse prevents the coupled-cavity linewidth of the arm to get too tiny.  Apparently this trick was very handy for Virgo when locking the PRFPMI, but it's not so clear that it will work for the DRFPMI, because the signal recycling cavity complicates things.

I need to look at, and meditate over, some Optickle simulations before I say much else about this stuff.

I made some small edits to the LSC screen. 

* When I added columns for the new AS110 PD, I had forgotten to make the Trigger matrix and Power Normalization matrix icons on the screen bigger, so we weren't seeing the last 2 columns in the overview screen.

* I added "show if not zero" oscillator icons to the Sensing Matrix part of the LSC overview screen, so that it's easier at a glance to see that there is an oscillator on.

I think Steve is trying to align the end transmission QPDs, since the arms are locked nicely right now.  I noticed that the QPDX pitch and yaw signals were digital zeros.  A quick look determined that the QPDX matrix to go from 4 quadrants to 3 degrees of freedom had been filled in for the POS row, but not pitch and yaw.  So, I copied the QPDY matrix over to QPDX (so the ordering of the rows and columns is assumed to be the same). 

Hopefully this will get us close to centered, but I suppose we ought to check really which quadrant is which, by shining a laser pointer at each quad at each end.

 Steve has promised to add another row of fuses to the LSC rack first thing in the morning.  Then, during Wednesday Chores, we can move the wires from the power supply to the fused power.

STEVE:  NEVER MIND about doing this in the morning.  Let's chat at the lunch meeting about what needs to be done to power things down, then back up again, in a nice order, and we can do it after lunch.  

So, please do not do anything to the LSC rack tomorrow!  Thank you.

[Rana, Jenne]

We looked at the time series for all the oplevs except the BS, from last Tuesday night, during a time when we were building up the power in the arms.  We conclude from a 400 second stretch of data that there is not discernible difference in the amount of motion of any optic, when the cavities are at medium power, and when they're at low power.  Note however, that we don't have such a nice stretch of data for the really high powers, so the maximum arm power in these plots is around 5.  Both the TRX and TRY signals look fairly stationary up to powers of 1 or 2, but once you get to 4 or 5, the power fluctuations are much more significant.  So, since this isn't caused by any optic moving more, perhaps it's just that we're more sensitive to optic motion when we're closer to resonance in the arms.

However, from this plot, it looks like the ETMY is moving much more than any other optic.  On the other hand, ETMY has not ever been calibrated (there's an arbitrary 300 in there for the calibration numbers on the ETMY oplev screen).  So, perhaps it's not actually moving any more than other optics.  We should calibrate the ETM oplevs nicely, so we have some real numbers in there.  ETMX also only is roughly calibrated, relative to the OSEMs.  We should either do the move-the-QPD calibration, or a Kakeru-style pitch and yaw some mirrors and look at transmitted power.

Traces on this xml file have been filtered with DTT, using zpk([0],[0.03],1,"n").

Something funny is going on with the framebuilder's communication with the LSC machine. 

This is a different failure mode / error than I have seen before.  It's not the type of problem that is solved by restarting the mxstreams (that is indicated by also the 2 blocks on top of one another, that are green on the lsc machine right now, being red), although I did try that, before I looked closer and realized that that wasn't the problem.

ssh-ing to c1lsc, and doing a "rtcds restart all" seems to be fixing the problem.  Both c1oaf and c1cal needed another round of restarting, because they needed their BURT buttons pressed manually.  All of the models on the lsc machine are running fine now, though.

Here's a screenshot of the CDS overview screen, with the error lights:

We have decided that, rather than replacing the power source for the amplifiers that are on the rack, and leaving the Thorlabs PD as POP22/110, we will remove all of the temporary elements, and put in something more permanent.

So, I have taken the broadband PDs from Zach's Gyro experiment in the ATF.  We will figure out what needs to be done to modify these to notch out unwanted frequencies, and amplify the signal nicely.  We will also create a pair of cables - one for power from the LSC rack, and one for signal back to the LSC rack.  Then we'll swap out the currently installed Thorlabs PD and replace it with a broadband PD.

Between the 40m meeting, and chatting with Gabriele, there was lots of talking yesterday about our 40m Lock Acquisition game plan. 

From those talks, here is my current understanding of the plan, in a Ward-style cartoon:

 (This is a 2 page document - description of steps is on 2nd page)

If you look closely, you will notice that there are several places that I have used "?" rather than numbers, to indicate what RFPD signal we should be using.  To fill these in, I need to look at some more simulations, and think more carefully about what signals exist at what ports, and what SNR we have at each of those ports.

Also, while the overall scale of the arm power plot is correct, the power level at each step is totally arbitrary right now, and should just be taken to mean places (in time) where the CARM offset is reduced a little more.

There are several things at this point that we know we need to look into:

* POP 22/110 PD and filtering electronics should be switched to a broadband PD, rather than the Thorlabs PD + Miniciruits filters. (Hardware)

* Whitening for the transmission QPDs needs to be thought about more carefully. (Calculation, then hardware)

* Chose a good SNR REFL DC signal, which may or may not be from the PD we are currently using (I think it's the DC of REFL11, but I'll have to check). (Calculation)

* For DRMI locking, what is the size of the SRCL error signal at AS55, AS165, and the REFL ports?  Do we need to lock with AS port, and then switch over to a REFL 3f port, to make acquisition easier?  (Simulation)

* Similarly, I want to make the equivalent of Figure 3 of T1000294, with our 40m parameters. (Simulation)

* To set the phase of AS110, simulate the demod phase of AS110 in both DRMI and SRMI cases.  If no (significant) change, maybe we can set the phase in the real system by misaligning the PRM, and watching the SRMI flash.  (Simulation)

* Simulate an arm sweep, up to many orders of the sidebands, to see how close to the carrier resonance any sideband resonances might be.  If something like the 4th order sideband resonates, and then beats with a 1st order sideband, is that signal big enough to disturb our 3f locking of the PRMI / DRMI?  We want to be holding the arms off resonance with ALS closer to the carrier than any "important" sideband resonances (where the definition of "important" is still undetermined).  (Simulation)

* Check if we can hand DARM from the DC transmission signals to the final RF signal while we still have a large CARM offset. Is there a point where the CARM offset is too large, and we must be still using the DC signals? (Simulation)

* At what arm power level can we transition from ALS to IR DC transmission signals for the individual arms? (Simulation)

* Still need to finish calculating what could be causing our big arm power fluctuations (Test mass angular motion?  PRM angular motion? ALS noise?) (Calculation)

Replys, and comments are welcome, particularly to help me understand where I may have (likely did) go wrong in drawing my cartoon. 

Here is a photo of the board inside the broadband photodiode (one of them) that I took from the Gyro experiment:

This PD is Serial Number S1200271.

We need to have a look at the schematic, figure out what's in here now, and then modify this to be useful (appropriate resonances / notches, as well as amplification) for POP 22/110.

 I have done a sweep of CARM, while looking at the fields inside of one arm (I've chosen the Xarm), to see where any resonances might be, that could be causing us trouble in keeping the PRMI locked as we bring the arms into resonance. 

Since Gabriele pointed out to me that we're using the 3x55MHz signal for locking, we should be most concerned about resonances of the higher orders of 55, and not of 11.  So, on this plot, I have up to the 6th order 55 MHz sidebands, which are 332 MHz.  Although the Matlab default color chart has wrapped around, it's clear that the carrier is the carrier, and the +4f2, which is the same blue, is not the giant central peak.  So, it's kind of clear which trace is which, even though the legend colors are degenerate.  Also, the main point that I want to show here is that there is nothing going on near the carrier, with any relevant amplitude.  The nearest things are the plus and minus 55 MHz sidebands themselves, and they're more than 50 nm away from the carrier. 

Recalling from elog 9122, the PRFPMI and DRFPMI linewidths are about 40pm.  50pm away from the resonant point is ~1/10 the power, and 100pm away from the resonant point is ~1/100 the power.  So, 50 nm is a looooong ways away. 

Just for kicks, here is a plot of all the resonances of the 1f and 2f modulation frequencies, up to 30*f1, which is the same 6*f2:

The resonances which are "close" to the carrier are the 9th order 11 MHz sidebands, and they're 280pm from the carrier, so twice as far as we need to be, to get our arm powers to ~1/100 of the maximum, and, they're a factor of ~1e4 smaller than the carrier.

 I have the X end transmission QPD, as well as the whitening board, out on the electronics bench.  Since the Thorlabs high-gain TRX PD also goes through this whitening board, we have no transmission signal for the Xarm at this time. The whitening board was in the left-most slot, of the top crate in the Xend rack.  The only cables that exist for it (like the Yend), are the ribbon from the QPD, the 4-pin lemo from the Thorlabs PD, and the ribbon going to the ADC.

I have taken photos, and want to make sure that I know what is going on on the circuits, before I put them back in. 

The QPD:

The whitening board:

 I think that our problem of seeing significant arm power fluctuations while we bring the arms into resonance during PRMI+arms tests is coming from PRM motion. I've done 3 calculations, so I will describe below why I think the first two are not the culprit, and then why I think the PRM motion is our dominant problem.

===============================================================

ALS length fluctuations

Arm length fluctuations seem not to be a huge problem for us right now, in terms of what is causing our arm power fluctuations.

What I have done is to calculate the derivative of the power in the arm cavity, using the power buildup that optickle gives me. The interferometer configuration I'm using is PRFPMI, and I'm doing a CARM sweep. Then, I look at the power in one arm cavity. The derivative gives me Watts buildup per meter CARM motion, at various CARM offsets. Then, I multiply the derivative by 60 nm, which is my memory of the latest good rms motion of the ALS system here at the 40m. I finally divide by the carrier buildup in the arm at each offset, to give me an approximation of the RIN at any CARM offset.

I don't know exactly what the calibration is for our ALS offset counts, but since we are not seeing maximum arm cavity buildup yet, we aren't very close to zero CARM offset. 

From this plot, I conclude that we have to be quite close to zero offset for arm length fluctuations to explain the large arm power fluctuations we have been seeing.

=======================================================================

AS port contrast defect from ETM motion

For this calculation, I considered how much AS port contrast defect we might expect to see given some ETM motion. From that, I considered what the effect would be on the power recycling buildup. 

Rather than doing the integrals out, I ended up doing a numerical analysis. I created 2 Gaussian beams, subtracted the fields, then calculated the total power left. I did this for several separations of the beams to get a plot of contrast defect vs. separation. My simulated Gaussian beams have a FWHM of 1 unit, so the x-axis of the plot below is in units of spot motion normalized by spot size. 

Unfortunately, my normalization isn't perfect, so 2 perfectly constructively interfering beams have a total power of 0.3, so my y-axis should all be divided by 0.3. 

The actual beam separation that we might expect at the AS port from some ETM motion (of order 1e-6 radians) causing some beam axis shift is of the order 1e-5 meters, while the beam spot size is of the order 1e-3 meters. So, in normalized units, that's about 1e-2. I probably should change the x-axis to log as well, but you can see that the contrast defect for that size beam separation is very small. To make a significant difference in the power recycling cavity gain, the contrast defect, which is the Michelson transmission, should be close to the transmission of the PRM. Since that's not true, I conclude that ETM angular motion leading to PRC losses is not an issue. 

I still haven't calculated the effect of ITM motion, nor have I calculated either test mass' angular effect directly on arm cavity power loss, so those are yet to be done, although I suspect that they aren't our problem either. 

========================================================================

PRM motion

I think that the PRM moving around, thus causing a loss in recycling gain, is our major problem. 

First, how do I conclude that, then some thoughts on why the PRM is moving at all. 

=========

theta = 12e-6 radians (ref: oplev plot from elog 9338 last week)

L = 6.781 meters

g = 0.94

a = theta * L /(1-g) = 0.0014 meters axis displacement

w0 = 3e-3 meters = spot size at ITM

a^2/w0^2 = 0.204 ==>> 20% power loss into higher order modes due to PRM motion.

That means 20% less power circulating, hitting the ITMs, so less power going into the arm cavities, so less power buildup. This isn't 50%, but it is fairly substantial, using angular fluctuation numbers that we saw during our PRMI+arms test last week. If you look at the oplev plot from that test, you will notice that when the arm power is high (as is POP), the PRM moves significantly more than when the carrier buildup in the cavities was low. The rms motion is not 12 urad, but the peak-to-peak motion can occasionally be that large. 

So, why is that? Rana and I had a look, and it is clear that there is a difference in PRM motion when the IFO is aligned and flashing, versus aligned, but PSL shutter is closed. Written the cavities flash, the PRM gets a kick. Our current theory is that some scattered light in the PRC or the BS chamber is getting into the PRM's OSEMs, causing a spike in their error signal, and this causes the damping loops to push on the optic. 

We should think a little more on why the PRM is moving so much more that any other optic while the power is building up, and if there is anything we can do about the situation without venting. If we have to, we should consider putting aluminum foil beam blocks to protect the PRM's OSEMs. 

The restore scripts from the IFO config screen half-failed, with this error:

retrying (1/5)...
retrying (2/5)...
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Wed Nov 13 2013 17:24:00.389261330
..................................................................

Jamie, do you know what this might be?  When requested, ETMY was not misaligned or restored, but we got these errors.  So, somehow we're not talking properly to EY, but other things seem fine (the models are running okay, the suspension is damped, etc, etc.)

[Gabriele, Jenne]

Nic and Evan put the ISS together (elog 9376), and we used an injection into the error point (?) to modulate the laser power before the PMC (The AOM had a bias offset, but there is no loop).  This gives us some RIN, that we can try to correlate with the PRM OSEM sensors. 

We injected several lines, around 100, 200, 500 and 800 Hz.  For 100, 200 and 800 Hz lines, we see a ratio between POPDC and the OSEM sensors of 1e-4, but at 500 Hz, the ratio was more like 1e-3. We're not sure why this ratio difference exists, but it does.  These ratios were true for the 4 face OSEMs.  The side OSEM saw a slightly smaller signal.  

For these measurements, the PRMI was sideband locked, and we were driving the AOM with an amplitude of 10,000 counts (I don't know what the calibration is between counts and actual drive, which is why we're looking at the POPDC to sensor *ratio*).  

To get a more precise number, we may want to consider locking the PRMI on carrier, so we have more power in the cavity, and so more signal in the OSEMs.  

These ratios look, by eye, similar to the ratios we see from the time back on 30 Oct when we were doing the PRMI+2arms test, and the arms were resonating about 50 units.  So, that is nice to see some consistency.

This time series is from 1067163395 + 27 seconds, from 30 Oct 2013 when we did the PRMI+2arms.

Ideas to go forward:

We should think about chopping the OSEM LEDs, and demodulating the PD sensors. 

We should also take a look in the chamber with a camera from the viewport on the north side of the BS chamber, to see if we see any flashes in the chamber that could be going into the OSEMs, to see where we should maybe put aluminum foil shields.

AOM driving from DAC:

I found that the DAC channels for TT3 and TT4 are connected up in the simulink model, but we aren't using them, since we don't actually have those tip tilts installed.  So, we hooked up the TT4 LR DAC output, which is channel 8 on the 2nd set of SMA outputs.  We put our AOM excitations into TT4_LR_EXC.

In the process of figuring out what we can do to fix our PRM motion problem, I am looking at the PRM oplev. 

Eventually (as in, tomorrow), I'd like to be able to simulate some optic motion as a result of an impulse, and see what the oplev loops do to that motion.  (For starters, I'll take the impulse response of the OSEM loop as my time series that the oplev loop sees).

One thing that I have done is look at the oplev model that Rana put together, which is now in the noisebudget svn: /ligo/svncommon/NbSVN/aligonoisebudget/trunk/OpLev/C1

This script plots the open loop gain of the modeled oplev:

This should be compared to the pitch and yaw measured transfer functions:

In the YAW plot, there are 2 transfer functions.  The first time around, the UGF was ~2.5Hz, which is too low, so I increased the gain in the C1:SUS-PRM_OLYAW filter bank from -3 to -9. 

The shapes of the measured and modeled transfer functions look reasonably similar, but I haven't done a plot overlay.  I suspect that the reason I don't see the same height peak as in the model is just that I'm not taking a huge number of points.  However, if the other parts of the TF line up, I'll assume that that's okay.

I want to make sure that the modeled transfer function matches the measured ones, so that I know I can trust the model.  Then, I'll figure out how to use the time series data with the simulated loop.  Ideally, I'd like to see that the oplev loop can fully squish the motion from the OSEM kicks.  Once I get something that looks good (by hand-tweaking the filter shape), I'll give it a try in the actual system.  We should, as soon as I get the optimal stuff working, redo this in a more optimal way.  Both now, and after I get an optimal design, I'll look at the actual step and impulse responses of the loop, to make sure there aren't any hidden instabilities.

Other thoughts for the night:

Rana suggests increasing the gain in some of the oplev QPD heads (including PRM), so that we're getting more than a few hundred counts of power on each quadrant.  Since our ADCs go to 32,000 counts, a few hundred is very small, and keeping us close to our noise limits.

Also, just an observation, but when I watch the REFL camera along with POP and AS, it's clear that the PRM is getting kicked, and I don't have the ETMs aligned right now, so this is just PRMI flashes.  There is also a lot of glow in the BS chamber during flashes (as seen on the PRM face video camera).

 This problem is now worse - the sliders on IFO_ALIGN for ETMY are white.  I can't telnet to the machine either, although auxex works okay.  Rather, it looks like maybe I'm getting to auxey, but then I'm immediately booted.  I can ping both c1auxex and c1auxey with no problem.
 

Heeeeelllp please.  Is this just a "shut off, then turn back on" problem?  I'm wary of hard rebooting things, with all the warnings and threats in the elog lately.  I've sent an email to Jamie to ping him.

There are some vague instructions in the wiki, but they begin at doing the burt restores, not actually restarting the computers: wiki  Back in July, elog 8858 was written, from which the wiki instructions seem to be based.  But in the elog it says "...went to the /cvs/cds/caltech/target/ area and started to (one by one) inspect all of the targets to see if they were alive.", but I don't know what "inspected" means in this case.  I probably should, since I've been here for something like a millennia, but I don't.

 This is what I remember doing all the time when Rob was around, but with all the new computers, I forgot whether or not this was allowed for the slow computers.

Anyhow, I went down there and keyed the crate, but auxey isn't coming back.  I'll give it a few more minutes and check again, but then I might go and power cycle it again.  If that doesn't work, we may have a much bigger problem.

 I went and keyed the crate again, and this time the computer came back.  I burt restored to Nov 10th.  ETMY is damping again.

It crossed my mind that, from these pictures, it could be glow from the oplev scattered light that is causing the problem.  However, that seems not possible, since the power fluctuations that we see depend on the presence of the IR light - if it were the oplev light, then when I close the PSL shutter, I should see the same amount of kick, which I don't.  Also, the amount of fluctuation increases with increased stored power in the cavities.  Also, also, Steve reminds me that some of the MC mirrors see similar kicks in their OSEM signals, but they don't have oplevs.

So, I don't believe that the oplev light is causing the problem, but I wanted to write down why I don't think that's it. 

Investigations into OSEM and oplev loops to get rid of the kicks are continuing.

I have created a new filter for the PRM oplev damping loops.  The biggest change is an increase in the gain between 0.4 - 7 Hz.

Here is a plot of the old, and my new modelled open loop gain:

When I look at my step and impulse response time series, the notches for the bounce and roll were causing some ringing, so for now they are turned off, both in the model and in the real time system.  Also, the "OLG orig" trace has a 4th order elliptic lowpass at 75 Hz, but the real system had a 4th order elliptic low pass at 35 Hz.  When we use 35 Hz in the model, we get lots of ringing.  So, we have moved both model and real system to 55 Hz 4th order elliptic low passes.  Also, also, we haven't been using the 3.3 Hz resonant gain, so I removed that from the modelled loop.

I have put the "boost" for the .4-7 Hz emphasis into FM 7 of the PRM oplev filters.  I also removed several old filters that are never used.  So, for now, the PRM oplevs should have engaged:  FM 1, 7, 9. Pitch gain is +5, yaw gain is -9.  We can consider re-implementing the bounce-roll notches, and the stack resgain if it looks like those are getting rung up, and causing trouble.

Here is a set of spectra, showing the improvement.  It's unclear why yaw is worse than pitch below 4Hz, and why pitch is so much worse than yaw between 4-15 Hz, however for each of pitch and yaw, the before (reference pink and cyan traces) is higher than the improved (dark red, dark blue traces) between a few tenths of a Hz up to 3ish Hz.  And, we're not causing more noise elsewhere.  We do want to monitor to make sure we're not ringing up the bounce and roll modes, but for now they seem fine.

 The auxey machine is back, in that I can interact with the IFO_ALIGN sliders, and they actually make the optic move, but I still can't read and write to and from the EPICs channels:

controls@rossa:/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt 0$ cdsutils read C1:SUS-ETMY_PIT_COMM
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Mon Nov 18 2013 21:13:52.044973819
..................................................................
Could not connect to channel (timeout=2s): C1:SUS-ETMY_PIT_COMM
controls@rossa:/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt 1$ cdsutils read C1:SUS-ETMY_YAW_COMM
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Mon Nov 18 2013 21:14:07.040168660
..................................................................
Could not connect to channel (timeout=2s): C1:SUS-ETMY_YAW_COMM
controls@rossa:/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt 1$

This is also causing trouble for the BURT save and BURT restore scripts, that are called from the IFO_ALIGN screen.  If I look at the log that is written from an attempted 'save' of the slider values, I see:

**** READ BURT LOGFILE

--- Start processing files
file >/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt/ETMY.req<
preprocessing ... done
pv >C1:SUS-ETMY_PIT_COMM< nreq=-1
pv >C1:SUS-ETMY_YAW_COMM< nreq=-1
--- End processing files

--- Start searches
C1:SUS-ETMY_PIT_COMM ... ca_search_and_connect() ... OK
C1:SUS-ETMY_YAW_COMM ... ca_search_and_connect() ... OK
--- End searches
Waiting for 2 outstanding search(es) ...
Waiting for 2 outstanding search(es) ...
did not find 2

--- Start reads
C1:SUS-ETMY_PIT_COMM ... not connected so no ca_array_get_callback()
C1:SUS-ETMY_YAW_COMM ... not connected so no ca_array_get_callback()
--- End reads

--- Start wait for pending reads

-- End wait for pending reads 0 outstanding read(s)

**** END BURT LOGFILE

The burt save file has no values in it.  Even if I copy over the ETMX save file and put in the correct channel names and values, a burt restore is unsuccessful. 

So, I can do locking tonight by restoring and misaligning by hand, but this sucks, and needs to be fixed. Other optics (at least PRM, SRM, ETMX) seem to be working just fine.  It's just ETMY that has a problem.

After I aligned the IR interferometer (no ASS - we still need to figure out what's going on with that), I am trying to find the green beatnotes for each arm.

First, I locked the green lasers to each arm.

I then went out to the PSL table and aligned the Green Yarm path by overlapping the near-field and far-field of the yarm transmission and the PSL green pickoff.  I then turned on the power for the Beat PDs, since it was off (I confirmed that the outputs were plugged into the beatbox, so they are seeing 50 ohms).  I assume that the beat PDs were off since Manasa pulled the Beatbox last week, but there is no elog reference!!  Anyhow, after seeing a real signal, I maximized the DC power on the beat PD for the Yarm.  I then maximized the light on the DC transmission PD for the Yarm.

I looked at the Xarm, and the near-field alignment looks okay, but I haven't checked the far-field.

I started looking for the beatnotes from the control room:

I am changing the SLOW_SERVO2_OFFSETs by 30 counts, and then unlocking and relocking the arms, and checking to see if I see a peak on the RF spectrum analyser. 

The Y offset started at -10320, and I found a beatnote at -11230 (beatnote is about 26MHz).  The X offset started at 4500.  Going larger seemed to get me to a less bright TEM00 mode, so I switched and have been searching by going down in offset, but haven't yet found the beatnote.  I suspect that I actually need to align the X path on the PSL table.  The Y beatnote is very small, about -30dBm, so I also need to tweak the alignment by maximizing the peak value.

EricQ said that he's going to start hanging out at the 40m a bit, and I was thinking about what I can have him help me with.  This lead to me writing up a wishlist for things that have to do with the ALS system and green lasers.  Some of these are very small tasks, while others are pretty big.  They are certainly not all high priority.  But, they're on my wishlist.

Calibrations

• How many counts of SLOW_SERVO2_OFFSET is one green FSR (for each arm)?
• Calibrate ALS OFFSETTER#_OFFSET counts to nm or Hz offset between the end lasers and the PSL.

Automation / script writing

• Automate finding the beatnotes (requires freq counters)
• Automate locking the ALS

Digital Acquisition

• All 3 laser temperatures
• Frequency counting of beatnotes

Hardware

• Install flipper mirrors on the PSL table to switch between trans DCPDs and far-field views of beam overlap for each arm.
• IR beatnote project - send pickoff of end lasers to PSL via fiber, set up beat detection for each arm, create PLLs.
• Yarm PZT installation and autoalignment.

I am able to lock the Yarm ALS, but not at the full gain that I should be.  I attribute this to my mediocre alignment of the path on the PSL table.  EDIT: Manasa pointed out that I forgot to set the PSL FSS slow adjust to ~zero, so the PSL temperature was off, so there wasn't really any hope for me last night.

However, I decided that I should write down the ALS locking procedure, as shown to me by Masayuki on 29Oct2013, that is written in one of the Control Room notebooks.  So, here it is.  I will write channel names and DTT template names for the Y arm, but the procedure is the same for both arms.

1. Lock and align arms using IR.
2. Lock green beams to arms.
3. Align green beams to arms.
4. Check beatnote alignment on PSL table.
5. Find beatnote by changing end laser temperature (C1:ALS-Y_SLOW_SERVO2_OFFSET) in steps of ~30, watch spectrum analyser for peak.  Easier if arms are locked in IR, but disable LSC system before moving to step 6.  Beatnote should be less than ~50 MHz, and should have a peak height of about -20dBm or more.  When doing 2 arms, be careful that beatnotes of the different arms do not overlap in frequency.  Manasa reminds me that you must also remember to set the PSL FSS SLOW actuator adjust to near zero, to get the PSL back near its nominal temperature.
6. Check UGF of phase tracker loop.  (DTT template in /users/Templates/ALS/YALS_PT_OLTF.xml) Want UGF to be ~2kHz.  Change C1:ALS0BEATY_FINE_PHASE_GAIN as necessary.
7. Start the watch script from the ALS screen to watch for lockloss.
8. Look at the PHASE_OUT spectrum (DTT template in /users/Templates/ALS/ALS.xml).
9. Clear history of Phase Tracker Loop (clear hist button on C1:ALS-BEATY-FINE_PHASE screen).  Very important to do this before step 10, every time you get to step 10  (i.e. if you lose lock and are starting over)!
10. Check sign of loop gain by using + or - 0.1 for the gain (C1:ALS-YARM_GAIN).  Beatnote should immediately stop moving if you have the sign right.  Otherwise, it'll zip around (if it does, repeat step 9, step 10).
11. Turn gain of ALS up to ~15.  Watch the PHASE_OUT spectrum, look for the servo bump.  When you see it, back off the gain a little.  Gain of ~15 is usually about the right ballpark.
12. Turn on FM 2, 3, 6, 7, 8 of C1:ALS-YARM.  (FM5 should already have been on).
13. Wait for PHASE_OUT spectrum to come down.  Turn on FM10 of C1:ALS-YARM.
14. Check UGF of ALS loop (DTT template in /users/Templates/ALS/YALS_OLTF.xml).  Want UGF to be about 150 or 170 Hz (at the peak of the phase bubble).  Adjust C1:ALS-YARM_GAIN as necessary.
15. ALS is locked!  Use something like the "Scan Arm" script from the ALS screen to find IR resonance, or do whatever measurement you want.  Dataviewer template /users/Templates/Dataviewer_Templates/ALSdtv.xml may be useful.

 Right now all 3 servos that control PRM angle (OSEM damping, Oplev, and ASC) run in parallel, and they're all AC coupled.