40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 61 of 344  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  10788   Fri Dec 12 02:30:25 2014 JenneSummaryGeneralPSL table optical layout

Quote:

 

 I missed to elog this earlier. I have temporarily removed the DC photodiode for GTRY to install the fiber holder on the PSL table. So GTRY will not be seeing anything right now.

 

 After some confusion, I discovered this a few hours ago.

  10791   Fri Dec 12 14:38:39 2014 manasaSummaryGeneralFrequency Offset Locking - To Do List (Revised)

Unfortunately the order placed for beam samplers last week did not go through. These will be used at the X and Y end tables to dump the unwanted light appropriately. Since they will not be here until Tuesday, I revised the timeline for FOL related activities accordingly.

Attachment 1: FOLtodolist.pdf
FOLtodolist.pdf
  10792   Fri Dec 12 15:19:04 2014 manasaSummaryGeneralDec 12 - PSL table

Quote:

Unfortunately the order placed for beam samplers last week did not go through. These will be used at the X and Y end tables to dump the unwanted light appropriately. Since they will not be here until Tuesday, I revised the timeline for FOL related activities accordingly.

I was working on the PSL table today. 

Since the rejected 1064nm light after the SHG crystal is not easily reachable to measure beam widths close to the waist, I put a lens f=300mm and measured the beam size around its focus. I used this data and redesigned the telescope using 'a la mode'.

I used a beam splitter to attenuate the beam directed towards the fiber. The reflected beam from BS has been dumped (I need to find a better beam dump than what is being used right now. 

I have only ~200uW at the input of the fiber coupler after the BS and 86uW at the output of the fiber (43% coupling)

I moved the GTRY DC photodiode and the lens in front of it to make space for the fiber coupler mount.

The layout on the PSL table right now is as shown below.

PSLtoFiber.png 

I have also put the fiber chassis inside the PSL enclosure on the rack. I moved the coherent spectrum analyser controller that is not being used to make space on the rack.

PSLfiberChassis.png

 
Attachment 2: PSLfiberChassis.png
PSLfiberChassis.png
  10800   Mon Dec 15 22:40:09 2014 ranaSummaryPSLPMC restored

 Found that the PMC gain has been set to 5.3 dB instead of 10 dB since 9 AM this morning, with no elog entry.

SadToastFace.jpg

I also re-aligned the beam into the PMC to minimize the reflection. It was almost all in pitch.

  10808   Wed Dec 17 11:57:56 2014 manasaSummaryGeneralY arm optical layout

I was working around the PSL table and Y endtable today.

I modified the Y arm optical layout that couples the 1064nm light leaking from the SHG crystal into the fiber for frequency offset locking.

The ND filter that was used to attenuate the power coupled into the fiber has been replaced with a beam sampler (Thor labs BSF-10C). The reflected power after this optic is ~1.3mW and the trasmitted power has been dumped to a razor blade beam dump (~210mW).

Since we have a spare fiber running from the Y end  to the PSL table, I installed an FC/APC fiber connector on the PSL table to connect them and monitored the output power at the Y end itself. After setting up, I have ~620uW of Y arm light on the PSL table (~48% coupling).

During the course of the alignment, I lowered the power of the Y end NPRO and disengaged the ETMY oplev. These were reset after I closed the end table.

Attached is the out of loop noise measurement of the Y arm ALS error signal before (ref plots) and after.

 

Attachment 1: 58.png
58.png
  10829   Mon Dec 22 15:46:58 2014 KurosawaSummaryIOOSeven transfer functions

IMC OL TF has been measured from 10K to 10M

Attachment 1: MC_OLTF.pdf
MC_OLTF.pdf
  10849   Tue Dec 30 20:35:59 2014 ranaSummaryPSLPMC Tune Up
  1. Calibrated the Phase Adjust slider for the PMC RF Modulation; did this by putting the LO and RF Mod out on the TDS 3034 oscope and triggering on the LO. This scope has a differential phase measurement feature for periodic signals.
  2. Calibrated the RF Amp Adj slider for the PMC RF Modulation (on the phase shifter screen)
  3. The PMC 35.5 MHz Frequency reference card is now in our 40m DCC Tree.
  4.  The LO and RF signals both look fairly sinusoidal !
  5. Took photos of our Osc board - they are on the DCC page. Our board is D980353-B-C, but there are no such modern version in any DCC.
  6. The PMC board's Mixer Out shows a few mV of RF at multiples of the 35.5 MHz mod freq. This comes in via the LO, and can't be gotten rid of by using a BALUN or BP filters.
  7. In installed the LARK 35.5 MHz BP filter that Valera sent us awhile ago (Steve has the datasheet to scan and upload to this entry). It is narrow and has a 2 dB insertion loss.

For tuning the phase and amplitude of the mod. drive:

- since we don't have access to both RF phases, I just maximized the gain using the RF phase slider. First, I flipped the sign using the 'phase flip' button so that we would be near the linear range of the slider. Then I put the servo close to oscillation and adjusted the phase to maximize the height of the ~13 kHz body mode. For the amplitude, I just cranked the modulation depth until it started to show up as a reduction in the transmission by ~0.2%, then reduced it by a factor of ~3. That makes it ~5x larger than before.

Attachment 1: 17.png
17.png
Attachment 2: PMCcal.ipynb.xz
Attachment 3: PMC_Osc_Cal.pdf
PMC_Osc_Cal.pdf
  10879   Thu Jan 8 19:02:42 2015 JaxSummaryElectronicsMC demod modifications

Here's a summary of the changes made to the D990511 serial 115 (formerly known as REFL 33), as well as a short procedure. It needed tuning to 29.5MHz and also had some other issues that we found along the way. 

So here's a picture of it as built:

The changes made are:

1. U11 and U12 changed from 5MHz LP to 10 MHz LP filters.

2. Resistors R8 and R9 moved from their PCB locations to between pins 1 (signal) and 3 (ground) of U11 and U12, respectively. These were put in the wrong place for proper termination so it made sense to shift them while I was already replacing the filters.

Also, please note- whoever labeled the voltages on this board needed an extra cup of coffee that day. There are two separate 15V power supplies, one converted from 24V, one directly supplied. The directly supplied one is labeled 15A. This does NOT mean 15 AMPS.

Transfer functions:

Equipment: 4395A, Signal generator (29.5 MHz), two splitters, one mixer

You can't take the TF from PD in to I/Q out directly. Since this is a demod board, there's a demodulating (downconverting) mixer in the I and Q PD in paths. Negligible signal will get through without some signal applied to the L input of the mixer. In theory, this signal could be at DC, but there are blocking capacitors in the LO in paths. Therefore, you have to upconvert the signal you're using to probe the board's behavior before it hits the board.  Using the 4395A as a network analyzer, split the RF out. RFout1 goes to input R, RFout2 goes to the IF port of the mixer. Split the signal generator (SG). SG1 goes to LO in, SG2 goes to the L port of the mixer. The RF port of the mixer (your upconverted RFout2) goes to PD in, and the I/Q out goes back to the A/B port of the 4395A - at the same frequency as the input, thanks to the board's internal downconversion. 

Phase measurement:

Equipment: Signal generator (29.5 MHz), signal generator (29.501 MHz), oscilloscope

Much simpler: 29.5 MHz to the LO input (0 dBm), 29.501 MHz to the PD input (0 dBm), compare the phases of the I/Q outputs on the oscilloscope. There are four variable capacitors in the circuit that are not on the DCC revision of the board - C28-31. On the LO path, C28 tunes the I phase, C30 tunes the Q phase. On the PD path, C29 and 31 appear to be purely decorative - both are in parallel with each other on the PD in Q path, I'm guessing C29 was supposed to be on the PD in I path. Fortunately, C28 and C30 had enough dynamic range to tune the I/Q phase difference to 90 degrees.

Before tuning:

After tuning:

 

  10899   Wed Jan 14 02:11:07 2015 ranaSummaryTreasure2-loop Algebra Loopology

I show here the matrix formalism to calculate analytically the loop TF relationships for the IMC w/ both FSS actuators so that it would be easier to interperet the results.

The attached PDF shows the Mathematica notebook and the associated block diagram.

In the notebook, I have written the single hop connection gains into the K matrix. P is the optical plant, C is the Common electronic gain, F is the 'fast' NPRO PZT path, and M is the phase Modulator.

G is the closed loop gain matrix. The notation is similar to matlab SS systems; the first index is the row and the second index is the column. If you want to find the TF from node 2 to node 3, you would ask for G[[3,2]].

As examples, I've shown how to get the FAST gain TF that I recently made with the Koji filter box as well as the usual OLG measurement that we make from the MC servo board front panel.

Attachment 1: FSSloop.pdf
FSSloop.pdf FSSloop.pdf
Attachment 2: FSSloop.png
FSSloop.png
  10952   Wed Jan 28 23:53:24 2015 KojiSummaryASCXarm ASS fix

X-Arm ASS was fixed.
ASS_DITHER_ON.snap was updated so that the new setting can be loaded from the ASS screen.

The input and output matrices and the servo gains were adjusted as found in the attached image.
The output matrix was adjusted by looking at the static response of the error signals when a DC offset
was applied to each actuator.

The servo was tested with misalignment of the ITM, ETM, and BS. In fact, the servo restored transmission
from 0.15 to 1.

The resulting contrast after ASSing was ~99% level. (I forgot to record the measurement but the dark fringe level of ASDC was 4~5count.)

Attachment 1: 12.png
12.png
  10974   Wed Feb 4 18:27:55 2015 KojiSummaryASCXarm ASS fix

Please remember that Xarm ASS needs FM6 (Bounce filters) to be ON in order to work properly.

  10986   Sat Feb 7 13:34:11 2015 KojiSummaryPSLISS AOM driver check

I wanted to check the status of the ISS. The AOM driver response was measured on Friday night.
The beam path has not been disturbed yet.

- I found the AOM crystal was removed from the beam path. It was left so.

- The AOM crystal has +24V power supply in stead of specified +28V.
  I wanted to check the functionality of the AOM driver.

- I've inserted a 20dB directional coupler between the driver and the crystal.
  To do so, I first turned off the power supply by removing the corresponding fuse block at the side panel of the 1X1 Rack.
  Then ZFDC-20-5-S+ was inserted, the coupled output was connected to a 100MHz oscilloscope with 50Ohm termination.
  Then plugged in the fuse block again to energize the driver box.

  Note that the oscilloscope bandwidth caused reduction the amplitude by a factor of 0.78. In the result, this has already been compensated.

- First, I checked the applied offset from a signal generator (SG) and the actual voltage at the AOM input. The SG OUT
  and the AOM control input are supposed to have an impedance of 50Ohm. However, apparently the voltage seen at the
  AOM in was low. It behaved as if the input impedance of the AOM driver is 25Ohm.
  In any case, we want to use low output impedance source to drive the AOM driver, but we should keep this in mind.

- The first attachment shows the output RF amplitude as a function of the DC offset. The horizontal axis is the DC voltage AT THE AOM INPUT (not at the SG out).
  Above 0.5V offset some non linearity is seen. I wasn't sure if this is related to the lower supply voltage or not. I'd use the nominal DC of 0.5V@AOM.

  The output with the input of 1V does not reach the specified output of 2W (33dBm). I didn't touch the RF output adjustment yet. And again the suppy is not +28V but +24V.

- I decided to measure the frequency response at the offset of 0.53V@AOM, this corresponds to the DC offset of 0.8V. 0.3Vpp oscillation was given.
  i.e. The SG out seen by a high-Z scope is V_SG(t) = 1.59 + 0.3 Sin(2 pi f t) [V]. The AOM drive voltage V_AOM(t) = 0.53 + 0.099 Sin(2 pi f t).
  From the max and min amplitudes observed in the osciiloscope, the response was checked. (Attachment 2)
  The plot shows how much is the modulation depth (0~1) when the amplitude of 1Vpk is applied at the AOM input.
  The value is ~2 [1/V] at DC. This makes sense as the control amplitude is 0.5, the applied voltage swings from 0V-1V and yields 100% modulation.

  At 10MHz the first sign of reduction is seen, then the response starts dropping above 10MHz. The specification says the rise time of the driver is 12nsec.
  If the system has a single pole, there is a relationship between the rise time (t_rise) and the cut-off freq (fc) as fc*t_rise = 0.35 (cf Wikipedia "Rise Time").
  If we beieve this, the specification of fc is 30MHz. That sounds too high compared to the measurement (fc ~15MHz).
  In any case the response is pretty flat up to 3MHz.

Attachment 1: AOM_drive.pdf
AOM_drive.pdf
Attachment 2: AOM_response.pdf
AOM_response.pdf
  10988   Sun Feb 8 21:54:50 2015 ranaSummaryPSLISS AOM driver check

This is good news. It means that the driver probably won't limit the response of the loop - I expect we'll get 20-30 deg of phase lag @ 100 kHz just because of the acoustic response of the AOM PZT + crystal.

  11005   Wed Feb 11 18:11:46 2015 KojiSummaryLSC3f modulation cancellation

33MHz sidebands can be elliminated by careful choice of the modulation depths and the relative phase between the modulation signals.
If this condition is realized, the REFL33 signals will have even more immunity to the arm cavity signals because the carrier signal will lose
its counterpart to produce the signal at 33MHz.

Formulation of double phase modulation

m1: modulation depth of the f1 modulation
m2: modulation depth of the f2 (=5xf1) modulation

The electric field of the beam after the EOM

E=E_0 \exp \left[ {\rm i} \Omega t + m_1 \cos \omega t +m_2 \cos 5 \omega t \right ]
\flushleft = {\it E}_0 e^{{\rm i} \Omega t} \\ \times \left[ J_0(m_1) + J_1(m_1) e^{{\rm i} \omega t}- J_1(m_1) e^{-{\rm i} \omega t} + J_2(m_1) e^{{\rm i} 2\omega t}+ J_2(m_1) e^{-{\rm i} 2\omega t} + J_3(m_1) e^{{\rm i} 3\omega t}- J_3(m_1) e^{-{\rm i} 3\omega t} + \cdots \right] \\ \times \left[ J_0(m_2) + J_1(m_2) e^{{\rm i} 5 \omega t}- J_1(m_2) e^{-{\rm i} 5 \omega t} + \cdots \right]
\flushleft = {\it E}_0 e^{{\rm i} \Omega t} \\ \times \left\{ \cdots + \left[ J_3(m_1) J_0(m_2) + J_2(m_1) J_1(m_2) \right] e^{{\rm i} 3 \omega t} - \left[ J_3(m_1) J_0(m_2) + J_2 (m_1) J_1(m_2) \right] e^{-{\rm i} 3 \omega t} + \cdots \right\}

Therefore what we want to realize is the following "extinction" condition
J_3(m_1) J_0(m_2) + J_2(m_1) J_1(m_2) = 0

We are in the small modulation regime. i.e. J0(m) = 1, J1(m) = m/2, J2(m) = m2/8, J3(m) = m3/48
Therefore we can simplify the above exitinction condition as

m_1 + 3 m_2 = 0

m2 < 0 means the start phase of the m2 modulation needs to be 180deg off from the phase of the m1 modulation.

E = E_0 \exp\left\{ {\rm i} [\Omega t + m_1 \cos \omega t + \frac{m_1}{3} \cos (5 \omega t + \pi)] \right \}

Field amplitude m1=0.3, m2=-0.1 m1=0.2, m2=0.2
Carrier 0.975 0.980
1st order sidebands 0.148 9.9e-2
2nd 1.1e-3 4.9e-3
3rd 3.5e-7 6.6e-4
4th 7.4e-3 9.9e-3
5th 4.9e-2 9.9e-2
6th 7.4e-3 9.9e-3
7th 5.6e-4 4.9e-4
8th 1.4e-5 4.1e-5
9th 1.9e-4 5.0e-4
10th 1.2e-3 4.9e-3
11th 1.9e-4 5.0e-4
12th 1.4e-5 2.5e-5
13th 4.7e-7 1.7e-6
14th 3.1e-6 1.7e-5
15th 2.0e-5 1.6e-4

 

  11029   Sat Feb 14 19:54:04 2015 KojiSummaryLSC3f modulation cancellation

Optical Setup

[Attachment 1]

Right before the PSL beam goes into the vacuum chamber, it goes through an AR-wedged plate.
This AR plate produces two beams. One of them is for the IO beam angle/position monitor.
And the other was usually dumped. I decided to use this beam.

A G&H mirror reflects the beam towards the edge of the table.
A 45deg HR mirror brings this beam to the beat set up at the south side of the table.
This beam is S-polarlized as it directly comes from the EOM.

[Attachment 2]

The beam from the PSL goes through a HWP and some matching lenses before the combining beam splitter (50% 45deg P).
The AUX laser beam is attenuated by a HWP and a PBS. The transmitted beam from the PBS is supposed
to have P-polarization. The beam alignment is usually done at the PSL beam side.

The combined beam is steered by a HR mirror and introduced to Thorlabs PDA10CF. As the PD has small diameter
of 0.5mm, the beam needed to be focused by a strong lens.

After careful adjustment of the beam mode matching, polarization, and alignment, the beatnote was ~1Vpp for 2.5Vdc.
In the end, I reduced the AUX laser power such that the beat amplitude went down to ~0.18Vpp (-11dBm at the PD,
-18dBm at the mixer, -27dBm at the spectrum analyzer) in order to minimize nonlinearity of the RF system and
in order that the spectrum analyzer didn't need input attenuation.

Electrical Setup

[Attachment 3]

The PD signal is mixed with a local oscillator signal at 95MHz, and then used to lock the PLL loop.
The PLL loop allows us to observe the peaks with more integration time, and thus with a better signal-to-noise ratio.

The signal from the PD output goes through a DC block, then 6dB attenuator. This attenuator is added to damp reflection
and distortion between the PD and the mixer. When the PLL is locked, the dominant signal is the one at 95MHz. Without this attenuator,
this strong 95MHz signal cause harmonic distortions like 190MHz. As a result, it causes series of spurious peaks at 190MHz +/- n* 11MHz.

10dB coupler is used to peep the PD signal without much disturbing the main line. Considering we have 6dB attanuator,
we can use this coupler output for the PLL and can use the main line for the RF monitor, next time.

The mixer takes the PD signal and the LO signal from Marconi. Marconi is set to have +7dBm output at 95MHz.
FOr the image rejection, SLP1.9 was used. The minicirsuit filters have high-Z at the stop band, we need a 50Ohm temrinator
between the mixer and the LPF.

The error signal from the LPF is fed to SR560 (G=+500, 1Hz 1st-order LPF). I still don't understand why I had to use a LPF
for the locking.
As the NPRO PZT is a frequency actuator, and the PLL is sensitive to the phase, we are supposed to use
a flat response for PLL locking. But it didn't work. Once we check the open loop TF of the system, it will become obvious (but I didn't).

The actuation signal is fed to the fast PZT input of the AUX NPRO laser.
 

Attachment 1: beat_setup1.JPG
beat_setup1.JPG
Attachment 2: beat_setup2.JPG
beat_setup2.JPG
Attachment 3: electrical_setup.pdf
electrical_setup.pdf
  11031   Sat Feb 14 20:37:51 2015 KojiSummaryLSC3f modulation cancellation

Experimental results

- PD response [Attachment 1]

The AUX laser temperature was swept along with the note by Annalisa [http://nodus.ligo.caltech.edu:8080/40m/8369]
It is easier to observe the beat note by closing the PSL shutter as the MC locking yields more fluctuation of the PSL
laser freuqency at low frequency. Once I got the beat note and maximized it, I immediately noticed that the PD response
is not flat. For the next trial, we should use Newfocus 1611. For the measurement today, I decided to characterize the
response by sweeping the beat frequency and use the MAXHOLD function of the spectrum analyzer.

The measured and modelled response of the PD are shown in the attachment 1. It has non-intuitive shape.
Therefore the response is first modelled by two complex pole pair at 127.5MHz with Q of 1, and then the residual was
empirically fitted with 29th polynomial of f.

- Modulation profile of the nominal setting [Attachment 2]

Now the spectrum of the PD output was measured. This is a stiched data of the spectrum between 1~101MHz and 99~199MHz
that was almost simultaneously measured (i.e. Display 1 and Display 2). The IF bandwidth was 1kHz. The PD response correction
described above was applied.

It obviously had the peaks associated with our main modulations. In addition, there are more peaks seen.
The attachment 2 breaks down what is causing the peaks.

  • Carrier: The PLL LO frequency is 95MHz. Therefore the carrier is locked at 95MHz.
  • Modulation sidebands (11/55MHz series):
    Series of sidebands are seen at the both side of the carrier. Their frequency is 95MHz +/- n * fmod  (fmod = 11.066128MHz).
    Note that the sidebands for n>10 were above 200MHz, and n<-9 (indicated in gray) were folded at 0Hz.
    With this measurement BW, the following sidebands were buried in the noise floor.
    n = -8, -12, -13, and -14, n<= -16, and n>=+7
  • Modulation sidebands for IMC and PMC (29.5MHz and 35.5MHz):
    First order sidebands for the IMC and PMC modulations of sidebands are seen at the both side of the carrier.
    Their frequency is 95MHz +/- 29.5MHz or 33.5MHz. The PMC modulation sidebands are supposed to be blocked
    by the PMC. However, due to finite finesse of the PMC, small fraction of the PMC sidebands are transmitted.
    In deed, it is comparable to the modulation depth of the IMC one.
  • RF AM or RF EMI for the main modulation and the IMC modulationand:
    If there is residual RF AM in the PSL beam associated with the IMC and main modulations, it appears as the
    peaks at the modulation frequency and its harmonics. Also EM radiation couples into this measument RF system
    also appears at these frequencies. They are seen at n * fmod  (n=1,2,4,5) and 29.5MHz.
  • Reflection/distortion or leakage from mixer IF to RF:
    The IF port of the mixer naturally has 190MHz signal when the PLL is locked. If the isolation from the IF port to the RF port
    is not enough, this signal can appear in the RF monitor signal via an imperfection of the coupler or a reflection from the PD.
    Also, if the reflecrtion/distortion exist between the PD and the mixer RF input, it also cause the signal around 190MHz.
    It is seen at 190MHz +/- n* fmod. In the plot, the peak at n=0, -1 are visible. In fact these peak were secondarily dominant
    in the spectrum when there was no 6dB attenuation in the PD line. WIth the attenuator, they are well damped and don't disturb
    the main measurment.

From the measured peak height, we are able to estimate the modulation depths for 11MHz, 55MHz, IMC modulations, as well as
the relative phase of the 11MHz and 55MHz modulation. (It is not yet done).

- 3f modulation reduction [Attachment 3]

Now, the redcution of the 3f modulation was tried. The measured modulation levels for the 11MHz and 55MHz were almost the same.
The calculation predicts that the modulation for the 55MHz needs to be 1/3 of the 11MHz one. Therefore the attenuation of 9dB and 10dB
of the modulation attenuation knob at the frequency generation box were tried.

To give the variable delay time in the 55MHz line, EG&G ORTEC delay line unit was used. This allows us to change the delay time from
0ns to 63.5ns with the resolution of 0.5ns. The frequency of 55MHz yields a phase sensitivity of ~20deg/ns (360deg/18ns).
Therefore we can adjust the phase with the precision of 10deg over 1275deg.

The 3rd-order peak at 61.8MHz was observed with measurement span of 1kHz with very narrow BW like 30Hz(? not so sure). The delay
time was swept while measuring the peak height each time. For both the atteuation, the peak height clearly showed the repeatitive dependence
with the period of 18ns, and the 10dB case gave the better result. The difference between the best (1.24e-7 Vpk) and the worst (2.63e-6 Vpk)
was more than a factor of 20.
The 3rd-order peak in the above broadband spectrum measurement was 6.38e-6 Vpk. Considering the attenuation
of the 55MHz modulation by 10dB, we were at the exact unluck phase difference.
The improvement expected from the 3f reduction (in the 33MHz signal)
will be about 50, assuming there is no other coupling mechanism from CARM to REFL33.

I decided to declare the best setting is "10dB attenuation & 28ns delay".

- Resulting modulation profile [Attachment 4]

As a confirmation, the modulation profie was measured as done before the adjustment.
It is clear that the 3rd-order modulation was buried in the floor noise. 10dB attenuation of the 55MHz modulation yields corresponding reduction of the sidebands.
This will impact the signal quality for the 55MHz series error signals, particularly 165MHz ones. We should consider to install the Teledyne Cougar amplifier
next to the EOM so that we can increase the over all modulation depth.

Attachment 1: beat_pd_response.pdf
beat_pd_response.pdf
Attachment 2: beat_nominal.pdf
beat_nominal.pdf
Attachment 3: 3f_reduction.pdf
3f_reduction.pdf
Attachment 4: beat_3f_reduced.pdf
beat_3f_reduced.pdf
  11032   Sat Feb 14 22:14:02 2015 KojiSummaryLSC[HOW TO] 3f modulation cancellation

When I finished my measurements, the modulation setup was reverted to the conventional one.
If someone wants to use the 3f cancellation setting, it can be done along with this HOW-TO.


The 3f cancellation can be realized by adding a carefully adjusted delay line and attenuation for the 55MHz modulation
on the frequency generation box at the 1X2 rack.  Here is the procedure:

1) Turn off the frequency generation box

There is a toggle switch at the rear of the unit. It's better to turn it off before any cable action.
The outputs of the frequency generation box are high in general. We don't want to operate
the amplifiers without proper impedance matching in any occasion.

2) Remove the small SMA cable between 55MHz out and 55MHz in (Left arrow in the attachment 1).

According to the photo by Alberto (svn: /docs/upgrade08/RFsystem/frequencyGenerationBox/photos/DSC_2410.JPG),
this 55MHz out is the output of the frequency multiplier. The 55MHz in is the input for the amplifier stages.
Therefore, the cable length between these two connectors changes the relative phase between the modulations at 11MHz and 55MHz.

3) Add a delay line box with cables (Attachment 2).

Connect the cables from the delay line box to the 55MHz in/out connectors. I used 1.5m BNC cables.
The delay line box was set to have 28ns delay.

4) Set the attenuation of the 55MHz EOM drive (Right arrow in the attachment 1) to be 10dB.

Rotate the attenuation for 55MHz EOM from 0dB nominal to 10dB.

5) Turn on the frequency modulation box


For reference, the 3rd attachment shows the characteristics of the delay line cable/box combo when the 3f modualtion reduction
was realized. It had 1.37dB attenuation and +124deg phase shift. This phase change corresponds to the time delay of 48ns.
Note that the response of a short cable used for the measurement has been calibrated out using the CAL function of the network analyzer.

Attachment 1: freq_gen_box.JPG
freq_gen_box.JPG
Attachment 2: delay_line.JPG
delay_line.JPG
Attachment 3: cable_spec.pdf
cable_spec.pdf
  11033   Sun Feb 15 16:20:44 2015 KojiSummaryLSC[ELOG LIST] 3f modulation cancellation

Summary of the ELOGS

3f modulation cancellation theory http://nodus.ligo.caltech.edu:8080/40m/11005

3f modulation cancellation adjustment setup http://nodus.ligo.caltech.edu:8080/40m/11029

Experiment http://nodus.ligo.caltech.edu:8080/40m/11031

Receipe for the 3f modulation cancellation http://nodus.ligo.caltech.edu:8080/40m/11032

Modulation depth analysis http://nodus.ligo.caltech.edu:8080/40m/11036

  11034   Sun Feb 15 20:55:48 2015 ranaSummaryLSC[ELOG LIST] 3f modulation cancellation

I wonder if DRMI can be locked on 3f using this lower 55 MHz modulation depth. It seems that PRMI should be unaffected, but that the 3*f2 signals for SRCL will be too puny. Is it really possible to scale up the overall modulation depths by 3x to compensate for this?

  11035   Mon Feb 16 00:08:44 2015 KojiSummaryLSC[ELOG LIST] 3f modulation cancellation

This KTP crystal has the maximum allowed RF power of 10W (=32Vpk) and V_pi = 230V. This corresponds to the maximum allowed
modulation depth of 32*Pi/230 = 0.44. So we probably can achieve gamma_1 of ~0.4 and gamma_2 of ~0.13. That's not x3 but x2,
so sounds not too bad.

Then Kiwamu's triple resonant circuit LIGO-G1000297-v1 actually shows the modulation up to ~0.7. Therefore it is purely an issue
how to deliver sufficient modulation power. (In fact his measurement shows some nonlinearity above the modulation depth of ~0.4
so we should keep the maximum power consumption of 10W at the crystal)

This means that we need to review our RF system (again!)

- Review infamous crazy attn/amp combinations in the frequency generation box.
- Use Teledyne Cougar ampilfier (A2CP2596) right before the triple resonant box. This should be installed closely to the triple resonant box in order to
minimize the effects of the reflection due to imperferct impedance matching.
- Review and refine the triple resonant circuit - it's not built on a PCB but on a universal board. I think that we don't need triple
resonance, but double is OK as the 29.5MHz signal is small.

We want +28V supply at 1X1 for the Teledyne amp and the AOM driver. Do we have any unused Sorensen?

  11036   Mon Feb 16 01:45:12 2015 KojiSummaryLSCmodulation depth analysis

Based on the measured modulation profiles, the depth of each modulation was estimated.
Least square sum minimization of the relative error was used for the cost function.
-8th, -12th~-14th, n=>7th are not included in the estimation for the nominal case.
-7th~-9th, -11th~-15th, n=>7th are not included in the estimation for the 3f reduced case.

Nominal modulation

m_f1 = 0.194
m_f2 = 0.234
theta_f1f2 = 41.35deg
m_IMC = 0.00153

3f reduced modulation

m_f1 = 0.191
m_f2 = 0.0579
theta_f1f2 = 180deg
m_IMC = 0.00149

(Sorry! There is no error bars. The data have too few statistics...)

Attachment 1: modulation_nominal.pdf
modulation_nominal.pdf
Attachment 2: modulation_3f_reduced.pdf
modulation_3f_reduced.pdf
  11106   Fri Mar 6 00:59:13 2015 ranaSummaryIOOMC alignment not drifting; PSL beam is drifting

In the attached plot you can see that the MC REFL fluctuations started getting larger on Feb 24 just after midnight. Its been bad ever since. What happened that night or the afternoon of Feb 23?
The WFS DC spot positions were far off (~0.9), so I unlocked the IMC and aligned the spots on there using the nearby steering mirrors - lets see if this helps.

Also, these mounts should be improved. Steve, can you please prepare 5 mounts with the Thorlabs BA2 or BA3 base, the 3/4" diameter steel posts, and the Polanski steel mirror mounts? We should replace the mirror mounts for the 1" diameter mirrors during the daytime next week to reduce drift.

Attachment 1: MCdrfit.png
MCdrfit.png
  11109   Fri Mar 6 13:48:17 2015 dark kiwamuSummaryIOOtriple resonance circuit

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

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

(An upgrade plan document)

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

  11112   Fri Mar 6 19:54:15 2015 ranaSummaryIOOMC alignment not drifting; PSL beam is drifting

MC Refl alignment follow up: the alignment from last night seems still good today. We should keep an cool on the MC WFS DC spots and not let them get beyond 0.5.

Attachment 1: Untitled.png
Untitled.png
  11134   Wed Mar 11 19:15:03 2015 KojiSummaryLSCROUGH calibration of the darm spectrum during the full PRFPMI lock

I made very rough calibration of the DARM spectra before and after the transition for the second lock on Mar 8.

The cavity pole (expected to be 4.3kHz) was not compensated. Also the servo bump was not compensated.

[Error calibration]

While the DARM/CARM were controlled with ALS, the calibration of them are provided by the ALS phase tracker calibration.
i.e 1 degree = 19.23kHz

This means that the calibration factor is

DARM [deg] * 19.23e3 [Hz/deg] / c [m Hz] * lambda [m] * L_arm [m]
= DARM* 19.23e3/299792458*1064e-9*38.5 = 2.6e-9 *DARM [m]

[Feedback calibration]

Then, the feedback signal was calibrated by the suspension response (f=1Hz, Q=5)
so that the error and feedback signals can match at 100Hz.

This gave me the DC factor of 5e-8.


The spectra at 1109832200 (ALS only, even not on the resonance) and 1109832500 (after DARM/CARM transitions) were taken.
Jenne said that the whitening filters for AS55Q was not on.

Attachment 1: 150308_DARM_ROUGH_CALIB.pdf
150308_DARM_ROUGH_CALIB.pdf
  11147   Thu Mar 19 16:58:19 2015 SteveSummaryIOOMC alignment not drifting; PSL beam is drifting

Polaris mounts ordered.

Quote:

In the attached plot you can see that the MC REFL fluctuations started getting larger on Feb 24 just after midnight. Its been bad ever since. What happened that night or the afternoon of Feb 23?
The WFS DC spot positions were far off (~0.9), so I unlocked the IMC and aligned the spots on there using the nearby steering mirrors - lets see if this helps.

Also, these mounts should be improved. Steve, can you please prepare 5 mounts with the Thorlabs BA2 or BA3 base, the 3/4" diameter steel posts, and the Polanski steel mirror mounts? We should replace the mirror mounts for the 1" diameter mirrors during the daytime next week to reduce drift.

 

Attachment 1: driftingInputBeam2.jpg
driftingInputBeam2.jpg
  11148   Thu Mar 19 17:11:32 2015 steveSummarySUSoplev laser summary updated

           March  19, 2015   2  new  JDSU 1103P, sn P919645 & P919639 received from Thailand through Edmond Optics. Mfg date 12/2014............as spares

  11149   Fri Mar 20 10:51:09 2015 SteveSummaryIOOMC alignment not drifting; PSL beam is drifting

Are the two  visible small srews holding the adapter plate only?

If yes, it is the weakest point of the IOO path.

Attachment 1: eom4.jpg
eom4.jpg
Attachment 2: eom3.jpg
eom3.jpg
  11158   Mon Mar 23 09:42:29 2015 SteveSummaryIOO4" PSL beam path posts

To achive the same beam height each components needs their specific post height.

 Beam Height Base Plate Mirror Mount Lens Mount  Waveplates-Rotary 0.75" OD. SS Post Height                      
             
4" Thorlabs BA2   Newport LH-1   2.620"  
4" Thorlabs BA2 Polaris K1     2.620"  
4" Thorlabs BA2 Polaris K2     2.220"  
4" Thorlabs BA2   Thorlabs LMR1   2.750"  
4" Thorlabs BA2     New Focus 9401 2.120"  
4" Thorlabs BA2 Newport U100     2.620"  
4" Thorlabs BA2 Newport U200     2.120"  
4" Newport 9021   LH-1   2.0" PMC-MM lens with xy translation stage: Newport 9022, 9065A    Atm3
4" Newport 9021   LH-1   1.89 MC-MM lens with translation stage: Newport 9022, 9025        Atm2

We have 2.625" tall, 3/4" OD SS posts for Polaris K1 mirror mounts: 20 pieces

Ordered Newport LH-1 lens mounts with axis height 1.0 yes

 

Attachment 1: .75odSSpost.pdf
.75odSSpost.pdf
Attachment 2: MC_mml_trans_clamp.jpg
MC_mml_trans_clamp.jpg
Attachment 3: PMCmmLn.jpg
PMCmmLn.jpg
  11171   Wed Mar 25 18:27:34 2015 KojiSummaryGeneralSome maintainance

- I found that the cable for the AS55 LO signal had the shielding 90% broken. It was fixed.

- The Mon5 monitor in the control room was not functional for months. I found a small CRT down the east arm.
It is now set as MON5 showing the picture from cameras. Steve, do we need any safety measure for this CRT?

  11173   Wed Mar 25 18:48:11 2015 KojiSummaryLSC55MHz demodulators inspection

[Koji Den EricG]

We inspected the {REFL, AS, POP}55 demodulators.

Short in short, we did the following changes:

- The REFL55 PD RF signal is connected to the POP55 demodulator now.
Thus, the POP55 signals should be used at the input matrix of the LSC screens for PRMI tests.

- The POP55 PD RF signal is connected to the REFL55 demodulator now.

- We jiggled the whitening gains and the whitening triggers. Whitening gains for the AS, REFL, POP PDs are set to be 9, 21, 30dB as before.
However, the signal gain may be changed. The optimal gains should be checked through the locking with the interferometer.


- Test 1

Inject 55.3MHz signal to the demodulators. Check the amplitude in the demodulated signal with DTT.
The peak height in the spectrum was calibrated to counts (i.e. it is not counts/rtHz)
We check the amplitude at the input of the input filters (e.g. C1:LSC-REFL55_I_IN1). The whitening gains are set to 0dB.
And the whitening filters were turned off.

REFL55
f_inj = 55.32961MHz -10dBm
REFL55I @999Hz  22.14 [cnt]
REFL55Q @999Hz  26.21 [cnt]


f_inj = 55.33051MHz -10dBm
REFL55I @ 99Hz  20.26 [cnt]  ~200mVpk at the analog I monitor
REFL55Q @ 99Hz  24.03 [cnt]


f_inj = 55.33060MHz -10dBm
REFL55I @8.5Hz  22.14 [cnt]
REFL55Q @8.5Hz  26.21 [cnt]


----
f_inj = 55.33051MHz -10dBm
AS55I   @ 99Hz 585.4 [cnt]
AS55Q   @ 99Hz 590.5 [cnt]   ~600mVpk at the analog Q monitor

f_inj = 55.33051MHz -10dBm
POP55I  @ 99Hz 613.9 [cnt]   ~600mVpk at the analog I monitor
POP55Q  @ 99Hz 602.2 [cnt]

We wondered why the REFL55 has such a small response. The other demodulators seems to have some daughter board. (Sigg amp?)
This maybe causing this difference.

-----

- Test 2

We injected 1kHz 1Vpk AF signal into whitening board. The peak height at 1kHz was measured.
The whitening filters/gains were set to be the same condition above.

f_inj = 1kHz 1Vpk
REFL55I 2403 cnt
REFL55Q
2374 cnt
AS55I   2374 cnt
AS55Q   2396 cnt
POP55I  2365 cnt
POP55Q
  2350 cnt

So, they look identical. => The difference between REFL55 and others are in the demodulator.

  11180   Fri Mar 27 20:32:17 2015 KojiSummaryLSCLocking activity

- Adjutsed the IMC WFS operating point. The IMC refl is 0.42-0.43.

- The arms are aligned with ASS

- The X arm green was aligned with ASX. PZT offsets slides were adjusted to offload the servo outputs.

- I tried the locking once and the transition was successfull. I even tried the 3f-1f transition but the lock was lost. I wasn't sure what was the real cause.

I need to go now. I leave the IFO at the state that it is waiting for the arms locked with IR for the full locking trial.

  11235   Wed Apr 22 11:48:30 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

Since the Frequency counters have not been a reliable error signal for FOL PID loop, we will put together an analog delay line frequency dicriminator as an alternative method to obtain the beat frequency.

The configuration will be similar to what was done in elog 4254 in the first place.

For a delay line frequency dicriminator, the output at the mixer is proportional to cos(\theta_{b}) where \theta_{b} = 2 \pi f_{b}L/v

L - cable length asymmetry, fb - beat frequency and v - velocity of light in the cable.

The linear output signal canbe obtained for  0< \theta_{b}<\pi

For our purpose in FOL, if we would like to measure beat frequency over a bandwidth of 200MHz, this would correspond to a cable length difference of 0.5 m (assuming the speed of light in the coaxial cable is ~ 2x108m/s.

  11236   Wed Apr 22 14:56:18 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

[Koji, Manasa]

Since the bandwidth of the fiber PD is ~ 1GHz, we could design the frequency discriminator to have a wider bandwidth (~ 500MHz). The output from the frequency discriminator could then be used to define the range setting of the frequency counter for readout or may be even error signal to the PID loop.

A test run for the analog DFD with cable length difference of 27cm gave a linear output signal with zero-crossing at ~206MHz.

Detailed schematic of the setup and plot (voltage vs frequency) will be updated shortly.

  11245   Fri Apr 24 21:31:20 2015 KojiSummaryCDSautomatic mxstream resetting

We were too much annoyed by frequent stall of mxstream. We'll update the RCG when time comes (not too much future).

But for now, we need an automatic mxstream resetting.

I found there is such a script already.

/opt/rtcds/caltech/c1/scripts/cds/autoMX

So this script was registered to crontab on megatron.
It is invoked every 5 minutes.

# Auto MXstream reset when it fails
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /opt/rtcds/caltech/c1/scripts/cds/autoMX >> /opt/rtcds/caltech/c1/scripts/cds/autoMX.log

  11252   Sun Apr 26 00:56:21 2015 ranaSummaryComputer Scripts / Programsproblems with new restart procedures for elogd and apache

Since the nodus upgrade, Eric/Diego changed the old csh restart procedures to be more UNIX standard. The instructions are in the wiki.

After doing some software updates on nodus today, apache and elogd didn't come back OK. Maybe because of some race condition, elog tried to start but didn't get apache. Apache couldn't start because it found that someone was already binding the ELOGD port. So I killed ELOGD several times (because it kept trying to respawn). Once it stopped trying to come back I could restart Apache using the Wiki instructions. But the instructions didn't work for ELOGD, so I had to restart that using the usual .csh script way that we used to use.

  11267   Fri May 1 20:33:31 2015 ranaSummaryComputer Scripts / Programsproblems with new restart procedures for elogd and apache

Same thing again todaysad. So I renamed the /etc/init/elog.conf so that it doesn't keep respawning bootlessly. Until then restart elog using the start script in /cvs/cds/caltech/elog/ as usual.

I'll let EQ debug when he gets back - probably we need to pause the elog respawn so that it waits until nodus is up for a few minutes before starting.

Quote:

Since the nodus upgrade, Eric/Diego changed the old csh restart procedures to be more UNIX standard. The instructions are in the wiki.

After doing some software updates on nodus today, apache and elogd didn't come back OK. Maybe because of some race condition, elog tried to start but didn't get apache. Apache couldn't start because it found that someone was already binding the ELOGD port. So I killed ELOGD several times (because it kept trying to respawn). Once it stopped trying to come back I could restart Apache using the Wiki instructions. But the instructions didn't work for ELOGD, so I had to restart that using the usual .csh script way that we used to use.

 

  11268   Sun May 3 01:04:19 2015 ranaSummaryPEMSeismo signals are bad

https://ldas-jobs.ligo.caltech.edu/~max.isi/summary/day/20150502/pem/seismic/

Looks like some of our seismometers are oscillating, not mounted well, or something like that. No reason for them to be so different.

Which Guralp is where? And where are our accelerometers mounted?

  11270   Mon May 4 10:21:09 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

Attached is the schematic of the analog DFD and the plot showing the zero-crossing for a delay line length of 27cm. The bandwidth for the linear output signal obtained roughly matches what is expected from the length difference (370MHz) .

We could use a smaller cable to further increase our bandwidth. I propose we use this analog DFD to determine the range at which the frequency counter needs to be set and then use the frequency counter readout as the error signal for FOL.

 

Attachment 1: DFD.png
DFD.png
Attachment 2: DFD_resp.png
DFD_resp.png
  11272   Mon May 4 12:42:34 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

Koji suggested that I make a cosine fit for the curve instead of a linear fit.

I fit the data to V(f) = A + B cos(2\pi f_{b}L/v) 
where L - cable length asymmetry (27 cm) , fb - beat frequency and v - velocity of light in the cable (2*10m/s)

The plot with the cosine fit is attached. 

Fit coefficients (with 95% confidence bounds):
       A =      0.4177  (0.3763, 0.4591)
       B =       2.941  (2.89, 2.992)

Attachment 1: DFD_cosfit.png
DFD_cosfit.png
  11300   Mon May 18 14:46:20 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

Measuring the voltage noise and frequency response of the Analog Delay-line Frequency Discriminator (DFD)

The schematic and an actual photo of the setup is shown below. The setup was checked to be physically sturdy with no loose connections or moving parts.

The voltage noise at the output of the DFD was measured using an SR785 signal analyzer while simultaneously monitoring the signal on an oscilloscope.

The noise at the output of the DFD was measured for no RF input and at several RF input frequencies including the zero crossing frequency and the optimum operating frequency of the DFD (20MHz).

The plot below show the voltage noise for different RF inputs to the DFD. It can be seen that the noise level is slightly lower at the zero crossing frequency where the amplitude noise is eliminated by the DFD.

I also did measurements to obtain the frequency response of the setup as the cable length difference has changed from the prior setup. The cable length difference is 21cm and the obtained linear signal at the output of the DFD extends over ~ 380MHz which is good enough for our purposes in FOL. A cosine fit to the data was done as before. //edit- Manasa: The gain of SR560 was set to 20 to obtain the data shown below//

Fit Coefficients (with 95% confidence bounds):
       a =     -0.8763  (-1.076, -0.6763)
       b =       3.771  (3.441, 4.102)

Data and matlab scripts are zipped and attached.

Attachment 4: DFD.zip
  11368   Mon Jun 22 12:57:09 2015 ericqSummaryLSCX/Y green beat mode overlap measurement redone

I took measurements at the green beat setup on the PSL table, and found that our power / mode overlap situation is still consistent with what Koji and Manasa measured last September [ELOG 10492]. I also measured the powers at the BBPDs with the Ophir power meter.

Both mode overlaps are around 50%, which is fine. 

The beatnote amplitudes at the BBPD outputs at a frequency of about 50MHz are -20.0 and -27.5 dBm for the X and Y beats, respectively. This is consistent with the measured optical power levels and a PD response of ~0.25 A/W at 532nm. The main reason for the disparity is that there is much more X green light than Y green light on the table (factor of ~20), and the greater amount of green PSL light on the Y BBPD (factor of ~3) does not quite make up for it. 

One way to punch up the Y beat a little might be to adjust the pickoff optics. Of 25uW of Y arm transmitted green light incident on the polarizing beamsplitter that seperates the X and Y beams, only 13uW makes it to the Y BBPD, but this would only win us a couple dBms at most. 

In any case, with the beat setup as it exists, it looks like we should design the next beatbox iteration to accept RF inputs of around -20 to -30 dBm. 


In the style of the referenced ELOG, here are today's numbers. 

            XARM   YARM 
o BBPD DC output (mV)
 V_DARK:   +  1.0  + 2.2
 V_PSL:    +  7.1  +21.3
 V_ARM:    +165.0  + 8.2


o BBPD DC photocurrent (uA)
I_DC = V_DC / R_DC ... R_DC: DC transimpedance (2kOhm)

 I_PSL:       3.6   10.7
 I_ARM:      82.5    4.1


o Expected beat note amplitude
I_beat_full = I1 + I2 + 2 sqrt(e I1 I2) cos(w t) ... e: mode overwrap (in power)

I_beat_RF = 2 sqrt(e I1 I2)

V_RF = 2 R sqrt(e I1 I2) ... R: RF transimpedance (2kOhm)

P_RF = V_RF^2/2/50 [Watt]
     = 10 log10(V_RF^2/2/50*1000) [dBm]

     = 10 log10(e I1 I2) + 82.0412 [dBm]
     = 10 log10(e) +10 log10(I1 I2) + 82.0412 [dBm]

for e=1, the expected RF power at the PDs [dBm]
 P_RF:      -13.2  -21.5


o Measured beat note power (no alignment done)     
 P_RF:      -20.0  -27.5  [dBm] (53.0MHz and 46.5MHz) 
    e:       45.7   50.1  [%]                         

 

  11370   Mon Jun 22 14:53:37 2015 ranaSummaryLSCX/Y green beat mode overlap measurement redone
  • Why is there a factor of 20 power difference? Some of it is the IR laser power difference, but I thought that was just a factor of 4 in green.
  • Why is the mode overlap only 50% and not more like 75%?
  • IF we have enough PSL green power, we could do the Y-beat with a 80/20 instead of a 50/50 and get better SNR.
  • The FFD-100 response is more like 0.33 A/W at 532 nm, not 0.25 A/W.

In any case, this signal difference is not big, so we should not need a different amplifier chain for the two signals. The 20 dB of amplification in the BeatBox was a fine way, but not great in circuit layout.

The BBPD has an input referred current noise of 10 pA/rHz and a transimpedance of 2 kOhm, so an output voltage noise of 20 nV/rHz (into 50 Ohms). This would be matched by an Amp with NF = 26 dB, which is way worse than anything we could bur from mini-circuits, so we should definitely NOT use anything like the low-noise, low output power amps used currently (e.g. ZFL-1000LN....never, ever use these for anything). We should use a single ZHL-3A-S (G = 25 dB, NF < 6 dB, Max Out = 30 dBm) for each channel (and nothing else) before driving the cables over to the LSC rack into the aLIGO demod board. I just ordered two of these now.

  11384   Tue Jun 30 11:33:00 2015 JamieSummaryCDSprepping for CDS upgrade

This is going to be a big one.  We're at version 2.5 and we're going to go to 2.9.3.

RCG components that need to be updated:

  • mbuf kernel module
  • mx_stream driver
  • iniChk.pl script
  • daqd
  • nds

Supporting software:

  • EPICS 3.14.12.2_long
  • ldas-tools (framecpp) 1.19.32-p1
  • libframe 8.17.2
  • gds 2.16.3.2
  • fftw 3.3.2

Things to watch out for:

  • RTS 2.6:
    • raw minute trend frame location has changed (CRC-based subdirectory)
    • new kernel patch
  • RTS 2.7:
    • supports "commissioning frames", which we will probably not utilize.  need to make sure that we're not writing extra frames somewhere
  • RTS 2.8:
    • "slow" (EPICS) data from the front-end processes is acquired via DAQ network, and not through EPICS.  This will increase traffic on the DAQ lan.  Hopefully this will not be an issue, and the existing network infrastructure can handle it, but it should be monitored.
  11390   Wed Jul 1 19:16:21 2015 JamieSummaryCDSCDS upgrade in progress

The CDS upgrade is now underway

Here's what's happened so far:

  • Installed and linked in all the RTS supporting software packages in /opt/rtapps (only on front end machines and fb):
    controls@c1lsc ~ 2$ find /opt/rtapps/ -mindepth 1 -maxdepth 1 -type l -ls
    12582916    0 lrwxrwxrwx   1 controls 1001           12 Jul  1 13:16 /opt/rtapps/gds -> gds-2.16.3.2
    12603452    0 lrwxrwxrwx   1 controls 1001           10 Jul  1 13:17 /opt/rtapps/fftw -> fftw-3.3.2
    12603451    0 lrwxrwxrwx   1 controls 1001           15 Jul  1 13:16 /opt/rtapps/libframe -> libframe-8.17.2
    12603450    0 lrwxrwxrwx   1 controls 1001           13 Jul  1 13:16 /opt/rtapps/libmetaio -> libmetaio-8.2
    12582915    0 lrwxrwxrwx   1 controls 1001           34 Jul  1 15:24 /opt/rtapps/framecpp -> ldas-tools-1.19.32-p1/linux-x86_64
    12582914    0 lrwxrwxrwx   1 controls 1001           20 Jul  1 13:15 /opt/rtapps/epics -> epics-3.14.12.2_long
  • Checked out the RTS source for the version we'll be using: 2.9.4

/opt/rtcds/rtscore/tags/advLigoRTS-2.9.4

  • built and installed all of the RTS components:
    • mbuf
    • mx_stream
    • daqd
    • nds
    • awgtpman
       
  • mx_stream is not working. Unknown why. It won't start on the front end machines (only tested on c1lsc so far) with the following error:
    controls@c1lsc ~ 1$ /opt/rtcds/caltech/c1/target/fb/mx_stream -s c1x04 c1lsc c1ass c1oaf c1cal -d fb:0
    mmapped address is 0x7ff7b71a0000
    send len = 263596
    mx_connect failed Remote Endpoint is Closed
    controls@c1lsc ~ 1$
    
    Have contact Keith T. and Rolf B. for backup.  This is a blocker, since this is what ferries the data from the front ends.
     
  • Rebuilt almost all models.  This was good.  Initially nothing would compile because of IPC creation errors, so I moved the old chans/ipc/C1.ipc file out of the way and generated a new one and then everything compiled (of course senders have to be compiled before receivers).
    I only had to fix a couple of things in the models themselves:
    • c1ioo - unterminated FiltCtrl inputs
    • C1_SUS_SINGLE_CONTROL - unterminated FiltCtrl inputs
    • c1oaf - bad part named "STATIC". There is some hacky namespace stuff going on in the RCG. I was able to just explode that part and it now works.
    • c1lsc - unterminated FiltCtrl inputs
    Haven't installed or tried to run anything yet, but the fact they compile is good.
    Some models are not compiling because they have C code in src blocks that are throwing errors:
    • c1lsc
    • c1cal
    It shouldn't be too hard to fix whatever is causing those compile errors.

That's it for today.  Will pick up again first thing tomorrow

  11392   Tue Jul 7 17:22:16 2015 JessicaSummary Time Delay in ALS Cables

I measured the transfer functions in the delay line cables, and then calculated the time delay from that.

The first cable had a time delay of 1272 ns and the second had a time delay of 1264 ns. 

Below are the plots I created to calculate this. There does seem to be a pattern in the residual plots however, which was not expected. 

The R-Square parameter was very close to 1 for both fits, indicating that the fit was good. 

Attachment 1: cableA_fit.jpg
cableA_fit.jpg
Attachment 2: cableA_resid.jpg
cableA_resid.jpg
Attachment 3: cableB_fit.jpg
cableB_fit.jpg
Attachment 4: cableB_resid.jpg
cableB_resid.jpg
  11393   Tue Jul 7 18:27:54 2015 JamieSummaryCDSCDS upgrade: progress!

After a couple of days of struggle, I made some progress on the CDS upgrade today:

Front end status:

  • RTS upgraded to 2.9.4, and linked in as "release":

/opt/rtcds/rtscore/release -> tags/advLigoRTS-2.9.4

  • mbuf kernel module built installed
  • All front ends have been rebooted with the latest patched kernel (from 2.6 upgrade)
  • All models have been rebuilt, installed, restarted.  Only minor model issues had to be corrected (unterminated unused inputs mostly).
  • awgtpman rebuilt, and installed/running on all front-ends
  • open-mx upgraded to 1.5.2:

/opt/open-mx -> open-mx-1.5.2

  • All front ends running latest version of mx_stream, built against 2.9.4 and open-mx-1.5.2.

We have new GDS overview screens for the front end models:

It's possible that our current lack of IRIG-B GPS distribution means that the 'TIM' status bit will always be red on the IOP models.  Will consult with Rolf.

There are other new features in the front ends that I can get into later.

DAQ (fb) status:

  • daqd and nds rebuilt against 2.9.4, both now running on fb

40m daqd compile flags:

cd src/daqd
./configure --enable-debug --disable-broadcast --without-myrinet --with-mx --enable-local-timing --with-epics=/opt/rtapps/epics/base --with-framecpp=/opt/rtapps/framecpp
make
make clean
install daqd /opt/rtcds/caltech/c1/target/fb/

However, daqd has unfortunately been very unstable, and I've been trying to figure out why.  I originally thought it was some sort of timing issue, but now I'm not so sure.

I had to make the following changes to the daqdrc:

set gps_leaps = 820108813 914803214 1119744016;

That enumerates some list of leap seconds since some time.  Not sure if that actually does anything, but I added the latest leap seconds anyway:

set symm_gps_offset=315964803;

This updates the silly, arbitrary GPS offset, that is required to be correct when not using external GPS reference.

Finally, the last thing I did that finally got it running stably was to turn off all trend frame writing:

# start trender;
# start trend-frame-saver;
# sync trend-frame-saver;
# start minute-trend-frame-saver;
# sync minute-trend-frame-saver;
# start raw_minute_trend_saver;

For whatever reason, it's the trend frame writing that that was causing things daqd to fall over after a short amount of time.  I'll continue investigating tomorrow.

 

We still have a lot of cleanup burt restores, testing, etc. to do, but we're getting there.

  11395   Wed Jul 8 17:46:20 2015 JessicaSummaryGeneralUpdated Time Delay Plots

I re-measured the transfer function for Cable B, because the residuals in my previous post for cable B indicated a bad fit. 

I also realized I had made a mistake in calculating the time delay, and calculated more reasonable time delays today. 

Cable A had a delay of 202.43 +- 0.01 ns.

Cable B had a delay of 202.44 +- 0.01 ns. 

Attachment 1: resid_CableA.png
resid_CableA.png
Attachment 2: resid_CableB.png
resid_CableB.png
  11396   Wed Jul 8 20:37:02 2015 JamieSummaryCDSCDS upgrade: one step forward, two steps back

After determining yesterday that all the daqd issues were coming from the frame writing, I started to dig into it more today.  I also spoke to Keith Thorne, and got some good suggestions from Gerrit Kuhn at GEO.

I  realized that it probably wasn't the trend writing per se, but that turning on more writing to disk was causing increased load on daqd, and consequently on the system itself.  With more frame writing turned on the memory consuption increased to the point of maxing out the physical RAM.  The system the probably starting swaping, which certainly would have choked daqd.

I noticed that fb only had 4G of RAM, which Keith suggested was just not enough.  Even if the memory consumption of daqd has increased significantly, it still seems like 4G would not be enough.  I opened up fb only to find that fb actually had 8G of RAM installed!  Not sure what happend to the other 4G, but somehow they were not visible to the system.  Koji and I eventually determined, via some frankenstein operations with megatron, that the RAM was just dead.  We then pulled 4G of RAM from megatron and replaced the bad RAM in fb, so that fb now has a full 8G of RAM cool.

Unfortunately, when we got fb fully back up and running we found that fb is not able to see any of the other hosts on the data concentrator network sad.  mx_info, which displays the card and network status for the myricom myrinet fiber card, shows:

MX Version: 1.2.16
MX Build: controls@fb:/opt/src/mx-1.2.16 Tue May 21 10:58:40 PDT 2013
1 Myrinet board installed.
The MX driver is configured to support a maximum of:
    8 endpoints per NIC, 1024 NICs on the network, 32 NICs per host
===================================================================
Instance #0:  299.8 MHz LANai, PCI-E x8, 2 MB SRAM, on NUMA node 0
    Status:        Running, P0: Wrong Network
    Network:    Myrinet 10G

    MAC Address:    00:60:dd:46:ea:ec
    Product code:    10G-PCIE-8AL-S
    Part number:    09-03916
    Serial number:    352143
    Mapper:        00:60:dd:46:ea:ec, version = 0x63e745ee, configured
    Mapped hosts:    1

                                                        ROUTE COUNT
INDEX    MAC ADDRESS     HOST NAME                        P0
-----    -----------     ---------                        ---
   0) 00:60:dd:46:ea:ec fb:0                            D 0,0

Note that all front end machines should be listed in the table at the bottom, and they're not.   Also note the "Wrong Network" note in the Status line above.  It appears that the card has maybe been initialized in a bad state?  Or Koji and I somehow disturbed the network when we were cleaning up things in the rack.  "sudo /etc/init.d/mx restart" on fb doesn't solve the problem.  We even rebooted fb and it didn't seem to help.

In any event, we're back to no data flow.  I'll pick up again tomorrow.

  11397   Wed Jul 8 21:02:02 2015 JamieSummaryCDSCDS upgrade: another step forward, so we're back to where we started (plus a bit?)

Koji did a bit of googling to determine that 'Wrong Network' status message could be explained by the fb myrinet  operating in the wrong mode:
(This was the useful link to track down the issue (KA))
 

    Network:    Myrinet 10G

I didn't notice it before, but we should in fact be operating in "Ethernet" mode, since that's the fabric we're using for the DC network.  Digging a bit deeper we found that the new version of mx (1.2.16) had indeed been configured with a different compile option than the 1.2.15 version had:

controls@fb ~ 0$ grep '$ ./configure' /opt/src/mx-1.2.15/config.log          
  $ ./configure --enable-ether-mode --prefix=/opt/mx
controls@fb ~ 0$ grep '$ ./configure' /opt/src/mx-1.2.16/config.log
  $ ./configure --enable-mx-wire --prefix=/opt/mx-1.2.16
controls@fb ~ 0$

So that would entirely explain the problem.  I re-linked mx to the older version (1.2.15), reloaded the mx drivers, and everything showed up correctly:

controls@fb ~ 0$ /opt/mx/bin/mx_info
MX Version: 1.2.12
MX Build: root@fb:/root/mx-1.2.12 Mon Nov  1 13:34:38 PDT 2010
1 Myrinet board installed.
The MX driver is configured to support a maximum of:
    8 endpoints per NIC, 1024 NICs on the network, 32 NICs per host
===================================================================
Instance #0:  299.8 MHz LANai, PCI-E x8, 2 MB SRAM, on NUMA node 0
    Status:        Running, P0: Link Up
    Network:    Ethernet 10G

    MAC Address:    00:60:dd:46:ea:ec
    Product code:    10G-PCIE-8AL-S
    Part number:    09-03916
    Serial number:    352143
    Mapper:        00:60:dd:46:ea:ec, version = 0x00000000, configured
    Mapped hosts:    6

                                                        ROUTE COUNT
INDEX    MAC ADDRESS     HOST NAME                        P0
-----    -----------     ---------                        ---
   0) 00:60:dd:46:ea:ec fb:0                              1,0
   1) 00:25:90:0d:75:bb c1sus:0                           1,0
   2) 00:30:48:be:11:5d c1iscex:0                         1,0
   3) 00:30:48:d6:11:17 c1iscey:0                         1,0
   4) 00:30:48:bf:69:4f c1lsc:0                           1,0
   5) 00:14:4f:40:64:25 c1ioo:0                           1,0
controls@fb ~ 0$

The front end hosts are also showing good omx info (even though they had been previously as well):

controls@c1lsc ~ 0$ /opt/open-mx/bin/omx_info
Open-MX version 1.5.2
 build: controls@fb:/opt/src/open-mx-1.5.2 Tue May 21 11:03:54 PDT 2013

Found 1 boards (32 max) supporting 32 endpoints each:
 c1lsc:0 (board #0 name eth1 addr 00:30:48:bf:69:4f)
   managed by driver 'igb'

Peer table is ready, mapper is 00:30:48:d6:11:17
================================================
  0) 00:30:48:bf:69:4f c1lsc:0
  1) 00:60:dd:46:ea:ec fb:0
  2) 00:25:90:0d:75:bb c1sus:0
  3) 00:30:48:be:11:5d c1iscex:0
  4) 00:30:48:d6:11:17 c1iscey:0
  5) 00:14:4f:40:64:25 c1ioo:0
controls@c1lsc ~ 0$

This got all the mx_stream connections back up and running.

Unfortunately, daqd is back to being a bit flaky.  With all frame writing enabled we saw daqd crash again.  I then shut off all trend frame writing and we're back to a marginally stable state: we have data flowing from all front ends, and full frames are being written, but not trends.

I'll pick up on this again tomorrow, and maybe try to rebuild the new version of mx with the proper flags.

ELOG V3.1.3-