I have made the same modification to the Yarm trans PD whitening board as was done for the xend, to increase our SNR.  I put in a 2.1kOhm thin film resistor in the Rgain place.

When I was pulling the board, the ribbon cable that goes to the ADC had its connector break.  I redid the ribbon connector before putting the board back. 

I see signals coming into the digital system for both the high gain and low gain Y transmission PDs, so I think we're back.  I will re-do the normalization after Jamie is finished working on the computers for the day.

Jamie tells me that the 2 big consequences of this are (a) we are not archiving any data that is collected on the ioo machine, and (b) that we will not have access to test points on the IOO or ALS models.

To make sure that this is not a show-stopper for locking, I have locked the arms using ALS.  The signals seem to still be getting from the ALS model to the LSC model, and I'm able to acquire ALS lock, so we should be able to work tonight.  All of the data that I have been looking at lately has been coming off of the LSC machine, so we should even be okay in terms of look-back for lockloss studies, etc.

Some time series data from Wednesday night. 

Here is the first time we've gotten the arm transmissions to about 1 count, while holding CARM and DARM on IR signals, so the transmission, as well as POPDC, were relatively quiet.

As we were attempting to transition CARM to REFL11I, at least 2 of the times, we were hitting a CARM oscillation:

Last night, as well as tonight, the ALS seems not quite as robust as it was earlier in the week.

I have just taken noise spectra, and ALS is definitely more noisy than usual. 

These plots are with the arms held in CARM and DARM mode, with servo gains of 8. I was seeing the beginnings of gain peaking at a gain of 10, so I turned it back to 8.  Our ALS in-loop RMS is usually something like a few hundred Hz, but I'm seeing over 1kHz, so I have a factor of 4 or 5 too much noise.  Why?!?!?

This evening, I was not able to successfully transition CARM from ALS to 1/sqrt(trans) signals.  The TRY time series looked odd, so I took a spectra, and we have huge 60Hz noise in TRY. 

I found a lock stretch from around 6:30pm that did not show the 60Hz noise, and then there was a lock stretch around 8pm that did have the noise.  So, something happened at the Yend between 6:30 and 8pm tonight.

Asking around, this was the time frame in which Manasa was down at the Yend to realign the green beam, and to check cabling for the PZT_OUT and ERR_MON signals to the ADC.

Looking at the spectra, Rana noted that we have even as well as odd harmonics of the 60Hz line, which is unusual.

To try to diagnose the problem, Rana and I tried to make sure no cables' connectors were touching, and that no equipment was plugged in that shouldn't be.  We noticed that none of: the shutter, the Thorlabs TRY PD, or the QPD TRY are isolated from the table.  To see if perhaps the shutter was the problem, I turned off the power to the Yend green shutter, and unplugged the cable.  The cable is laying on the table, with the connector sitting on a piece of plastic to isolate it.  Removing the shutter from the system did not change anything. 

We don't see the 60Hz noise in the Xarm, so it's not on the laser light itself.  Also, we don't see the 60Hz lines in the Yarm feedback signal, so we're not putting the lines onto the mirror, and thus onto the Yarm's light. 

Manasa, can you please take a look, and see if you can figure out what is going on?  We need TRY so that we can transition to 1/sqrt(trans) signals for CARM.  Thanks!!

[Jenne, Q]

The frame builder (or something) is unhappy again.  I know that we've seen this before, but I can't find the elog entry that relates to this particular problem.

Every few minutes, the fb status lights on the CDS_STATUS screen go white, and then come back green.  It's annoying when it happens every hour or so (which is unfortunately typical), but it's pretty debilitating when it stops dataviewer and dtt every few minutes.  Just from the way the lights change, it looks like perhaps the daqd process is restarting itself periodically? 

 I re-plugged in the Yend shutter, and turned it on.

I tried some locking anyway tonight, even though we don't have TRY. 

The biggest conclusion is that I miss the auto-resonance-finding.  I've been roughly scanning the Y-ALS offset to find the POY zero crossing when I see the resonance on the test mass face cameras. 

The next-biggest conclusion, is that I can hold the PRFPMI close to resonance, using ALS for CARM and DARM.  I was trying to transition DARM to AS55, but I couldn't get the last bit of the way.  That is, I couldn't turn off the ALS control.  So, I think that AS55 wasn't actually holding DARM, until maybe the last moment or so.

Anyhow, here are some time series.  My average TRX value is around 40 counts, and POPDC is maybe 250 counts (just PRMI, POPDC is about 75 counts).  Obviously this is noisy as hell, but I'm not using any IR signals for the arms.  Near the end of this first time series, I am trying to switch to AS55 for DARM.

Zooming in, my real lockloss is due to PRCL oscillating at ~350 Hz:

However, I also saw ~25Hz peaks in CARM and DARM on the spectra starting to show up, and I see a ~25 Hz oscillation in DARM a few moments after the PRCL lockloss.  (Plot #2 is a zoom of the ~1.1 second mark on Plot #3.)

The locking parameters:

CARM:

Input:  Using the new CESAR matrix, -1*ALSX, +1*ALSY.  Beatnotes both move up in freq if temp sliders move up.

Servo: gain = 6, FMs 1, 2, 3, 5, 6, 7, 9 on.  Offset = 0 counts. 

Output = -1*MC2

DARM:

Input:  +1*ALSX, +1*ALSY

Servo:  gain = 4.  FMs 1, 2, 3, 5, 6, 7, 9 on.  Offset = 0 counts.

Output = -1*ETMX, +1*ETMY

PRCL:

Input:  +1*REFL33_I, Norm = +0.01*POPDC, sqrt engaged.

Servo:  acquisition easier with -0.04 or -0.06, less gain peaking at -0.02   FMs 4, 5 on; 2, 3, 6, 9 triggered with 0.5 sec delay.  Servo trigger = POPDC, up 100, down 10.  FM trigger = POPDC, up 300, down 20.

Output = +1*PRM

PRCL ASC off, PRM oplev on.

MICH:

Input:  +1*REFL33_Q, Norm = +0.01*POPDC, sqrt engaged.

Servo:  gain = 2, FMs 4, 5 on; 2, 3 triggered with 0.2 sec delay.  Servo trigger = POPDC, up 100, down 10.  FM trigger = POPDC, up 300, down 20.

Output = +0.5*BS, -0.2625*PRM

PDs:

REFL33 analog gain set to 30 dB for both I&Q.

AS55 set to 0 dB for both I&Q.  AS55 had DC normalization of 80 counts (which was the measured number for PRFPMI when TRX was about 0.1 count this evening)

Here is 1 second of data, with REFLDC, POPDC and TRX:

Here is a zoom of the first 3 big peaks in TRX.  The weird jumps at the beginning of each TRX peak are due to the triggered switching between the Thorlabs trans PD and the QPD trans PD.  Clearly we need to work on their relative normalizations.  There are also little jumps after each peak as the triggering sends the signal back to the Thorlabs PD.

Here is a zoom of the single big peak about halfway through the 1 second of data:

And here is a zoom of the tail of that peak.  It looks to me like we want to start thinking about using REFL DC when our transmitted powers are around 2 counts.  We could do as soon as 1 count, but 2 is a little farther into the dip.

 I was unhappy with the discontinuities between the Thorlabs and QPD versions of our transmitted light powers.  I realized that in the olden days, we just used the Thorlabs PD, and we set the no-light offset in the LSC version of the TR[x,y] filter banks.  However, now that we have brought the QPDs back, we are setting the dark offsets in the end suspension models, so that the signal chosen by the trigger already has its offset taken care of before we send it to the LSC model. 

Anyhow, having the offsets script try to put a value in the C1:LSC-TR[x,y]_OFFSET was giving us an extra offset and then when we did the normalizations, the numbers came out all wrong.  So.  I have removed the C1:LSC-TR[x,y] filter banks from the offset list, since they were made redundant. 

I have redone the normalizations for both arms (after running the ASS scripts).  I checked by watching the _OUT16 versions of the Thorlabs and QPD diodes before the triggering happens, and as I put offsets into the LSC servos to change the transmitted power, the diodes both change in the same way.  So, we'll have to see if this holds true for more than just values 0-1 the next time we lock, but hopefully it won't need changing for a while.

[Jenne, Koji]

The IFO is being uncooperative tonight, and I have an early morning meeting, so I'm calling it a night. 

Koji's filter module changes have been propagated from the Xarm to the Yarm, to CARM and to DARM.  (Actually, Q overwrote the changes to Xarm on Sunday accidentally, so first he reverted those for us, and then we propagated the changes). 

Today, with careful measuring, we find that for X and Y arms individually locked with the ALS, we want the gains to be +17 for the Yarm, and -17 for the Xarm (with the beatnote up-is-up convention).  This puts the UGFs at 150 Hz. 

We then switched over to CARM and DARM locking.  We guessed that the gains should be a factor of 2 lower since we're pushing on both ETMs for DARM, and the MC2 actuator is roughly the same strength as the sum of the ETMs.  In the end, after measuring the CARM and DARM loops, we find that the gains should be +7.5 for CARM, and +8.0 for DARM to set the UGFs at 150 Hz.  The servo is a little bit delicate, so having too low of gain is not okay. 

For some reason, we seem to be utilizing more actuator range with the new setup, so the limiters in the filter banks have been set to 11,000 (previously were 8,000), and the ALS watch script (ALSdown.py) threshold has been increased to 10,000 (previously 7,000). 

When finding the IR resonances with the new scheme, we are having trouble holding lock throughout the scan.  I have set the tramp for the coarse part of the scan to be 0.05 seconds (previously 0.01 seconds), which is an increase of a factor of 5 in the ramp time.  This helps, but may still not be enough, since we don't always hold lock until both IR resonances are found.

Probably the most annoying thing from tonight is the fact that ETMY keeps drifting off, particularly in yaw, when locked.  I don't have an explanation of why this is happening, but you can watch it happen sometimes, and the lock will be lost shortly thereafter.  Definitely when we lose lock and the ETM gets kicked, it is far enough away in yaw alignment that I have to completely redo the Yarm alignment.  This happens whether or not the ETMY oplevs are on.

To summarize, 3 scripts have been modified:

(1) ALSdown - threshold increased  (Modification from last week - turns off the slow temp servos for the end lasers, clears histories)

(2) ALSfindIRresonance - increase ramp time

(3) Lock_ALS_CARMandDARM - final gain values set to 7.5 for CARM and 8 for DARM, no filters come on until gains all the way up, turns on new set of Koji filters. (Modification from last week - turns on the slow temperature servos for the end lasers)

[Rana, EricQ, Jenne]

We locked the Yarm by using the CM board this evening. 

POY is going from its demod board to the CM board, and then the slow output of that is going to the POY channel of the whitening, and then on to the ADC.  So, with no AO path engaged, this is basically like regular Yarm locking. 

First of all, Den and Koji back in December were concerned that they were seeing some EOM saturation in the fast path, but we don't think that's an issue.  We looked at the FSS PCDRIVE while we increased the AO gain.  In fact, it looks like the offset is coming from the MC board's IN2 slider.  Even with no input on that slider, increasing its value puts an offset into the MC.  To fix this, I am going to put a 6.8uF cap in series with R30 in the MC board, which is part of the crossbar switch where the IN1 and IN2 get summed.  This should AC-couple the output of the IN2 slider before the summing node.

We aren't sure which sign to use for the AO path of the CM board...Eric is doing some modelling to see if he can figure it out.  He's going to try to see which spectra (below) his model matches.

For the spectra, we have a reference trace with no AO path, a trace with "Plus" polarity on the CM board which started to show a peak when the value of the MC IN2 slider was at about -6 dB, and a trace with "Minus" polarity, which started to show a peak when the value of the MC IN2 slider was at about -16 dB. 

We took loop measurements for each of the Plus and Minus cases. Something that seems a little weird is how shallow of a slope we have in both cases near our UGF.

 MC board is out, so don't be surprised that the MC isn't locking.

 MC board is back in place, MC is locked.

If I disable all of the AO path bits of the CM servo (disable switch, and also gain slider to -32dB), and then move the MC IN2 slider around, the MC does not get an offset anymore (as seen by reduced transmission and increased reflected power), so I think the DC coupling is working.  I do lose lock of the MC if the slider goes above ~22 dB in this situation, but I don't see any effect before then, whereas we were able to see a steady increase in the reflected power as we moved the slider around last night.  So, it seems like things are good with the DC coupling of the IN2 slider.

Here are some photos from before I modified the board (front, back, and zoom of the area I was working in):

And here is my modification, putting the 6.8uF cap in series with (a new) 2k thin film resistor, in the spot for R30:

The board is https://dcc.ligo.org/DocDB/0004/D040180/001/D040180-C.pdf

[Edit, 20140721: It looks like this is actually D040180 rev B, not rev C. —Evan]

I touched up the alignment of the Ygreen on the PSL table.

I have taken out of loop spectra for both arms, by looking at POX/POY while the arms were controlled with ALS.

To do this, I put the POY11 Q signal directly to the whitening board, which meant that I removed the cable coming from the common mode board.  (Now that we're doing CM stuff again, I have put it back, so POY is still in the slightly weird "going through the CM slow path" situation). 

For the locking, both arms had FMs 1, 2, 3, 5, 6 engaged.  Yarm had a gain of +17, Xarm had a gain of -17. 

Y beatnote was 98.6MHz with a peak height of -22 dBm.  X beatnote was 45.0MHz with a peak height -11 dBm.

I drove ITMY at 503.1 Hz with 100 counts.  I drove ITMX at 521.1 Hz with 25 cnt. 

Koji helped me match up the peak heights between the FINE_PHASE_OUT_HZ calibrated signals and the PDH signals. 

The out of loop noise is definitely below 1kHz rms now, which is better than it was!  Hooray!

 Today I finally implemented a feature in the whitening triggering that I should have a long time ago:  an override button.

Now, on each RFPD's phase rotation screen, there is a button to either allow triggering for that PD (both quads) or to be in manual mode.  

If you are allowing triggering, they will behave as they have for the last ~year.....if any degree of freedom is using either quadrant of that PD, and that degree of freedom is triggered, then engage analog whitening and digital de-whitening.

If you chose manual mode, then you can engage or disengage the whitening as you please.  (The analog whitening and digital de-whitening are still tied together).

[Rana, Jenne]

This evening, we were able to lock the Yarm through the common mode board, using AS55 as our error signal.  Our final UGF is about 5kHz, with 60 degrees of phase margin.

Before dinner, Rana switched the input of the CM board's REFL1 input to be AS55I rather than POY11Q, in the hopes that it would have better SNR.  Demod phase of AS55 was measured to be 14 deg for optimum Yarm->I-phase and has been set to 0 degrees.  Since the POY demod phase had been 90 degrees, which puts in a minus sign, and now we're using 0 deg which doesn't have a minus sign, we're using the plus (instead of minus) polarity of the CM board.

We re-allocated gains to help lower the overall noise by moving 15dB from the CM board AO gain slider to the MC IN2 gain slider, so we weren't attenuating signals.

We see, by taking loop measurements even before engaging the AO path (so, just the digital loop portion) that we've gained something like 20 degrees of phase margin!  We think that about 5 degrees is some LSC loop re-shaping of the boost filter.  We weren't sure why there was a hump of extra gain in the boost filter, so we've created a new (FM8) boost filter which is just a usual resonant gain:  resgain(16.5,7,50)

The cm_down and cm_step scripts in ..../scripts/PRFPMI/ were modified to reflect the settings below, and their current states are included in the tarball attached.

Also, throughout our endeavors this evening, the PC fast rms has stayed nice and low, so we don't suspect any EOM saturation issues.

Now our Yarm digital servo has a gain of -0.0013, with FMs 2, 4, 5, 7, 8 engaged (2, 7, 8 are triggered). 

Our final CM board settings are: 

REFL1 gain = +22dB

offset = -2.898V

Boost = enable

Super Boost = 0

option = disable

1.6k:79 coupled cavity compensator = enabled

polarity = plus

option = disable

AO gain = 15dB

limiter = enable

MC board:  IN1 gain = 18dB, IN2 gain = 0dB.

Here is a measurement of the Common Mode MCL/AO crossover.  The purple/orange trace here is after/before the boost was engaged.

We also have a measurement of the total loop gain, measured with the SR785.  The parameter file, as well as the python script to get the data, are in the tarball attached.  Noteably, the excitation amplitude was 500mV, whereas Q and Rana yesterday were using 5 or 8 mV.  We aren't sure why the big change was necessary to get a reasonable measurement out.  This measurement is with the boost enabled.

Finally, here is a measurement of the MC error point spectra, with the CM boost on, after we reallocated the gains.  There's a giant bump at several tens of kHz.  We need to actually go out with the fast analyzer and tune up the MC loop.

To get ready for the PRFPMI CM trials tonight, I put AS55's cables back to their nominal state, and now have REFL11 I going to IN1 of the CM board.  The OUT1 of the CM board goes to the REFL11I whitening channel.

REFLDC was not disconnected in the last few days, so it is still set up for IN2 of the CM board, with an external offset adjust.

I was thinking about POP today, and wanted to know if there was something to be done to allow us to use the PRCL ASC for at least a little bit farther into arm power buildup.

Anyhow, I checked, and while PRMI is locked on sidebands (ETMs misaligned), POP DC is about 80 counts, and the power measured by the Ophir power meter is 24 microWatts. 

We were on the 3rd gain setting for the QPD's power amplifier.  I turned it down to the "2" option.  (When at 4, the front panel light indicates saturation).

It's not clear to me what the gain settings mean exactly.  I think that "1" means 4*10^3 V/A, and "6" means 4*10^6 V/A (On-Trak OT301 info site), but I don't know for sure how the gain changes for the settings 2-5.  Anyhow, I have changed the digital gain for the ASC to be -0.063 from -0.023 for both pitch and yaw.

As part of checking the common mode board before we get too carried away with using it, I looked at the time series of the AO servo output when I turned on various boosts, or changed gain values.  As it turns out, basically anything that I did caused glitches.  Oooops.

I plugged a function generator to the IN1 port of the CM board, with a freq of 400Hz, and a voltage of 10mVpp (which is the smallest value that it would allow).  I plugged the BNC version of the servo output into a 300MHz 'scope.

First I looked at "boost" and "super boost", and then I looked at various steps of the AO gain slider.  For all of the button presses that gave me glitches, I saved .png's of the 'scope screen (on a floppy, so I'll have to fetch the data tomorrow...).

Both enabling, and disabling the "Boost" button gave me glitches.

For "Super Boost", I saw glitches for all of the steps, 0->1, 1->2, 2->3. 

For the AO path, I only started at 0dB, and only captured screenshots of glitches when I increased the gain, since presumably that's when we'll care the most during acquisition.  I found that going down in gain caused glitches at every step!  For increasing the gain, steps from an odd number of dBs to an even number consistently caused glitches.  Steps from an even number to an odd number occasionally caused glitches, but they weren't very common.  For the steps that did cause glitches, some were worse than others (7dB to 8dB, 15 dB to 16 dB, and 23 dB to 24 dB seemed the worst.)

After my work, I put all of the cables back, so that we should be ready to utilize the CM board for locking this evening.

For posterity, here are the notes that I took while I was working - I'll make them more coherent when I fold them in with my images tomorrow.  The "first .png, next, etc." are because the 'scope numbers them in order as a default.

1st png = boost enable, then disable
2nd png = super boost, start at 0, then 1, then 2, then 3
3rd png = AO gain from 1 to 0
4th is AO gain from 0 to 1 (happens less often than 1->0, which is every time I get a glitch)
Next is AO gain 1->2, got 2 glitches!
3->2 glitch often, 2->3 much less often
next is 2->3
next png is 3->4, 2 glitches with weird dip
4->5, rare
next png is 5->6
6->7 is rare
next png is 7->8, which is nasty!!
8->9 is rare
png 9->10
10->11 is rare
png 11-> 12, 3 glitches
 12->13 rare
png 13->14, 2 glitches
14->15, rare
png 15->16, kind of nasty
png 17->18, 2 glitches
png 19->20, 3 glitches
png 21->22, 2 glitches
png 23->24, kind of nasty
png 25->26, 2 glitches
png 27->28, 3 glitches, at least
png 29->30, 2 glitches

Somehow, the images got put into a whole new entry, even though I thought I was editing this one.  Anyhow, please see elog 9938.

Note:  I thought I was editing elog 9935, but somehow this became a whole new entry.  Either way, all the info is in here.

As part of checking the common mode board before we get too carried away with using it, I looked at the time series of the AO servo output when I turned on various boosts, or changed gain values.  As it turns out, basically anything that I did caused glitches.  Oooops.

I plugged a function generator to the IN1 port of the CM board, with a freq of 400Hz, and a voltage of 10mVpp (which is the smallest value that it would allow).  I plugged the BNC version of the servo output into a 300MHz 'scope.

First I looked at "boost" and "super boost", and then I looked at various steps of the AO gain slider.  For all of the button presses that gave me glitches, I saved .png's of the 'scope screen (on a floppy, so I'll have to fetch the data tomorrow...).

Both enabling, and disabling the "Boost" button gave me glitches.

For "Super Boost", I saw glitches for all of the steps, 0->1, 1->2, 2->3. 

For the AO path, I only started at 0dB, and only captured screenshots of glitches when I increased the gain, since presumably that's when we'll care the most during acquisition.  I found that going down in gain caused glitches at every step!  For increasing the gain, steps from an odd number of dBs to an even number consistently caused glitches.  Steps from an even number to an odd number occasionally caused glitches, but they weren't very common.  For the steps that did cause glitches, some were worse than others (7dB to 8dB, 15 dB to 16 dB, and 23 dB to 24 dB seemed the worst.)

After my work, I put all of the cables back, so that we should be ready to utilize the CM board for locking this evening.

For posterity, here are the notes that I took while I was working - I'll make them more coherent when I fold them in with my images tomorrow.  The "first .png, next, etc." are because the 'scope numbers them in order as a default.

1st png = boost enable, then disable
2nd png = super boost, start at 0, then 1, then 2, then 3
3rd png = AO gain from 1 to 0
4th is AO gain from 0 to 1 (happens less often than 1->0, which is every time I get a glitch)
Next is AO gain 1->2, got 2 glitches!
3->2 glitch often, 2->3 much less often
next is 2->3
next png is 3->4, 2 glitches with weird dip
4->5, rare
next png is 5->6
6->7 is rare
next png is 7->8, which is nasty!!
8->9 is rare
png 9->10
10->11 is rare
png 11-> 12, 3 glitches
 12->13 rare
png 13->14, 2 glitches
14->15, rare
png 15->16, kind of nasty
png 17->18, 2 glitches
png 19->20, 3 glitches
png 21->22, 2 glitches
png 23->24, kind of nasty
png 25->26, 2 glitches
png 27->28, 3 glitches, at least
png 29->30, 2 glitches

The screenshot of the Boost enable / disable I'll have to re-take.  Apparently I instead caught a screenshot of the list of files on the floppy...ooops.

This is a shot of enabling the Super Boosts.  At the beginning, it's at "0", so no superboosts (also, regular boost was off).  Then, I switch to "1", and the trace gets a little fuzzy.  Then I switch to "2", and it gets very fuzzy.  Then I switch to "3", and a lot of the fuzz goes away.  There's a glitch at each transition.

The following screenshots are all of various steps of the AO gain slider.  For all of these, both the "boost" and "super boosts" were off.  Each screenshot is a single gain step, even if there are several glitches captured.

First, 0dB to 1dB:

Next, 1dB to 2dB:

2dB to 3dB:

3dB to 4dB:

While increasing the gain, I didn't find any more steps from an even to an odd number where I got a glitch.  They would glitch when I undid that step (decreased the gain), but over ~5 trials for each increase, I didn't ever catch a glitch.  The odd to even steps still had glitches while increasing the gain though.

5dB to 6dB:

7dB to 8dB:

9dB to 10dB:

11dB to 12dB:

13dB to 14dB:

15dB to 16dB:

17dB to 18dB:

19dB to 20dB:

21dB to 22dB:

23dB to 24dB:

25dB to 26dB:

27dB to 28dB:

29dB to 30dB:

We need to go back and have a look at all of our optical lever control filters, and make sure they make sense. 

In particular, we should have a look at the ITMs, since they have a huge amount of motion around 10Hz. 

Notes:  ETMX shouldn't have that lower notch.  The bounce mode Qs should be lowered.

[Jenne, Rana, EricQ]

We tried a few times to engage the AO path while holding CARM on sqrtTrans and DARM on ALS, but failed every time.  Since we cannot stably hold lock at arm powers of 1, even though we were able to do so early last week, we think that we have a problem (obviously).  One noticeable thing is that while held with ALS, the Xarm transmission fluctuates almost full power.

As we were seeing late last week, the Xarm IR transmission while held with ALS was fluctuating wildly, whether we were locked on individual arms or on CARM/DARM. 

Tonight we took some out of loop spectra, with different HEPA settings, to see how that affected things.  It looks like HEPA at the nominal ~20% is okay, but anything higher than that starts to affect the Xarm beatnote sensing, while it mostly leaves the Yarm beatnote sensing okay.  Perhaps this is something that isn't tightened enough in the Xarm path, or something on a skinny floppy mount that needs to be more secure.

I am still a little confused though, why we don't see large power fluctuations in *both* arms while using ALS to control CARM/DARM.  Why are we not seeing this Xarm noise being fed back into the Yarm, through either the ETM via DARM, or common stuff via CARM actuating on MC2.

Note that the change at high frequency is because I switched from using non-DQ channels to DQ channels, so that's not anything to pay attention to.  The noise reduction we see is below about 20Hz.

Rana pointed out that our POPDC level was very small.  We don't have screens for them, but the DC PDs have the same analog whitening as the RF PD signals do.  I changed C1:LSC-POPDC_WhiteGain.VAL from 0 to 11.  Now our POPDC while locked on sidebands is about 8,000 counts.

We also swapped the cables between the SR785 and the CM board around.  Now channel 2 of the 785 goes to TP2A, channel 1 goes to TP2B, and the source goes to EXCB.  This is so that we can break the AO loop with the disable switch just after the slow/fast split, and look at the transfer function before we close the loop. 

I took loop measurements of ETMX pit and yaw, and set the upper UGF to be ~6Hz for both.  This required a pitch gain of 25, and a yaw gain of 16.

The spectra look similar to what they were before Steve did the swap.

I believe that the Xend aux laser was turned off earlier today, for Steve's work swapping out the oplev.  When I went down there, the red "off" LED was illuminated, and the LCD screen was showing something.  I pushed the green "on" button, and I immediately got green.

Also, I saw that the 24Hz roll mode was very rung up on ETMX.  I looked at the FM5 "bounce roll" filter, and it had some old values, 12Hz and 18Hz for the resonant gains.  All other optics have the proper 16Hz and 24Hz frequencies.  I copied the BS oplev bounce roll filter over to ETMX pit and yaw (both were wrong), and loaded them in.  The mode is starting to ring down.

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

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

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

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

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

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

It's starting to get a little crowded, but I modified the IFO_ALIGN screen to have new buttons to show the aligned / misaligned state of each optic.  Koji made a good point, and I left the old restore script functional so that if the slider is moved significantly, we can always go back gently to the burt restored value.  I have removed the old misalign function though, since we shouldn't ever be using that again.

I tried many times this evening to engage the AO path, with limited success.

Q's new scripts worked really well, and so I have some transfer functions!  To take these measurements, in ...../scripts/general/netgpib, I am running ./TFSR785 TFSR785_CARMloop_May2014.yml, where the file name is the name of my parameter file.  The data, and the saved pdfs, are in /users/jenne/PRFPMI/CARM_loop_measurements/2014May14/ .  For these measurements, the SR785 is hooked up to the "A" set of excitation and test points on the CM board.

All of these traces were taken while the IFO was PRFPMI, with PRCL and MICH on REFL33, DARM on ALS diff, and CARM on InvSqrtTrans.  carm_cm_up.sh is up to date, through the echo "REFL_I should now be zero" (~line 111 in the script).  All you need to do is set the beatnotes, and then run the script.  Follow instructions in the prompt (such as "press enter to confirm PRMI is locked"). 

Here are my notes for the various times:

23:01:44 - MC IN2 = 0dB, CARM gain = 5.0

23:13:45 - MC IN2 = 10dB, CARM gain = 5

23:26:10 - MC IN2 = 6dB, CARM gain = 10 (after Q suggested increasing overall gain, rather than just AO path)

00:13:07 - MC IN2 = 6dB?, CARM = 6ish?  don't remember exactly.

00:45:00ish, Realigned IFO using IR with arms.

01:03:17 - MC In2 = 0dB, CARM gain = 5

01:07:42 - MC IN2 = 8dB, CARM gain = 6.295  (AO went up to 6dB, then +1dB steps to both simultaneously using  ezcastep C1:LSC-CARM_GAIN 1dB C1:IOO-MC_AO_GAIN 1)

01:08:57 - MC IN2 = 10dB, CARM gain = 7.92447

01:10:08 - MC IN2 = 12dB, CARM gain = 9.97631

lockloss when trying to add 1 more dB to both.

01:41:36 - MC IN2 = 12dB, CARM gain = 9.97

lockloss when just MC IN2 up by 1dB, left CARM gain alone.

Other notes:

The 60Hz noise in TRY is back.  Since I thought I remembered someone suggesting that it was leakage light from the exit sign, Koji went in and wrapped the end table in foil, however the lines are still present.

 In addition to a transparent legend, we need the corresponding CM crossover measurements from DTT to compare with the Q-Mist-Loop model results. The xover tells us when the AO gain is high enough so that they can be ramped up together.

Also, I wonder how much power fluctuation we get from the large ALS DIFF noise and if that demands we get the TR signals normalized by POPDC.

[Rana, Jenne]

We have looked at a few things that do and don't affect the out of loop noise of the ALS X beat, and found that cavity alignment and beatnote RF frequency had the strongest effects.

Possible causes of noise:

1.  Air currents from A/C or flowbench.  No effect. 

        * When table lid is on, turning on and off the flow bench air did not qualitatively change the out of loop beatnote time series signal.

2.  Scattered light from other beams hitting green PDH PD.  No effect.

        * There are a few spots of green light that are hitting the case of the PDH photodiode, but when I put an iris in place to block those spots, there was no change in the beatnote spectra.  This makes sense to me since none of those spots were close to hitting the diode itself. 

        * Rana did notice that the beam was not well centered on the PD, so he steered the beam onto the center of the diode.  Also, the PD is now tilted a little bit so that the reflection from the diode doesn't go back into the beam path.  Neither of these things had an effect that we noticed in the beatnote noise.

3.  Oplev laser light getting to PDH PD.  Not tested.

       * We don't see any red light over by the PDH PD, so we did not try turning off the oplev's laser to see if that had an effect, but we suspect that it is not the cause of our noise.

4.  Clipping of main IR / green beam on Xend table.  Not tested.

      * We should still go have a look at this, but we no longer think that this is the main cause of the elevated noise.

5.  Scattered light all over Xend table.  Not tested.

     * We should still work on dumping extraneous beams on the table, but we do not think that this is the main cause of the elevated noise.

     * Rana took some photos so that we can see how truely bad the situation is.

6.  Amplitude modulation dip in NPRO.  Not tested.

    * It is probably still a good idea to check this, in case the dip in the amplitude modulation has changed over the year or two since it was last measured, but we also don't think that this is the main problem.

7.  Check PDH servo.  Not done.

     * I think this is still on Q's long-term todo list, but we should give the PDH servos a once-over.

8.  Arm cavity longitudinal motion.  No effect.

     * While the Xarm was locked with IR, we put a line at 1.7 Hz with 325 counts into the ITMX position.  To keep lock, the ETM had to move as well.  When we turned on this line (and increased its amplitude up to the final value of 325 cts), we did not see any qualitative change in the beatnote time series noise.

9.  Arm cavity alignment.  Significant DC effect.

    * When the alignment of one of the arm cavity mirrors is changed, the DC value of the beatnote signal changes. 

           * ITMX moved in yaw, we see a 7kHz/15urad DC shift in the BEATX_FINE_PHASE_OUT_HZ time series.

          * ETMX moved in yaw, we see an 8kHz/5.5urad DC shift in the time series.  We aren't sure why this is about a factor of 3 times larger effect (same shift for smaller misalignment) than the ITM.

    * We want to do a Yuta-style analysis to see what the angle to length coupling looks like, so that we can measure the angular motion of our cavity mirrors and put the expected noise into our ALS noise budget.  Perhaps this will help us understand the low frequency difference between our in-loop beatnote error signal and our in-loop PDH error signals (red vs. maroon on the ALS noise budget posted above Pianosa). 

    * I've asked Manasa to take some transfer functions in the morning, so that we can start to have an idea of what is going on with this.

10.  Beatnote RF frequency.  Significant broadband effect.

     * We have found that when the Xarm beatnote is at low RF frequencies, the noise is high, and when the beatnote is at high RF frequencies, the noise is low! 

     * Low RF freqs are below about 40 MHz, while high RF freqs are above about 90 MHz.  This has not been tested for the Yarm.  Also, these are for the case of "temp slider up, beatnote up".  I have not checked if the same is true for the other side of the PSL frequency, although I don't have reason to believe that it would be.

     * Maybe we are saturating some amplifiers?  We need to check this out.  One thought that Den mentioned was the harmonics, and that perhaps they are causing trouble in the electronics.

     * Den is going to think about implementing a frequency divider so that we can directly digitize the beatnote signal. 

    * Here are spectra for different cases:

        * And here is a spectrogram showing us going back and forth between the high and low noise states:

                     *  A:  First noticing that noise is good when RF frequency is high.

                     * B:  Not locked on TEM00 mode, so extra noisy.  Disregard.

                     * C:  Bad noise time.  Xbeat was 21 MHz (dark purple on DTT spectrum above), Ybeat was 118 MHz (sea green on DTT spectrum above).

                    * D:  Good noise time. Xbeat was 89 MHz (light purple on DTT plot), Ybeat was still 118MHz (turquoise on DTT plot).

                     * E:  Bad noise time.  Xbeat was 37.5 MHz, Ybeat was still 118 MHz.

                     * F:  Good noise time.  Xbeat was 113 MHz, Ybeat was still 118 MHz.

Since Q has found that REFL165 will be better for holding the PRMI while we reduce the CARM offset, I had a look at locking PRMI sideband locking with both 3f PDs.

I checked the REFL165 demod phase, and changed it from -142.5 deg to -138.5 deg. to minimize the Q signal while driving PRM length.

I found that keeping the MICH and PRCL loop gains the same, and using matrix elements +0.1 for both I and Q for REFL165, rather than +1 for both I and Q for REFL 33.

MICH gain is +0.8, PRCL gain is -0.02.  FMs 4,5 on for both, FM 2 triggered for MICH, FMs 2,3,6 triggered for PRCL.

I then locked the PRMI on sideband with REFL 33 and then REFL 165, and measured the other one as an out of loop sensor of the motion.  I find that REFL33 and 165 are both comparable, and so we shouldn't have any trouble using REFL165 for locking.

[Rana, Jenne]

We spent some time tonight looking at locking the PRMI with REFL165 vs. REFL33, while reducing the CARM offset. 

We were not able to lock the PRMI on REFL165 I&Q at small CARM offsets.  When locking at larger CARM offsets (about 100 counts, which is about 100nm) and then re-adjusting the REFL165 demod phase as I reduced the CARM offset, I saw that I had to significantly rotate the phase.  For PRMI only (no arms), the REFL165 demod phase was -138.5 deg.  When the PRMI was locked with a -100 count CARM offset, the optimal demod phase was -123 deg.  Then at -90 counts the phase was -113 deg.  At -70 counts, the phase was -108 deg, at -50 counts it was -98 deg, and at -40 it was -93 deg.  We want to go back and look at these more carefully, and in a more continuous way, by watching the sensing matrix calibration lines.  It's unclear to me right now why we're seeing this, but it's possible that we're getting some kind of extra 55MHz resonances.

REFL DC looks like it should be good - same slope and gain as sqrtTR, extra 20 or 30 deg of phase margin, so we think that we should be able to transition over to it, and then try engaging the AO path.  Tonight we had Den's new 1kHz lowpass engaged, and with this, everything looks nice and stable.

Game plan:  Bring CARM in until transmissions are at about 10ish, then try keeping CARM on sqrtInvTrans for the DC part, and engage the AC AO part with REFL DC.  We probably just need to try this for a while more to find just the right way to turn it on.

Need to think about demod phase rotation vs CARM offset as well as extra resonances, but this may take a while, and if we can just get the AO path engaged, that would be good.

I just realized that I forgot to elog this, but yesterday afternoon I bypassed the amplifier in the BeatX path, and now the X beatnote is about -27dBm.  Arms lock nicely with ALS.

Sorry, I had been in a hurry when I worked on this last week, and again when I wrote the elog, but I wanted to at least put in a note for any weekend workers.

The ALS beatnote setups need alignment on the PSL table.  However, even at very low RF beat frequency, the X beatnote now at low frequencies matches our best measurement from last week.  The "HEPA off" (teal and purple) measurements are from last week, and the red and blue are from this week.  The X beatnote was 10MHz and the Y beatnote today was 31MHz.

Grr.  I am very frustrated.  After lunch I redid alignment for both X and Y green systems (Yarm both at the end and on the PSL table, Xarm just on the PSL table).  After that realignment work, I cannot find a beatnote for the Xarm!!! 

The Ybeat, after aligment, was up to -5.5 dBm when the beat was at 11 MHz. Last week it was something like -20 dBm, so alignment makes a big difference.  After doing IR alignment I had noticed that the green transmitted through the Yarm didn't look very bright on the camera, and the power was around 0.2, so I went to the Yend and gently touched the green input steering mirrors, and got the Ygreen trans PD back to more than 0.9 with the PSL green shutter closed.  Awesome.  Then I touched up the Ygreen PSL alignment, and then saw that the beatnote was nice and large.  Hooray.  I measured the out of loop noise, and it was even better than the best we saw last week:  (greenish was best last week for Yarm, teal blue is new Ygreen):

At this point, I still hadn't touched anything on the X path (except the PZT input steering mirrors, remotely from the control room).  The beatnote was about the same size as it was on Friday, around -27dBm.  I went onto the PSL table and did the same alignment procedure that I had just done for the Yarm:  Remove the green trans PD and the accompanying lens so that I get far-field spots on the wall, and then steer the PSL green and the X green spots until they are nicely overlapped at both the camera (near-field) and on the wall.  I looked at the DC output of the beat PD, and centered the beam on the diode.  I put back the thorlabs DC transmission PD and the lens, and centered the beam on that.  However, after this work, I cannot find a beatnote for the X arm!  I still see the nice big Ygreen beatnote, and I have the PSL and Xend temperatures where they usually are (  abs(FSS Slow) < 0.1, and X end Slow around 10,090. )  I scanned -10,000 counts, and +5,000 counts from there, and still don't find a beatnote!

I went back inside, and I don't see an RF signal coming into the beatbox from the Xarm.  It's not the cable's fault though, since I then hooked the RF output of the beat PD to a 'scope, and still didn't see any beatnote.  The DC path of the PD is definitely seeing things, because when I switch the 'scope over to the DC output of the Xbeat PD, and I block/unblock the beam, I see the voltage step up and down as expected. 

I have not pulled out the Xgreen broadband PD, but unless someone else has a good idea of what to check, that might be one of the next things to do. 

Ideas of things I could try:

* Put the X broadband PD on the Y beatnote path to see if I see the same Y beatnote (use the port where the Y green trans PD is, since it has the coaligned beams, and a lens).

* Open the PD and see if anything on the RF path is fried.

* Move the Y PD over to the X path, to see if it sees the beatnote.

* ????

Also, while I was working on the PSL table, I heard noise that sounded like a bearing rolling around.  I suspected the HEPAs, since the one on the north east corner of the table has a problem when it's turned up high (we've known about this for a long time), however turning off the HEPAs didn't affect the noise.  The noise is strongest near the back of the PSL controller on the shelf above the table, and the PSL controller box is vibrating.  So, I suspect that the fan on the PSL controller box is about to give out.

EDIT:  To clarify, I mean the Innolight's controller.

Current computer status:

All fast machines except c1iscey are up and running. I can't ssh to c1iscey, so I'll need to go down to the end station and have a look-see. On the c1lsc machine, neither the c1oaf nor the c1cal models are running (but for the oaf model, we know that this is because we need to revert the blrms block changes to some earlier version, see Jamie's elog 9911).

Daqd process is running on framebuilder.  However, when I try to open dataviewer, I get the popup error saying "Can't connect to rb", as well as an error in the terminal window that said something like "Error getting chan info".

Slow machines c1psl, c1auxex and c1auxey are not running (can't telnet to them, and white boxes on related medm screens for slow channels).  All other slow machines seem to be running, however nothing has been done to them to point them at the new location of the shared hard drive, so their status isn't ready to green-light yet.

Things that we did on Friday for the fast machines:

The shared hard drive is "physically" on Chiara, at /home/cds/.  Links are in place so that it looks like it's at the same place that it used to be:  /opt/rtcds/...... 

The first nameserver on all of the workstation machines inside of the file /etc/resolv.conf has been changed to be 192.168.113.104, which is Chiara's IP address (it used to be 192.168.113.20, which was linux1).  This change has also been made on the framebuilder, and in the framebuilder's /diskless/root/etc/resolv.conf file, which is what all of the fast front ends look to. 

On the framebuilder, and in the /diskless place for the fast front ends, presumably we must have changed something to point at the new location for the shared drive, but I don't remember how we did that [ERIC, what did we do???]

The slow front ends that we have tried changing have not worked out. 

First, we tried plugging a keyboard and monitor into c1auxey.  When we key the crate to reboot the machine, we get some error message about a "disk A drive error", but then it goes on to prompt pushing F1 for something, and F2 for entering setup.  No matter what we press, nothing happens.  c1auxey is still not running.

We were able to telnet into c1auxex, c1psl, and c1iool0.  On each of those machines, at the prompt, we used the command "bootChange".  This initially gives us a series of:

$ telnet c1susaux
Trying 192.168.113.55...
Connected to c1susaux.
Escape character is '^]'.

c1susaux > bootChange

'.' = clear field;  '-' = go to previous field;  ^D = quit

boot device          : ei
processor number     : 0
host name            : linux1
file name            : /cvs/cds/vw/mv162-262-16M/vxWorks
inet on ethernet (e) : 192.168.113.55:ffffff00
inet on backplane (b):
host inet (h)        : 192.168.113.20
gateway inet (g)     :
user (u)             : controls
ftp password (pw) (blank = use rsh):
flags (f)            : 0x0
target name (tn)     : c1susaux
startup script (s)   : /cvs/cds/caltech/target/c1susaux/startup.cmd
other (o)            :

value = 0 = 0x0
c1susaux >

If we go through that again (it comes up line-by-line, and you must press Enter to go to the next line) and put a period a the end of the Host Name line, and the Host Inet (h) line, they will come up blank the next time around.  So, the next time you run bootChange, you can type "chiara" for the host name, and "192.168.113.104" for the "host inet (h)".  If you run bootChange one more time, you'll see that the new things are in there, so that's good.

However, when we then try to reboot the computer, I think the machines weren't coming back after this point.  (Unfortunately, this is one of those things that I should have elogged back on Friday, since I don't remember precisely).  Certainly whatever the effect was, it wasn't what I wanted, and I left with the machines that I had tried rebooting, not running.

Rana and I now seem to have the fast front end computers (c1lsc, c1sus, c1ioo, c1iscex and c1iscey) up and running!  Hooray!

It seemed that we needed to change the soft links back to hard links for rtcds and rtapps on the front end machines.  On c1ioo, we did:

cd /opt

sudo rm -rf rtcds

sudo rm -rf rtapps

sudo mkdir rtcds

sudo mkdir rtapps

sudo chown controls:1001 rtcds

sudo chown controls:1001 rtapps

mount /opt/rtcds

mount /opt/rtapps

At this time, the front end fstab had several other options in addition to "nolock" for both rtcds and rtapps.  They had rw,bg,user,nolock.  This state still had some permissions problems.  (Later, we have decided that perhaps our next step was unneccesary, since it still left us with (fewer) permissions problems. Taking out the rw,bg,user options from the front end fstab seems to have fixed all permissions issues, so maybe this next chmod step didn't need to be done.  But it was done, so I record it for completeness).

On chiara, we did:

cd /home/cds/rtcds

sudo chmod -R 777 *

Then on c1iscex, I didn't have to deal with the soft links, but I did need to mount the rtcds and rtapps directories so that I could see files in them.  I just did the last 2 operations from the c1ioo list above (mount /opt/rtcds and mount /opt/rtapps). 

Since we were still seeing some (fewer) permissions problems, we took out the extra options in the front ends' fstab that Rana had added.  Rebooting c1iscex after this, everything came back as expected.  Nice!

I think that, at this point, remotely rebooting (sudo shutdown -r now) the other front ends made everything come back nicely. Since we had gotten the fstab situation correct, we didn't have to by-hand mount any directories, and all of the models restarted on their own.  Finally!

For posterity, here are things that we'll want to remember:

Frame builder's fstab, in /etc/fstab (only the uncommented lines, since there are lots of comments):

/dev/sdb1               /               ext3            noatime         0 1
/swapfile               none            swap            sw              0 0
shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0 0
/dev/sda1               /frames         ext3    noatime         0 0
192.168.113.104:/home/cds/                      /cvs/cds        nfs     _netdev,auto,rw,bg,soft      0 0
192.168.113.104:/home/cds/rtcds                  /opt/rtcds     nfs     _netdev,auto,rw,bg,soft 0 0
192.168.113.104:/home/cds/rtapps                 /opt/rtapps    nfs     _netdev,auto,rw,bg,soft 0 0


Fast front end fstabs, which are on the framebuilder in /diskless/root/etc/fstab:

master:/diskless/root                   /               nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
master:/usr                             /usr            nfs     sync,hard,intr,ro,nolock,rsize=8192,wsize=8192    0 0
master:/home                            /home           nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
none                                    /proc           proc    defaults          0 0
none                                    /var/log        tmpfs   size=100m,rw    0 0
none                                    /var/lib/init.d tmpfs   size=100m,rw    0 0
none                                    /dev/pts        devpts  rw,nosuid,noexec,relatime,gid=5,mode=620        0 0
none                                    /sys            sysfs   defaults        0 0
master:/opt                             /opt            nfs     async,hard,intr,rw,nolock  0 0
192.168.113.104:/home/cds/rtcds         /opt/rtcds      nfs     nolock                     0 0
192.168.113.104:/home/cds/rtapps        /opt/rtapps     nfs     nolock                     0 0

Rana mentioned this in his elog entry re: SLOW computer recovery, but I want to highlight it:

We cannot yet lock the mode cleaner.

It seems that we need to be aware of the sticky slider issue that we have seen for years (although don't deal with too often) that a burt restore will make it seem like an EPICS channel is at some value, but in fact it is at some other value.  For any sliders or buttons in question, change the value by some amount, and then change it back.  This forces things to refresh, and it'll then be at the value that is reported.

However, for the MC board, this seems to not be enough.  Changing the offset slider doesn't seem to actually change the offset value.  The fast output of the MC board is railed at 9.996 V.  So.  We need to check out the MC servo board and ensure that we are actually connected and talking to it through the c1iool0 (C1i-oh-oh-L-zero, to make the characters more clear) slow machine.

 I have brought back c1auxex and c1auxey.  Hopefully this elog will have some more details to add to Rana's elog 10015, so that in the end, we have the whole process documented.

The old Dell computer was already in a Minicom session, so I didn't have to start that up - hopefully it's just as easy as opening the program.  (Edit, JCD, 9July2014:  Startup a terminal session, and then type "minicom" and press enter to get a Minicom session).

I plugged the DB9-RJ45 cable into the top of the RJ45 jacks on the computers.  Since the aux end station computers hadn't had their bootChanges done yet, the prompt was "VxWorks Boot".  For a computer that was already configured, for example the psl machine, the prompt was "c1psl", the name of the machine.  So, the indication that work needs to be done is either you get the Boot prompt, or the computer starts to hang while it's trying to load the operating system (since it's not where the computer expects it to be).  If the computer is hanging, key the crate again to power cycle it.  When it gets to the countdown that says "press any key to enter manual boot" or something like that, push some key.  This will get you to the "VxWorks Boot" prompt. 

Once you have this prompt, press "?" to get the boot help menu.  Press "p" to print the current boot parameters (the same list of things that you see with the bootChange command when you telnet in).  Press "c" to go line-by-line through the parameters with the option to change parameters.  I discovered that you can just type what you want the parameter to be next to the old value, and that will change the value.  (ex.  "host name   : linux1   chiara"   will change the host name from the old value of linux1 to the new value that you just typed of chiara). 

After changing the appropriate parameters (as with all the other slow computers, just the [host name] and the [host inet] parameters needed changing), key the crate one more time and let it boot.  It should boot successfully, and when it has finished and given you the name for the prompt (ex. c1auxex), you can just pull out the RJ45 end of the cable from the computer, and move on to the next one.

ETMX had default 1's for gains, 0's for matrix elements, etc., so I did a burt restore to May 25th, 2pm, which was a few days before the Crash.  It looks fine now.

We have (now) in the lab 2 cables that are RJ45-DB9.  The gray one is LIGO-made, while the blue one is store-bought.  

The gray LIGO-made one works, but the blue store-bought one does not.  I checked their pinouts, and they are completely different.  On the sketch below, the pictures of the connectors is me looking at them face-on, with the cables going out the back of the page.  The DB9 is female. 

[Jenne, Rana]

Today, Rossa has been hanging at bootup.  You get the desktop, and most of the gui things, and can move the mouse pointer around, but clicking the mouse or using the keyboard have no effect.  Once you try clicking something, the mouse pointer turns into the spinning ball, and stays like that.

If, upon rebooting (soft rebooting from another machine, through an ssh session), you hold down the Shift key, you should get to a Grub menu.  If you arrow-key down and select the next-most-recent version (not the recovery mode, but just the regular earlier version), and press Enter, Rossa starts up nice and happily.

I am not sure how to make Rossa always boot into this version of things, or how to get rid of the newest version so that the version that works is the most recent, but I'm hoping one of my Linux buddies will help me out on this one.  I think (maybe) that I need to find out what package was recently updated and could have caused problems, and then revert that one package.  (I think I can look at tail /var/log/apt/history.log to tell me what has recently been updated).

[Rana, Jenne]

Mc autolocker:

MC autolocker is running.  The trouble was with caput and caget and cavput on Pianosa.  Rana has switched those lines in mcup and mcdown over to ezcaread and ezcawrites, and that seems to have fixed things. For the MC2tickleON and -OFF scripts, we left the caput and caget and cavput, and saw that they do run successfully on Ottavia.  (We tried testing again on Pianosa, and now it seems to be okay with cavput, but we promise it was hanging up on this earlier this evening.)  Anyhow, it's all a bit confusing, but it seems to be running fine now.

The autolocker is now running on Ottavia, and Rana is putting it into Ottavia's cronjob list, and commented it out on op340m.

fstab changes:

We have removed the option "all_squash" from /etc/exports on Chiara (both lines).  We then checked that the files have ownership "controls controls" on Chiara, Pianosa and Rossa.  Ottavia still has ownership of "nobody nogroup", so we still need to figure that out. 

FSS slow loop:

We confirmed that the slow loop is running.  Also, since caput and caget seem to take a while, and the real PID integral gain is the value that we set times a sampling rate, the effective gain had changed.  So, Rana compensated by changing C1:PSL-FSS_SLOWKI from 0.03 to 0.1. 

Other thoughts:

Do we have an autoburt saver on another computer, in addition to op340m?  (It's in the op340m crontab list)  We really only want one of these at a time.

I noticed today, and Rana said that he saw Saturday, that the MC refl value when the MC is unlocked is unusually high.  It typically goes to about 4.5 V, but now is going up to 6.5V.  Since the PMC output is the same as usual (max seen has been about 0.82 today), something must have happened between the PMC and the IMC. 

Late last week, EricG and Nichin were looking at things on the AS table.  Was anything touched on the AS table?  Was anything touched on the PSL table?  'Fess up please, so that we can pinpoint what the change was.

Also, this afternoon, I touched up the MC alignment a bit, although it still needs work (I've asked Manasa to look at it tomorrow).  Rana centered the WFS to my MC alignment (this will need to be redone after the MC is truely aligned), and we turned the WFS on.  I also locked both arms individually, and locked MICH and PRMI sideband.  The PRMI wasn't especially stable unless I turned on the POP ASC.  I assume (hope) that this is just because I was doing it during the day, and not because there is something actually different about the PRMI since the computer meltdown.

Rana and I also took some notes on things that need to be done, starting tomorrow (the first line and the yellow line are scribbles):

PRMI locking with REFL33 is fine.  As it was yesterday, it's a little wobbly without the ASC (just PRM oplev), but I don't know that it's any different than it used to be.  It'll hold for long periods of time, so I feel okay about it. 

When the PRMI is locked, you can push the "up" button on the ASC screen, and it'll turn down the PRM oplev gain by a large factor, and engage the ASC.  When you lose lock, press the "down" button to undo these changes.  (Probably the ifoconfig script should include the ASC down script).  These up and down scripts for the ASC are already included in the carm_up script (the ASC up), and the watch scripts which run a down script (including ASC down) for the whole IFO when ALS loses lock.  If the ASC is engaged, I get bored of watching it before the PRMi loses lock on its own, so I think it's okay.  (Let's say that means I've watched it stay locked for at least a few tens of seconds, but it looks like it always has with the ASC - like it'll stay forever).

The only thing that seems different about the PRMI is that I've increased the PRCL gain from -0.02 to -0.04.  This is a value that it was at some weeks ago, and then we turned it down for loop osc reasons, but now it doesn't want to catch lock with the lower value, and if I turn it down after it's locked, it has trouble holding on.  I have included this change into the PRMI sideband configure script.

I haven't tried anything creative like locking with REFL 165.  I also didn't lock with 11 or 55, since 33 just worked.

The MC autolocker is once again running on Ottavia, with the nohup command.  

It was hanging for a long time (at least minutes) on the cavput and the caputs in the MC2 tickle on and off scripts.  I claim that there isn't a good reason to not just use ezcawrite, or whatever the latest and greatest fully functioning function is, so I've changed the cavput to a series of ezcawrites, and all of the caputs are also ezcawrites.  Now I don't see any hanging, and the MC locks itself.

This does not solve the scripto_cron issue, so if Ottavia is rebooted, or the autolocker is otherwise killed, it will not start itself up. 

I have modified the /etc/default/grub file, so that we're loading up the previous linux kernel version on reboot.  Now Rossa boots up (at least one time so far) without any fancy button-pushing.

(Note, if things go south again, we have to push "shift" starting after the Dell screen is gone.  Holding it down while the Dell screen is still up doesn't seem to make it register that you want the grub menu).

The grub file USED to look like:

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

but now it looks like:

GRUB_DEFAULT=2
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=false
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

Note that the first line, GRUB_DEFAULT has changed from 0 (first item in grub menu, if you successfully hit shift and get to it) to 2 (the third item in the list).  I think that the GRUB_HIDDEN_TIMEOUT_QUIET=false is supposed to force it to show the countdown time when you can push shift, but I didn't see any difference there.

To edit this file, you must use "sudo [text editor] grub".  I like emacs, so I used "sudo emacs grub".  After an edit, before a reboot, you must run "sudo update-grub".  Then you can reboot (sudo shutdown -r now is what I use), and hopefully it will boot as you directed.

Right now, the 0th (first) entry in the grub menu is "Ubuntu, with Linux 2.6.32-61-generic".  The 2nd (third) entry is "Ubuntu, with Linux 2.6.32-58-generic".  If we install a new kernel version, the 61 version will bump down in the list, and we'll be booting that, which I assume will fail.  We should not update Rossa until we're ready to go to Ubuntu 12, and when we do, we must ensure that the grub file first line reads GRUB_DEFAULT=0.  (As a side note, the 1st (really 2nd) entry in the grub menu is "Ubuntu, with Linux 2.6.32-61-generic (recovery mode)", which we don't want.  The 58 version has a recovery mode as the next line item, since it alternates version-N, version-N recovery mode, version-(N-1), version-(N-1) recovery mode, etc.)

Arms locked in comm and diff with ALS. PRMI locked with REFL33 I&Q while arms off resonance. Having trouble reducing CARM offset, even to get to arm powers of 1.

After Manasa installed the new Xgreen PD, Koji looked at the PSL table alignment with me.  I saw only a very weak beatnote with the X BBPD, even though I could see the beatnote on the Y PD from the leakage of the X beam to the Y PD  (Yend shutter was closed, so just PSL and X greens were on the table).  I had thought that my near-field and far-field alignments were pretty good (actually, I checked them, but didn't feel that I needed to tweak them since Manasa did the alignment this afternoon).  Anyhow, it was just a matter of tweaking up the alignment a bit, and then the X beatnote got up to about -25dBm at a few tens of MHz.  I am starting to question myself if the other BBPD is broken, or if I just not well enough aligned.  Anyhow, the spare is in, we can still have a look at the previous X BBPD, but it may be okay, and it's just me embarrassing myself by not catching an alignment problem.

Anyhow, after the X beat was found, I was able to (on my first try) lock the arms using ALS comm and diff.  (I already had a nice strong Y beatnote, so that didn't need finding, other than temp adjustment of the end laser).  I ran the carm_cm_up.sh script, and it did everything nicely.  I did a quickie check of the phase tracker loop gains, but that should be redone in the morning.

PRMI was a little reluctant to lock, so I played around with the MICH and PRCL gains, but didn't really find any combination that was any better than the usual (+0.8 for MICH, -0.04 for PRCL as I had last night, although I needed to reduce the PRCL gain back to -0.02 to eliminate loop osc). 

After an arm lockloss, I relocked just the PRMI and used awggui to put a line into C1:LSC-PRM_EXC to check the RF PD phasing.  I changed REFL33 from 133.5 to 138.5, and REFL 165 from -142.5 to -152.5.  I didn't think that REFL11 needed changing, and I didn't check REFL55.  I also checked that I could lock PRMI without arms, using both REFL33 and REFL165 - they seemed about the same to me, both stable.  REFL33 has 1's in the input matrix, and I was using 0.07's for REFL165.  The demod phase adjustment didn't really improve PRMI locking while the arms were held off resonance, even if I moved the arms even farther from resonance (usually we do 3nm, I went out to 5nm to see if that helped - it didn't).  I tried REFL165 locking, but that wasn't any good either.  I tried using REFL165 with the arms held off resonance, but that didn't seem to catch at all (at least with REFL33 I was getting short lock blips). 

Anyhow, of the 3 or 4 times that I caught REFL33 PRMI lock and tried to reduce the CARM offset, only one time did I even get to arm powers of about 1 (CARM digital offset of -0.1, with CARM held on sqrt transmission signals), and then it didn't stay for more than a few tens of seconds.  The other few times, it broke lock on the way up to arm powers of 1. 

So, carm_cm_up.sh works pretty well, although perhaps the arm powers of 1 offset reduction needs to be a little slower.  PRMI doesn't catch and hold lock very easily with REFL33, and even less so with REFL165.  It may be useful to try catching lock with REFL11 or 55, and doing a transition over to 3f.  No real progress forward, but we're pretty much recovered.