[Diego, Jenne, Eric]

Tonight we kept on following our current strategy for locking the PRFPMI:

• the first few tries were pretty unsuccessful: the PRMI lock wasn't much stable, and we never managed to reduce CARM offset to zero before losing lock;
• then we did some usual manteinance: we fixed the X arm green beatnote, fixed the phase tracker and given much attention to ASS alignment, since the X arm wasn't doing great;
• the last few locks were consintently better: we managed to get to CARM offset zero "easily", but the arm power was not very high (~8);
• then we tried to transition CARM to REFL11, both with the usual configuration and using CM_SLOW, using REFL11 as input for the Common Mode Board;
  • with the usual configuration, we lost lock right after the transition, because of MICH hitting the rail;
  • we did a very smooth CARM transition directly to REFL11 on the CM_SLOW path; we managed to take a spectrum with the SR785, but we couldn't take any more measurements before losing lock because of some weird glitch, as we can see from the lockloss plot;
• another thing that helped tonight was changing the ELP of the MICH filter bank: it went from 4th order to 6th order, and from 40 dB suppression to 60 dB suppression;

both of the last two locks, the most stable ones (one transition to usual REFL11 and one transition to "CM_SLOW" REFL11) were acquired actuating on MC2;

EDITs by JCD:  At least one of the times that we lost PRMI lock (although kept CARM and DARM lock on ALS), was due to MICH hitting the rail, even after we increased the limiter to 15,000 counts.

 Here is the transfer function between CARM ALS (CARM_IN1) and REFL11 coming through the CM board (CARM_B), just before we transitioned over.  Coherence was taken simultaneously as usual, I just printed it to another sheet.

CARM_3Feb2015_CarmBwasCMslow_CarmAwasLiveALS.pdf

CARM_3Feb2015_CarmBwasCMslow_CarmAwasLiveALS_Coh.pdf

Here is the lockloss plot for the very last lockloss.  This is the time that we were sitting on REFL11 coming through the CM_SLOW path.  A DTT transfer function measurement was in progress (you can see the sine wave in the CARM input and output data), but I think we actually lost lock due to whatever this glitch was near the right side of the plots.  This isn't something that I've seen in our lockloss plots before.  I'm not sure if it's coming from REFL11, or the CM board, or something else.  We know that the CM board gives glitches when we are changing gain settings, but that was not happening at this time.

Q: Here's the SR785 TF of CARM locked through CM board, but still only digital control; nothing exciting. Excitation amplitude was only 1mV, which explains the noisy profile. 

[Diego, Eric]

Tonight was a sad night... We continued to pursue our strategy, but with very poor results:

• before doing anything, we made sure we had a good initial configuration: we renormalized the arm powers, retuned the X arm green beatnote, did extensive ASS alignment;
• since the beginning of the night we faced a very uncooperative PRMI, which caused a huge number of locklosses, often just by itself, without even managing to reduce the MICH offset before reducing the CARM one;
• we had to reduce the PRCL gain to -0.002 in order to acquire PRMI lock, but keeping it such or restoring it to -0.004 once lock was acquired either didn't improve the PRMI stability at all;
• we also tweaked a bit the PRCL and MICH UGF servos (namely, their frequencies to ~80 Hz and ~40 Hz respectively) and that seemed to help earlier during the night, but not much longer;
• we only managed to transition CARM to REFL11 via CM SLOW twice;
  • the first time we lost lock almost immediately, probably because of a non-optimal offset between CARM A and B;
  • the second time we managed to stay there a little longer, but then some spike in the PRCL loop and/or the MICH loop hitting the rails threw us out of lock (see the lockloss plot);
  • both times we transitioned at arm power ~18;
• during the night we used an increased analog ASDC whitening gain, as from Eric's elog here http://nodus.ligo.caltech.edu:8080/40m/10972 ; even with this fix, though, MICH is still often hitting the rails and causing the lock losses;
• the conclusion for tonight is that we need to figure what is going on with the PRMI...

[Diego, Jenne]

We kept struggling with the PRMI, although it was a little better than yesterday:

• we retuned the X Green beatnote;
• we managed to reach lower CARM offsets than yesterday night, but we still can't keep lock long enough to perform a smooth transition to CM SLOW/REFL11;
• we tweaked MICH a bit:
  • the ELP in FM8 now is always on, because it seems to help;
  • we tried using a new FM1 1,1:0,0 instead of FM2 1:0 because we felt we needed a little more gain at low frequencies, but unfortunately this didn't change much MICH's behaviour;
  • now, after catching PRMI lock, the MICH limiter is raised to 30k (in the script), as a possible solution for the railing problem; the down/relock scripts take care of resetting it to 10k while not locked/locking;

So, still no exciting news, but PRMI lock seems to be improving a little.

I forgot to elog about these ones, my bad... The new/updated laptops are giada, viviana and paola; paola is already in the lab, while giada and viviana are in the control room waiting for a new home. The Pool of Names Wiki page has already been updated to reflect the changes.

I wrote the script with the recipe we used, using the Yarm and AS55 on the IN2 of the CM board; however, the steps where the offset should be reduced are not completely deterministic, as we saw that the initial offset (and, therefore, the following ones) could change because of different states we were in. In the script I tried to "servo" the offset using C1:LSC-POY11_I_MON as the reference, but in the comments I wrote the actual values we used during our best test; the main points of the recipe are:

• misalign the Xarm and the recycling mirrors;
• setting up CARM_B for POY11 locking and enabling it;
• setting up CARM_A for CM_SLOW;
• setting up the CM_SLOW filter bank, with only FM1 and FM4 enabled;
• setting up the CARM filter bank: FM1 FM2 FM6 triggered, only FM3 and FM5 on; usual CARM gain = 0.006;
• setting up CARM actuating on MC2;
• turn off the violin filter FM6 for MC2;
• setting up the default configuration for the Common Mode Servo and the Mode Cleaner Servo; along with all the initial parameters, here is where the initial offset is set;
• turn on the CARM output and, then, enable LSC mode;
• wait until usual POY11 lock is acquired and, a bit later, transition from CARM_B to CARM_A;
• then, the actual CM_SLOW recipe:
  • CM_AO_GAIN = 6 dB;
  • SUS-MC2_LSC FM6 on (the 300:80 filter);
  • CM_REFL2_GAIN = 18 dB;
  • servo CM_REFL_OFFSET;
  • CM_AO_GAIN = 9 dB;
  • CM_REFL2_GAIN = 21 dB;
  • servo CM_REFL_OFFSET;
  • CM_REFL2_GAIN = 24 dB;
  • servo CM_REFL_OFFSET;
  • CM_REFL2_GAIN = 27 dB;
  • servo CM_REFL_OFFSET;
  • CM_REFL2_GAIN = 31 dB;
  • servo CM_REFL_OFFSET;
  • CM_AO_GAIN = 6 dB;
  • SUS-MC2_LSC FM7 on (the :300 compensating filter);

I tried the procedure and it seems fine, as it did during the tries Q and I made; however, since it touches many things in many places, one should be careful about which state the IFO is into, before trying it.

The script is in scripts/CM/CM_Servo_OneArm_CARM_ON.py and in the SVN.

I've turned off the power supply. I've attached a picture of the rack with the switch that I flipped circled

 Very nice error signal. Still, I think we need to take into account the frequency shape of the transfer function TR -> CARM. 

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.

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:

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

 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.

Tonight I have modified transition steps from als to pdh signals. I have added 1:20 filters to CARM_A and DARM_A filter banks to make them unconditionally stable. These filters made locking more robust -- duty cycle is was ~70% tonight. I have also modified slow/ao crossover to avoid ringing up of lines above 1kHz.

Once AO is engaged with high bandwidth, REFL55 signal looks good and I transition PRCL from 165I to 55I. Optical gain compared to PRMI reduced from 55I/165I = -330 down to 55I/165I = 30 in full lock.

I worked on alignment of ETMs. Looking on the cameras I could improve arm power up to 160 and ifo visibility was 80%. POP22 fluctuated by ~50% and every few minutes we loose lock because POP22 almost touches zero.

Tonight I measured seismic noise coupling to beam spot on PR2. There is coherence of 0.9 from X to PIT and Y to YAW around the stack resonances. TF was fited using vectfit and put into static matrix of oaf in the elements T240X -> PRM PIT, T240Y -> PRM YAW. I think we should actuate on the error point of the PRM OL but I decided not to go for a model change tonight. Data from seismometers and POP QPD was obtained during the UTC time 04:06:00 - 04:50:00 when PRMI was locked on sideband

Interferometer was locking rather robustly and every lock lasted on the everage of 3 minutes. During these lock periods I incresed bandwidth of optical lever servos of BS and test masses from 4Hz up to 10Hz and then closed transmission QPD loops. It seems from the camera that lock losses correspond to strong motion of the beam on pop camera. Scripts that change OPLEV bandwidth are in /users/den "increase_ol_bandwidth.sh" "decrease_ol_bandwidth.sh". Script "engage_qpd_servos" turns off ETM oplevs and turns on ETM -> trans QPD servos. These scripts can be copied to locking directrly if are useful.

Please, note that transition from 3f to 1f should still be tuned. Only PRCL was stably controlled using 1f so far

I was asked by Koji to point out where a schematic of the triple resonant circuit is.
It seems that I had posted a schematic of what currently is installed (see elog 4562 from almost 4 yrs ago!).

(Some transfomer story)
Then I immediately noticed that it did not show two components which were wideband RF transformers. In order to get an effective turns ratio of 1:9.8 (as indicated in the schematic) from a CoilCrfat's transformer kit in the electronics table, I had put two more transformers in series to a PWB1040L which is shown in the schematic. If I am not mistaken, this PWB1040L must be followed by a PWB1015L and PWB-16-AL in the order from the input side to the EOM side. This gives an impedance ratio of 96 or an effective turns ratio of sqrt(96) = 9.8.

(An upgrade plan document)

Also, if one wants to review and/or upgrade the circuit, this document may be helpful:
https://wiki-40m.ligo.caltech.edu/Electronics/Multi_Resonant_EOM?action=AttachFile&do=get&target=design_EOM.pdf
This is a document that I wrote some time ago describing how I wanted to make the circuit better. Apparently I did not get a chance to do it.

The periscope design for beam elevation of the green beams is posted. The design for the 90 deg steering version is also coming.

(2010-03-29: update drawings by daisuke)

90deg version: http://nodus.ligo.caltech.edu:8080/40m/2725

Here the design of the periscope for the 90 deg steering version is posted.

straight version http://nodus.ligo.caltech.edu:8080/40m/2709

I added lubricating oil to roughing pumps RP1 and RP3 yesterday and this morning.  Also, I found a nearly full 5 gallon jug of grade 19 oil in the lab.  This should set us up for quite a while.  If you need to add oil the the roughing pumps, use the oil in the quart bottle in the flammables cabinet.  It is labeled as Leybold HE-175 Vacuum Pump Oil.  This bottle is small enough to fill the pumps in close quarters.

For the sake of writing it down: /cvs/cds/caltech/apps/linux64/rockNDS

I have done the following on allegra and rosalba:

[root@allegra caltech]# yum install glade2

On rosalba the matplotlib was out of date with respect to allegra.  I have no idea how the version 0.98 on allegra got there, but I left it.  However I updated rosalba to the epel version

  1 yum remove python-numpy
  2 yum install python-matplotlib numpy scipy --enablerepo=epel --disablerepo=rpmforge

This is all to support the LIGO data listener which now has a shortcut on rosalba and allegra's desktop.  It seems to work for (live mode) right now.
 

So, near 2 of the trashcans in the control room and underneath a desk there are hundrends of ants. Is this normal?

Comparing  PSL-FSS-RMTEMP and PEM-MC1-TEMPS

So, to compare temp channels, I made a plot of PSL-FSS_RMTEMP and PEM-MC1_TEMPS(the test temp sensor channel after converting from cts to degC). This plot begins about 2 months ago t_initial=911805130. The temperature channels look kinda similar but MC1-TEMPS (the temp sensor clamped to MC1,3 chamber) is consistently higher in temperature than FSS_RMTEMP. See compare_temperature_channels.png.

MC1-TEMPS isn't exactly consistent with FSS-RMTEMP. I attached a few plots where I've zoomed in on a few hours or a few days. See compare_temperature_channels_zoom1.pdf & compare_temperature_channels_zoom2.pdf

Change the room temperature, see what happens to the chamber temperature

A while ago, somebody was fiddling around with the room temperature.  See compare_temperature_channels_zoom4.pdf.  This is a plot of PEM-MC1_TEMPS and PSL-FSS_RMTEMP at t0=911805130. You can see the chamber heating up and cooling down in happy-capacitory-fashion. Although, the PSL-FSS_RMTEMP and the PEM-MC1_TEMPS don't really line up so well. Maybe, the air in the location of the MC1,3 chamber is just warmer than the air in the PSL or maybe there's an offset in my calibration equation.

Calibration equation for PEM-MC1-TEMPS

For the calibration (cts to degC) I used the following equation based on the data-sheet for the LM34 and some measurements of the circuit:

TEMPERATURE[degC]=5/9*(((-CTS/16384/451.9/1.04094)-(.0499*10^-3))/(20*10^-6)-35);

How does the chamber temperature compare with the air temperature?

It looks like the chamber may be warmer than the air around it sometimes.

I wanted to check the temperature of the air and compare it with the temperature the sensor had been measuring. So, at t=918855087 gps, I took the temp sensor off of the mc1-mc3 chamber and let it hang freely, close to the chamber but not touching anything. See compare_temperature_chamber_air.png. MC1_TEMPS increases in temperature when I am handling the temp-sensor and then cools down to below the chamber temperature, close to FSS_RMTEMP, indicating the air temperature was less than the chamber temperature.

 When, I reattached temp sensor to the chamber at t=919011131 gps, the the temperature of the chamber was again higher than the temperature of the air. See compare_temperature_air2chamber.pdf.

Also, as one might expect, when the temp-sensor is clamped to the chamber, the temperature varies less, & when it's detached from the chamber, the temperature varies more. See compare_temperature_air_1day.pdf & compare_temperature_chamber_1day.pdf.

New temp-sensor power supply vs old temp-sensor power supply

The new temp-sensor is less noisy and seems to work OK. It's not completely consistent with PSL-FSS_RMTEMP, but neither was the old temp-sensor. And even the air just outside the chamber isn't the same temperature as the chamber. So, the channels shouldn't line up perfectly anyways.

I unplugged the 'old' temp-sensor power supply for a few hours and plugged in the 'new' one, which doesn't have a box but has some capacitors and and 2 more voltage regulators. The MC1_TEMPS channel became less noisy. See noisetime.png & noisefreq.pdf. For that time, the minute trend shows that with the old temp-sensor power supply the temp sensor varies +/-30cts and with the new power supply, it is more like +/-5cts (and Volt/16,384cts * 1degF/10mV -->  apprx +/-0.03degF). So, it's less noisy. 

I kept the new temp-sensor power supply plugged in for about 8 hours, checking if new temp sensor power supply worked ok. Compared it with PSL-FSS_RMTEMP after applying an approximate calibration equation. See ver2_mc1_rmtemp_8hr_appxcal.png.

Just for kicks

Measuring time constant of temp sensor when detached from chamber. At 918858981, I heated up the temp sensor on of the mc1-mc3 chamber with my hand. Took hand off sensor at  918859253 and let it cool down to the room temperature. See temperature_sensor_tau.pdf. 

I plugged the Guralp cables back into the PEM ADCU

       Guralp NS1b ---> #11

       Guralp Vert1b --->#10

       Guralp EW1b --->#12

For several of the channels on the PEM ADCU, zeros are occuring at the same time. Does anyone know why that might happen or how to fix it?

I unplugged Guralp EW1b and Guralp Vert1b and plugged in temp sensors temporarily. Guralp NS1b is still plugged in.