40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 171 of 341  Not logged in ELOG logo
ID Date Author Type Category Subject
  8555   Thu May 9 00:05:12 2013 rana, Koji, JenneSummaryLSCAA and AI change

We would like to increase the UGF of the PRC loop so as to allow more suppression of the PRC signal and less pollution of the MICH signal (remember that the PRC/MICH optical gain ratio is huge).

We were already losing phase because of delay in the LSC - SUS digital link. In addition to that, a major source of delay is the analog anti-aliasing (on the LSC error signals before they enter the ADC) and the analog anti-imaging (between the SUS DAC and the coil driver).

 IN addition to these, the other major sources of phase lag in the system are the FM5 filter in the LSC-PRC filter bank, the digital upsampling and downsampling filters, and the DAC sample and hold.

In the near term, we want to modify these analog filters to be more appropriate for our 64 kHz ADC/DAC sample rate. Otherwise, we are getting the double phase lag whammy.

 

Staring at the schematics for the AA (D000076-01) and the AI (D000186-A), we determined a plan of action.

For the AA, we want to remove the multi-pin AA chip filter from Frequency Devices, Inc. and replace it with a passive LC low pass. Hopefully, these chips are socketed. Rana will design an appropriate LC combo and elog; we should make the change on a Wednesday afternoon so that we have enough soldering help.

For the AI, the filter is a dual bi-quad using discrete components and LT1125 opamps. Not so clear what to do with these. The resistors are all the noisy thick film kind and maybe should be replaced. Koji will find some online design tool for these or do it in LISO. Changing the TF is easy; we can just scale the capacitors. But we also want to make sure that the noise of the AI does not destroy the noise reduction action of the dewhitening board which precedes it.

Jenne should figure out how low the noise needs to be at the input to the coil driver.

 

P.S. the matlab code which defines these filters

>> [z,p,k] = ellip(4,4,60,2*pi*7570,'s');
>> misc.ai = zpk(z,p,k*10^(4/20)) * zpk([],-2*pi*13e3,2*pi*13e3);
>>
>> % Fudged Anti-Imaging Filter
>> [z,p,k] = ellip(8,0.001,80,2*pi*7570,'s');
>> misc.aa = zpk(z,p,k*10^(0.001/20)) * zpk([],-2*pi*32768,2*pi*32768);

Attachment 1: AAAI.pdf
AAAI.pdf
  8554   Wed May 8 22:36:42 2013 KojiUpdateASSXARM ASS (YARM ASS - faster and more precise convergence)

Same ASS setup for the X arm has been done.

Now Arm ASS can run simultaneously.

I reverted the number of the lockin banks from 6 to 8 for future implementation of A2L for the ITMX by coil balancing.
Since A2L for the ITMX is just barely visible for now, I am going to leave the coil balance untouched.

Attachment 1: XARM_ASS.png
XARM_ASS.png
  8553   Wed May 8 19:31:17 2013 JamieConfigurationLSCLSC: added new SQRT_SWITCH to power normalization DOF outputs

This removes the old sqrt'ing from the inputs to the POW_NORM matrix (was only on the POP110 I/Q) and moves it to the DOF outputs.  Koji wanted this so that he could use the DC signals for normalization both sqrt'd and not sqrt'd.

The POW_NORM medm screen was updated accordingly.

  8552   Wed May 8 18:33:02 2013 KojiUpdateASSYARM ASS - faster and more precise convergence

Precise arm alignment is more demanded. as the PRMI locking requires good and reliable alignment of the ITMs.

I previously added the output matrix to ASS.

Now the input and output matrix as well as the gains and filters have been updated.

The current concept is

Fast loop: align the arms by the arm mirrors with regard to the given beam.

Slow loop: move the incident beam position and angle to make the spot at the center of the mirrors

This is actually opposite to Den's implementation.

In order to realize the faster alignment of the arm, I increased the corner frequency of the lockins for the arm signals from 0.5Hz to 1Hz.

With the new configuration the arm alignment converges in 10sec and the input pointing does in ~15sec.

The actuation to the input pointing TTs are done together with the feedforward actuation to the arms.
This way we can avoid too much coupling from the input pointing servos to the arm alignment servos.

The corresponding script /opt/rtcds/caltech/c1/scripts/ASS/YARM/DITHER_Arm_ON.py was also modified.

Attachment 1: YARM_ASS.png
YARM_ASS.png
Attachment 2: Screenshot.png
Screenshot.png
  8551   Wed May 8 17:45:49 2013 JamieConfigurationCDSMore bypassing c1rfm for c1mcs --> c1ioo IPCs

As with the last two posts, I eliminated more unnecessary passing through c1rfm for IPC connections between c1mcs and c1ioo.

All models were rebuilt/installed/restarted and svn committed.  Everything is working and we have eliminated almost all IPC errors and significantly simplified things.

  8550   Wed May 8 17:23:04 2013 JamieConfigurationCDSfixed direct IPC connection between c1als and c1mcs

As with the previous post, I eliminated and unnecessary hop through c1rfm for the c1als --> c1mcs connection for the ALS output to MC2 POS.

As a side note, we might considering piping the ALS signals into the LSC input matrix, elevating them to actual LSC error signals, which in some since they are.  It's just that right now we're routing them directly to the actuators without going through the full LSC control.

  8549   Wed May 8 17:03:35 2013 JamieConfigurationCDSmake direct IPC connections between c1lsc and c1sus/c1mcs

Previously, for some reason, many IPC connections were routed through the c1rfm model, even if a direct IPC connection was possible.  It's unclear why this was done.  I spoke to Joe B. about it and he couldn't remember either.  Best guess is that it was just for book keeping purposes.  Or maybe some old timing issue that has been fixed by DMA fixes in the RTS.  So the point is that it's no longer needed, and we can reduce delays by making direct connections.

I made direct IPC connections from c1lsc to both c1sus and c1mcs, bypassing the c1rfm, through which they had previously been routed.  All models were rebuilt/installed/restarted and everything seems to be working fine.

  8548   Wed May 8 16:10:09 2013 JamieUpdateCDSUnknown DAQ channels in c1sus c1x02 IOP?

Someone for some reason added full-rate DAQ specification to some ADC3 channels in the c1sus IOP model (c1x02):

#DAQ Channels

TP_CH15 65536
TP_CH16 65536
TP_CH17 65536
TP_CH18 65536
TP_CH19 65536
TP_CH20 65536
TP_CH21 65536

These appear to be associated with c1pem, so I'm guessing it was Den (particularly since he's the worst about making modifications to models and not telling anyone or logging or svn committing).

I'm removing them.

  8547   Tue May 7 23:03:12 2013 KojiConfigurationCDSCDS work

Summary:

c1rfm / c1lsc / c1ass / c1sus were modified. They were recomplied and installed. They are running fine
and confirmed PRMI locking (attempt), arm locking, and Yarm ass with the new codes.

Motivation:

1a. SQRTing switching for POP110 was wrong. 0 enabled sqrting, 1 disabled sqrting. I wanted to fix this.
1b. Sqrting for POP22 was not implemented.

2. Preparation for the shadow sensor control with POPDC.

3. ASS had only an input. I want to run two ASS for the X and Y arms.

SQRTing for POP110/22:

- Flipped the input of the bypass switch. Correspoding MEDM indicators are fixed on the power normalization screen.
- Copied the sqrting structure from POP110 to POP22. Correspoding MEDM buttom was made on the power normalization screen.

- The function of the sqrting buttons were confirmed.

Additional ASS output:

- The output path "NPRO" was removed. Corresponding RFM channels have also removed.
- The previous NPRO path was turned to the "ASS1" path. The previous "ASS" path was turned to "ASS2".
- Corresponding shared memory channel are created/renamed.
- c1ass was modified to receive the new ASS shared memory channels. ASS1 is assigned to the X arm. ASS2 is assigned to the Y arm
- The output matrix screen and the lockin screen were modified accordingly.
- Only script/ASS/Arm_ASS_Setup.py was affected. The corespoding lines (matrix assignment) was fixed.

- The function of Den's version of  ASS was confirmed.

LSC->PRM ASC path

- We want to connect POPDC to PRM ASC. POPDC is acquired on c1lsc.
- So, for now we use the LSC input matrix to assign POPDC to one of the servo bank.
- The last row of the LSC output matrix was assigned to the PCIE connection to c1sus.
- This PCIE connection was connected to the PRM ASC YAW input.

- The connection between LSC and SUS was confirmed.

- During this process I found that there are bunch of channels transferred from LSC to SUS via RFM.
  These channels are transferred via PCIE(dolphin) and then via RFM. But LSC and SUS are connected
  with dolphin. So this just adds additional sampling delay while there is no benefit. I think we should remove the RFM part.
  Note that we need to use RFM for the end mirrors but this also should use only the RFM connection.


Rebuilding the codes

- Prior to the tests of the new functionalities, the codes were rebuild/installed as usual.
- The suspension were shutdown with the watch dogs before the restart of the realtime codes.
- Once the realtime codes were restarted successfully, the watch dogs were reloaded.
- As we removed/added the channels, fb was restarted.
- c1rfm / c1lsc / c1ass / c1sus codes were checked-in to svn
 

  8546   Tue May 7 20:35:15 2013 ranaUpdatePSLPSL database / screen maintenance
  1. Fixed LOCKMC screen to display the SLOWM voltage instead of the ref cav transmission.
  2. PSL Status .db file updated to trigger on correct limits for FSS FAST and the FSS and PMC local oscillator levels.
  3. SETTINGS_SET screen can now take and display screen snapshots.

All of these changes were committed to the SVN.

  8545   Tue May 7 20:09:10 2013 Jamie, RanaUpdatePSLPMC problem was FSS slow actuator

Rana showed up and diagnosed the problem as a railed FSS SLOW output.  The SLOW Monitor about was showing ~6V, which is apparently a bad mode-hoppy place for the NPRO.  Reducing the SLOW output brought things back into a good range which allowed the PMC to lock again.

In attempting to diagnose the problem I noticed that there is -100 mV DC coming out of the PMC RFPD RF output.  This is not good, probably indicating a problem, and was what I thought was the PMC lock issue for a while.    Need to look at the PMC RFPD RF output.

  8544   Tue May 7 19:58:28 2013 ranaFrogsTreasurerabbitt whole

controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master 0$ ls
C1IOO_LKIN_OUT_MTRX.adl   C1IOO_MC_ASS_LOCKIN5.adl     C1IOO_WFS1_I.adl             C1IOO_WFS_LKIN.adl
C1IOO_LOCKMC.adl          C1IOO_MC_ASS_LOCKIN6.adl     C1IOO_WFS1_Q.adl             C1IOO_WFS_MASTER.adl
C1IOO_LOCKMC_BAK.adl      C1IOO_MC_ASS_PIT_LOCKIN.adl  C1IOO_WFS1_SETTINGS.adl      C1IOO_WFS_MASTER.adl~
C1IOO_MC_ALIGN.adl        C1IOO_MC_ASS_YAW_LOCKIN.adl  C1IOO_WFS1_SETTINGS.adl.old  C1IOO_WFS_MASTER_BAK.adl
C1IOO_MC_ALIGN.adl~       C1IOO_MC_LOCKINS.adl         C1IOO_WFS2_I.adl             C1IOO_WFS_OUTMATRIX.adl
C1IOO_MC_ALIGN_BAK.adl    C1IOO_MC_SERVO.adl           C1IOO_WFS2_Q.adl             C1IOO_WFS_QPD.adl
C1IOO_MC_ASS.adl          C1IOO_MC_TRANS_QPD.adl       C1IOO_WFS2_SETTINGS.adl      C1IOO_WFS_QPD.adl.old
C1IOO_MC_ASS_LOCKIN1.adl  C1IOO_Mech_Shutters.adl      C1IOO_WFS2_SETTINGS.adl.old  fmX
C1IOO_MC_ASS_LOCKIN2.adl  C1IOO_MODECLEANER.adl        C1IOO_WFS_HEADS.adl          junk
C1IOO_MC_ASS_LOCKIN3.adl  C1IOO_QPDS.adl               C1IOO_WFS_HEADS.adl.old      master
C1IOO_MC_ASS_LOCKIN4.adl  C1IOO_QPDS_BAK.adl           C1IOO_WFS_INMATRIX.adl       svn-commit.tmp~
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master/master/master 0$ helppp
helppp: command not found
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master/master/master 127$ help me
bash: help: no help topics match `me'.  Try `help help' or `man -k me' or `info me'.

  8543   Tue May 7 19:06:45 2013 ManasaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : progress

I have updated the waists (W)  and beam diameters (D) at 1064nm optics on the endtable.

I am not able to locate the characteristics of QPD-Y and oplev PD and hence took the beam diameter to be half of the detector surface area to determine their positions.

Beam diameter on PDA520 used for TRY was calculated using the transimpedance and responsivity of the PD from an old elog in 2004.

ETMY_endtable_New.png 

  8542   Tue May 7 18:42:20 2013 JamieUpdatePSLPMC not locking

I'm just now realizing that the PMC has also not been locked since noon today, and doesn't seem to be responding to anything right now.

wtf is going on here?

  8541   Tue May 7 18:16:37 2013 JamieUpdateComputers40MARS wireless network problems

Here's an example of the total horribleness of what's happening right now:

controls@rossa:~ 0$ ping 192.168.113.222
PING 192.168.113.222 (192.168.113.222) 56(84) bytes of data.
From 192.168.113.215 icmp_seq=2 Destination Host Unreachable
From 192.168.113.215 icmp_seq=3 Destination Host Unreachable
From 192.168.113.215 icmp_seq=4 Destination Host Unreachable
From 192.168.113.215 icmp_seq=5 Destination Host Unreachable
From 192.168.113.215 icmp_seq=6 Destination Host Unreachable
From 192.168.113.215 icmp_seq=7 Destination Host Unreachable
From 192.168.113.215 icmp_seq=9 Destination Host Unreachable
From 192.168.113.215 icmp_seq=10 Destination Host Unreachable
From 192.168.113.215 icmp_seq=11 Destination Host Unreachable
64 bytes from 192.168.113.222: icmp_seq=12 ttl=64 time=10341 ms
64 bytes from 192.168.113.222: icmp_seq=13 ttl=64 time=10335 ms
^C
--- 192.168.113.222 ping statistics ---
35 packets transmitted, 2 received, +9 errors, 94% packet loss, time 34021ms
rtt min/avg/max/mdev = 10335.309/10338.322/10341.336/4.406 ms, pipe 11
controls@rossa:~ 0$ 

Note that 10 SECOND round trip time and 94% packet loss.  That's just beyond stupid.  I have no idea what's going on.

  8540   Tue May 7 17:43:51 2013 JamieUpdateComputers40MARS wireless network problems

I'm not sure what's going on today but we're seeing ~80% packet loss on the 40MARS wireless network.  This is obviously causing big problems for all of our wirelessly connected machines.  The wired network seems to be fine.

I've tried power cycling the wireless router but it didn't seem to help.  Not sure what's going on, or how it got this way.  Investigating...

  8539   Tue May 7 17:30:28 2013 KojiUpdateRF SystemIdeal PRMI RF frequency

To change the MC length is not the point.

If we can improve the length sensing by the intentional shift of the modulation frequency from the MC FSR, that's worth to try, I thought.

But that is tough as the freq difference is 18kHz that is ~x4 of the line width of the MC.
Not only the 55MHz sidebands, but also the 11MHz sidebands will just be rejected.

Nevertheless: Is there any possibility that we can improve anything by shifting the modulation frequency by ~1kHz?

  8538   Tue May 7 17:13:30 2013 JenneUpdateRF SystemIdeal PRMI RF frequency

Koji asked me to look at what the ideal RF modulation frequency is, for just the PRMI case (no arms).  If we had a perfect interferometer, with the sidebands exactly antiresonant in the arms when the arms resonate with the carrier, this wouldn't be an issue.  However, due to vacuum envelope constraints, we do not have perfect antiresonance of the sidebands in the arm cavities.  Rather, the sideband frequencies (and arm lengths) were chosen such that they pick up a minimum amount of extra phase on reflection from the arms.  But, when the arms are off resonance (ex, the ETMs are misaligned), the sideband frequencies see a different amount of phase.   

We want to know what a rough guess (since we don't have a precise number for the length of the PRC since our last vent) is for the ideal RF modulation frequency in just the PRMI. 

If I take (from Manasa's kind measurements from the CAD drawing yesterday) the relevant distances to be:

L_P[meters] = 1.9045 + 2.1155 + 0.4067

L_X[meters] = 2.3070 + 0.0254*n

L_Y[meters] = 2.2372 + 0.0359*n + 0.0254*n

L_PRCL = L_P + (L_X + L_Y)/2 = 6.7616 meters.

The *n factors (n=1.44963) are due to travel through glass of the BS, and the substrate of the ITMs. 

I find the FSR of the PRC to be 22.1686 MHz. For the sidebands to be antiresonant, we want them to be 11.0843 MHz. This would correspond to a mode cleaner length of 27.0466 meters.  Our current modulation frequency of 11.066134 MHz corresponds to a MC length of 27.091 meters.  So, if we want to use this 'ideal' modulation frequency for the PRC, we need to shorten the mode cleaner by 4.4cm!  That's kind of a lot.

  8537   Tue May 7 16:21:01 2013 JenneSummaryLSCError signal simulation in PRMI

I asked Gabriele why it looked like for the PRCL sweep REFL 55 I&Q were zero at zero, but for the MICH sweep only REFL55 I was zero.  He took a look at his code, and found that he was not at the correct locking point.  Here is his email back to me:

I found the reason for the not zero value. Indeed, if you could zoom into the PRCL sweep, you would see that the error signals does not cross zero exactly at PRCL=0, but instead some 50 pm away from zero. This is enough to change a lot the PRCL signal when sweeping MICH. If I put PRCL to the correct zero point, and I sweep MICH, I now get everything at zero. I'm sending again the plots.

The fact that such a small detuning is enough to change PRCL signal when sweeping MICH is due, I believe, to the fact that MICH optical gain is much smaller than PRCL one.

Here are the redone plots:

Phase not tuned:

michsweep_errsigs_phasenottuned.pngprclsweep_errsigs_phasenottuned.png

 

Phase tuned:

michsweep_errsigs_tunedphase.pngprclsweep_errsigs_tunedphase.png

POP22 resonance for MICH and PRCL:

michsweep_pop22.pngprclsweep_pop22.png

POP110 resonance for MICH and PRCL:

michsweep_pop110.pngprclsweep_pop110.png

  8536   Tue May 7 15:09:38 2013 Max HortonUpdateSummary PagesImporting New Code

 

 I am now working on megatron, installing in /home/controls/lal.  I am having some unmet dependency issues that I have asked Duncan about.

  8535   Tue May 7 10:30:32 2013 KojiUpdateLockingPRM yaw responsible for RIN

Quote:

BS is contributing a little bit, but PRM is clearly contributing

No.

While the peak in the PRM OPLEV was more than 10 times higher than the spectrum level without the excitation,
we only saw small peaks in the RIN spectra. This suggests that the PRM angular motion did not contribute to the RIN spectra.

You should divide the POP110I and POPDC spectra by 400 and 450, which was the DC values of these channels, in order to convert them into RIN (1/rtHz)
The OPLEV spectra is calibrated to be urad/rtHz (is this true?) so you can obtain the conversion factor from OPLEV to RIN (1/urad)
by matching the peaks. This way you make a angular noise projection.

Quote:

I think that I need to install one of the T240's on the new granite slab, and see what kind of coherence we have between seismic and PRM yaw motion, and if FF can get rid of it.

Yes we should do that. BTW what should be pushed?

  8534   Tue May 7 03:25:28 2013 JenneUpdateIOOMC WFS drifting??

I'm not sure why, but starting ~3.5 hours ago, the WFS seem to not be holding the MC in optimal alignment. 

The WFS are definitely engaged and the loops are closed, but every time the MC locks, the WFS pitch and yaw values start drifting off.  In particular, the WFS loop actuation pushing on MC2 is in the many hundreds of counts after ~90 minutes of drift time.  I tried offloading those values by moving the MC2 slider, but then I unlocked the MC to check what that did to the alignment, and it was decidedly bad.  So, I'm not sure what's up with the WFS, but I need to look at it tomorrow.

  8533   Tue May 7 03:14:06 2013 JenneUpdateSUSPRM SUS_LSC violin (FM5) set to correct frequency

While looking over Koji's shoulder earlier, I noticed the big peak in the PRM yaw spectrum (and I was starting to get annoyed by the hum....the fibox is so useful in motivating tasks that otherwise get looked over!) 

I used DTT's peak find feature (cursor tab, enable both cursors, select Peak X/Y as your 'statistic', set the 2 cursors to be on either side of the desired peak) to find the frequency of the PRM's violin mode.  It is 627.75 Hz. I adjusted FM5 of the C1:SUS-PRM_LSC filter bank (the "violin" filter) to be centered around this frequency, with the start and stop freqs +\- 4Hz.  I plotted the filter linearly in frequency to ensure that my target freq was not too close to either side of the bandstop.  After loading and engaging the new filter, the hum slowly started to go away. 

Note, for posterity:  The bandstop used to be centered around ~645 Hz or so.  I assume this is a copy-and-paste situation, where we hadn't gone through to check the exact frequency for each optic.

  8532   Tue May 7 03:08:12 2013 JenneUpdate PRM yaw responsible for RIN

Koji spent some time earlier this evening exploring where the excess RIN that we see in the PRC is coming from. 

He did this by locking the PRMI (MICH on AS55Q, PRCL on REFL33I, Pnorm for MICH = sqrt(POP110) with 0.1, Pnorm for PRCL = sqrt(POP110) with 10, MICH gain = -30, PRCL gain = 8), and then exciting each relevant optic, one at a time, in yaw.  The excitation was always using the ASCYAW excitation point on each of the optics (BS, PRM, ITMX, ITMY), with a frequency of 4.56 Hz, and an amplitude of 30 counts.

He also took reference traces with no optics excited.

Here, I plot (for each excited optic separately) the reference traces and traces during excitation for POP110_I_ERR, POPDC, and the OPLEV_YERROR for the optic that is being excited.

What we are looking for (only in yaw, since we see on the cameras that the dominant motion is in yaw) is an increase in POPDC and POP110 at the same frequency as an optic's excitation. 

We see that neither ITM is contributing a noticeable amount to either POPDC or POP110.  BS is contributing a little bit, but PRM is clearly contributingNo this entry should be read. (KA)

A week or two ago, I calculated in elog 8489 that the angular motion that we see does not explain the RIN that we're seeing, unless our cavity is much more unstable than Jamie calculated in elog 8316

I think that I need to install one of the T240's on the new granite slab, and see what kind of coherence we have between seismic and PRM yaw motion, and if FF can get rid of it.

BS_excited.pdf

ITMX_excited.pdf

ITMY_excited.pdf

PRM_excited.pdf

 

  8531   Mon May 6 21:05:06 2013 rana, Jamie, KOjiUpdateIOOmode cleaner not locking

As it turned out, the setting of +26dB for the FSS Fast gain was making the NPRO PZT / Pockels cell crossover too unstable. This was the cause of the large ~30 kHz peak that Jamie was seeing in his spectra (more to follow in the morning).

After recovering the locking, etc. by fiddling with the gains, we went about systematically setting all of the gains/offsets. Jamie's elog will show all of the various spectra with different FSS gains.

For offset setting, this was the procedure:

  1. We want the MC servo board to have zero voltage on its MCL and MCF outputs (aka MC_SLOW_MON and MC_FAST_MON) with the Boosts ON, so we switched ON the 40:4000 and the 2 Super Boosts and put the VCO gain into its nominal +25 dB setting. This saturates the outputs and makes them impossible to use as readbacks so you have to be careful. Get the outputs close to zero as you turn on each boost. Finally, you will see that +/- 1mV of input offset (aka MC_REFL_OFFSET) will flip the FAST output between +/- 10V. This is the right setting.
  2. With the MC board adjusted to send 0 V into the FSS error point, adjust the FSS input offset (with the Common and Fast gains at the nominal values) so that the FAST output voltage goes to +5.5 V. This is the middle of the range for the high voltage driver which drives the NPRO.
  3. Let the MC lock and go through the UP script. When the MCL comes on with the integrator, the FAST voltage will shift from +5.5 V to something else. Use the following line: ezcaservo -r C1:PSL-FSS_FAST -g -1 -s 5.5 C1:SUS-MC2_MCL_OFFSET, to automatically tune the MCL offset.

     

    That's all. I have left the FSS common gain at +10.5 and the Fast gain at +23.5. These seem to be close to the optimum. Jamie will have more tuning tomorrow.
     
    I have also changed the 'mcup' script to set the MCL offset and set the FSS Slow setpoint to shoot for +5.5 V of FSS_FAST.
     
    MC_REFL_OFFSET = +1.176 V
    MC2_MCL_OFFSET = +47.8 counts
    FSS_INOFFSET   = -0.85 V
  8530   Mon May 6 19:04:30 2013 JamieUpdateIOOmode cleaner not locking

About 30 minutes ago the mode cleaner fell out of lock and has since not been able to hold lock for more than a couple seconds.

I'm not sure what happened.  I was in the middle of taking measurements of the MC error point spectrum, which included adjusting the FAST gain.  I've put all the gains back to their nominal levels but no luck.  I'm not sure what else could have gone wrong.  Seismic noise looks relatively quiet. 

  8529   Sat May 4 00:21:00 2013 ranaConfigurationComputersworkstation updates

 Koji and I went into "Update Manager" on several of the Ubuntu workstations and unselected the "check for updates" button. This is to prevent the machines from asking to be upgraded so frequently - I am concerned that someone might be tempted to upgrade the workstations to Ubuntu 12.

We didn't catch them all, so please take a moment to check that this is the case on all the laptops you are using and make it so. We can then apply the updates in a controlled manner once every few months.

  8528   Fri May 3 17:32:59 2013 JenneUpdateLSCRemeasuring the Schnupp asymmetry

I have looked at / analyzed the Schnupp data that Annalisa and I took last week, as well as some more Yarm data that I took this week.

I only have one set of Xarm data, but 3 sets of Yarm data.  I had intended to do careful error analysis of the data, but from the 3 sets of Yarm data, the variance in the answer I get using any one of the Yarm sets is much larger than the error in a single measurement.

 Xarm_SchnuppData_April2013.png

Yarm_SchnuppData_April2013.png

Using the central Yarm zero crossing, I get a Schnupp asymmetry of 3.9cm.  The other 2 Yarm data points give Schnupp asymmetries of 3.7cm and 4.1cm, so I'm claiming a value of 3.9 +\- 0.2cm . This is within error of Jamie's measurement of 3.64 ± 0.32 cm (elog 4821).

  8527   Fri May 3 09:17:41 2013 SteveUpdateSUSETMX needs some help
Attachment 1: ETMX3.2eq.png
ETMX3.2eq.png
  8526   Fri May 3 08:55:55 2013 SteveUpdatePEM3.2 M earthquake
Attachment 1: 3.2eqChannelIland.png
3.2eqChannelIland.png
Attachment 2: 3.2eq.png
3.2eq.png
  8525   Fri May 3 01:24:25 2013 KojiUpdateASSDen fixed the Yarm ASS scripts

Output matrices are added to ASS. Currently ASS is based on the mirror bases.
I prefer to have the actuator bases as the coils are more stable than the sensors.

At this point, the output matrices are identity. So Den's scripts are still working.

Striptool settings were also fixed.

  8524   Thu May 2 19:59:34 2013 JamieUpdateComputer Scripts / Programslookback: new program to look at recent past testpoint data

To aid in lock-loss studies, I made a new program called 'lookback', similar to 'getdata', to look at past data.

When called with channel name arguments, it runs continuously, storing all channel data in a ring buffer.  When the user hits Ctrl-C, all the data in the ring buffer is displayed.  There is an option to store the data in the ring buffer to disk as well.

 

controls@rosalba:/opt/rtcds/caltech/c1/scripts/general 0$ ./lookback -h
usage: lookback [-h] [-l LENGTH] [-o OUTDIR] channel [channel ...]

Lookback on testpoint data. The specified amount of data is stored in a ring
buffer. When Ctrl-C is hit, all data in the ring buffer is plotted. Both 'DQ'
and 'online' test point data is available. Use NDSSERVER environment variable
to specify host:port.

positional arguments:
  channel               Acquisition channel. Multiple channels may be
                        specified and acquired at once.

optional arguments:
  -h, --help            show this help message and exit
  -l LENGTH, --lookback LENGTH
                        Lookback time in seconds. This amount of data will be
                        stored in a ring buffer, and plotted on Ctrl-C.
                        Default is 10 seconds
  -o OUTDIR, --outdir OUTDIR
                        Output directory to write data (will be created if it
                        doesn't exist). Data from each channel stored as
                        '<channel>.txt'. Any existing data files will be
                        overwritten.
controls@rosalba:/opt/rtcds/caltech/c1/scripts/general 0$ 
  8523   Thu May 2 14:14:10 2013 Max HortonUpdateSummary PagesImporting New Code

 

 LALFrame was successfully installed.  Allegra had unmet dependencies with some of the library tools.  I tried to install LALMetaIO, but there were unmet dependencies with other LSC software.  After updating the LSC software, the problem has persisted.  I will try some more, and ask Duncan if I'm not successful.

Installing these packages is rather time consuming, it would be nice if there was a way to do it all at once.

  8522   Thu May 2 01:19:41 2013 ManasaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : progress

I started to put together optics at the endtable. I am attaching the layout with the green blocks showing the optics that are assembled and will not be moved henceforth unless somebody contradicts.

1. Power after HWP = 314mW
    Power before faraday = 310mW
    Power after faraday = 300mW (the power loss while aligning the faraday earlier was due to the AR coating on the focusing lens before the faraday - it was AR coated for visible and that accounted to the power lost)

2. Since we do not know the length of TGG inside faraday, I measured the beam profile after the faraday so that I can trace the beam without any errors to calculate exact mode matching solutions.

3. The NPRO beam seems to be obviously elliptical as seen on the IR card and also from beam profile measurement. So we cannot skip including cylindrical lenses in the layout.

ETMY_0502.png

 

  8521   Thu May 2 00:34:57 2013 KojiUpdateLSClocking

- Routine alignment

Locked the arm cavties. Ran ASS. As this was not enough precise alignment for PRMI locking, Yarm alignment was re-adjusted by sliders.
Xarm was also aligned in the same way.

- OPLEV alignment

Once the arms were aligned, OPLEV spots were adjusted. For this adjustment, PRM had to be aligned and OPLEV servos needed to be turned off.

- LSC offset nulling

While Jenne was measuring the dark output of the POP PD, LSC offset nulling script was executed.

- Compensation of the POP spot size fix

As Jenne reported the POP path now has a lens and the denominator for the normalization got bigger.
To compensate this change, PRMI(sb) was locked by the same configuration as yesterday (i.e. AS55Q for MICH, REFL33I for PRCL). 
After some try and error, configuration for stable locking was found. 

PRCL
Signal source: REFL33I / Normalization POP110I x 1.00 / Trigger POP110I 80up 10down
Servo: input matrix 1.00 -> PRCL Servo FM3/4/5/6 Always ON G=+8.00
Actuator: output matrix 1.00 -> PRM

MICH
Signal source: AS55Q / Normalization POP110I x 0.01 / Trigger POP110I 80up 10down
Servo: input matrix 1.00 -> MICH Servo FM4/5 Always On G=-30
Actuator output matrix -1.00 -> ITMX / +1.00 -> ITMY

This suggests that POP110I signal is 5~6 times more than before the lens was installed. 

- SQRTing option for POP110I was implemented

The PRMI optical gain is derived from (Carrier)x(1st order Sideband) or (2nd order SB)x(1st order SB).
Here the carrier and the 2nd order sidebands are nonresonant.
Therefore the optical gain is proportional to the amplitude power recycling gain of the 1st order sidebands.
On the other hand, POP 2f signals are derived from the product of the 1st and -1st order sidebands.
This means that we should take a sqrt of the POP signals to compensate the recycling gain fluctuation.

Screenshot.png

- Locking with SQRT(POP110I)

PRCL
Signal source: REFL33I / Normalization SQRT(POP110I) x 10 / Trigger POP110I 10up 3down
Servo: input matrix 1.00 -> PRCL Servo FM3/4/5/6 Always ON G=+8.00
Actuator: output matrix 1.00 -> PRM

MICH
Signal source: AS55Q / Normalization SQRT(POP110I) x 0.1 / Trigger POP110I 10up 3down
Servo: input matrix 1.00 -> MICH Servo FM4/5 Always On G=-30
Actuator output matrix -1.00 -> ITMX / +1.00 -> ITMY

The lock seems not so different from the ones without SQRTing.

The spot was still moving in yaw direction. If I chose a correct alignment, I could minimize the modulation of the internal power
by misalignment. As you can see in the following plot.

Screenshot2.png

When the alignment was deviated from the optimum, the misalignment induced RIN was much worse although this was the longest lock I ever had with the PRMIsb. (more than 8 min)

Screenshot3.png

- Locking with other signal sources

REF55I/Q trial:

Demodulation phase was adjusted to make the difference of the peak heights for MICH maximized.
After the lock is acquired, I tried to swap the signal source at the input matrix. PRCL swapping was successful but
MICH swapping was not successfull.

It is much more hard to lock the interferometer with REFL55I compared with REFL33I.

REFL165I/Q trial:

As REFL165 PD never produced any useful signal, I tried to swap it with the BBPD used in the green setup.

- Borrowed the PD, power supply from the green setup.

- Put REFL165PD aside. Placed the BBPD in the path. The DC output was 0.8V. This corresponds to the input power of ~5mW.

- Checked the signal but it was very litte (several counts even at the maximum whitening gain).

- Decided to use the power reduction pick off to introduce much more light on the PD.
  This PO mirror is 90% reflector. Therefore I had to be careful no to fry the diode.
  Currently there are OD1.3 (x1/20) power attenuator to reduce the input power down to 6.5V (40mW).

- The resulting signal is very wiered suggesting the saturation of the PD at the RF stages.

- Probably I need to make a new PD circuit which has the high pass filter to reject other low frequency components.

  8520   Wed May 1 17:36:26 2013 RijuConfigurationRF SystemPD frequency response

 Today I routed fiber from 1x16 splitter to POY table. Manasa helped me doing that. The fiber(25m) was laid on overhead rack through plastic pipe of length ~76ft. We put the fiber inside the pipe using one copper tube, and then tied the plastic pipe on the overhead rack. Finally one end of the fiber was laid on POY table and the other end was connected to the 1x16 splitter. The photographs corresponding are attached. There is no picture of splitter end, cause it was dark that time.

Attachment 1: IMG_0517.JPG
IMG_0517.JPG
Attachment 2: IMG_0518.JPG
IMG_0518.JPG
Attachment 3: IMG_0519.JPG
IMG_0519.JPG
  8519   Wed May 1 14:42:45 2013 JenneUpdateLSCPOP now has lens in front of PD

Quote:

- At the end of the session, Jenne told me that the POP PD still has a large diameter beam. (and a steering mirror with a peculiar reflection angle.)
==> THIS SHOULD BE FIXED ASAP
because the normalization factor can be too much susceptible to the misalignment of the spot.

 Koji set the IFO in a PRM-ITMY configuration for me, while I went to put a lens on the POP path.  Before putting the lens, the maximum average output that I saw from the diode (on a 'scope) was 4.40mV.  After putting in the lens and realigning the beam onto the diode, the new max DCvalue that I saw was 21.6mV.  This is a factor of 4.9. 

EDIT:  The dark value was -3.20mV, so actually the ratio is ~3.25 .

I have not yet done anything to fix the situation of the large angle of incidence on the first out-of-vac steering mirror.

  8518   Wed May 1 10:42:35 2013 SteveUpdateLSCcleanup

 

 Optics from the car were placed into glass door cabinet E0

  8517   Wed May 1 00:05:03 2013 KojiUpdateLSCMore stable lock of PRMI (REF33I and AS55Q)

[Jenne Koji]

- Today the spots were moving more than the usual. The OPLEV screens showed that the spots are too much off from the center.

- Each vertex OPLEVs were checked and OPLEV wonderland was discovered: Other than the usual misalignment of the spots,
it was found that PRM/ITMX/ITMY beams were clipped somewhere in the paths, BS/PRM oplevs had many loose components
including the input lenses (they are still clamped by a single dog clamp THIS SHOULD BE FIXED ASAP).

- On the ITMY table there were so many stray optics. They were removed and put on the wagon next to the ITMY table.
THIS SHOULD BE CLEARED ON THE WEDNESDAY CLEANING SESSION.

- During this OPLEV session, LSCoffset nulling was run.

- After the OPLEV session, the locking became really instantaneous. We wonder which of the OPLEV cleaning, LSC offset nulling,
and the usual seismic activity decay in the evening was effective to make it better.

- Initially the lock was attempted with REFL33I/Q and some ~10sec lock streches were obtained. During this lock,
  the optical gain of AS55Q was measured in relative to REFL33Q. In deed they were calibrated to be the same
  gain at the input matrix.

- After the MICH signal source was switched to AS55Q, the lock streches became more regular and the minutes long.
We precisely tuned the phase of AS55 and REFL55 in terms of the differential excitation of ITMX/Y using lockin (FREQ 250, AMP 1000).

- We noticed that the AS port spot with AS55Q MICH was darker than the REFL33Q MICH. This suggests the existence of residual offset
in REFL33Q. In deed we observed +30cnt offset in REFL33Q when the PRMI is locked with AS55Q MICH.

- Phases and relative gains of the signals were as follows:

PRCL: REFL33I 1.00 =REFL55I +0.4
MICH: AS55Q 29deg x1.00 = REFL33Q -14deg x1.00 = REFL55Q 118deg 0.03?

- We tried to lock PRMI with AS55Q. The acquisition was not as easy as that with REFL33I. This might be from the saturation of the
REFL55I signal. This configuration should tested with different whitening gain. Handing off using the input matrix went well once the
lock was obtained by REFL33I.

- Handing off from AS55Q to REFL55Q was not successful.

- At the end of the session, Jenne told me that the POP PD still has a large diameter beam. (and a steering mirror with a peculiar reflection angle.)
==> THIS SHOULD BE FIXED ASAP
because the normalization factor can be too much susceptible to the misalignment of the spot.

- The configuration of the filters:

PRCL FM3/4/5/6 G=+0.05 / NORM 0.04 POP110I
MICH FM4/5 G=-5.00 / NORM 0.01 POP110I (or none)

Screenshot.png

  8516   Tue Apr 30 23:17:25 2013 JenneUpdateLSCPRCL LSC filters copied to CARM bank temporarily

Koji is working on PRMI locking with different photodiodes, and rather than typing different numbers into the input matrix, it is more convenient to just be able to click on/off buttons for different filter banks.  So, the CARM filter bank in the LSC model is currently being borrowed as a secondary PRCL filter bank.  I have copied all of the current PRCL filters over to the CARM filter bank. 

Just for reference, although we have not yet used CARM for CARM, the previous filters were the "default" set, +6dB, 0:1, 1:5, 1:50, 1000:10, RG3.2, RG16.5, RG24, empty, empty.  These are currently the same in the DARM and MC filter banks, so we can copy them back over in the future.

  8515   Tue Apr 30 23:04:23 2013 JenneConfigurationRF SystemOnly 4 25m cables ordered

I have found in the depths of the elog the (original?) list of fibers and lengths that were decided upon:  elog 6535.

In Suresh's elog, we were assuming that POP22 & POP110 would be served by a single PD.  This is still the nominal plan, although we (Rana is maybe still thinking about this in the back of his head?) think that it might not be feasible.  Riju and I were hoping to put a 4th fiber in the tubing so that we wouldn't have to add it later if POP22 & POP110 are eventually 2 separate PDs.  Anyhow, for now, all we have available are 3 fibers for the POX table, so that is what was installed this afternoon.

  8514   Tue Apr 30 22:40:57 2013 JenneUpdateSUSoplev XY-plots reflect new calibration

Back when Gabriele was here, he and I implemented online calibration of the oplevs, into microradians.  A consequence of this is that all of the XY-plots on the medm screens were too small. 

I have gone through all the screens that I could think of (SUS_SINGLE, SUS_SINGLE_OPTLEV_SERVO, OPLEV_MASTER, OPLEV_SUMMARY, OPLEV_SUMMARY_SMALL_SCALE, IFO_OVERVIEW) and made the range of the XY-plots +/- 100, rather than the old scale of +/-1. 

I have also added red boxes behind the numbers on many (but not yet all) of these screens, so that you can see when (a) the oplev sum is too low, or (b) either the pit or yaw value is over 50 microradians. 

While I was putzing around on the IFO overview screen, I also made the oplev sum numbers clickable, with the related display being that optic's oplev servo screen.

  8513   Tue Apr 30 21:24:15 2013 JenneConfigurationRF SystemPOX fiber laying

Nice work.  That was a lot of effort, but having done it so nicely will definitely pay off, since it is now much harder to break the fibers.

2 small issues:  In your attachment 3, I see a coil of fiber just outside the POX table.  I thought Koji had asked that all spare coiled-up length of fiber always be at the splitter side.  Also, in securing the plastic tubing as it comes down near the PSL table, you have zip-tied the tubing to the PSL table.  Since that is a space that we need to access to align the Xgreen beatnote stuff, please disconnect that zip tie, and secure the tubing on the north side somewhere, underneath the AP table, rather than the PSL table (when you look closer, you may notice that no cables in that bundle are attached to the PSL side at the bottom, for this same reason). 

  8512   Tue Apr 30 19:39:14 2013 RijuConfigurationRF SystemPD frequency response

Today I have rerouted the fibers on POX table. The aim was to lay it overhead through the plastic pipe. A pipe ~50ft (~15.5m) long was taken for this purpose. I disconnected the two 25m long fibers for POP55 and POX11 PD (those had been already routed) from both of their ends - i.e. from the POX table and also from 1x16 splitter. Jenne and Koji suggested that we may have another two PDs ( POP22 and POP110) on POX table in future. So we used another 25m long fiber for these two (POP22/POP110). We could not use two fibers for these two since we have only four 25m long fibers and one of them we need for POY11 PD on POY table. Jenne and me put the three fibers inside the pipe using a copper tube. The tube then was put on the overhead rack, Manasa helped me to do it. The fiber ends were finally laid on the POX table at one end and connected to the 1x16 splitter at the other end.

The corresponding photos are attached herewith.

Attachment 1: IMG_0511.JPG
IMG_0511.JPG
Attachment 2: IMG_0512.JPG
IMG_0512.JPG
Attachment 3: IMG_0513.JPG
IMG_0513.JPG
Attachment 4: IMG_0514.JPG
IMG_0514.JPG
Attachment 5: IMG_0515.JPG
IMG_0515.JPG
  8511   Tue Apr 30 12:25:23 2013 ChloeUpdate QPD

Annalisa and I met yesterday and fixed the voltage regulator on the breadboard so the QPD circuit is working. We will meet with Eric on Thursday to determine the course of action with measurements.

  8510   Tue Apr 30 10:54:35 2013 JenneUpdateSUSETMX restored

I'm not sure why or when it was tripped, but I have restored the ETMX watchdog.

  8509   Mon Apr 29 23:02:48 2013 KojiConfigurationLSCQuestons

Q. How much Schnupp asymmetry we want in order to improve the signal ratio between PRCL/MICH in REFL ports?

Q. How much can we increase Schnupp asymmetry in the practical constraints?

Q. How PRCL/MICH ratio is different the REFL ports?
=> My modeling (many years ago) shows the ratio of {115, 51, 26, 23} for REFL{11, 33, 55, 165}.
These numbers should be confirmed by modern simulation of the 40m with updated parameters.
I should definitely use 55MHz but also prepare better 165MHz too.

Q. How the TT/PRM motions are affecting the lock stability? How can we quantify this effect? How can we mitigate this issue?

Q. Can we somehow change the sensing matrix by shifting the modulation frequency?

Q. Is normalization by POP22 or POP110 actually working well?
=> Time series measurement of error signals & servo inputs

  8508   Mon Apr 29 22:13:41 2013 KojiUpdateLSCLocking with ASDC

Today the locking was not as easy as that was last Friday.
So I tried something new. Today Rana talked about the ASDC locking with POPDC normalization.
This technique was tried. (This is somewhat similar to DC readout.)

PRCL
Signal source: REFL33I / Normalization POP110I x 0.04 / Trigger POP110I 20up 3down, otherwise  untouched from Friday locking
Servo: input matrix 1.00 -> PRCL Servo FM3/4/5/6 Always ON G=+0.06
Actuator: output matrix 1.00 -> PRM

MICH
Signal source: ASDC Offset -109.5 (nominal of the day -49.5) / Normalization POPDC x 1.00 / Trigger POP110I 20up 3down
Servo: input matrix 1.00 -> MICH Servo FM5 Always On G=+10000
ActuaroL output matrix -1.00 -> ITMX / +1.00 -> ITMY

Observation

- POP110I was ~120 during the lock (cf 170 on Friday). So there is some small leakage from the dark port.

- Lock was easier when FM4 of the MICH loop was turned off.

- During the lock horizontal motion of the intracavity mode was visible as usual.

Screenshot.png

  8507   Mon Apr 29 18:53:03 2013 JenneUpdateElectronics1pps timing fiber to OMC rack may be bent

While helping Riju out this afternoon, I noticed that the timing fiber that goes to the OMC rack (near the AP table) was bent, and is now possibly kinked, after the installation of the fiber splitter box. 

The fiber was hanging from the back of the rack, and had been strain relieved.  However, the path that the fiber was taking is now occupied by the fiber splitter for the RF PD diagnostic stuff.  So, the installation of the fiber splitter box put the old timing fiber under tension, causing the fiber to be bent at a little over 90 degrees, since it was pulled tightly against the corner of the splitter's front panel. 

I adjusted the strain relief so that the fiber is loose again, although there is still a bit of a kink that you can feel.  Things (for now) seem to be working, since the 1pps light on the front of the box at the top of the OMC rack is still blinking happily, indicating that the 1pps is still getting there. 

We are not using most of the stuff in that rack right now, but if we have problems in the future, we should check out the fiber to make sure it is still good.

  8506   Mon Apr 29 17:26:22 2013 RijuConfigurationRF SystemPD frequency response

 Today I have rerouted the fibers on AP table to remove the fiber rolls out of the AP table.  I removed the fibers one by one from both ends - from the 1x16 splitter and from the AP table - keeping the fiber roll intact, and then connected it in reverse way, i.e. the fiber end which was on AP table now is connected to the splitter (since length of the outside the roll is shorter that side) and the fiber end connected to splitter is now rerouted on AP table.

We need to keep the fibers in such a fashion so that no sharp bending occurs anywhere, and also it does not get strained due to its weight, particularly near the 1x16 splitter. Jenne suggested to use a plastic box over the splitter rack to keep the fiber rolls for time-being. We discussed a lot how this can be done nicely; in future we may use array of hooks, Koji suggested to use cable hangers and to tie the rolls using more than one hanging point, Jenne suggested to use the bottom shelf of the rack or to use one plastic box with holes. We tried to make holes on the plastic box using drill, but it developed crack on the box. So ultimately I used the opened box only and put it over the rack.

The corresponding photographs are attached herewith.

Tomorrow we will reroute the fibers for POX table.  

Attachment 1: IMG_0504.JPG
IMG_0504.JPG
Attachment 2: IMG_0503.JPG
IMG_0503.JPG
Attachment 3: IMG_0505.JPG
IMG_0505.JPG
Attachment 4: IMG_0506.JPG
IMG_0506.JPG
Attachment 5: IMG_0508.JPG
IMG_0508.JPG
Attachment 6: IMG_0509.JPG
IMG_0509.JPG
Attachment 7: IMG_0510.JPG
IMG_0510.JPG
ELOG V3.1.3-