40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 146 of 344  Not logged in ELOG logo
ID Datedown Author Type Category Subject
  9972   Tue May 20 02:12:35 2014 JenneUpdateLSCALS X noise investigation

[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:

          ALS_outofloop_19May2013.pdf

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

          XbeatSaturate.png

                     *  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.

  9971   Mon May 19 22:44:21 2014 denUpdatePEMxend sei isolation kit is set

Quote:

Yend seismometer isolation kit (elog 8461) hosts Guralp seismometer. I made a cable for inside connection, assembled the kit and relocated the instrument from its previous position at the yend inside the kit.

Seismometer is connected to the readout box and running.

    

 Xend internal cabling and external connector is ready. We are waiting for seismometer from Gyro lab. We still need to fix the pot with clamps after we put the instrument in.

We also need a long cable from Xend to the guralp readout box.

  9970   Mon May 19 09:19:44 2014 SteveUpdateLSChappy IFO

15 hours

  9969   Sun May 18 17:57:54 2014 ranaUpdateLSCETMX transients due to unseated bias cable

 The daytime crew had noticed that there were some ETMX angular shifts happening without any control or intention.

I reseated and strain relieved the bias cable coming into the backplane of the coil driver and now it seems OK.

In the 4-hour-long second trend plot below, the era before 2300 is before reseating. Afterwards, we make a couple adjustments, but so far there has been no un-asked for alignment shifts.

AdS has been run on both arms and offsets saved. Its locked on green/red and the beat frequencies are low and the amplitudes high. 

Sun May 18 23:53:37 2014: still OK...I declare it fixed.

 

  9968   Sun May 18 14:36:04 2014 denUpdateLSCoffsets in 3f and drmi stable lock on 1f

Eric, Den

We noticed that PRMI RIN is high when the cavity is locked on RELF33 I&Q signals. We compared the level of power fluctuations when PRMI was locked using REFL11, REFL55 and REFL 33. Attached plot "prmi_rin" shows the spectra.

Then we excited PRM and measured length to RIN coupling when PRMI was locked on REFL33 I&Q. DC offset of PRCL is only 3%. But MICH offset seems to be ~nm. When we gave offset of -15 cnts to the servo, power fluctuations improved by a factor of few.

Then we looked at DRMI. It seems that SRC macroscopic length is off but we still could lock it stably. To account for macroscopic length detuning we had to rotate REFL55 phase from 25 degrees to 50 degrees. Power at AS port increased by factor of ~2 compared to PRMI configuration. SPOP18 is decreased only by 30%. Attached plot "drmi_power" shows POP18, POP90, POPDC and ASDC in PRMI and DRMI configurations.

Plot "src_ol" shows srcl OL transfer function. UGF is 70 Hz. We have also centered SRM OL and copied the servo filters from PRM, gains are set to keep UGF at ~0.1 Hz and 7 Hz

This is a more detailed procedure:

1. Phase: REFL11: 19 degree, REFL55: 50 degrees (25 degrees for PRMI configuration)

2. Input matrix:

PRCL   0.15 0 0 REFL11I
MICH = 0 0.15 0 REFL55Q
SRCL   -0.09 0 1 REFL55I

3. Servo parameters:

PRCL: gain = -0.02, FM4,5 + trigger FM2,3,6,9

MICH: gain = 0.8, FM4,5 + trigger FM2

SRCL: gain = 0.25, FM4,5 + trigger FM2,3

4. Triggering:

signal is SPOP22 , levels 40:25

  9967   Sat May 17 14:48:06 2014 denUpdatePEMyend sei isolation kit is set

Yend seismometer isolation kit (elog 8461) hosts Guralp seismometer. I made a cable for inside connection, assembled the kit and relocated the instrument from its previous position at the yend inside the kit.

Seismometer is connected to the readout box and running.

IMG_1405.JPG    IMG_1406.JPG

  9966   Fri May 16 20:55:18 2014 JamieFrogsloreun-full-screening Ubuntu windows with F11

Last week Rana and I struggled to figure out how to un-full-screen windows on the Ubuntu workstations that appeared to be stuck in some sort of full screen mode such that the "Titlebar" was not on the screen.  Nothing seemed to work.  We were in despair.

Well, there is now hope: it appears that this really is a "fullscreen" mode that can be activated by hitting F11.  It can therefore easily be undone by hitting F11 again.

  9965   Fri May 16 16:08:12 2014 steveUpdateLSCIsolating base plates

 Electronic components should be ISOLATED as they are installed on the optical tables.

This is essential to avoid ground loops, 60 Hz and harmonic peaks in the spectrum. We have just got some made.

Please only use it for this reason. Earlier black delrin base plates were used up in not needed places.

 

The anodized Aluminum base plates with magenets certainly will conduct.

 

  9964   Fri May 16 11:22:23 2014 SteveUpdateLSCX Arm ALS Noise coming in and out

Quote:

Den and I spent some time with the interferometer last night with hopes of bringing in the AO path, but were stymied by the (re)occurrence of the anomalously high low frequency motion of the Xarm, as seen by fluctuations of TRX from .9 to .2 while "held" on resonance.

Jenne reported that they weren't seeing it earlier in the evening, and then it started again when I showed up. Holding the arms on IR, we could see a fair amount of excess low frequency noise in the BEATX_FINE_PHASE_OUT_HZ channel, as compared to BEATY, bringing its RMS to 5 times that of the Y arm. From the shape of the excess noise (broad slope from DC to tens of Hz), Rana suspected air currents and/or scattering effects being the culprit.

Den poked around a bit on the PSL table, which didn't really change much. He then went down to the X end table to inspect the table, and while he was there, I noticed the noise go down to being in line with the Yarm. I joined him at the end, and we found the beat phase noise in the frequency region of concern to be hugely sensitive to tapping on the enclosure, air current, etc. There is also a ton of green light everywhere, and multiple spots of green light around the green refl PD.

At that point however, the quiescent noise was acceptable (TRX fluctuations of <.2), so we went back to the control room to try to lock. Unfortunately, after a few attempts, the noise was back. At this point, we went home. The layout of the end table likely needs some attention to try and minimize our susceptibility to excess scatter effects. 

 Turn off the AC and flow bench please.

  9963   Fri May 16 10:54:42 2014 ericqUpdateLSCX Arm ALS Noise coming in and out

Den and I spent some time with the interferometer last night with hopes of bringing in the AO path, but were stymied by the (re)occurrence of the anomalously high low frequency motion of the Xarm, as seen by fluctuations of TRX from .9 to .2 while "held" on resonance.

Jenne reported that they weren't seeing it earlier in the evening, and then it started again when I showed up. Holding the arms on IR, we could see a fair amount of excess low frequency noise in the BEATX_FINE_PHASE_OUT_HZ channel, as compared to BEATY, bringing its RMS to 5 times that of the Y arm. From the shape of the excess noise (broad slope from DC to tens of Hz), Rana suspected air currents and/or scattering effects being the culprit.

Den poked around a bit on the PSL table, which didn't really change much. He then went down to the X end table to inspect the table, and while he was there, I noticed the noise go down to being in line with the Yarm. I joined him at the end, and we found the beat phase noise in the frequency region of concern to be hugely sensitive to tapping on the enclosure, air current, etc. There is also a ton of green light everywhere, and multiple spots of green light around the green refl PD.

At that point however, the quiescent noise was acceptable (TRX fluctuations of <.2), so we went back to the control room to try to lock. Unfortunately, after a few attempts, the noise was back. At this point, we went home. The layout of the end table likely needs some attention to try and minimize our susceptibility to excess scatter effects. 

  9962   Fri May 16 10:48:32 2014 SteveUpdateLSCY arm T- qpd is getting light guard extension tube

The qpd was removed from the east end table and threaded adaptor ring epoxied on it's shell.

This tube will cut down the amount of emergency exit light getting into the qpd.

  9961   Fri May 16 09:46:05 2014 SteveUpdatePSLpointing monitoring

Quote:

 Tonight I noticed that the drop in PMC transmission was ~1V, more than the usual of ~0.5V from the daily drift.

While re-aligning on the table, I noticed that the misalignment was not from either of the steering mirrors; i.e. I has to walk them both to get the alignment back. This implies that the misalignment is generated far upstream. Maybe the the laser itself is moving. We need some updates from Steve's laser misalignment tracker.

I'd like to replace the paper target with IOO -QPD_POS so we can log it.

  9960   Fri May 16 00:25:53 2014 ranaUpdatePSLPMC realign

 Tonight I noticed that the drop in PMC transmission was ~1V, more than the usual of ~0.5V from the daily drift.

While re-aligning on the table, I noticed that the misalignment was not from either of the steering mirrors; i.e. I has to walk them both to get the alignment back. This implies that the misalignment is generated far upstream. Maybe the the laser itself is moving. We need some updates from Steve's laser misalignment tracker.

  9959   Thu May 15 16:46:35 2014 ericqUpdateLSCPossible Path to AO path

 It's taken a lot of trial and error, but I've found a path through MATLAB loops that seems like it may be stable at all points.

CAVEAT: This doesn't give any indication as to why we weren't able to turn up the AO gain more last night, as far as I can tell, so it's not all good news. 

However, it's still ok to at least have a plan that works in simulation... 

Based on the location of the optical resonance peak in the CARM plant, we estimate our CARM offset to be 200pm. I haven't simulated TFs there exactly, but do have 100pm and 300pm TFs. This procedure works in MATLAB starting at either, though 100pm is a little nicer than 300. MATLAB data and code is attached in a zip. 

The steps below correspond to the attached figures: Bode plots and step response of the Loop at each step. 


0. [Not Plotted] DCTrans sensing, MCL actuation on CARM. FMs1,2,3,5,8; UGF = 120. (DARM not considered at all)

  1. AO path just turned on. Crossover with MCL path ~ 3.5kHz. 
  2. AO gain increased. Crossover ~ 500 Hz. There are now multiple UGFs! Handling all of these in a stable manner is tricky. 
  3. AO gain increased. Crossover = 150Hz. [No simulations with a higher crossover survived the next steps]
  4. Compensation filter applied to MCL path; 1 real Zero at 105Hz and a pole at 1k. From a TF point of view, this is sort of like switching to REFLDC, but the SNR at low frequencies is probably better in TR signals at this point. 
  5. CARM offset reduced to 30pm. (This smoothens out the optical plant resonance.)
  6. Overall gain increased by factor of 3. There is now just one UGF at a few kHz, above the optical resonance. From here, gain can be further increased, boosts can go on, offset can go way down. In reality, we should switch to a single error signal once we're back to one UGF, and go from there. 

AOtransitionBodes.pdfAOtransitionSteps.pdf


#4 Seems like the most sticky part. While both sides of this look stable as far as I can tell. I feel that flipping from the red phase curve to the teal might not actually be ok, since they are on either side of the bad phase of 0 degrees. It isn't immediately evident to me how to easily model the transitions between steps, rather than just the stability of of each step in the steady state. 

  9958   Thu May 15 15:10:02 2014 SteveUpdatePEMseismic activities

Our only seismometer is at the east end now.

Atm1, Ditch Day morning puzzle. The gardener came after the freshman did leave and cut the grass with the lawn mower.

Atm2, Yesterday afternoon the Aztecs containers moved out.

  9957   Thu May 15 02:52:51 2014 JenneUpdateLSCStarted engaging the AO path, not getting all the way yet

 

 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.

  9956   Thu May 15 02:32:01 2014 JenneUpdateLSCStarted engaging the AO path, not getting all the way yet

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"). 

TFSR785_15-05-2014_011008.pdf

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.

  9955   Thu May 15 01:42:07 2014 ranaUpdateCDS/frames space cleared up, daqd stabilized

 Script seems to be working now:

nodus:~>df -h | grep frames

fb:/frames              13T    12T   931G    93%    /frames

  9954   Wed May 14 17:36:32 2014 ericqUpdateCDSNew netgpib scripts for SR785

 I have redone the SPSR785 (spectrum measurement) and TFSR785 (TF measurement) commands in scripts/general/netgpibdata. This was mostly motivated by my frustration with typing out either a ton of command line arguments, or rooting around in the script itself; I'd rather just have a static file where I define the measurement, and can keep track of easier. 

They currently take one argument: a parameter file where all the measurement details are specified. (i.e. IP address, frequencies, etc.) There are a few template files in the same directory that they use as default. (Such as TFSR785template.yml)

If you call the functions with the option '--template', it will copy a template file into your working directory for you to modify as you wish. "SPSR785 -h" gives you some information as well (currently minimal, but I'll be adding more)

In the parameter file, you can also ask for the data to be plotted (and saved as pdf) when the measurement is finished. In SPSR785, and soon TFSR785, you can specify a directory where the script will look for reference traces to plot along with the results, presuming they were taken with the same measurement parameters and have the same filename stem. 

I've tested both on Pianosa, and they seem to work as expected. 

Todo:

  • Add support for modifying some parameters at the command line 
  • Extend to the Agilent analyzer
  • Maybe the analyzer settings written to the output file should be verified by GPIB query, instead of writing out the intended settings. (I've never seen them go wrong, though)
  • Make sure that the analyzer has PSD units off when taking a TF. (Thought I could use resetSR785 for this, but there's some funkiness happening with that script currently.)
  • Possibly unify into one script that sees what kind of analyzer you're requesting, and then passes of to the device/measurement type specific script, so we don't have to remember many commands. 

Comments, criticism, and requests are very welcome. 

(P.S. all the random measurement files and plots that were in netgpibdata are now in netgpibdata/junk. I feel like this isn't really a good place to be keeping data. Old versions of the scripts I changed are in netgpibdata/oldScripts)

  9953   Wed May 14 14:39:31 2014 JenneUpdateSUSNew buttons on IFO_ALIGN screen

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.

Screenshot-Untitled_Window.png

  9952   Wed May 14 10:04:06 2014 SteveSummarySUS oplev laser and temperature

 ETMX oplev qpd gain has to be increased.

 

  9951   Wed May 14 02:37:58 2014 JenneUpdateLSCNo big locking news

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.

  9950   Tue May 13 22:55:57 2014 JenneSummarySUSETMX oplev: cleanup

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.

  9949   Tue May 13 17:45:21 2014 ranaUpdateCDS/frames space cleared up, daqd stabilized

 

 Late last night we were getting some problems with DAQD again. Turned out to be /frames getting full again.

I deleted a bunch of old frame files by hand around 3AM to be able to keep locking quickly and then also ran the wiper script (target/fb/wiper.pl).

controls@pianosa|fb> df -h; date

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda1             440G  9.7G  408G   3% /

none                  7.9G  288K  7.9G   1% /dev

none                  7.9G  464K  7.9G   1% /dev/shm

none                  7.9G  144K  7.9G   1% /var/run

none                  7.9G     0  7.9G   0% /var/lock

none                  7.9G     0  7.9G   0% /lib/init/rw

none                  440G  9.7G  408G   3% /var/lib/ureadahead/debugfs

linux1:/home/cds      1.8T  1.4T  325G  82% /cvs/cds

linux1:/ligo           71G   18G   50G  27% /ligo

linux1:/home/cds/rtcds

                      1.8T  1.4T  325G  82% /opt/rtcds

fb:/frames        13T   12T  559G  96% /frames

linux1:/home/cds/caltech/users

                      1.8T  1.4T  325G  82% /users

Tue May 13 17:35:00 PDT 2014

Looking through the directories by hand it seems that the issue may be due to our FB MXstream instabilities. The wiper looks at the disk usage and tries to delete just enough files to keep us below 95% full for the next 24 hours. If, however, some of the channels are not being written because some front ends are not writing their DAQ channels to frames, then it will misestimate the disk size. In particular, if its currently writing small frames and then we restart the mxstream and the per frame file size goes back up to 80 MB, it can make the disk full.

For now, I have modified the wiper.pl script to try to stay below 93%. As you can see by the above output of 'df', it is already above 96% and it still has files to write until the next run of wiper.pl 7 hours from now at. at 6 AM.

IF we assume that its writing a 75MB file every 16 seconds, then it would write 405 GB of frames every day. There is 559 GB free right now so we are OK for now. With 405 GB of usage per day, we have a lookback of ~12TB/405GB ~ 29 days (ignoring the trend files).

  9948   Tue May 13 17:31:32 2014 JenneSummarySUSETMX oplev laser replaced: New oplev gains set

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.

OLerr_13May2014.pdf

OLfb_13May2014.pdf

  9947   Tue May 13 17:03:05 2014 SteveSummarySUSETMX oplev laser replaced

Quote:

Quote:

For some reason or another, I decided that we should see if the optical lever servos were injecting too much noise into the test masses. The ITMs are much worse than the ETMs and I am afeared that they might be making the main noise for our arms in the 20-40 Hz region. Jenne is checking up on these feedback loops to see what's up.

To estimate the actuator gains of the mirrors, I turned on 1 count drives from LSC/CAL oscillators into the LSC drives of each test mass at the frequencies shown in the plot with the resulting peaks showing up in in POX/Y with the single arm locks in red. I will leave these going permanently, but with 0.1 count ampltiudes; we need to make it so in the scripts.

 I'm in the process of filling this table

OPLEV

SERVO     

300 ^

2:0

BR ELP RLP BOOST RES

GAIN

QPD

COUNTS

 

QPD

mW

QPD

beam

OD

HE/NE

output

mW

%

back

on QPD

                                
ETMY PIT  FM1  FM5    55      -30 8,200 0.2   3.3  
        YAW  FM1  FM5    55      -28          
ETMX PIT  FM1  FM5  35        4.4 900 0.2   1.7  
       YAW  FM1  FM5  35       2.1  1,750  0.33    2.8  
ITMY PIT  FM1  FM5        3.3   52 14,400 0.4   9.5  
      YAW  FM1  FM5        3.3  -46          
ITMX PIT  FM1  FM5  50      3.3   30 7,400 0.17   2.8  
       YAW  FM1  FM5  50      3.3  -20          
BS  PIT  FM1  FM5  35      3.3   9 2,800 0.05   2.8  
    YAW  FM1  FM5  35      3.3  -9          
PRM  PIT FM1  FM5  55   FM7  3.3  7 3200 0.06   2.8  
       YAW FM1  FM5  55   FM7  3.3  -5          
SRM  PIT  FM1            -20       9.5  
       YAW  FM1            20          

 I should replace ETMX He/Ne laser

 

  9946   Tue May 13 13:27:58 2014 SteveSummarySUSOptical Lever Servos setting table

Quote:

For some reason or another, I decided that we should see if the optical lever servos were injecting too much noise into the test masses. The ITMs are much worse than the ETMs and I am afeared that they might be making the main noise for our arms in the 20-40 Hz region. Jenne is checking up on these feedback loops to see what's up.

To estimate the actuator gains of the mirrors, I turned on 1 count drives from LSC/CAL oscillators into the LSC drives of each test mass at the frequencies shown in the plot with the resulting peaks showing up in in POX/Y with the single arm locks in red. I will leave these going permanently, but with 0.1 count ampltiudes; we need to make it so in the scripts.

 I'm in the process of filling this table

OPLEV

SERVO     

300 ^

2:0

BR

16,24

Hz

ELP RLP BOOST RES

GAIN

QPD

COUNTS

 

QPD

mW

QPD

beam

OD

HE/NE

output

mW

%

back

on QPD

                                
ETMY PIT  FM1  FM5    55      -30 8,200 0.2   3.3  
        YAW  FM1  FM5    55      -28          
ETMX PIT  FM1  FM5  35        4.4 900 0.2   1.7  
       YAW  FM1  FM5  35        2.1          
ITMY PIT  FM1  FM5        3.3   52 14,400 0.4   9.5  
      YAW  FM1  FM5        3.3  -46          
ITMX PIT  FM1  FM5  50      3.3   30 7,400 0.17   2.8  
       YAW  FM1  FM5  50      3.3  -20          
BS  PIT  FM1  FM5  35      3.3   9 2,800 0.05   2.8  
    YAW  FM1  FM5  35      3.3  -9          
PRM  PIT FM1  FM5  55   FM7  3.3  7 3200 0.06   2.8  
       YAW FM1  FM5  55   FM7  3.3  -5          
SRM  PIT  FM1            -20       9.5  
       YAW  FM1            20          

 I should replace ETMX He/Ne laser

  9945   Tue May 13 03:30:10 2014 JenneUpdateLSCLocking activities - no progress

[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.

ALS_outofloop.pdf


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. 

  9944   Tue May 13 00:46:58 2014 ranaHowToPSLPMC relocking

The PMC runs out of range sometimes due to the daily temperature swing. The voltage swings up after sunset and then starts to swing down before sunrise. So when you relock the PMC at the beginning of the locking night, the mnemonic from the PMC is:

Sun Go Low, Lock Me Voltage Low.

  9943   Mon May 12 22:52:59 2014 JenneSummarySUSOptical Lever Filters are all different

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.

OpLevFilters.pdf

  9942   Mon May 12 22:42:19 2014 ranaSummarySUSOptical Lever QPD Sum trends: they're almost all too weak

For some reason or another, I decided that we should see if the optical lever servos were injecting too much noise into the test masses. The ITMs are much worse than the ETMs and I am afeared that they might be making the main noise for our arms in the 20-40 Hz region. Jenne is checking up on these feedback loops to see what's up.

To estimate the actuator gains of the mirrors, I turned on 1 count drives from LSC/CAL oscillators into the LSC drives of each test mass at the frequencies shown in the plot with the resulting peaks showing up in in POX/Y with the single arm locks in red. I will leave these going permanently, but with 0.1 count ampltiudes; we need to make it so in the scripts.

  9941   Mon May 12 14:42:25 2014 steveUpdateendtable upgradeoptical table enclosure wall proposal and table at ETMY

Quote:

 Sanwiched wall as shown: 1" clear acrylic, 2 layers of 0.004" thick "window tint", 1 layer of  0.007" thermashield  and  0.125" yellow acrylic

Visibility: 70 %,    Transmission of 1064 nm  2-3 % at 0-50 degrees incident,   power density  ~ 0.7 W/mm2

Max power 100 mW

        

More details about this east end  " acrylic + "   enclosure ( optical table cover ) can be found elog entry 6210, 7194 and  7106

 

Window tinted layer transmission plot is below.

 

We have a film which may meet your requirements and the values are shown below:

         

               Wavelength (nm)              Transmission                     Reflectance(front)            Reflectance (back)

 

                        1060                               .0772                               .604                                     .759

 

                        1070                               .0723                               .615                                     .772

 

These values are taken from the LBNL Optics 6 program and if you have access to that program, the NFRC ID for the film is 202.   If you do not have access to the program, I have a captured the graph which may be of some help.  I apologize for the appearance of the graph but someone at LBNL decided it would look better with a dark gray background – the yellow is the transmission curve, the blue is the reflectance (front) and the green is the reflectance (back).

 

 

The film is referred to as “Hilite 70” and has a 72% visible light transmission.  These results were obtained with the film mounted on 1/8” clear glass.

 

I

 

 

 

 

 

Saint-Gobain Performance Plastics

www.solargard.com

 

Please consider your environmental responsibility before printing this email.

 

 

 

  9940   Mon May 12 10:42:01 2014 ranaUpdateSUSsome Arm maintenance

I ran the ASS/ADS for the arms because the X-arm was way out. There was also some problem with its locking due to bad ramps in FM2. I copied over the filters from YARM and then adjusted some of the ramps and thresh trigs in the filter file until the transients in POX got smaller. Basically, you should not really be ramping on Integrators. Secondly, we should do some testing when adjusting the filter parameters.

I hooked up the 4395 to the MC servo board OUT2 so that we can monitor the error point when the PCDRIVE goes nuts.

  9939   Fri May 9 21:18:51 2014 KojiUpdateGreen LockingReverted X green light power

It is actually very tricky to measure the green power at the output of the doubling crystal as the IR often leaks into the measurement.
I checked the green beam powers on the X/Y/PSL tables.

CONCLUSION: There is no green beam which exceeds 5mW anywhere in the 40m lab.

Note: The temperature of the doubling crystal at the X end was optimized to have maximum green power. It was 36.3degC and is now 36.7degC.

X END:

When the angles of the wave plates are optimized, we have 539mW input to the doubling crystal.
With the Xtal temperature of 36.7degC, where the green power is maximized, the power right after
the harmonic separator (H.S.) was 9.6mW.

Xtal temp 36.7degC   ~~~
                      |

--539mW@IR-->{Xtal}-->/-->9.6mW-->{Mirror}-->4.69mW-->{Mirror}-->4.54mW-->{Faraday}
                    (H.S.)

If we believe these 4.69mW and 4.54mW are purely from the green, we have 4.8mW right after the H.S.
This corresponds to the conversion efficiency of 1.6%/W (cf. theretical number 2%/W)

By disabling the heating of the crystal, we can reduce the green light by factor of 60. But still the reading right after the H.S. was 5.3mW

Xtal temp 29.2degC   ~~~
                      |
--539mW@IR-->
{Xtal}-->/-->5.3mW-->{Mirror}-->285uW-->{Mirror}-->74.3uW-->{Faraday}
                    (H.S.)

Naively taking the difference, the green beam right after the H.S. is 4.4mW.

In either cases, the green power right after the oven is slightly less than 5mW.

Y END:

When the angles of the wave plates are optimized, we have 287mW input to the doubling crystal.
With the Xtal temperature of 36.0degC, where the green power is maximized, the power right after
the harmonic separator (H.S.) was 0.86mW.

Xtal temp 36.0degC   ~~~
                      |

--287mW@IR-->{Xtal}-->/-->0.86mW-->
                    (H.S.)

When the temperature was shifted to 39.2degC, the reading after the H.S. was 70uW. Therefore the contamination by the IR is small
in this setup and we can believe the above reading in 70uW accuracy. This 0.86mW corresponds to the conversion efficiency of 1.2%/W.

PSL

The incident IR is 80mW. We have 170uW after the H.S., which corresponds to the conversion efficiency of 2.6%/W. Maybe there is some IR contamination?
From the vacuum chamber total 1mW of green is derivered when both arms are locked and aligned.

Thus the total green power at the PSL table is less than 5mW.

  9938   Fri May 9 14:01:24 2014 JenneUpdateLSCCM board boost turn-on checkout

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.

SuperBoosts.PNG

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:

AOgain_0dBto1dB.PNG

Next, 1dB to 2dB:

AOgain_1dBto2dB.PNG

2dB to 3dB:

AOgain_2dBto3dB.PNG

3dB to 4dB:

AOgain_3dBto4dB.PNG

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:

AOgain_5dBto6dB.PNG

7dB to 8dB:

AOgain_7dBto8dB.PNG

9dB to 10dB:

AOgain_9dBto10dB.PNG

11dB to 12dB:

AOgain_11dBto12dB.PNG

13dB to 14dB:

AOgain_13dBto14dB.PNG

15dB to 16dB:

AOgain_15dBto16dB.PNG

17dB to 18dB:

AOgain_17dBto18dB.PNG

19dB to 20dB:

AOgain_19dBto20dB.PNG

21dB to 22dB:

AOgain_21dBto22dB.PNG

23dB to 24dB:

AOgain_23dBto24dB.PNG

25dB to 26dB:

AOgain_25dBto26dB.PNG

27dB to 28dB:

AOgain_27dBto28dB.PNG

29dB to 30dB:

AOgain_29dBto30dB.PNG

  9937   Fri May 9 11:23:11 2014 steveUpdateGreen Lockingdecreased X green light power

Green light power decreased from 3 mW to 1 mW at the ETMX-ISCT shutter. More later.

  9936   Fri May 9 04:51:13 2014 ericqSummaryLSCREFL_DC handoff didn't work last night

Quote:

Last night after checking cabling and turning on ISS, we tried several times to handoff to REFL_DC but it didn't work at all.

Some issues:

  1. The ISS was injecting a lot of very low frequency power fluctuations because of bad AC coupling.
  2. The SR560 @ LSC rack was saturating a lot with the x10 gain that Jenne and Rana put in; we turned it back to G = 1.
  3. The ISS was also saturating a lot. We turned it off around 4 AM, but still no success.
  4. The ALS sequence for finding the Red Resonance takes too long (~2 minutes), so we're trying a faster scheme tonight.

 Still no success tonight

  • We took CARM OLTFs at various CARM offsets and could clearly see the peak in the optical TF (in once case ~2.5kHz), which gave us an indication of our offset (~200pm)
  • REFLDC effectively sees the same plant TF as the transmission signals plus a zero at ~110 Hz, at all offsets under 1nm, from my simulations; this pushes up the optical resonance and causes a loop instability when we try to handoff. 
  • We need to make the CARM OLTF steeper to suppress this instability, but also to make a good crossover with the AO path, which otherwise has too similar of a slope around the UGF, as we saw with our one arm test. 
  • We're thinking of trying to turn the AO path on with REFLDC while keeping the arms on SQRTINV signals. This may be tricky, but if we can get the loop bandwidth above the optical peak, it'll be a lot easier to deal with, and transfer digital control to REFLDC as well. 
  9935   Fri May 9 04:09:39 2014 JenneUpdateLSCCM board boost turn-on checkout

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.

  9934   Fri May 9 01:36:28 2014 ranaSummarySUSOptical Lever QPD Sum trends: they're almost all too weak

 We want there to be ~16000 cts of signal per quadrant on the optical levers. I think that most of the QPDs have been modified to have 100k transimpedance resistors.

From the attached 90 day trend, you can see that the ETMX, BS, PRM, and SRM are really low. We should figure out if we need to change the lasers or if the coating reflectivities are just low.

Steve, can you please measure the laser powers with a power meter and then reply to this entry?

Another possibility is that we are just picking a dim beam and a brighter one is available.

  9933   Thu May 8 17:25:17 2014 steveUpdateLSCTRY 60Hz noise hunt

 I worked at the ETMY-ISCT this morning and late afternoon.  I will continue the 60 Hz noise hunt tomorrow. 

  9932   Thu May 8 17:00:56 2014 rana, QSummaryLSCREFL_DC handoff didn't work last night

Last night after checking cabling and turning on ISS, we tried several times to handoff to REFL_DC but it didn't work at all.

Some issues:

  1. The ISS was injecting a lot of very low frequency power fluctuations because of bad AC coupling.
  2. The SR560 @ LSC rack was saturating a lot with the x10 gain that Jenne and Rana put in; we turned it back to G = 1.
  3. The ISS was also saturating a lot. We turned it off around 4 AM, but still no success.
  4. The ALS sequence for finding the Red Resonance takes too long (~2 minutes), so we're trying a faster scheme tonight.
  9931   Thu May 8 15:55:43 2014 jamieUpdateCDSpython issues

Quote:

On pianosa: The ezca.Ezca class somehow initializes with its prefix set to "C1:", even though the docstring says the default is None. This makes existing scripts act wonky, because they're looking for channels like "C1:C1:FO-BLAH".

In ligo/apps/linux-x86_64, I ran ln -sfn cdsutils-old cdsutils to get the old version back for now, so I don't have to edit all of our up/down scripts.

Also, Chiara can't find the epics package when I try to load Ezca. It exists in '/usr/lib/pymodules/python2.6/epics/__init__.pyc' on pianosa, but there is no corresponding 2.7 folder on chiara.

I just pushed a fix to ezca to allow for having a truly empty prefix even if the IFO env var is set:

controls@pianosa:~ 0$ ipython
Python 2.6.5 (r265:79063, Feb 27 2014, 19:43:51) 
Type "copyright", "credits" or "license" for more information.

IPython 0.10 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

In [1]: import ezca

In [2]: ezca.Ezca()
Out[2]: Ezca(prefix='C1:')

In [3]: ezca.Ezca(ifo=None)
Out[3]: Ezca(prefix='')

In [4]: ezca.Ezca(ifo=None).read('C1:LSC-DARM_GAIN')
Out[4]: 0.0

This is in cdsutils r232, which I just installed at the 40m.  I linked it in as well, so it's now the default version.  You will have to make a modification to any python scripts utilizing the Ezca object, but now it's a much smaller change (just in the invocation line):

-ca = ezca.Ezca()
+ca = ezca.Ezca(ifo=None)

 

  9930   Thu May 8 14:37:02 2014 JenneUpdateASCPOP ASC QPD power

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.

  9929   Thu May 8 02:03:51 2014 ranaUpdateISSISS: fuse was blown, repaired, loop back on

Back in November, Nic and Evan turned on an SR560 based ISS. It uses the PMC TRANS PD as the error signal and makes an AC coupled loop with 2 SR560's and then it drives the RF amplifier which drives the AOM upstream of the PMC.

This was the saturating SR560 under the PSL table that Steve found this week*. Tonight I found that the +24 V rack fuse for this was blown. I replaced the previous 2A fuse with a new 2A fuse (turned off the +/24 V Sorensens during this operation). I think all of the servo settings are basically the same as before, except that I'm using a gain of 10000 instead of 50000 on the first SR560. It was saturating otherwise. My guess is that the fuse blew many months ago and no one has noticed...

 I checked the out of loop performance in MC_TRANS and in the IFO REFL_DC and there's some high frequency improvement with the loops on.

The main improvement, however, was in lowering the HEPA fan speed. This should only be turned up to Hurricane when you are working on the table. Similarly, those of us trying to lock at night, can't really trust that the HEPA is set to its nominal low setting of 20%. The whole difference in the MC_TRANS from 5-50 Hz is from this however, so we can use this ISS reference .xml as a way to see if the HEPA is up too high.

If we want to do better for RIN from 100-1000 Hz for improving the REFL_DC/CARM noise, we would have to think of how to improve the PMC_TRANS PD RIN.

 

* Steve gets +1 point for finding this, but then -3 points for not elogging.

  9928   Thu May 8 01:33:21 2014 ericqUpdateCDSpython issues

On pianosa: The ezca.Ezca class somehow initializes with its prefix set to "C1:", even though the docstring says the default is None. This makes existing scripts act wonky, because they're looking for channels like "C1:C1:FO-BLAH".

In ligo/apps/linux-x86_64, I ran ln -sfn cdsutils-old cdsutils to get the old version back for now, so I don't have to edit all of our up/down scripts.

Also, Chiara can't find the epics package when I try to load Ezca. It exists in '/usr/lib/pymodules/python2.6/epics/__init__.pyc' on pianosa, but there is no corresponding 2.7 folder on chiara.

 

  9927   Thu May 8 00:40:39 2014 ericqUpdateLSCBNC vs. 2pin LEMO for AO

 I've checked that the 2pin lemo connector that was run some time ago from the LSC rack to the MC board does indeed transmit signals. To try and evaluate its suitability I did the following:

  • Generated a 5mVpp 1.3kHz signal with an SR785 and fed that into CM board In1, all boosts off, 0dB AO gain. 
  • Both BNC and LEMO connected to CM servo out
  • One of BNC or LEMO connected to IN2 of MC servo, input gain of 30dB but disabled, OUT2 switched to AO and fed to Agilent spectrum analyzer. 
  • Terminated MC IN2 for comparison. 

No real difference was seen between the two cases. The signal peak was the same height, width. 60Hz and harmonics were of the same amplitude. Here are the spectra out to 200k, they are very similar. 

AOcablesWide.pdf

Mode cleaner was locked during this whole thing. This may interfere with the measurement, but is similar to the use case for the AO path. If ground loop / spurious noise issues keep occurring, it will be worthwhile to examine the noise of the CM and MC servo paths, inputs and outputs more carefully. 

  9926   Wed May 7 23:30:21 2014 jamieUpdateCDScdsutils should be working now

Should be fixed now.  There were python2.6 compatibility issues, which only show up on these old distros (e.g. ubuntu 10.04).

controls@pianosa:~ 0$ cdsutils read C1:LSC-DARM_GAIN
0.0
controls@pianosa:~ 0$ cdsutils --version
cdsutils 230
controls@pianosa:~ 0$ 
  9925   Wed May 7 23:09:06 2014 rana, jamieSummaryComputer Scripts / ProgramsOttavia back on network

After Jamie fixed the third party repo issue with Ottavia, he was able to upgrade it to Ubuntu 12.04 Precise Pangolin. But its network stopped working.

I tried to fix its issues by ifconfig and GUI, but what it really wanted was for me to put the network cable back into its eth0 slot. The eth1 network card appears not be working anymore.

All seems fine now. Next I will mount the shared user disk from linux1 and put in a .bashrc.

  9924   Wed May 7 22:47:33 2014 ranaUpdateCDScdsutils updated to version 226: not working on pianosa or rossa

 controls@rossa:~ 0$ cdsutils read C1:LSC-DARM_GAIN
Traceback (most recent call last):
  File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
    exec code in run_globals
  File "/ligo/apps/cdsutils-226/lib/python2.6/site-packages/cdsutils/__main__.py", line 57, in <module>
    imp.load_module('__main__', f, pathname, description)
  File "/ligo/apps/cdsutils-226/lib/python2.6/site-packages/cdsutils/read.py", line 32, in <module>
    print ezca.Ezca(prefix).read(rest, as_string=args.as_string)
  File "/ligo/apps/linux-x86_64/cdsutils-226/lib/python2.6/site-packages/ezca/cached.py", line 17, in __call__
    key = (args, tuple(kwargs.viewitems()))
AttributeError: 'dict' object has no attribute 'viewitems'

  9923   Wed May 7 17:10:59 2014 ranaUpdateCDScdsutils updated to version 226

 This upgrade from Jamie has given us the new apps (avg, servo, and trigservo). We should figure out if there's a way to integrate Masayuki's work, so that we can have a 'cdsutils demod' function too.

ELOG V3.1.3-