40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log  Not logged in ELOG logo
Entry  Thu Feb 23 15:48:43 2017, johannes, Update, Computers, c1psl un-bootable scope_PDA520_ITM_aligned_ETM_misaligned.pngscope_PDA520_ITM_slightly_misaligned.pngpmc_trans_last10days.png
    Reply  Thu Feb 23 18:52:53 2017, rana, Update, Computers, c1psl un-bootable 
       Reply  Thu Feb 23 19:44:48 2017, johannes, Update, Computers, c1psl un-bootable slow_startup_logs.tar.gz
          Reply  Fri Feb 24 20:38:01 2017, johannes, Update, Computers, c1psl boot-stall culprit identified 
          Reply  Tue Feb 28 01:28:52 2017, johannes, Update, Computers, c1psl un-bootable 
             Reply  Wed Mar 8 18:18:51 2017, johannes, Update, Computer Scripts / Programs, loss script 
                Reply  Thu Mar 9 22:28:11 2017, johannes, Update, Computer Scripts / Programs, loss script 
                   Reply  Fri Mar 10 11:37:25 2017, gautam, Update, Computer Scripts / Programs, loss script 
                      Reply  Fri Mar 10 19:48:56 2017, johannes, Update, Computer Scripts / Programs, loss script 
                         Reply  Sat Mar 11 20:11:58 2017, johannes, Update, Computer Scripts / Programs, loss script 
Message ID: 12849     Entry time: Thu Feb 23 15:48:43 2017     Reply to this: 12850
Author: johannes 
Type: Update 
Category: Computers 
Subject: c1psl un-bootable 

Using the PDA520 detector on the AS port I tried to get some better estimates for the round-trip loss in both arms. While setting up the measurement I noticed some strange output on the scope I'm using to measure the amount of reflected light.

The interferometer was aligned using the dither scripts for both arms. Then, ITMY was majorly misaligned in pitch AND yaw such that the PD reading did not change anymore. Thus, only light reflected from the XARM was incident of the AS PD. The scope was showing strange oscillations (Channel 2 is the AS PD signal):

For the measurement we compare the DC level of the reflection with the ETM aligned (and the arm locked) vs a misaligned ETM (only ITM reflection). This ringing could be observed in both states, and was qualitatively reproducible with the other arm. It did not show up in the MC or ARM transmission. I found that changing the pitch of the 'active' ITM (=of the arm under investigation) either way by just a couple of ticks made it go away and settle roughly at the lower bound of the oscillation:

In this configuration the PD output follows the mode cleaner transmission (Channel 3 in the screen caps) quite well, but we can't take the differential measurement like this, because it is impossible to align and lock the arm but them misalign the ITM. Moving the respective other ITM for potential secondary beams did not seem to have an obvious effect, although I do suspect a ghost/secondary beam to be the culprit for this. I moved the PDA520 on the optical table but didn't see a change in the ringing amplitude. I do need to check the PD reflection though.

Obviously it will be hard to determine the arm loss this way, but for now I used the averaging function of the scope to get rid of the ringing. What this gave me was:
(16 +/- 9) ppm losses in the x-arm and (-18+/-8) ppm losses in the y-arm

The negative loss obviously makes little sense, and even the x-arm number seems a little too low to be true. I strongly suspect the ringing is responsible and wanted to investigate this further today, but a problem with c1psl came up that shut down all work on this until it is fixed:

I found the PMC unlocked this morning and c1psl (amongst other slow machines) was unresponsive, so I power-cycled them. All except c1psl came back to normal operation. The PMC transmission, as recorded by c1psl,  shows that it has been down for several days:

Repeated attempts to reset and/or power-cycle it by Gautam and myself could not bring it back. The fail indicator LED of a single daughter card (the DOUT XVME-212) turns off after reboot, all others stay lit. The sysfail LED on the crate is also on, but according to elog 10015 this is 'normal'. I'm following up that post's elog tree to monitor the startup of c1psl through its system console via a serial connection to find out what is wrong.

ELOG V3.1.3-