40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 150 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  9515   Thu Jan 2 13:35:06 2014 KojiUpdateVAC vacuum monitor is still blank

We probably need to restart the machine, but I didn't want to touch c1vac1 and c1vac2. 

  9514   Thu Jan 2 10:50:24 2014 SteveUpdateVAC vacuum monitor is still blank

 The date is correct on this monitor.

Last stored RGA scan data Dec 20, 2013

IFO pressure at CC1 5.8e-6 Torr

Valve configuration: Vacuum Normal, confirmable only by manual checking of position indicators and pressure gauge controllers  readouts

 

Attachment 1: Help.png
Help.png
Attachment 2: vacation.png
vacation.png
Attachment 3: 20131220lastRGAscan.png
20131220lastRGAscan.png
  9513   Thu Jan 2 10:15:20 2014 JamieSummaryGenerallinux1 RAID crash & recovery

Well done Koji!  I'm very impressed with the sysadmin skillz.

  9512   Wed Jan 1 15:01:29 2014 KojiSummaryGeneralIFO recovery

IFO restart after the recovery of linux1

Machine recovery in the following order
- Start fb
- Start the following machines: mafalda, megatron, op340m
- Start c1ioo, c1lsc, c1sus, c1iscex, c1iscey

CDS recovery / burtrestore

- Confirm all of the RT systems are running in "green". If not, restart corresponding model.
- c1iscaux, ciscaux2 didn't have response (white boxes). Went to the LCS digital rack and power cycled these targets
- burtrestore: The snapshots at Dec 19 05:07 were used. For c1iscaux and c1iscaux2 the snapshots at Dec 22 05:07 were used.

fast machines
c1alsepics.snap
c1assepics.snap
c1asxepics.snap
c1calepics.snap
c1iooepics.snap
c1lscepics.snap
c1lspepics.snap
c1mcsepics.snap
c1oafepics.snap
c1pemepics.snap
c1rfmepics.snap
c1scxepics.snap
c1scyepics.snap
c1spxepics.snap
c1supepics.snap
c1susepics.snap
c1tstepics.snap

slow machines
c1auxex.snap
c1auxey.snap
c1aux.snap
c1iool0.snap
c1iscaux2.snap
c1iscaux.snap
c1psl.snap
c1susaux.snap

 

IFO recovery

- Reload watchdogs => restore sus damping
- MC misaligned but TEM00 was locked
- Gave a small touch on MC2 yaw => IMC almost aligned
- Autolocker wasn't running => Manually launched rather than wait for an hour for cron to launch it
- PMC was largely misaligned. => Aligned on the PSL table (PSLTRANS 0.640->0.753)
- MC WFS ON
- IFO X/Y arm locked and aligned with ASS.
- PRMI mode: manually aligned PRM. The PRMIsb momentally locked.

  9511   Tue Dec 31 23:19:58 2013 KojiSummaryGenerallinux1 RAID crash & recovery

Dec 22 between 6AM and 7AM, physical or logical failure has occure on the 4th disk in the RAID array on linux1.
This caused the RAID disk fell into the readonly mode. All of the hosts dependent on linux1 via NFS were affected by the incident.

Today the system has been recovered. The failed filesystem was restored by copying all of the files (1.3TB total) on the RAID to a 2TB SATA disk.
The depending hosts were restarted and we recovered elog/wiki access as well as the interferometer control system.


Recovery process

o Recover the access to linux1

- Connect an LCD display on the host. The keyboard is already connected and on the machine.
- One can login to linux1 from one of the virtual consoles, which can be switched by Alt+1/2/3 ...etc
- The device file of the RAID is /dev/sda1
- The boot didn't go straightforward as mounting of the disks accoding to /dev/fstab doesn't go well.
- The 40m root password was used to login with the filesystem recovery mode.
- Use the following command to make the editing of /etc/fstab available

# mount -o rw, remount /

- In order to make the normal reboot successfull, the line for the RAID in /etc/fstab needed to be commented out.

o Connect the external disk on linux1

- Brought a spare 2TB SATA disk from rossa.
- Connect the disk via an USB-SATA enclosure (dev/sdd1)
- Mount the 2TB disk on /tmpdisk
- Run the following command for the duplication

# rsync -aHuv --progress /home/ /tmpdisk/ >/rsync_KA_20131229_0230.log

- Because of the slow SCSI I/F, the copy rate was limited to ~6MB/s. The copy started on 27th and finished 31st.

o Restart linux1

- It was found that linux1 couldn't boot if the USB drive is connected.
- The machine has two SATA ports. These two are used for another RAID array that is not actually used. (/oldhome)
- linux1 was pulled out from the shelf in order to remove the two SATA disks.
- The 2TB disk was installed on the SATA port0.
- Restart linux1 but didn't start as the new disk is recognized as the boot disk.
- The BIOS setting was changed so that the 80GB PATA disk is recognized as the boot disk.
- The boot process fell into the filesystem recovery mode again. /etc/fstab was modified as follows.

/dev/VolGroup00/LogVol00 /                ext3    defaults        1 1
LABEL=/boot              /boot            ext3    defaults        1 2
devpts                   /dev/pts         devpts  gid=5,mode=620  0 0
tmpfs                    /dev/shm         tmpfs   defaults        0 0
proc                     /proc            proc    defaults        0 0
sysfs                    /sys             sysfs   defaults        0 0
/dev/VolGroup00/LogVol01 swap             swap    defaults        0 0
#/dev/md0                 /oldhome         ext3    defaults        0 1
/dev/sda1                /home            ext3    defaults        0 1
#/dev/sdb1                /tmpraid         ext3    defaults        0 1

- Another reboot make the operating system launched as usual.

o What's happen to the RAID?

- Hot removal of the disk #4.
- Hot plug of the disk #4.
- Disk #4 started to get rebuilt -> ~3hours rebuilding done
- This made the system marked as "clean". Now the raid (/dev/sdb1) can be mounted as usual.


o Nodus

- Root password of nodus is not known.
- Connect an LCD monitor and a Sun keyboard on nodus.
- Type Stop-A. This leads the nodus transition to the monitor mode.
- Type sync.
- This leads the system rebooted.

  9510   Sat Dec 21 10:53:35 2013 SteveUpdateVACpower supply replaced with a short vent-pumpdown completed

The recovery- pumpdown reached valve configuration  vacuum normal at 20 hours, cc1 7.7e-6 Torr

Lesson learned: turn all pumps off, close all valves before you reboot ! like you would prepare for AC power shut down.

 

Attachment 1: 20hrsVacNormal.png
20hrsVacNormal.png
  9509   Sat Dec 21 01:54:04 2013 KojiConfigurationLSCLSC Whitening for the DCPDs/CM servo replaced

The previous LSC whitening filters for the DCPDs were in an unknown state (although the transfer functions were actually measured and fit a while ago)
They had no DC gain control and some of the channels had modifications.

To make the setup clear, the filter module was replaced with the spare module without any modification.

The channels are now respoding to the whitening gain switches. So far there is no screen for the new  whitening gains yet.

Also I found that POX11 DC cable has not been connected. Now it is connected.

  9508   Fri Dec 20 23:00:41 2013 KojiUpdateVACpower supply replaced with a short vent

I'm leaving the 40m now. IFO is aligned. Everything look good.

- The main volume P1=5e-4, CC1=1.4e-5 is still pumped by TP1 and TP2

- RGA P4<0e-4, CC4 2.1e-7, is pumped by TP3

- The annuluses are isolated.

- RP1/2/3 are off.

  9507   Fri Dec 20 22:45:02 2013 KojiUpdateLSChigh bandwidth loop achieved for yarm

I checked the offset situation in the CM servo boost circuit. 

- The offset voltage on the CM servo screen is a raw DAC output. This number is diluted by the voltage divider before the amplifier.
  So, the actual offset of the boost circuit was much smaller. (~20mV)

- There is a offset trimmer on the board. This was adjusted so that the boost does not generate an output offset.

- So the default offset is 0V.

- When the arm was locked with (digital) POY11, the CM servo offset is necessary to be -2.7 (now).
  This means that analog POY11Q and digital POY11 has different offset for the best resonance transmission.
  That is believable if POY11I is contributing to the digital POY11 signal.

  9506   Fri Dec 20 20:04:01 2013 SteveUpdateVACpower supply replaced with a short vent

Quote:

Quote:

Instrument rack power supplies checked and labeled at present loads.

The vacuum rack Sorensen is running HOT! Their is only 0.3A load at 24V There is plenty of space around it.

It is alarming to me because all vacuum valve positions are controlled by this 24V

 The temperature went down to room temp with temporary fan in the back. Voltage and current are stable.

Regardless, it will be replaced early next week.

Koji, Steve

 It was a bad experience again with our vacuum system.  The valves went crazy as we rebooted the computer. This was required for the swap in of a good 24V power supply.

The IFO was vented to 27 Torr through the annuloses, VA6, V7, Maglev,VM2 and VM1 (VC2 was open too)

I just opened the PSL shutter after a 4 hours pumpdown.

Condition: annuloses are not pumped, the IFO and the RGA are pumped as Atm2 shows

I will be here tomorrow morning to switch over to vacuum normal. 

More details later

 

 

Attachment 1: 4hrPumpdown.png
4hrPumpdown.png
Attachment 2: pumpdownAfterHickup.png
pumpdownAfterHickup.png
Attachment 3: PSpumpdown.png
PSpumpdown.png
  9505   Fri Dec 20 18:00:02 2013 KojiSummaryCDSRCG parsing bug?

The bug is still there but the incorrect bits are now overridden.

Attachment 1: Screenshot-c1lsc-LSC.png
Screenshot-c1lsc-LSC.png
  9504   Fri Dec 20 17:41:25 2013 SteveUpdateGeneralProjector - lightbulb replaced

 The lamp lasted for 4,622 hours.

This time I purchased just the bare lamp itself . The housing doubles the price. The disadvantage of this technic that the lamp housing window can not be cleaned  perfectly. Atm2 picture is exaggerating this spot.

However, It does not degrade the image quality.

Roll over image to zoom in

      

 
 

Glamps RLC-061 Projector Original Bulb Lamp for VIEWSONIC Pro8200 Pro8300

 

 

Attachment 1: explodedlamp.jpg
explodedlamp.jpg
Attachment 2: clweanedWindowShield.jpg
clweanedWindowShield.jpg
  9503   Fri Dec 20 11:40:13 2013 JamieSummaryCDSRCG parsing bug?

I submitted a bug report for this:

https://bugzilla.ligo-wa.caltech.edu/bugzilla3/show_bug.cgi?id=553

However, given how old our RCG version is (2.5 vs. 2.8 current deployed at the sites) I don't think we're going to see any traction on this.  Even if this is still a bug in 2.8, they'll only fix it in 2.8.  There's no way they're going to make a bug fix release for 2.5.

We need to upgrade.

  9502   Fri Dec 20 10:08:43 2013 JamieConfigurationGeneralnetgpibdata is working again now

Quote:

Now netgpibdata is working again.

Usage:

cd /cvs/cds/rtcds/caltech/c1/scripts/general/netgpibdata   
./netgpibdata -i 192.168.113.108 -d AG4395A -a 10 -f meas01
./netgpibdata -i 192.168.113.105 -d SR785 -a 6 -f meas01   

Just wanted to point out that the correct "modern" path to this stuff is:

/opt/rtcds/caltech/c1/scripts/general/netgpibdata

This is, of course, the same directory, but under the correct "/opt/rtcds", instead of the old, incorrect "/cvs/cds".

  9501   Fri Dec 20 03:34:40 2013 KojiUpdateLSChigh bandwidth loop achieved for yarm

This too huge offset difference with/without "BOOST" switch should be checked.

  9500   Fri Dec 20 03:31:07 2013 KojiUpdateLSClock acquisition path for the CM servo

up/down scripts are to be made

(Offset Edit on Dec 20 10:38PM)


Configuration:
POY11QMon -> CM Servo In1 -> CM Servo -->Out1 -> ADC -> CM Slow FM -> LSC MC Servo FM -> ETMY(x1.0) -> DAC -> ETMY
                                       |
                                       -->Servo Out -> SR560 (DC, 1st order 30kHz LPF) -> MC In2


Lock acquisition path 1

Initial condition:

CM Slow FM:

  • Gain 2.6

CM Servo setting:

  • In1 Gain 31dB, SW:OFF, Offset -1.880, Boost Off, Super Boost Off, AO +8dB

MC Servo setting:

  • In2 10dB, SW:OFF

Acquisition:

  • Engage LSC
  • LSC MC servo gain +0.1, FM7/FM10 (Trigger FM2 with 3sec delay)
  • Turn on MC

Transition:

  • Enable AO path (CM servo In1 SW:ON, MC servo In2 SW:ON)
  • LSC MC gain +0.1 -> +0.2
  • AO path gain 8dB->14dB
  • LSC MC gain +0.2 -> +0.35
  • AO path gain 14dB->18dB
  • CM servo offset -1.88 -2.7 -> 0.8 0.0 (gradually)
  • Enable CM servo Boost

Lock acquisition path 2

Initial condition:

CM Slow FM:

  • Gain 2.6

CM Servo setting:

  • In1 Gain 31dB, SW:OFF, Offset -1.880, Boost Off, Super Boost Off, AO +20dB

MC Servo setting:

  • In2 10dB, SW:OFF

Acquisition:

  • Engage LSC
  • LSC Yarm G=+0.25 FM4/5 (Trigger FM3/6/7/8)

Transition:

  • Enable MC servo In2 (SW:ON)
  • Set LSC MC gain +0.2 FM7/10
  • Enable LSC MC (On)
  • Enable CM servo In1 (SW:ON)
  • Disable LSC Yarm (OFF)
  • Change CM servo offset -1.88 -> +0.700 -2.70 -> 0.0
  • Enable CM servo Boost
  • Turn on LSC CM FM2 (optional)

Transition to ETMY LSC to MCL

  • After all of the transition: LSC output matrix ETMY (+1.00)
  • LSC output matrix MC2 (-1.00)
  • LSC output matrix ETMY (0.00)
  9499   Fri Dec 20 01:24:11 2013 DenUpdateLSChigh bandwidth loop achieved for yarm

Koji, Den

CM Servo with POY11 successfully engaged. UGF: ~15kHz.


Tonight we decided to repeat one arm locking using high-bandwidth CM servo. We low-passed AO signal to avoid saturations of the EOM. We tried different configurations that compromise between noise and loop phase margin and ended up with a pole at 30kHz. SR560 is used as a low-pass filter.

Another problem that we faced was big (~2.6V) electronic offset at the input of 40:4000 BOOST. Once engaged, cavity would be kicked out of lock. We calibrated this offset to be almost half linewidth of the cavity (~300pm). To avoid lock loss during engaging the boost we increased common mode gain to maximum (31 dB).

Measured OL is attached. UGF is 15kHz, phase margin is 60 degrees. We have also simulated evolution of loop shape during bringing AO path. Plot is attached.

The final procedure is

  • set common gain up to 31dB, AO gain to 8dB, MC IN2 gain 10dB, CM offset 0.7V
  • lock arm with CM slow path with bandwidth of 200 Hz
  • enable AO path, gradually increase slow and fast gains by 12 dB
  • enable boost
Attachment 1: CM_OL_meas.pdf
CM_OL_meas.pdf
Attachment 2: cm_ol_sim.pdf
cm_ol_sim.pdf
Attachment 3: CM_slow_fast_cross.pdf
CM_slow_fast_cross.pdf
  9498   Fri Dec 20 00:16:39 2013 KojiSummaryCDSRCG parsing bug?

A while ago, I noticed that the most significant bits of the LSC whitening DOs are not toggling.
I track this issue down and found what is happening. I need experts' help.


To illuminate the issue, terminators are connected to Bit15 of the Bit2Word blocks in the LSC model (attached screen shots).

The corresponding source file is found in c1lsc.c at the following location.
The last channels of the Bit2Word are connected to lsc_cm_slow (the filter module).
This is the source of the issue. This wrong assignment of the connections
can't be changed by connecting Go-From tags to the chennels.

/opt/rtcds/caltech/c1/rtbuild/src/fe/c1lsc/c1lsc.c

3881// Bit2Word:  LSC_cdsBit2Word1                                                                                                              
3882{
3883double ins[16] = {
3884        lsc_as110_logicaloperator4,
3885        lsc_as110_logicaloperator1,
3886        lsc_refl11_logicaloperator4,
3887        lsc_refl11_logicaloperator1,
3888        lsc_pox11_logicaloperator4,
3889        lsc_pox11_logicaloperator1,
3890        lsc_poy11_logicaloperator4,
3891        lsc_poy11_logicaloperator1,
3892        lsc_refl33_logicaloperator4,
3893        lsc_refl33_logicaloperator1,
3894        lsc_pop22_logicaloperator4,
3895        lsc_pop22_logicaloperator1,
3896        lsc_pop110_logicaloperator4,
3897        lsc_pop110_logicaloperator1,
3898        lsc_as165_logicaloperator4,
3899        lsc_cm_slow
3900};
3901lsc_cdsbit2word1 = 0;
3902for (ii = 0; ii < 16; ii++)
3903{
3904if (ins[ii]) {
3905lsc_cdsbit2word1 += powers_of_2[ii];
3906}
3907}
3908}

3946// Bit2Word:  LSC_cdsBit2Word2                                                                                                              
3947{                                                                                                                                           
3948double ins[16] = {                                                                                                                          
3949        lsc_as55_logicaloperator4,                                                                                                          
3950        lsc_as55_logicaloperator1,                                                                                                          
3951        lsc_refl55_logicaloperator4,                                                                                                        
3952        lsc_refl55_logicaloperator1,                                                                                                        
3953        lsc_pop55_logicaloperator4,                                                                                                         
3954        lsc_pop55_logicaloperator1,                                                                                                         
3955        lsc_refl165_logicaloperator4,                                                                                                       
3956        lsc_refl165_logicaloperator1,                                                                                                       
3957        lsc_logicaloperator_cm_ctrl,                                                                                                        
3958        ground,                                                                                                                             
3959        ground,                                                                                                                             
3960        lsc_logicaloperator_popdc,                                                                                                          
3961        lsc_logicaloperator_poydc,                                                                                                          
3962        lsc_logicaloperator_poxdc,                                                                                                          
3963        lsc_logicaloperator_refldc,                                                                                                         
3964        lsc_cm_slow                                                                                                                         
3965};                                                                                                                                          
3966lsc_cdsbit2word2 = 0;                                                                                                                       
3967for (ii = 0; ii < 16; ii++)                                                                                                                 
3968{                                                                                                                                           
3969if (ins[ii]) {                                                                                                                              
3970lsc_cdsbit2word2 += powers_of_2[ii];
3971}
3972}
3973}

 

Attachment 1: Bit2Word1.png
Bit2Word1.png
Attachment 2: Bit2Word2.png
Bit2Word2.png
  9497   Thu Dec 19 21:16:16 2013 KojiConfigurationGeneralnetgpibdata is working again now

Now netgpibdata is working again.

Usage:

cd /cvs/cds/rtcds/caltech/c1/scripts/general/netgpibdata   
./netgpibdata -i 192.168.113.108 -d AG4395A -a 10 -f meas01
./netgpibdata -i 192.168.113.105 -d SR785 -a 6 -f meas01   

Jenne witnessed and certified that they were working fine.
Now no one can say "it does not work"!


These weeks I was annoyed by the fact that netgpibdata was messed up by dummies.
A terrible situation was found:

1. Someone pushed the factory reset of one of the wifi bridges (LINKSYS WET54G).
2. Someone gave wrong IPs to the bridges (192.168.1.* instead of 192.168.113.*)
3. Someone left a default IP to the bridges. This means the routers had the same IPs.

-------

I gave the IPs to the bridges. According lines of /etc/hosts in linux1 were updated.

192.168.113.230 WET54G1
192.168.113.231 WET54G2

All of the network settings are taped on the bridge now.
The reset switch of each bridge was covered by a tape so that dummies can't randomly push the button.

The command was tested with each device.

  9496   Thu Dec 19 19:45:12 2013 ericqUpdateGreen LockingX-Arm Green PDH Loop Stuff
With the fixed servo box, I remeasured the OLTF, the servo, and the low pass filter between the mixer output and servo input. Dividing the OLTF by the servo and LPF transfer functions should just leave the the [laser PZT->cavity->PD] transfer function, which should have the shape of the cavity pole plus any delay in the loop, up until the PZT is no longer linear / the measurement has bad SNR.

I'm missing a few pieces of the loop. While I know the PD gain in V/W, I don't know how much power is in the sideband, which affects the slope of the PDH error function. Also, I've found old ELOG posts mentioning either 1 or 5MHz/V being the NPRO PZT response, but am not sure how to determine what it actually is. These are essentially just scalars though, so finding the reason for low phase margin doesn't depend on them.

Here are the TFs I've measured ("residual" refers to OLTF/(servo*LPF)):



The teal "residual" TF presumably owes its shape to the cavity pole + the time delay around the loop. Messing around with the data, the shape fits very well to a real pole at 27kHz and a ~3usec delay. I have no real way to back that up as the unique truth behind it, however. Is there a good way to measure the delay? Without assuming any delay, the shape is best fit by a real pole at 26kHz and some funky complex zeros.

Another thing to look at is the CLG implied by the measurement of the OLTF, given by 1/(1-G). I plotted this quantity for the measured loop, and also for G/2 and 3G/2 to get an idea for how it changes as you turn the servo gain knob. I measured with the knob at 4.0. There seems to be quite a bit of gain peaking!



Also, I drew up a simple block diagram sort of thing to show how everything is connecting down at the green electronics rack at the end of the X arm (while totally glossing over the optical elements involved). This hopefully helps anyone who wants to inspect/take apart/massacre the setup.

  9495   Thu Dec 19 18:33:25 2013 GabrieleSummaryLSCEstimate of the sign of the PRC length error

Maybe I'm getting confused, but I still believe there is no way to decide the direction from yesterday's measurement.

Let's say for example that the arm sideband detuning from antiresonance is equivalent to a PRC length change of +1cm away from the position of ideal resonance of the sidebands without arms. Then we can get a measured separation of the sidebands, without arms, corresponding to 5cm both if the PRC is off by +4cm or by -6cm...

  9494   Thu Dec 19 14:40:42 2013 KojiUpdateCDSRFM Time over mitigation for c1mcs

I worked on the mitigation of c1mcs time-over issue this afternoon.

The timing for the c1mcs is successfully reduced from >60us to 45us.


The previous models are svned in redoubt as follows:

MCS rev. 6696
RFM rev. 6697
IOO rev. 6698

What I changed was:

- Remove connection from ALS (on c1ioo) to MCS (on c1sus). This should be all done in LSC. (# of RFM IPC in MCS -1)

- MC2 trans QPD filters are moved from IOO to MCS to reduce the RFM channels in MCS.
  Previously the signals for the 4 segments are sent. Now the processed siganls (pit/yaw/sum) are sent. (# of RFM IPC in IOO -1, MCS -1)

- WFS MC3 feedback channels are moved from MCS to RFM to distribute the RFM channels (# of RFM IPC in MCS -2, in RFM +2)

model    prev. timing[us] current timing[us]  diff in time[us]  diff in ch#
c1mcs         >60                45                -15              -4
c1rfm         47                 53                + 6              +2       
c1ioo         47                 36                -11              -1

Revisions of the new models:
MCS rev. 6702
RFM rev. 6701
IOO rev. 6700

  9493   Thu Dec 19 12:51:57 2013 JenneSummaryLSCEstimate of the sign of the PRC length error

My hunch is that the PRC is SHORT by a few cm, not long. 

In my Optickle simulation, the sidebands are not perfectly co-resonating in the PRMI when the arms are not locked.  See Fig 1, which is the fields in the PRMI using the design PRC length.  If I add 5cm to the PRC length, I get Fig 2, where the peaks are about the same separation, but the upper and lower sidebands have swapped sides of the 0 mark.  However, if I remove 5cm from the PRC length, I get Fig 3, where the peaks are much farther apart than in Fig 1.  This case looks more similar to the data that Gabriele plotted in his elog entry, where the peaks are separated by at least a linewidth.  This is not at all conclusive, but it's a guess for which direction we need to move.  Obviously doing an actual measurement will be better. 

My tummy feelings also agree with this simulation:  When we flipped PR3 (the only optic change in the PRC since Gabriele and I measured the 55MHz peak separation in April), since the HR side of the optic is now at the back, we had to push the whole suspension cage forward to get the beam aligned to the Yarm.  Conversely, however, transmitting through the glass substrate adds to the optical path length.  So, my tummy feelings may be wrong.

Figure 1, PRC at design length, PRMI sweep:

DesignLength.png

Figure 2, PRC 5cm longer than design length:

Plus5cm.png

Figure 3, PRC 5cm shorter than design length:

Minus5cm.png

 

  9492   Thu Dec 19 03:29:34 2013 DenUpdateLSCCM servo test using yarm is complete

Koji, Den

Procedure:

  • lock yarm on IR, wire POY to CM input
  • transition arm to CM length path by actuating on IMC
  • increase AO gain for a stable crossover
  • engage CM boosts

Result:

  • arm can be kept on resonance and even acquired on MC2
  • stable length / AO crossover is achieved
  • high bandwidth loop can not be engaged because POY signal is too noisy and EOM is running out of range

We spent some time tuning CM slow servo such that fast path would be stable in the AO gain range -32db -> 29dB (UGF=20kHz) when all boosts are turned off and common gain is 25dB. Current filters that we use for locking are not good enough - AO can not be engaged due to oscillations around 1kHz. This is clearly seen from slow path closed loop transfer function. I will attach servo shapes tomorrow.

Attached plot "EOM" shows EOM rms voltage while changing AO gain from -10dB to 4dB. For UGF of 20kHz we need AO gain of 29dB.

It seems we can start using CM servo for CARM offset but the sensor should be at least factor of 30 better than POY. Add another factor of 10 if we would like to use BOOST 2 and BOOST 3.

Attachment 1: EOM.png
EOM.png
  9491   Wed Dec 18 18:45:39 2013 JenneUpdateLSCREFL 165 demod phases

I checked out the REFL165 demod phase, and it looks like it was okay.  it was -20.9 degrees.  I turned on my sensing matrix oscillators, and maximized the PRCL signal in the REFL165_I_ERR channel, and got a pretty good maximization at +155 degrees.  I used this to lock the PRMI on sidebands, with MICH gain of +0.3, and PRCL gain of +0.1 . 

Since this is working, I'm leaving the REFL 165 phase here, at +155 degrees, although this is almost exactly 180 degrees from what Den left it at, so I'm not sure why I was not able to lock with a demod phase of -20.9.  (I tried all 4 permutations of signs, with gain values of the same magnitude (0.3 for MICH, 0.1 for PRCL), and wasn't able to lock.  I'll try to figure this out tomorrow, but it was time for the meeting, then the IFO has been busy doing more important things the rest of the afternoon.

Plan for checking:  Lock with demod phase of 155, measure TF to one of the other REFL diodes (11, 33 or 55), lock on that other REFL diode.  Then, change the REFL 165 demod phase back to -20.9, and measure the transfer function again.  Hopefully the answer is just that I was doing something dumb, and it works easily.  This test/measurement should only take a few minutes, but it'll make me happier knowing that things still work as they should.

  9490   Wed Dec 18 17:28:50 2013 GabrieleSummaryLSCEstimate of the PRC length error

Measurement 

Looking back at what I did in april (see log #8411) I realized that it is possible to get an estimate of how much the PRC length is wrong looking at the splitting of the sideband resonant peak as visible in the POP_110_I signal. With the help of Jenne the PRMI was aligned and left swinging. The first plot shows a typical example of the peak splitting of 55MHz sidebands. This is much larger than what was observed in April.

When the sidebands resonate inside the PRC they get a differential dephasing given by 

dPhi = 4*pi*f_mod/c * dL

where dL is the cavity length error with respect to the one that makes the sidebands perfectly resonant when the arms are not there. This is not exactly the error we are interested in, since we should take into account the shift from anti-resonance of the SBs in the arm cavities.

Nevertheless, I can measure the splitting of the peak in units of the peaks full width at half maximum (FWHM). I did this fitting few peaks with the sum of two Airy peaks. Here is an example of the result

data_fit2.png

The average splitting is 1.8 times the FWHM. Knowing the PRC finesse, one can determine the length error:

dL = c / (4 * f_mod * Finesse) * (dPhi / FWHM)

Assuming a finesse of 60, I get a length error of 4 cm.

To get another estimate, we kicked the PRM in order to get some almost linear sweeps of the PRC length. Here is one of the best results:

data_kick.png

The distance between consecutive peaks is the free spectral range (FSR) of the PRC cavity. Again, I can measure the peak splitting in units of the FSR and determine the length error:

dL = c / (4 * f_mod) * (dPhi / FSR)

The result is again a length error of 4 cm.

Simulation

An error of 4 cm seems pretty big. Therefore I set up a quick simulation with MIST to check if this makes sense. Indeed, if I simulate a PRMI with the 40m parameters and move the PRC length from the optimal one, I get the following result for POP_110_I, which is consistent with the measurement.

pop110_vs_dL.png

 

 Therefore, we can quite confidently assume that the PRC is off by 4 cm with respect to the position that would make the 55 MHz sideband resonant without arms. Unfortunately, it is not possible with this technique to infere the direction of the error.

 

 

 

 

 

 

Attachment 3: pop110_vs_dL.png
pop110_vs_dL.png
  9489   Wed Dec 18 15:35:48 2013 SteveUpdatePEMexcess seismic noise

This is not a test. Life can be dangerous in the 40m Control  Room.

Attachment 1: seismicCar.jpg
seismicCar.jpg
  9488   Wed Dec 18 13:34:03 2013 SteveUpdateGeneralLIGOX people

40m crew and visitor Holger Muller from Berkeley.

Attachment 1: 40m2013Dec.jpg
40m2013Dec.jpg
Attachment 2: 40mCup.jpg
40mCup.jpg
  9487   Wed Dec 18 11:37:12 2013 JenneUpdateLSCPOP22 and POP110 demod phases

Somehow the POP22 and POP110 demod phases weren't correct anymore.  I guess Den saw this after he changed the setup for the REFL165 PD at the LSC rack, but didn't elog it. 

I went out to the LSC rack, and found that the power supply that is supplying the amplifiers for both POP22/110 and REFL165 was set to ~16V each channel.  I put it back to 15V for each channel.  I don't know what Den intended for the 165 amplifier (more volts is more gain), but the POP22/110 amplifier usually runs with 15V. 

I also reset the POP22 and POP110 demod phases.  Since I'm not able to lock PRMI on sideband this morning (why?!?!), I locked on the carrier, and moved the phases around until POP22 and POP110 were both maximally negative.  The phases are/were:

  OLD [deg] NEW [deg]
POP22 107.2 -165.0
POP110 95.0 150.0

This is a ~60 degree change for both PDs. 

I am not sure if Den ever checked the demod phase of REFL165 after he put in the new SMA cable (there's no mention of it in the elog!), so I'm going to check that to see if it helps get PRMI locking back.  I know that Den had also been using REFL11 for PRMI locking, but the parameters he used for that aren't in the log either.

  9486   Wed Dec 18 11:32:34 2013 ranaUpdateLSCXend QPD schematic investigation

 

 Since we use the TransMon QPD for triggering the high/low gain switching we need to run with the whitening OFF during lock acquisition and the turn it on after we have the arms locked with ALS. This should be put into the up/down scripts.

  9485   Wed Dec 18 03:29:48 2013 DenUpdateLSCyarm locked on mc

As a CM slow path test I locked free swinging yarm by actuating on MC length with bandwidth of 200 Hz. Crossover with AO is not stable so far.

I used xarm as an ool frequency noise sensor. MC2 violin mode is at 645 Hz, I have added a notch filter to LSC-MC2 bank.

Attachment 1: MC_ARM.pdf
MC_ARM.pdf
  9484   Wed Dec 18 00:26:15 2013 JenneUpdateLSCXend QPD schematic investigation

I have looked at the photo of the Xend QPD from elog 9367, as well as the schematic for the board (D990272). 

Things that will need swapping out:

  • Thick film resistors in the signal path need to be changed to thin film.
  • MAX333 needs to be replaced with MAX333A.  The 333 has "ON Resistance" of 140-175 ohms, whereas the 333A has "ON Resistance" of 20-35 ohms.
  • AD797 needs to be replaced by OPA140.  The 797 is a low voltage noise op-amp, but for a diode we want low current noise.  AD797 has 2pA/rtHz at 1kHz, whereas the OP140 has 0.8fA/rtHz at 1kHz (see Zach's elog 8125 re: OPA140).

I have ordered from digikey via techmart 10 each of the MAX333A's and the OPA140's.  (4 per QPD times 2 QPDs plus 2 spares = 10).  Both of these new chips have the same footprint and pinout as the part that they are replacing, so it'll be a fairly easy task.

Next up, I need to make a LISO model for the circuit for one of the quadrants, to see what shape it'll turn out to be.  Part of this will include deciding what resistors and capacitors to put in the OPA140 gain stage. 

Right now, the AD797s say on the schematic that the gain options are different by a factor of 5, but the actual QPD has a different resistor than is on the schematic, and there is also a capacitor in parallel with each resistor, so I need to just pull those out, and pick some values that make sense to me. 

Rana and I have discussed ignoring the 2nd and 3rd gain switching options on each quadrant, as that is getting to be more fine control than we need. 

Other things on the board:

  • The 50 ohm resistors to ground for the "QPD_rtn" have all shorted.  Rana says this is good, so leave it as-is.
  • The positive input to the AD797's all have a 100 ohm resistor to ground, rather than just being connected to ground.  Why is this??

For now, I will probably just work on the QPD head, and not the whitening board.  For now, we can run with 1 stage of whitening, and if we need lower noise, we can revisit the whitening board (including replacing the thick film resistors with thin film).

When thinking about what gains I want on my gain stages, I want to have my full arm power (~700 TRX units) be ~20,000 counts from the ADC.  So, I want my single arm power (1 TRX unit) to be ~30 counts from the ADC.  This is not such a big number, so this may also require more thinking. 

  9483   Tue Dec 17 21:28:36 2013 JenneUpdateLSCCM servo slow output digitized

Den just plugged an output from the common mode board into an LSC whitening board (the spare channel that used to be called "PD_XXX_I" in the LSC model).  I have modified the LSC model to reflect the new name of the new signal ("CM_SLOW"), and have added this channel to the LSC input matrix.  Koji is, I believe, adding this channel to the LSC screen in the auxiliary error signals section.  I am also adding the _OUT of the filter bank to the DAQ channels block.

  9482   Tue Dec 17 20:59:23 2013 JenneUpdateLSC1/sqrt(TR) signals added to frames

I noticed that we have not been saving the 1/sqrt(TRX) and 1/sqrt(TRY) data, so I modified the c1lsc model and added them to the DAQ channels block.  I restarted the c1lsc model, and the _DQ channels are now archived.

  9481   Tue Dec 17 14:06:59 2013 ranaUpdateLSCNew Broadband PD for POP 22/110

 I looked at the BBPD design so that we could make a POP22/110. It looks like it will be easy (I hope).

 The first attachment shows the schematic with the RF notch modified to handle 55 MHz. As long as the capacitor in this notch can be kept to below 20 pF, it doesn't degrade the noise so much,

The second attachment shows the TF and input referred noise. We ought to be able to get 20 pA/rHz at the input to the first RF amplifier.

The LISO files are in the svn under liso/examples/aLIGO_BBPD/,

Later, if we have to notch more than just 55 MHz, we can add a notch between the 2 RF amplifiers as Koji has done for the REFL165.

Attachment 1: POP22110sch.pdf
POP22110sch.pdf
Attachment 2: POP22110.pdf
POP22110.pdf POP22110.pdf
  9480   Tue Dec 17 02:10:29 2013 DenUpdateLSClocking activity

Koji, Den

Some results and conclusions from tonight:

PRC macroscopic length is detuned. We measured REFL phases in carrier and sideband configurations - they are different by ~45 degrees for both 11 and 55 MHz sidebands. Additional measurement with phase locked lasers is required.

We got stable lock of PRMI+2arms with CARM offset of ~200 pm. We think this is the point when we should transition to 1/sqrt(TR) signals. We plan to rewire LSC model and also test CM servo with 1 arm during the day.

POP ASC OL shape changes when we reduce CARM offset probably due to normalization by sum inside the PD. Servo gets almost useless when PRMI power fluctuates by a factor of few.

SMA cables were made and installed for the REFL165 RF amplifier in lsc rack.

  9479   Mon Dec 16 20:08:43 2013 KojiUpdateLSCCM servo module installed

I found another backplane cable for the CM servo module. It is plugged to the module now.

I can see that C1:LSC-CM_SLOW_MON is responding to C1:LSC-CM_REFL_OFFSET.
But C1:LSC-CM_SUM_MON and C1:LSC-CM_FAST_MON are not replated to the given offset.
I probably need to check the cross connects.

  9478   Mon Dec 16 02:20:49 2013 DenUpdateLSCMICH rms is improved

When PRMI is locked on REFL 165 I&Q signals MICH rms is dominated by the 60 Hz line and harmonics. It comes from demodulation board.

To increase SNR ZFL-100 LN amplifier (+23.5dB) was installed in LSC analog rack. MICH 60 Hz and harmonics are improved as shown on the plot "mich_err"

I have also added a few resg at low frequencies. MICH rms is not 3*10-10. In Optickle I simulated power dependence in PRC and ARMs on MICH motion. Plot is attached.

 I think we need to stabilize MICH even more, down to ~3*10-11 . We can think about increasing RF amplifier gain, modulation index and power on BB PD.

CARM offset reduction was a little better today due to improved MICH RMS. Power in arms increases up to 15 and than starts to oscillate up to 70 and then PRMI looses lock.

Tomorrow we need to discuss where to put RF amplifier. Current design has several drawbacks:

  • DC power for the amplifier is wired from a custom (not rack based) +15V power supply that was already inside the lsc rack and used for other ZFL-100LN
  • BNC cables are used because I could not find any long SMA cables
  • we would like gain of ~40 dB instead of 23.5 dB
Attachment 1: MICH_ERR.pdf
MICH_ERR.pdf
Attachment 2: DC_power.pdf
DC_power.pdf
Attachment 3: ARM_OFFSET.pdf
ARM_OFFSET.pdf
  9477   Sun Dec 15 21:01:19 2013 KojiUpdateLSCCM servo module installed

Now the module is inserted at the 2nd crate from the top of 1Y2 (LSC analog rack). It is next to the DCPD whitening module.

I found the backplane cable for the Common Mode servo module.
I traced a cable form XY220 at the right most module on the crate where iscaux2 is living.
This cable was connected to the upper backplane connector.

Switching of the module is tested. All the switches and gain control are doing their job.

It was found that the offset and slow readback are not responding.
I checked the schematic of the CM servo module (D040180).
It seems that there is another cable for the offset and read back voltages.

  9476   Sun Dec 15 20:37:41 2013 ranaSummaryTreasureThere is a Wagonga in the container that Steve does not believe in

From Linda and Bram:

Attachment 1: WagSu.pdf
WagSu.pdf
Attachment 2: Wagonga.jpg
Wagonga.jpg
Attachment 3: MandehlingMedStrong.jpg
MandehlingMedStrong.jpg
  9475   Sun Dec 15 03:13:15 2013 DenUpdateLSCattempt to reduce carm offset

X,Y arms were stabilized using ALS and moved 5 nm from the resonance, PRMI was locked on sideband using REFL165 I&Q. POP angular servo was running; PRMI RIN was good (~2-3%)

During slow offset reduction I was sweeping MICH, PRCL and POP servos for instabilities due to possible optical gain variations, loops were fine.

I could reduce offset down to ~200 pm and then lost lock due to 60 Hz oscillations as shown on the attached plot "arm_offset"

Arms were stabilized with RMS comparable to the offset and power in arms was fluctuating from 3 to 45.

60 Hz line most probably comes from MICH. RMS is dominated by the power lines and is ~ 1 nm as seen on the plot "PRMI_CAL". I think this is too much but we need to do simulations.

Attachment 1: ARM_OFFSET.pdf
ARM_OFFSET.pdf
Attachment 2: PRMI_CAL.pdf
PRMI_CAL.pdf
  9474   Sat Dec 14 14:21:46 2013 DenUpdateLSCcommon mode servo

Quote:

 

 These seem like pretty terrible loop shapes. Can you give us a plot with the breakdown of several of the TFs and some .m file?

Attached is matlab code that I used

 % IMC OL
G = zpk(-2*pi*8964, 2*pi*[-10; -10; -10; -1000; -274000], db2mag(242.5)) * ...
    tf([1 0.8*1.55e+05 3.1806e+10], 1);

% CARM PATH
CARM = G/(1+G);

% Common mode boosts
BOOST = zpk(-2*pi*4000, -2*pi*40, 1);
BOOST1 = zpk(-2*pi*20000, -2*pi*1000, 1);
BOOST2 = zpk(-2*pi*20000, -2*pi*1000, 1);
BOOST3 = zpk(-2*pi*4500, -2*pi*300, 1);

% Coupled cavity pole
CCPole = zpk([], -2*pi*100, 2*pi*100);

% Servo gain
Gain = db2mag(43);

% CARM OL with boosts
H = CARM * CCPole * BOOST * Gain;
H1 = H * BOOST1;
H2 = H1 * BOOST2;
H3 = H2 * BOOST3;

% Plot
% bode(H, H1, H2, H3, 2*pi*logspace(3, 5, 10000));
% bode(1/(1+H), 1/(1+H1), 1/(1+H2), 1/(1+H3), 2*pi*logspace(3, 5, 10000));

  9473   Sat Dec 14 13:46:54 2013 DenUpdateIOOlow bandwidth MCL loop

Last time we designed MCL loop with UGF ~ 30 Hz and I think, it was hard to lock the arm because of large frequency noise injected to IFO.

This time I made a low bandwidth MCL loop with UGF=8 Hz. MCL error RMS is suppressed by factor of 10 and arms lock fine.

Attached plots show MCL OL, MCL error suppression and frequency noise injection to arms.

It is interesting that spectrum of arms increases below 1 Hz meaning that IMC sensing noise dominates in this range.

I did not include the loop into the IMC autolocker. I think it is necessary to turn it on only during day time activity and when beatnote is moving too much during arm stabilization.

Attachment 1: MCL_OL.pdf
MCL_OL.pdf
Attachment 2: MCL_ERR.pdf
MCL_ERR.pdf
Attachment 3: MCL_ARMS.pdf
MCL_ARMS.pdf
Attachment 4: MCL_MEDM.png
MCL_MEDM.png
  9472   Sat Dec 14 11:56:54 2013 ranaUpdateLSCcommon mode servo

Quote:

 

 It seems to me that current design of the common mode servo is already fine. Attached plots show common mode open and closed loop transfer function.

 These seem like pretty terrible loop shapes. Can you give us a plot with the breakdown of several of the TFs and some .m file?

We should be able to estimate the noise coming out of the MC using the single arm and then make a guess for the CM loop gain requirement. There's no reason to keep the old Boost shapes; those were used in the old MC configuration which had a RefCav. In addition to minimizing the EOM range, we should also minimize the AO signal as Koji has pointed out. In practice, I've seen that using ~300 Hz of offset makes no harm with 4 kHz MC pole.

  9471   Sat Dec 14 02:51:47 2013 DenUpdateLSClocking activity

I had a look on x,y arms stabilization using ALS. Input green beam was misaligned and I was loosing 00 every few minutes. I vent on the floor and realigned green beams.

YARM alignemt was smooth - transmission increased from 0.4 to 0.85 with PSL shutter off.

XARM was tough. Steering mirrors did not have any derivatives when transmission power was 0.5. I walked the beam with piezos but got only 0.55. It seems that the input beam is mismatched to the cavity. When the transmission was 1 last time? Does anyone have a model of the xend table to compute mode matching?

Input green alignent was improved and I could keep arms stabilized for periods of ~30min - 1 hour. Still not forever.

I noticed that ALS_XARM and ALS_YARM servos have limiters of 6000 and control signal had high frequency components that were not rolled off as shown on the plot "ETMY_DRIVE". I have added a low pass filter that reduced RMS by factor of 5 and took 7 degrees of phase at UGF=150 Hz. Now margin is 33 degrees.

Then I excited ETMY longitudinally at 100 Hz and measured first and second harmonics of the YARM RIN. I got total DC offset of 0.3 nm. This means significant length coupling to RIN. First of all, "scan arm" script does not tune the offset very precise. I guess it looks at DC power, checks when cavity passes through symmetrical points of the resonance and takes the average. It is also useful to look at POX/POY and confirm that average is 0. Plot "ALS_RIN" shows comparison of YARM power fluctuations when it is locked using IR and stabilized using ALS. By manually correcting the offset I could reduce length coupling into RIN, coherence was ~0.1.

Cavity RMS motion also couples length to RIN. Plot "ALS_IR" shows YARM error signal. I also looked at POY signal (LSC-YARM_IN1) as an OOL sensor. At low frequencies POY sees only IMC length fluctuations converted to frequency. I have engaged MCL path and ALS error and LSC error signals overlaped. Cavity RMS motion is measured to be 200 pm.

Attachment 1: ETMY_DRIVE.pdf
ETMY_DRIVE.pdf
Attachment 2: ALS_RIN.pdf
ALS_RIN.pdf
Attachment 3: ALS_IR.pdf
ALS_IR.pdf
  9470   Fri Dec 13 23:07:04 2013 KojiUpdateIOOcommon mode servo

Looks good.

Once the control cable (bakplane cable) is identified, we can install the module to the LSC analog rack.

We should be able to test the CM servo with either POX or POY and only one correspoding arm without modifying the servo TF.
Just for this test, we don't need to use MCL.

  9469   Fri Dec 13 19:33:56 2013 DenUpdateASCETM X,Y QPDs

I have modified/compiled/installed/restarted c1scx and c1scy models to include arm transmission QPDs in angular controls.

For initial test I have wired normalized QPD pitch and yaw outputs to ASC input of ETMs. This was done to keep the signals inside the model.

QPD signals are summed with ASS dither lines and control. So do not forget to turn off QPD output before turning on dither alignment.

Medm screens were made and put to medm/c1sc{x,y}/master directory. Access from sitemap is QPDs -> ETM{ X,Y} QPD

  9468   Fri Dec 13 18:03:00 2013 DenUpdateIOOcommon mode servo

Quote:

Well, let's see how the CM servo can handle this.
The key point here is that we have enough data to start the design of the CM servo.

 It seems to me that current design of the common mode servo is already fine. Attached plots show common mode open and closed loop transfer function.

Frequency response of the servo is taken from the document D040180. I assumed coupled cavity pole to be ~100 Hz.

The only question is if our EOM has enough range. Boost 2 increases noise injection by 10 dB in the frequency range 20-50 kHz. Boost 3 has even higher factor.

Attachment 1: CM_OL.pdf
CM_OL.pdf
Attachment 2: CM_CL.pdf
CM_CL.pdf
  9467   Fri Dec 13 16:34:20 2013 SteveUpdateVACPS will be replaced next week

Quote:

Instrument rack power supplies checked and labeled at present loads.

The vacuum rack Sorensen is running HOT! Their is only 0.3A load at 24V There is plenty of space around it.

It is alarming to me because all vacuum valve positions are controlled by this 24V

 The temperature went down to room temp with temporary fan in the back. Voltage and current are stable.

Regardless, it will be replaced early next week.

Attachment 1: hotPSvacRack.jpg
hotPSvacRack.jpg
Attachment 2: fan1X8.jpg
fan1X8.jpg
  9466   Fri Dec 13 13:45:50 2013 KojiUpdateCDSMEDM/ADL: replace rectangle with specified objects

rect_replace.py script was updated.
This sounds crazy but it was actually quite easy as I could use a free font data.


/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/rect_replace.py

Usage:

cat C1LSC_OVERVIEW_ADC.adl | ./rect_replace.py > tmp.adl

Description:

The script takes stdin and spits the result to stdout. It parses a given ADL file. When a "rectangle" object
with Channel A with a string "REPLACE_XXXX", it replaces it with the objects predefined as "XXXX".

Now new type "CHAR" (i.e. REPLACE_CHAR) was added. This replaces the string in Channel B slot
into 5x7 dot matrix representation of the string with the specified color. The dot size is derived from the
height of the original rectangular object.

 

Attachment 1: screen_shot.png
screen_shot.png
ELOG V3.1.3-