40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 104 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  4700   Thu May 12 08:54:11 2011 steveUpdateIOOIP_POS cable found

Quote:

A cable for IP_POS has been disconnected at the LSC rack, 1Y2. Due to it currently no IP_POS signal shows up on the digital side.

It looks like we disconnected the cable together with some unused cables when we were cleaning up the wiring of the LSC rack.

The cable, a shielded flat-cable, is supposed to send DC power to the QPD and send the signals from the QPD to an interface board on the LSC rack.

I will check how it used to be and reconnect it.

 I found the disconnected cable, but I do not see the interface board at the LSC rack

  4699   Thu May 12 05:25:26 2011 kiwamuUpdateIOOIP_POS disconnected

A cable for IP_POS has been disconnected at the LSC rack, 1Y2. Due to it currently no IP_POS signal shows up on the digital side.

It looks like we disconnected the cable together with some unused cables when we were cleaning up the wiring of the LSC rack.

The cable, a shielded flat-cable, is supposed to send DC power to the QPD and send the signals from the QPD to an interface board on the LSC rack.

I will check how it used to be and reconnect it.

  13807   Wed May 2 21:39:33 2018 gautamConfigurationALSIR ALS for EY

The new K6XS mounts I ordered have arrived. I want to install one of them at the Y-end. I can't find a picture of the current layout but it exists as there is a hardcopy affixed to the ETMY chamber door, Steve, can we dig this up and put it in the wiki? In any case, the current beam going into the fiber is the pickoff from the post-SHG harmonic separator. I'd like to change the layout a bit, and use a pickoff before the doubling oven, but looking at the optical table, this seems like a pretty involved task and would probably require large scale optical hardware rearrangement. In any case, the MM of the green beam into the Y-arm is <50%, so I would like to redo that as well. Does anyone know of a measurement of the mode from the Lightwave NPRO that is installed at EY? I think Annalisa is the one who installed this stuff, but I can't find an actual NPRO mode measurement in her elog thread.


Found it: elog4874, elog8436. I updated the laser inventory page to link the lasers in use to the most recent mode measurements I could find on the elog. I guess ideally we should also link the AM/PM response measurements.

------------------------------------------------------------------------------------------------------

SV  ETMY optical table layout  

     as of 3-31-2016

The oplev path was optimized with AR coated lenses and new He/Ne laser Jan 24, 2017

  14800   Mon Jul 22 23:53:16 2019 gautamUpdateALSIR ALS locking attempt

Summary:

My goal tonight was to lock the PSL frequency to be resonant in the XARM cavity, using the PSL+EX beat as the error signal. I was not successful - mainly, I was plagued by huge BR mode coupling in the error signal, and I could not enable the BR notch filter in the control loop without breaking the lock. Need to think about next steps.

Details:

  • POX and POY locking was easily restored.
  • EX green alignment was tweaked at the end-table. A large YAW correction was required, which I opted to apply on the mechanical mirror mounts rather than the PZTs. GTRX ~0.4 was recovered.
  • The arm cavity length was first locked using POX as an error signal 
    • Then I looked at the out-of-loop ALS noise, trusting the DFD's V/Hz calibration (red-trace in Attachment #1).
    • I judged it to be close enough to the benchmark reference (green-trace in Attachment #1), and so decided that I could go ahead and try locking.
  • A modified version of the script /opt/rtcds/caltech/c1/scripts/XARM/Lock_ALS_XARM.py was used to transition control from POX to the ALS error signal
    • I found that I had to change the sign of the CARM loop gain for the servo to remain stable (in this config, CARM-->MC2 length, thereby modifying the IMC frequency to keep the PSL resonant in the XARM cavity).
    • I don't know why this sign change was required - we are still sticking to the same convention that the beat frequency increases when the temperature slider for the EX laser is incremented in counts.
    • The script failed multiple times at the BOOST/BR notch filter enabling step.
    • Doing these steps manually, I found that turning the BR notch, FM6, ON destroyed the lock immediately.
    • Motivated by this observation, I looked at the in-loop error signal spectrum, see Attachment #2. Here, the PSL frequency is servoed by the ALS error signal, but the BR notch filter isn't enabled.
    • The Bounce-mode peak is huge - where is this coming from? It is absent in the ALS spectrum when the XARM is locked with POX. So it is somehow connected with actuating on the MC2 suspension? Or is it that the FM6=BounceRoll filter of the XARM loop is squishing the noise when looking at the ALS spectrum in POX lock, i.e. Attachment #1? In which case, why can't I engage FM6 for the CARM loop???

Anyway, now that I have a workable set of settings that gets me close to the ALS lock of the XARM, I expect debugging to proceed faster.


Update 2019 July 23: I looked at the control loop shape today, see Attachment #3. I'm not sure I understand why the "BounceRoll" filter  in this filter bank looks like a resonant gain rather than a notch, as it does for the Oplev or SUSPOS loops for example - don't we want to not actuate at these frequencies because the reason the signal exists is because of the imperfect OSEM/magnet positioning? This does not explain the spectrum shown in Attachment #2 however, as that filter was disabled.

Attachment 1: ALS_X_outOfLoopnoise.pdf
ALS_X_outOfLoopnoise.pdf
Attachment 2: ALS_X_inLoopnoise.pdf
ALS_X_inLoopnoise.pdf
Attachment 3: CARM_loopShape.pdf
CARM_loopShape.pdf
  14521   Mon Apr 8 00:04:08 2019 gautamUpdateALSIR ALS noise budget

To start the noise budgeting, I decided to measure the "DFD noise", which is really the quadrature sum of the following terms:

  • ZHL-3A (RF amplifier) noise, NF ~ 6dB per spec (~ 1nV/rtHz)
  • Delay line demod board noise, ~30nV/rtHz [measurement]
  • AA board noise [measurement]
  • ADC noise

According to past characterizations of these noises, the ADC noise level, which is expected to be at the level of a few uV/rtHz, is expected to be the dominant noise source.

The measurement was made by disconnecting the NF 1611 free space photodiode from the input to the RF amplifier on the PSL table, and connecting a Marconi (f_carrier = 40 MHz, signal level=-5dBm) instead. The phase tracked output was then monitored, and the resulting digital spectrum is the red curve in Attachment #1. The blue curve is the ASD of fluctuations of the beatnote between the PSL and EX IR beams, as monitored by the DFD system, with the X arm cavity length locked to the PSL frequency via the LSC servo, and the EX green frequency locked to the X arm cavity length by the analog PDH servo. 

Conclusions:

Assuming the Marconi frquency noise is lower than the ones being budgeted:

  1. the measured frequency noise is above the DFD noise - this needs to be budgeted.
  2. The DFD noise level is consistent with a frequency discriminant of 15 uV/rtHz and an ADC noise level of 3 uV/rtHz at high frequencies.

Next noises to budget:

  1. In-loop X arm length noise
  2. In-lop EX laser frequency noise
Attachment 1: DFDnoise.pdf
DFDnoise.pdf
  14528   Tue Apr 9 19:07:12 2019 gautamUpdateALSIR ALS noise budget

Updated the noise budget to include the unsuppressed frequency noise from the EX laser. It does not explain the noise between 10-100 Hz, although the 1-3 Hz noise is close.

Actually, I think the curve that should go on the budget is when the X arm length is locked to the PSL frequency, whereas this is when the X arm is just locally damped. I will update it later tonight.

Update 1010pm: I've uploaded the relevant plot as Attachment #2. Predictably, the unsuppressed frequency noise of the EX laser is now higher, because the MC length is a noisier frequency reference than the arm cavity. But still it is a factor of 10 below the measured ALS noise.

Quote:

Next noises to budget:

  1. In-loop X arm length noise
  2. In-lop EX laser frequency noise
Attachment 1: ALS_noiseBudget.pdf
ALS_noiseBudget.pdf
Attachment 2: ALS_noiseBudget.pdf
ALS_noiseBudget.pdf
  13796   Fri Apr 27 01:36:02 2018 gautamConfigurationALSIR ALS noise performance

Summary:

My goal was to do some further characterization of the IR ALS system tonight. With POX as an OOL sensor, I measured an RMS displacement noise of  8 pm with the arm under ALS control. I calculated the CARM linewidth to be 77 Hz (=10.3 pm) for the 40m parameters, assuming 30ppm arm loss. Fuurthermore, this number is 3x better than the 24 pm RMS quoted in the Izumi et. al. paper. Of course I am quoting the best results from my efforts tonight. Conclusions:

  1. [Attachment #1] --- With XARM locked using POX, the ALS beat noise (i.e. Phase Tracker output noise) lines up well with the reference we have been using for some time now (and indeed, is better in some places).
  2. [Attachment #2] --- With the arm locked on ALS and POX as an OOL sensor, I measured performance comparable to this measurement we did sometime last year. Anomalies in this measurement and the one above were what precipitated the IMC noise investigation.
  3. [Attachment #3] --- The above two attachments are not the whole story. During the day, I get significantly worse performance (so much so that I couldn't even do the handoff to ALS control). But in 5 minutes of measurement, the ALS noise seems quite stationary.
  4. [Attachment #4] --- This is really the same as Attachment #2, but I wanted to overlay some vlines. Maybe this is a clue to some 60 Hz / ground loop issues, but the RMS has significant contribution from these harmonics. Tmrw, I will add the old measurement overlaid to this plot (and for what its worth, the Izumi et. al. spectrum as well).
  5. [Attachment #5] --- With the arm under ALS control, I was able to maintain the lock for a solid hour (and more as I write up this elog). Somehow inkscape screwed up the fonts, but main point here is that TRX is stable to within 10% throughout the observation time.

Since the stability and noise seemed quite good, I decided to collect some arm scan data to give to our modeSpec SURFs to practice fitting (which is the short dip in TRX in Attachment #4). Although after the discussion with Rana today, I think it may be that we want to do this measurement in reflection and not transmission, and look for a zero crossing in the PDH signal. In any case, I was able to scan 7 FSRs without any issues. I will upload the data to some git repo. GPS start time is 1208850775, sweep was 3mins long.

I think the next step here is to noise-budget this curve. At least the DFD noises

Attachment 1: 2018_04_BeatMouth_POX.pdf
2018_04_BeatMouth_POX.pdf
Attachment 2: 2018_04_BeatMouth.pdf
2018_04_BeatMouth.pdf
Attachment 3: ALSSpecgram.pdf
ALSSpecgram.pdf
Attachment 4: ALS_ASD.pdf
ALS_ASD.pdf
Attachment 5: ALSstab.pdf
ALSstab.pdf
  14811   Thu Jul 25 12:25:56 2019 gautamUpdateALSIR ALSX noise

Summary:

  1. There are some broad peaks in the ALS out-of-loop noise, centered at ~145 Hz, ~245 Hz and ~570 Hz which are absent in both the POX in-lock error signal and in the green PDH error signals (see Attachment #1). So I conclude they originate in the IR ALS beat chain somewhere. Needs more investigation, in the general quest to improve the ALS noise.
  2. This measurement also shows that the ALS noise is limited by unsuppressed EX green PDH frequency noise above ~400 Hz (100 Hz if you ignore the unexplained broad humps).

These spectra were taken with the arm cavity length locked to the PSL frequency using POX as an error signal, and the EX laser frequency locked to the XARM cavity length by the analog PDH servo at EX, so there is no feedback control with the ALS beat signal as an error signal.

Other details:

  • The transition of arm resonance control from POX to ALS error signal is more robust now - I am able to do this during daytime, and also maintain the lock for >20 minutes at a time.
  • Rana encouraged me not to spend too much time on this - so my next goal here will be to get the Y arm IR ALS working, and then we can control the two arms using ALS error signals in the CARM/DARM basis instead of the X/Y basis.
  • I still think it's worth getting the ALS good enough that the locking becomes repeatable and reliable.
    • The main task here is going to be re-doing the EY green layout to match the EX layout, get good MM into the cavity etc.
    • The IR light also has to be coupled into the fiber at EY.
Attachment 1: ALS_broadPeaks.pdf
ALS_broadPeaks.pdf
  3225   Wed Jul 14 20:15:04 2010 DmassBureaucracyCamerasIR Olympus

I borrowed the Olympus and forgot to leave a note - I should have it for at most a day. dmassey@ligo if you need it urgently

  10654   Thu Oct 30 02:54:38 2014 diegoUpdateLSCIR Resonance Script Status

[Diego, Jenne]

The script is moving forward and we feel we are close, however we still have a couple of issues, which are:

1) some python misbehaviour between the system environment and the anaconda one; currently we call bash commands within the python script in order to avoid using the ezca library, which is the one complaining;

2) the fine scan is somewhat not so robust yet, need to investigate more; the main suspects are the wavelet parameters given to the algorithm, and the Offset and Ramp parameters used to perform the scan.

Here is an example of a best case scenario, with 20s ramp and 500 points:

 

Attachment 1: AllPython_findIRresonance_WL_X_ramp_20_500_2.png
AllPython_findIRresonance_WL_X_ramp_20_500_2.png
Attachment 2: AllPython_findIRresonance_WL_Y_ramp_20_500_2.png
AllPython_findIRresonance_WL_Y_ramp_20_500_2.png
Attachment 3: AllPython_findIRresonance_WL_ramp_20_500_2.png
AllPython_findIRresonance_WL_ramp_20_500_2.png
  10674   Thu Nov 6 01:48:30 2014 diegoUpdateLSCIR Resonance Script Status

 Tonight I tried some more tests on the script; it seems to work better, with both performance and robustness improved, although the Xarm behaved badly almost all the time. I did not perform all the tests I wanted because the ALS lock was pretty unstable tonight (not only because of the X arm), with more than a few lock losses; after the last lock loss, however, I couldn't restore the Xarm. I'll do some more tests as soon I can recover it, or post the result of the first batch of tests.

In addition, I encountered the following error multiple times, but I have no idea about what could it be:

Thu Nov 06 02:00:13 PST 2014
medmCAExceptionHandlerCb: Channel Access Exception:
Channel Name: Unavailable
Native Type: Unavailable
Native Count: 0
Access: Unavailable
IOC: Unavailable
Message: Virtual circuit disconnect
Context: fb.martian.113.168.192.in-addr.arpa:5064
Requested Type: TYPENOTCONN
Requested Count: 0
Source File: ../cac.cpp
Line number: 1214
 

  10676   Thu Nov 6 03:29:00 2014 diegoUpdateLSCIR Resonance Script Status

EDIT on X arm: I found different settings in C1SUS_ITMX, with respect to ETMX, ITMY and ETMY (namely LSC/DAMP is OFF and LSC/BIAS is ON); I don't know if this is intended or for some reason ITMX was not recovered properly after the lock loss, so I didn't change anything, but it may be worth looking into that.

 

Still no luck in recovering the X arm, I am giving up for tonight; honestly I didn't try many things, as I don't know well the system and didn't want to mess things up.

 

Preliminary results so far:

I confirm that the best settings for the ramp of the ALS scan are 20s and 500 points; this causes however the script to be fairly slow (80s for the scan/data collection, 7s for the coarse peak finding, 17s for the fine peak finding, total ~2 min); in the best cases the TR*_OUT obtained is around 0.90, as shown in the first plot (early in the evening, all the following plots are in chronological order, if that can help finding the reason for the X arm misbehaviour...):

AllPython_findIRresonance_WL_ramp_20_500_0.png

 

However, after a few minutes somehow the TR*_OUT went down a bit, without any kind of intervention; also, it is visible the instability of the X arm:

AllPython_findIRresonance_WL_ramp_20_500_0_1.png

 

Even when X arm was somewhat stable, its performance and robustness were (far) worse than the Y arm ones:

AllPython_findIRresonance_WL_ramp_20_500_6.png

The following plot shows (about the Y arm only) that there is still some margin, as the maximum value of TRY_OUT is not completely kept at the end of the procedure:

AllPython_findIRresonance_WL_ramp_20_500_7_Y_rise.png

 

Finally the last plot I managed to obtain, before the X arm went completely crazy...

AllPython_findIRresonance_WL_ramp_20_500_9.png

 

The next step, after obviously figuring out the X arm situation, is to try some averaging during the fine scan, I don' t know if this will improve the situation, however it shouldn't impact on the execution time. Tomorrow I'll post something more detailed on the script itself and the wavelet implementation.

  10687   Fri Nov 7 17:44:10 2014 diegoUpdateLSCIR Resonance Script Status

Yesterday I did some more tests with a modifies script; the main difference is that scipy's default wavelet implementation is quite rigid, and it allows only very few choices on the wavelet. The main issue is that our signal is a real, always positive symmetrical signal, while wavelets are defined as 0-integral functions, and can be both real or complex, depending on the wavelet; I found a different wavelet implementation, and I combined it with some modified code from the scipy source, in order to be able to select different wavelets. The result is the wavelet_custom.py module, which lives in the same ALS script directory and it is called by the script. In both the script and the module there the references I used while writing them. It is now possible to select almost any wavelet included in this custom module; "almost" means that the scipy code that calls the find_peaks_cwt routine is picky on the input parameters of the wavelet function, I may dig into that later. For the last tests, instead of using a Ricker wavelet (aka Mexican hat, or Derivative of Gaussian Order 2), I used a DOG(6), as it also has two lesser positive lobes, which can help in finding the resonance; the presence of negative lobes is, as I said, unavoidable. I attach an example of the wavelet forms that are possible, and in my opinion, excluding the asymmetric and/or complex ones, the DOG(6) seems the best choice, and it has provided slightly better results. There are other wavelet around, but they are not included in the module so I should implement them myself, I will first see if they seem fitting our case before starting writing them into the module. However, the problem of not finding the perfect working point (the "overshoot-like" plot in my previous elog) is not completely solved. Eric had a good idea about that: during the fine scan, the the PO*11_ERR_DQ signals should be in their linear range, so I could also use them and check their zero crossing to find the optimal working. I will be working on that.

Attachment 1: wavelets.nb.zip
  10747   Wed Dec 3 01:18:15 2014 diegoUpdateLSCIR Resonance Script Status

Tonight I started testing a new method for the fine scan:

  • the idea is to use the zero crossings of the PO*11_ERR_DQ signals after (or as an alternative of) the fine scan, but such signals are quite dirty, so I need to find some good way to smooth/filter them;
  • I didn't manage to make many tests, because:
    • once arms were locked fine with ALS, the CARM & DARM lock wasn't very robust, in both acquiring and maintaining lock;
    • during the night, the slow OFSs of the arms misbehaved, and at least once per arm they raised their warning box (independently from each other, and it was hastily recovered), even for values that had been perfectly fine before; I am confused about this;
    • as a result, notwithstanding many tries, the beatnotes are gone;
  • I have enough information to push the script a little further, but I'll do more testing soon;

 

  10749   Wed Dec 3 02:01:57 2014 KojiUpdateLSCIR Resonance Script Status

The other night (before the holidays), I tried ALS offset tuning  with IR POX/POY signals and it worked pretty good.
I didn't need to tune the offset after the scanning script stopped.

Once we are at the foot hill of the main resonance, I ran something like

ezcaservo -r C1:LSC-POX11_I_MON C1:LSC-ALSX_OFFSET -g -0.003 &
ezcaservo -r C1:LSC-POY11_I_MON C1:LSC-ALSY_OFFSET -g -0.003 &

(... I am writing this with my memory. I could be wrong but conceptually the commands looked like these)

  4306   Wed Feb 16 02:04:11 2011 kiwamuUpdateASCIR beam alignment

[Jenne and Kiwamu]

 This time we aligned the vertical angle (not the translation) of the IR beam so that the transmitted light from BS shoots the center of ETMY.

The idea is to use ETMY as a beam pointing reference instead using IP_ANG, assuming the translation is not so bad.

As a result it looks like we are wining. A quick A2L test on ITMX_PITCH showed a small off-centering at sub-milimeter level.

 

 We are concluding that the initial beam after PZT2 had been pointing downward somehow.

Before doing this whole job, we checked the spot shape on IP_POS to see if the beam is clipped or not. It was a round shape, which means no clipping around MMT.

But on the other hand, the spot on IP_ANG had been clipped more than half of its bottom as Suresh reported on his elog (see here).

I found that this clipping is able to be fixed by moving the beam angle upward. I guess the clipping happened at one of the steering mirror in the ETMY chamber.

According to these information, we imagined that the beam was somehow pointing downward after PZT2.

So we started aligning the beam by touching only PZT2 for vertical direction. Then we found a beam spot on ETMY's suspension frame, and brought it to the center.

Then we aligned BS and X arm for this new beam axis. The it resulted a small off-centering on pitch.

Once the MC fully gets back, we will examine the TRX degradation with this configuration.

  4295   Tue Feb 15 03:10:37 2011 kiwamuUpdateASCIR beam alignment for Xarm : TRX reduction

I tried aligning the IR beam axis for the X arm to have good beam centering on ITMX and ETMX.

As a first attempt, I started translating the beam upward by steering PZT1 and PZT2, since the pitch was quite off from the center on ITMX.

As a result I could decrease the pitch off-centering down to about 0.5 mm on ITMY, but on the other hand TRX decreased a lot (by a factor of 4).

I am worrying if something in the central part of IFO might be clipping the beam.

 


(notes)

When I was touching PZT1 and PZT2, I payed attention on IP_ANG so that I don't lose a beam spot on IP_ANG.

As long as the beam is on the IP_ANG QPD, the angle of the beam should not be so much different.

Each time after I touched the PZTs, I realigned ITMX and ETMX to maximize the transmitted light.

In this way I proceeded the alignment by changing the PZT offsets little by little while keeping the X arm locked always.

At the beginning, all the PZT offsets were zero. And at the end of this work they became:

 C1:LSC-PZT1_Y = 1.880

 C1:LSC-PZT2_Y = -1.699

But during this alignment work TRX gradually decreased eventually down to 0.25, which had been 1 at the beginning (TRX is calibrated by dividing it by its maximum power).

Along with this TRX reduction, I found that the optical gain also decreased by a factor of about 5.

This fact has been confirmed by intentionally increasing the filter gain such that the servo oscillates at the UGF.
 

Quote:

The amounts of the X arm's beam off-centering have been measured by the A2L technique.

     - ETMX

         PIT  = -1.61 mm

         YAW =  -0.918 mm

    - ITMX

         PIT = -3.76 mm

        YAW = -2.24 mm

 

  10110   Fri Jun 27 23:49:56 2014 KojiUpdateGeneralIR beam found, TTs not aligned well yet

The IR beam was found on the PRM surface, some CCDs, and in the X arm. The TTs are not aligned well yet.

I'm leaving the IFO with the following state.


Status:

ITMY/ETMY - aligned to the given green beam. GTRY (no PSL green) 1.0~1.1

ITMX/ETMX - aligned to the green beam. The end PZT for the green beam was steered to have maximum GTRX (0.76 without PSL green)

TT1/TT2 - unknown alignment, TT1/TT2 are related such that the spot is on the POP CCD

PRM - aligned to the given IR beam (i.e. PRM spot on the REFL CCD)

BS - aligned to the given IR beam (i.e. ITMX spot on the AS CCD, The X arm is flashing)


Notes:

- ITMX was stuck in the suspension. it was caused by the EQ.

- When the X arm was aligned to the green beam, there was no green hitting on the GTRX PD. That's why the end PZT was adjusted.

- In order to earn more range for TT1, C1:IOO-TT1_YAW_GAIN and C1:IOO-TT1_PIT_GAIN were increased to 300 (100 nominal) and the limiter (at 500) were removed.

- The HeNe laser for BS/PRM does not emit the beam even with the driver turned on. Is there a hidden shutter or something? ==> Jenne

 


TO DO:

- Find the Y arm fringe by moving TT1 and TT2 without loosing the PRM/AS/POP spots.

 

  6758   Tue Jun 5 22:03:22 2012 JenneOmnistructureGreen LockingIR beat signal at PSL

Yuta is going to bring this up at the 40m meeting so it can be argued over, but we (I) want a permanent IR beat setup at the PSL table.  This isn't a novel idea or anything, I just think it will save us time if we can quickly re-acquire the beat signal, so I'm bringing it up again.  Eventually, as Koji suggested to me, we can make the IR beat part of a servo, so that the green beat is always within the bandwidth of the green beat PD.  But for Phase 1, it's enough to just see the Ir beat on a ~1GHz PD.  Suresh tells me most of the bits and pieces are around, we just have to gather them all in one place.

  11556   Tue Sep 1 17:07:06 2015 ericqUpdateLSCIR beatnote confusion

There has been some discussion here and there of using fiber coupled IR beats for ALS. A few weeks ago, and again today with Eric G, I poked around a bit with the fiber box Manasa set up for the FOL scheme. 

Somehow, the IR beatnote is ~1000 times smaller than expected, both with the Thorlabs fiber coupled PD and a fiber coupled NF 1611.

In essence, after the fiber combiner, there is on the order of hundreds of uW each of PSL and AUX X IR light. The output of the fiber from each source looks nice and gaussian. The DC output of the 1611 indicates that it is seeing the right level of light. The green beatnote exists with good SNR at twice the IR beat frequency, so we know that the IR beat isn't some junky modes beating. 

For the 1611, we would expect an RF signal of ~1mW*0.9A/W*700V/A -> .6V / +8dBm. Instead we see ~2mV / -40dBm.

Incidentally, there is some 20mV / -20dBm signal at ~400kHz, presumably from the green PDH modulation at ~200k. 

(The level out of the thorlabs PD is similarly tiny; it doesn't have a DC output though, so we don't know the DC power that the active surface really sees. Not that I expect it to be much different, but the NF just makes it easier to estimate.)

The only things that should be able to cause the beat to be smaller than expected from the power levels are mode matching and polarization matching. All the fibers are single mode, so mode matching should be effectively 100%. Maybe somthing fishy is happening with the polarizations, but they'd have to be really maliciously close to orthogonal to cause this level of mismatch. 

Maybe we just don't understand the splitter/combiners. Mysterious.

  11557   Tue Sep 1 17:38:58 2015 ericqUpdateLSCIR beatnote confusion
Quote:

Maybe we just don't understand the splitter/combiners.

After an email from Eric G, I think this is the case.

If you read the text at Thorlabs about Fiber-Based Polarization Beam Combiners/Splitters, it suggests that these things take input beams both aligned to their slow axes, and outputs one field along the slow, and one orthogonal to it on the fast axis. Which is exactly what we don't want for a beat. 

  11559   Wed Sep 2 13:44:04 2015 ericqUpdateLSCIR beatnote confusion

From the AFW website about our product, the POBC-64-C-1-7-2-25dB:

port1 slow axis -> port3 slow axis 
port2 slow axis -> port3 fast axis

crying

  11568   Thu Sep 3 17:15:26 2015 ericqUpdateLSCIR beatnote confusion

I was thinking that the "FOSC" product line (which is called a "coupler" instead of a "splitter/combiner") was what we wanted. 

Koji brought to my attention that the 90/10 splitters we already have are of this line. So, I rigged a few up to shine a hopefully beating pair of fields on the fiber coupled thorlabs PD. 

I was able to get ~80uW each of PSL and AUX X light on the PD, which produced a -10dBm beatnoteyes Thus, I think these FOSC splitters are indeed what we want. 

I then threw this IR beatnote at our ALS signal chain. The beatnote was too big to throw through our ~+27dB RF amps, so I just sent the -10dBm over to the LSC rack.

The IR beat spectrum is somwhat noisier from 10-100Hz, but, more interesting, is that the sub-4Hz noise is identical in the two beats, and very coherent. This excludes ALS noise arising from anything happening in the green beat optics on the PSL table.

Obviously, the high frequency noise is largely the same and coherent too, but also coherent with the AUX X PDH control signal, so it is understood. 

Attachment 1: GREENvIRbeats.pdf
GREENvIRbeats.pdf
  11575   Fri Sep 4 09:36:48 2015 SteveUpdateLSCIR beatnote confusion.....

 

Quote:

I was thinking that the "FOSC" product line (which is called a "coupler" instead of a "splitter/combiner") was what we wanted. 

Koji brought to my attention that the 90/10 splitters we already have are of this line. So, I rigged a few up to shine a hopefully beating pair of fields on the fiber coupled thorlabs PD. 

I was able to get ~80uW each of PSL and AUX X light on the PD, which produced a -10dBm beatnoteyes Thus, I think these FOSC splitters are indeed what we want. 

I then threw this IR beatnote at our ALS signal chain. The beatnote was too big to throw through our ~+27dB RF amps, so I just sent the -10dBm over to the LSC rack.

The IR beat spectrum is somwhat noisier from 10-100Hz, but, more interesting, is that the sub-4Hz noise is identical in the two beats, and very coherent. This excludes ALS noise arising from anything happening in the green beat optics on the PSL table.

Obviously, the high frequency noise is largely the same and coherent too, but also coherent with the AUX X PDH control signal, so it is understood. 

FOSC-2-64-50-L-1-H64F-2
Single mode coupler, 2x2, 1064nm +/-20nm, 50/50 ratio, 900micron loose tube jacket, Hi1060flex fiber, 1m fiber length, FC/APC connectors

Four of these items ordered yesterday from http://afwtechnologies.com.au/sm_coupler.html

  8127   Thu Feb 21 13:34:35 2013 JenneUpdateTreasureIR card removed

Quote:

The sensor card on the bottom of the chamber was not salvaged yet.

 Yuta retrieved the IR card that had fallen to the bottom of the IOO chamber, just before we put on the access connector yesterday.  The clean "pickle picker" long grabber tool worked wonders.

  9446   Fri Dec 6 10:03:07 2013 SteveUpdateSUSIR effect on MC sensors only

Quote:

 Sorry to say but MC1, MC2, MC3 and PRM face OSEMS are having the same problem of leaking IR into the sensors

The PMC was not locked for 11 minutes on this plot.

 

 The PRM sensors are no longer effected by IR. What changed? The MC still does.

Attachment 1: 10minPMCnotLocked.png
10minPMCnotLocked.png
Attachment 2: 6Dec2013.png
6Dec2013.png
  9386   Thu Nov 14 14:35:12 2013 SteveUpdateSUSIR effect on MC and PRM sensors

 Sorry to say but MC1, MC2, MC3 and PRM face OSEMS are having the same problem of leaking IR into the sensors

The PMC was not locked for 11 minutes on this plot.

 

Attachment 1: MC_PRM_IReffect.png
MC_PRM_IReffect.png
  4099   Fri Dec 31 12:41:02 2010 ranaUpdateGeneralIR flashes

I came in today to check up on the StripTool and burn the Ubuntu LTS (new CDS OS) DVD. I was pretty excited to see the PRM flashes on Mon1.

I waggled the PRM/BS alignments and got a good contrast MICH and then bright flashes in the PRM that totally overload Mon1's CCD.

Now I can see flashes of some IR junk in the X Arm; its way off on the left edge of the mirror, but there's a beam.

For the short term, we can hook up the IO PZTs to some old EPICS channels (like one of the AUX guys in the LSC area), but eventually it has to get hooked up to the new ASC or ASS. We have to bug Joe to see where this shows up in his master diagram.

**Note: if you get lost sometimes when doing the alignments, remember that you can use time_machine_conlog.

Ex:

rossa:general>./time_machine_conlog 2010/12/31,11:00:00 PDT C1:SUS-ITMX_PIT_COMM
Issuing the conlog command:
/cvs/cds/caltech/conlog/bin/conlog +epics -interp at 2010/12/31,11:00:00 PDT "C1:SUS-ITMX_PIT_COMM"


Conlog Replied:

LIGO controls: values at 2010 12/31 11:00:00 pst
 __Epics_Channel_Name______   __value_____
 C1:SUS-ITMX_PIT_COMM         0.406100



Restoring now...

Restoration Successful

Attached is the last 8 days of Vacuum Pressure trend which includes the pumpdown.

Attachment 1: Untitled.png
Untitled.png
  12465   Thu Sep 1 19:59:22 2016 JohannesUpdateSUSIR mode flashes in Y arm

[Gautam, Lydia, Johannes]

  • After placing the irises on the ETMY and ITMY cages we found that the green beam pointing was off in YAW and corrected it to hit the center of ITMY
  • The green beam was well centered on ETMY to begin with, so we used it as a reference for the alignment of ITMY, sending it back through the ETMY iris
  • We used the green transmission to tune the pitch and yaw of ETMY
  • Using TT1 and TT2 we steered the beam IR through both irises and were hoping to see mode flashes in the IR arm transmission, which we did

The next step is the tip tilt fine alignment of the IR into the arm, using TRY, from which we removed the ND filter for the time being.

  12166   Fri Jun 10 12:09:01 2016 jamieConfigurationCDSIRIG-B debugging

Looks like we might have a problem with the IRIG-B output of the GPS receiver.

Rolf came over this morning to help debug the strange symmetricom driver behavior on fb1 with the new Spectracom card.  We restarted the machine againt and this time when we loaded the drive rit was clocking at a normal rate (second/second).  However, the overall GPS time was still wrong, showing a time in October from this year.

The IRIG-B122 output is supposed to encode the time of year via amplitude modulation of a 1kHz carrier.  The current time of year is:

controls@fb1:~ 0$ TZ=utc date +'%j day, %T'
162 day, 18:57:35
controls@fb1:~ 0$ 

The absolute year is not encoded, though, so the symmetricon driver has the year offset hard coded into the driver (yuck), to which it adds the time of year from the IRIG-B signal to get the correct GPS time.

However, loading the symmetricom module shows the following:

...
[ 1601.607403] Spectracom GPS card on bus 1; device 0
[ 1601.607408] TSYNC PIC BASE 0 address = fb500000
[ 1601.607429] Remapped 0xffffc90017012000
[ 1606.606164] TSYNC NOT receiving YEAR info, defaulting to by year patch
[ 1606.606168] date = 299 days 18:28:1161455320
[ 1606.606169] bcd time = 1161455320 sec  959 milliseconds 398 microseconds  959398630 nanosec
[ 1606.606171] Board sync = 1
[ 1606.616076] TSYNC NOT receiving YEAR info, defaulting to by year patch
[ 1606.616079] date = 299 days 18:28:1161455320
[ 1606.616080] bcd time = 1161455320 sec  969 milliseconds 331 microseconds  969331350 nanosec
[ 1606.616081] Board sync = 1
controls@fb1:~ 0$ 

Apparently the symmetricom driver thinks it's the 299nth day of the year, which of course corresponds to some time in october, which jives with the GPS time the driver is spitting out.

Rolf then noticed that the timing module in the VME crate in the adjacent rack, which also receives an IRIG-B signal from the distribution box, was also showing day 299 on it's front panel display. We checked and confirmed that the symmetricom card and the VME timing module both agree on the wrong time of year, strongly suggesting that the GPS receiver is outputing bogus data on it's IRIG-B output, even though it's showing the correct time on it's front panel.  We played around with setting in the GPS receiver to no avail.  Finally we rebooted the GPS receiver, but it seemed to come up with the same bogus IRIG-B output (again both symmetricom driver and VME timing module agree on the wrong day).

So maybe our GPS receiver is busted?  Not sure what to try now.

 

  5836   Mon Nov 7 17:27:28 2011 jamieUpdateComputersISCEX IO chassis timing slave dead

It appears that the timing slave in the c1iscex IO chassis is dead.  It's front "link" lights are dark, although there appears to be power to the board (other on-board leds are lit).  These front lights should either be on and blinking steadily if the board is talking to the timing system, or blinking fast if there is no connection to the timing distribution box.  This likely indicates that the board has had some sort of internal failure.

Unfortunately Downs has no spare timing slave boards lying around at the moment; they're all stuffed in IO chassis awaiting shipping.  I'm going to email Rolf about stealing one, and if he agrees we'll work with Todd Etzel to pull one out for a transplant

  5854   Wed Nov 9 18:02:42 2011 jamieUpdateCDSISCEX front-end working again (for the moment...)

The c1iscex IO chassis seems to be working again, and the iscex front-end is running again.

However, I can't say that I actually fixed the problem.

Originally I thought the timing slave board had died by the fact that the front LED indicators next to the fiber IO were out.  I didn't initially consider this a power supply problem since there were other leds on the board that were lit.  I finally managed to track down Rolf to give downs the OK to pull the timing boards out of a spare IO chassis for us to use.  However, when I replaced the timing boards in the chassis with the new ones, they showed the exact same behavior.

I then checked the power to the timing boards, which comes off a 2-pin connector from the backplane board in the back of the IO chassis.  Apparently it's supposed to be 12V, but it was only showing ~2.75V.  Since it was showing the same behavior for both timing boards, I assumed that the issue was on the IO chassis backplane.

I (with the help of Todd Etzel) started pulling cards out of the IO chassis (while power cycling appropriately, of course) to see if that changed anything.  After pulling out both the ADC and DAC cards, the timing system then came up fine, with full power.  The weird part is that everything then stayed fine after we started plugging all the cards back in.  We eventually got back to the fully assembled configuration with everything working.  But, nothing was changed, other than just re-seating all the cards.

Clearly there's some sort of flaky connection on the IO chassis board.  Something is prone to shorting, or something, that overloads the power supply and causes the voltage supply to the timing card to drop.

All I can do at this point is keep an eye on it and go through another round of debugging if it happens again.

If it does happen again, I ask that everyone please not touch the IO chassis and let me look at it first.  I want to try to poke around before anyone giggles any cables so I can track down where the issue might be.

  5830   Mon Nov 7 14:50:19 2011 JenneUpdateComputersISCEX is having a bad day

I clicked on the FE status screen, just to check on things, and everything on the c1iscex section was red (the IOP and c1scx).  Upon deciding that was probably a bad thing, I did a soft reboot from the control room.  Now the IOP says "NO SYNC", and the c1scx status thing is totally frozen. 

I have sent Jamie a whiny email. He promises to be here soon to fix it.

  243   Wed Jan 16 19:57:49 2008 tobinConfigurationPhotosISCT_EX
Here's a photo of the ISCT_EX table, for the purpose of planning our auxiliary laser arm locking scheme. Note the (undumped!) beam from the beamsplitter before QPDX (the leftmost gold-colored box); perhaps we could inject there.
Attachment 1: trx-annotated-small.jpg
trx-annotated-small.jpg
  5568   Wed Sep 28 21:23:23 2011 MirkoUpdateComputersISCY FE network card / cable not ok

[Mirko,Jenne]

We discovered that the left network cable is not rigidly connected to the back of the ISCY FE computer. You can easily pull it out a mm disconnecting it. It should click rigidly in place. Not clear if it's the cable or the network card.

  85   Thu Nov 8 18:44:01 2007 tobinConfigurationPSLISS
Tobin, Rob

With the Sense PD blocked, I adjusted the offset trim of the fourth stage in the ISS servo until the current shunt signal was zeroed. After this adjustment, we are able to crank the ISS gain all the way up to 30 dB without CS saturations (provided the HEPA is turned down to a very quiet level), getting about 35kHZ UGF at that gain setting. However, the current shunt mean value was still enormous.

Examining the current shunt signal on a fast scope, we saw an enormous (>2Vpp) 3.6 MHz sawtooth signal. Going up the chain of op-amps, we found that U1, as measured at the "Filter Out" testpoint, is oscillating wildly at 12 MHz (680 mVpp).
  89   Fri Nov 9 17:33:33 2007 robConfigurationPSLISS

The 3.7 MHz is actually on the light. It's the beat between the 29.5 MHz sidebands and the 33.2 MHz sidebands. There are pads in the ISS PCB for a filter to notch this frequency--John is working on it.

I also found a 1.2 ND filter on the lens which focuses the beam on the ISS diodes. I replaced it with a 0.6 ND filter, which brought the ISS DC level (on the screen) up to ~4.2 (it saturates at 5). Once John finishes the filter we should be able to crank up the gain.
  96   Mon Nov 12 15:18:34 2007 robUpdatePSLISS

After John soldered a 3.7 MHz notch filter onto the ISS board, I took a quick TF and RIN measurement. The out-of-loop RIN is attached, including a dark noise trace, and with the gain slider at 10dB. The UGF is 35kHz with a phase margin of 30deg. John is currently doing a more thorough inspection, and will detail his findings in a subentry.
Attachment 1: ISS.png
ISS.png
  97   Mon Nov 12 23:44:19 2007 JohnUpdatePSLISS

Quote:

After John soldered a 3.7 MHz notch filter onto the ISS board, I took a quick TF and RIN measurement. The out-of-loop RIN is attached, including a dark noise trace, and with the gain slider at 10dB. The UGF is 35kHz with a phase margin of 30deg. John is currently doing a more thorough inspection, and will detail his findings in a subentry.


No progress on the ISS tonight. I tried to implement a new filter (attached)to try and gain some phase before the notch. If anything this made things worse. More work is needed.

The ISS loop is off and the power is off at the chassis.
Attachment 1: ISSfilter.jpg
ISSfilter.jpg
  101   Wed Nov 14 12:47:19 2007 tobinUpdatePSLISS
John, Tobin

With John's notch filter installed and the increased light on the ISS sensing diode, we were able to get a UGF of about 60 kHz with the gain slider set to about 20 dB. This morning we met with Stefan to learn his ISS-fu.

His recommendations for the ISS include:
  • Replace the cables from the board to the front panel connectors if this hasn't already been done.
  • Replace the input opamps with 4131's. Be sure to test both positive and negative input signals.
  • Check that all the compensation capacitors are in place and are 68 pF
  • Make sure all the feedback loops have high frequency rolloff
  • The ISS board reads the PDs differentially; make sure the PD sends differentially.
  • Add a big (ie 10uF tantalum) capacitor to the PD to suppress power supply noise
  • Add bigger power supply bypass caps to the ISS
I just took sensing noise spectra (from the PD DC bnc ports) and then took the photodiodes off the table to check that they have the negative end of the differential line connected to ground. (I placed black metal beam blocks on the table in place of the ISS PD's. Also, from the ISS schematic, it looks like it sends a differential output to the PD DC bnc ports, but we have been plugging them directly into the SR785 (grounding the shield). We should make a little BNC-doodle that separates the signal+shield to go into the A and B inputs on the spectrum analyzer.) Opening up one of the photodiodes, it appears that the negative line of the differential output is not connected. Will continue later this afternoon.
  103   Wed Nov 14 17:50:00 2007 tobinUpdatePSLISS
Here's the current wiring between the ISS and its PDs:

pin cable PD ISS
1 blue +5 +5
2 red +15 +15
3 white -15 -15
4 brown OUT IN PD +
5,6,7,8 no connection no connection GND
9 black GND IN PD -


The schematics for the ISS and the PDs are linked from our wiki.

We'll connect the ISS GND to the PD GND.
  137   Wed Nov 28 21:51:52 2007 tobinConfigurationPSLISS
I replaced the front-end differential receivers for the ISS's "inner-loop" sensor and monitor diode inputs with lower-noise THS4131's (formerly THS4151's). I verified operation by taking the transfer function from the "PD+" and "PD-" inputs (separately) to the testpoint following the differential receiver; the surgery appears successful.

I measured the dark spectra at the ISS's DC PD BNC ports and found a noise floor of ~ 16 nV/rtHz, compared with a floor of ~ 22 nV/rtHz last week. This seems to add up, assuming the DC PD port has 0dB gain: the 4131 has a rated noise of 1.3 nV/rtHz and the 4151 a noise floor of 7.6 nV/rtHz, a difference of 6 nV/rtHz. The other change made in that time was to add a larger power supply bypass capacitor in the PD.

There are two of the old 4151 chips still on the ISS board on the two "outer-loop" channels that we don't use. If I dig up any more 5131's I will replace these too for completeness.

There is currently no light on the ISS diodes; I'm not sure where it's intended to come from.
  141   Thu Nov 29 15:17:53 2007 robConfigurationPSLISS

I put some ISS beam on the diode on the PSL table. In the previous layout, this was the monitor diode (and it's labeled monitor) but I plugged it into the sensor jack anyways so we can run with the loop closed for now; we can just switch the cables later. The reason the beam was unclear is because someone popped up a flipper mirror which redirects the beam from the ISS into an OSA.

With the ISS gain slider at 15 dB the UGF is around 40kHz.

Why do we have such short cables for the ISS diodes?
  162   Mon Dec 3 22:20:09 2007 tobinConfigurationPSLISS
I replaced the painfully short 1' cables on the ISS photodiodes with luxurious five foot cables, made by chopping a ten foot Amphenol cable (P/N:CS-DSPMDB09MM-010) in half and using each half for one of the diodes. All of the ISS GND connections are wired to the PD GND, as is the PD- differential signal. The diodes are installed on the PSL table, but I have not tested them beyond looking at the DC values as I blocked/unblocked the beam.
  163   Tue Dec 4 23:16:35 2007 tobinUpdatePSLISS
I was confused to find that I could increase the ISS gain slider all the way from 15dB to 30dB without seeing much of any increase in gain in the measured open-loop transfer function. While making these swept-sine measurements, the saturation indicator almost never tripped, indicating it was seemingly happy. But then I noticed an odd thing: if I disable the test ("analog excitation") input, the saturation indicator trips immediately. I hooked up a scope to the current shunt test point (TP12). With the test input enabled, the loop closed, and the analog excitation port connected to the SR785, I see a a 5 Vpkpk, 2.55 MHz triangle wave there. It is there even if I set the SR785 excitation amplitude to zero, but it disappears if I disconnect the cable from the SR785.

I found oscillations at TP20, TP30, TP36, TP41, and TP42. Many of these are in the (unused) "outer loop" circuitry and currently lack compensation capacitors.
  167   Wed Dec 5 17:49:57 2007 tobinUpdatePSLISS
Attached is a plot of the ISS RIN with a variety of gain settings.

Unfortunately the dark noise is huge now--a result of the new cables & wiring?
Attachment 1: rin.pdf
rin.pdf
  591   Sun Jun 29 11:31:52 2008 JohnSummaryPSLISS
I reduced the gain of the ISS (C1: PSL-ISS_VGAGAIN) from 5dB to 2dB. Any higher and it constantly saturates.
  595   Sun Jun 29 19:53:26 2008 JohnSummaryPSLISS

Quote:
I reduced the gain of the ISS (C1: PSL-ISS_VGAGAIN) from 5dB to 2dB. Any higher and it constantly saturates.


Seemed to go back to normal after the frame builder came back.
  8876   Thu Jul 18 21:45:36 2013 CharlesUpdateISSISS - Full Schematic

 Here I have included the full schematic (so far) of the proposed ISS. There are two sheets: the first schematic details the filter stages and their accompanying circuitry while the second schematic details the RMS threshold detection and subsequent triggering.

The first schematic is fairly self explanatory as to what different portions do, and I have annotated much of the second schematic as there are some non-traditional components etc.

I have not yet included some mechanism to adjust the threshold voltage in real time or any of the power regulation, but these should follow fairly quickly.

Attachment 1: 40mServo_v1.pdf
40mServo_v1.pdf 40mServo_v1.pdf
  8920   Wed Jul 24 22:58:03 2013 CharlesUpdateISSISS - Full Schematic - Updated

 I have made significant changes to the ISS schematic, mostly in the form of adding necessary subsystems.

Some changes I have made:

  • Added a front page with sheet symbols that are representations of the other schematic sheets.
  • Added an 'Excitation' subsystem for use in determining the closed-loop transfer function
  • Added an instrumentation amplifier (with ADA4004s at Rana's recent suggestion) to handle the differential input from the PD
  • Included a switchable inverting amplifier (Gain of 1 or -1) to ensure we have the correct polarity
  • Made it so the first filtering stage is immediately active when the ISS loop is closed
  • Added LP filters with large time constants to buffer/delay trigger signals
  • Added test points all over the board
  • Refined a few buffer amplifiers

On the front page, all inputs and outputs are currently BNC ports, although this is most likely not the final design that will be used. For instance, the ports ENABLE, INPUT GND and INVERT are supposed to be logic inputs for a MAX333a switch. These will most likely be front panel switches that either connect the switch's logic pin to GND (Logic 0) or something like a +5 V supply (Logic 1).

I also have not included power regulation for my board although I have some of the actual D1000217 Chasis Power Regulator boards and I'll incorporate those in my design soon.

Attachment 1: 40mServo_v1.pdf
40mServo_v1.pdf 40mServo_v1.pdf 40mServo_v1.pdf 40mServo_v1.pdf 40mServo_v1.pdf
ELOG V3.1.3-