40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 110 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  9609   Fri Feb 7 12:43:12 2014 ericqUpdateGeneralIn-Vac Alignment

[ericq]

PRC Locked on Sidebands

Jenne reminded me that if we change a cavity, phases can change... So, first, I locked the PRC on the carrier, and then gave it MICH and PRCL excitations to optimize the AS55 and REFL55 phase rotation angles by looking at the excitation demodulated outputs of the unused quadrature (i.e. we want all of MICH to be in AS55 Q, so I rotated the phase until C1:CAL-SENSMAT_MICH_AS55_I_I_OUTPUT was zero on average).

This resulted in:

  • AS55: 7 -> -5.5
  • REFL55: 73 -> 86.9

I then used the same settings as in ELOG 9554, except I used -1s instead of +1s for the POP110I trigger matrix elements. (I'm not sure why this is different, but I noticed that the PRC would lock on carrier with positive entries here, so I figured we wanted the peaks with opposite sign).

So far, it seems more stable than when we were doing the demodulation phase measurements, it's been locked for >15 minutes without me having to tweak the gains or the alignment from the carrier locked case.

  9610   Fri Feb 7 13:00:52 2014 JenneUpdateGeneralIn-Vac Alignment

Quote:

I then used the same settings as in ELOG 9554, except I used -1s instead of +1s for the POP110I trigger matrix elements. (I'm not sure why this is different, but I noticed that the PRC would lock on carrier with positive entries here, so I figured we wanted the peaks with opposite sign).

 Nice work!!  As with all the other RF PDs, POP110's phase likely needs tuning.  You want POP110 (and POP22) I-quadratures to be maximally positive when you're locked on sidebands, and maximally negative when locked on carrier.  What you can do to get close is lock PRC on carrier, then rotate the POP phases until you get maximally negative numbers.  Then, when locked on sideband, you can tweak the phases a little, if need be.

  9611   Fri Feb 7 13:30:22 2014 GabrieleUpdateGeneralIn-Vac Alignment

Quote:

Quote:

I then used the same settings as in ELOG 9554, except I used -1s instead of +1s for the POP110I trigger matrix elements. (I'm not sure why this is different, but I noticed that the PRC would lock on carrier with positive entries here, so I figured we wanted the peaks with opposite sign).

 Nice work!!  As with all the other RF PDs, POP110's phase likely needs tuning.  You want POP110 (and POP22) I-quadratures to be maximally positive when you're locked on sidebands, and maximally negative when locked on carrier.  What you can do to get close is lock PRC on carrier, then rotate the POP phases until you get maximally negative numbers.  Then, when locked on sideband, you can tweak the phases a little, if need be.

 Very good news! We should have a look at the POP110 sideband peak splitting, to see if we really got the right PRC length... 

  9612   Fri Feb 7 13:30:25 2014 ericqUpdateGeneralIn-Vac Alignment

Quote:

 

 Nice work!!  As with all the other RF PDs, POP110's phase likely needs tuning.  You want POP110 (and POP22) I-quadratures to be maximally positive when you're locked on sidebands, and maximally negative when locked on carrier.  What you can do to get close is lock PRC on carrier, then rotate the POP phases until you get maximally negative numbers.  Then, when locked on sideband, you can tweak the phases a little, if need be.

Adjusted the angles as Jenne suggested:

  • POP22: 105 -> 163
  • POP110: 150 -> -83
  15464   Thu Jul 9 17:12:52 2020 gautamUpdateBHDIn-air BHD

Summary:

We can probably learn something about the interferometer / top level BHD plan with an in-air BHD setup, even if the noise is bad. Here are some thoughts about how we would do it. 

LO delivery:

For this first attempt, we don't really care about the PRC filtering. So possible places to pick off an LO beam are:

LO beam pickoff options
Location Pros Cons
IP POS
  • Filtered by IMC
  • Medium level of invasiveness  
  • We lose the IP POS diagnostic, which is kind of useful nowadays given the drifty TTs.
  • Only few mW LO power available
PSL table IR beam currently going to green doubling setup
  • Least invasive w.r.t. normal IFO operation
  • Plenty of light (~100 mW) available. But how much can we safely couple into fiber?
  • Beam not filtered by IMC (although it is filtered by the PMC)
POX/POY
  • Since this beam is extracted from inside the PRC, probably enjoys the best filtering.
  • Possibly drifts a lot, so tricky to reliably couple into a fiber?
  • Maximally invasive w.r.t. regular IFO operations.

In all cases, I think the easiest option to actually route whatever beam we choose into a fiber, and then bring it over to whatever cavity we choose to use for an OMC. I'm assuming whatever phase control technique we end up using can cancel the fiber phase noise at relevant frequencies.

LO phase control

  • Stress the fiber? This will require us to purchase some custom hardware, and interface it to the CDS system.
  • PZT mirror? We should have sufficient hardware available to drive a PI style PZT mirror.

There is a question about the range, but I think these are the only two realistic options we can implement on a reasonable time scale.

OMC:

Again, there are a few options. Here are some pros and cons that come to my mind.

OMC cavity options
Option Pros Cons
Old copper OMC
  • Probably the simplest option in terms of the peripherals.
  • PZT driver recently verified to work
  • We can get the OMMT and DCPDs out as well.
  • Allows us to not compromise on the RF darm optical gain (not sure if locking will be as easy if we cut the power to the AS55 photodiode by 50-75%).
  • Requires a vent.
  • Probably not the most efficient use of the space on the AP table.
  • Filtering performance isn't quantified.
Spare PMC
  • Doesn't require a vent.
  • Compact footprint.
  • Need to build the cavity.
  • Need to check if the drive electronics from the old copper OMC can easily be interfaced with whatever PZT we use on this cavity.
  • Filtering performance kind of unknown?
Custom cavity with spare mirrors
  • Doesn't require a vent.
  • Probably no more difficult than the spare PMC option?
  • We need at least one actuatable mirror, so we'd need some PZT mounted optic + associated drive electronics.

If we can do a vent (we'd just need a single chamber open), I'd go for the option of getting the copper OMC out and using that. Attachment #1 shows the approximate sizes of the various components (OMMT, OMC cavity, DCPDs), while Attachment #2 shows a rough sketch of where things would go on the AP table, with the rectangles approximately to scale.

CDS:

I'd made a c1omc model sometime ago. Basically, I think we have sufficient ADC/DAC channels in the c1ioo machine for any of the options listed above - but using the copper OMC and associated peripherals would allow the easiest interfacing.

Criticisms/comments/thoughts please.

Attachment 1: OMCchamber.pdf
OMCchamber.pdf
Attachment 2: AP_Table_20180328.pdf
AP_Table_20180328.pdf
  15493   Sun Jul 19 15:40:15 2020 gautamUpdateBHDIn-air BHD - CDS and wiring summary

Attachment #1 shows the proposed wiring and CDS topology for the in air BHD setup. The PDF document has hyperlinks you can follow to the DCC entries. Main points:

  1. I think we should run the realtime model on c1lsc. This will negate the need for any IPC between c1ioo and c1lsc machines.
  2. I think we have most of the electronics we need already, though I am still in the process of testing the various boards, especially the HV ones.
  3. We may choose to use the switchable whitening feature for the M2 ISS board
    • This would require some BIO channels
    • There are plenty spare in c1lsc, so it's not going to be a show stopper
    • This is why I've not explicitly included a whitening board for now...
  4. The main job seems to be to make a whole bunch of custom cables. For the most part, I think we have the long (~20m) long D9 cables, so I propose just snipping off the connector at one end, and soldering on the appropriate connectors to the correct conductors.
  5. For the homodyne phase control - the proposal is to use a PI PZT with 3 piezoelectric elements. We would drive the 3 elements with the same voltage, by shorting the conductors together (at least that's how I understood Koji's comment), so we'd only need a single DAC channel for this purpose.
    • Need to confirm that the parallel PZT capacitances (each element is ~300 nF so 3 in parallel would be ~900 nF) still allows sufficient actuation bandwidth.
    • If the relative actuation strength of the 3 elements needs to be individually tuned, we may have to use three DAC channels. The D980323 board will allow the driving of 3 independent channels. I have one of these boards in hand, but need to check if it works, and also implement the changes outlined here.
  6. The alignment control has not yet been accounted for
    • We could consider using the in-vacuum PZTs, these were verified to be working ~2018.
    • If we use only 1 steering PZT mirror, we have sufficient free DAC channels available in c1lsc. But if we need both (to avoid clipping for example), then we need more DAC channels - we can either free up one DAFI channel, or install a DAC in the c1lsc expansion chassis
  7. We may want to expand to have a second OMC at some point. In which case we'd need, at the very least
    • 1 more DAC card
    • A HV driver for the second OMC length (could use the Trek driver if we use D980323 for the homodyne phase control).

Please comment if I've overlooked something.

Attachment 1: wiringDiagram.pdf
wiringDiagram.pdf
  15505   Wed Jul 29 11:57:59 2020 ranaUpdateBHDIn-air BHD - CDS and wiring summary

3. I agree - this whitening will be handy to have for diagnostics.

4. I think in principle, we can ask a company to make the custom cables for us to save us some hand labor. Rich/Chub probably know the right companies to do small numbers of dirty cables.

5. Can't we just a single Noliac PZT in the same way that the OMC does? Or is the lead time too long?

6. Do we need active steering for this in-air test? I'm not even sure how we would get the alignment signal, so maybe that's a good reason to figure this out.

  15479   Tue Jul 14 15:29:25 2020 gautamUpdateBHDIn-air BHD - DCPD amplifier noise

For the first pass, it's probably easiest to use the existing DCPD amplifier. Looking at the gain and noise performance in Attachment #1, seems totally fine, the electronics noise will not be limiting if we have ~10mW of LO power. I assumed a transimpedance resistor of 1 kohm, and all other numbers as on the schematic (though who knows if the schematic is accurate). The noise should be measured to confirm that the box is performing as expected...

Attachment 1: DCPDamp.pdf
DCPDamp.pdf
  15497   Tue Jul 21 00:30:24 2020 gautamUpdateBHDIn-air BHD - LO RIN

Attachment #1 shows the RIN of the local oscillator beam delivered to the AP table via fiber. I used a PDA520 to make this measurement, while the electronics for the DCPDs are pending. I don't really have an explanation for the difference between the locked IFO trace vs the not locked trace - we don't have an ISS running (but this first test suggests we should) and the beam is picked off before any cavities etc, so this is a reflection of the state of the FSS servo at the times of measurement?


Tried locking CARM using the hybrid REFL (for AO path) and POX 11 (for MCL path) scheme a bunch of times today, but I had no luck. When the CARM offset is zeroed, the PRMI lock is lost almost immediately. Maybe this is indicative of some excess noise in the POX data stream relative to the REFL signal? The one thing I haven't tried is to take the IFO all the way to the locked state, and then transition the MCL actuation from CM_SLOW to POX11_I.


An SR785 is sitting on the North side of the AP table in the walkway - I will clear it tomorrow.

Attachment 1: LO_RIN.pdf
LO_RIN.pdf
  15483   Wed Jul 15 19:11:40 2020 gautamUpdateBHDIn-air BHD - alignment into OMC

I forgot about the pointing - probably we will need another actuator to control the pointing of the AS beam onto the DCPDs. I found a few old PI PZTs (model number is S-320, which is a retired part), one is labelled broken but the others don't indicate a-priori that they are broken. I'll post a more detailed hardware survey later.

  Draft   Wed Jul 15 19:17:09 2020 gautamUpdateBHDIn-air BHD - alignment into OMC

You can activate all 3axis

 

  15489   Thu Jul 16 01:12:22 2020 gautamUpdateBHDIn-air BHD - preparing the LO path

Attachment #1 - The 80mW pickoff was getting clipped on a BNC cable, and not making it to the doubling oven. 😢 .

  • Since the PSL doubled beam isn't used for locking these days, I just didn't notice.
  • I blame the ringdown team, this crazy tee arrangement wasn't the case before.
  • I fixed the situation by changing the cabling such that the beam clears the cables comfortably.

Attachment #2 - PSL green shutter removed. Alignment into the doubling oven is extremely tedious, and so I opted to preserve the capability of recovering the green beam by simply removing a single mirror.

Attachment #3 - The beam path for coupling the LO beam into a fiber.

  • Primary goal was to have easy access to some steering mirrors so that I can optimize alignment into the fiber collimator.
  • I opted to use the NW corner of the PSL table - that's where most of our existing fiber hardware is anyways, and there was sufficient space and easy access over there.
  • 3 Y1 mirrors were installed, using the preferred Polaris mounts and 3/4" post + baseplate hardware. They were labelled Y1-1037-45P so that future workers need not be un-necessarily tortured. The third mirror is not visible in this photograph.
  • Once the collimator arrives, I will mode match this beam into the fiber. Plan is to use the fiber originally used for the mode spectroscopy project. It needs to be moved to the NW corner of the PSL table, and the other end needs to be routed to the AP table (it was brought back to the PSL table to facilitate Anjali's fiber MZ experiment). 
  • There is plenty of space in the beam path for mode-matching lens(es) and polarization control optics.

Attachment #4 shows the BHD photodiodes taken from QIL. 

  • Unfortunately, we could not find the readout electronics. 
  • In the worst case, we can just interface these PDs with the existing Satellite box (associated with the copper OMC).
  • It might be that the OMC cavity can simply be placed on this breadboard, making the whole setup nice and portable.
  • We may want to consider having an OFI between the OMC and the IFO AS beam at some point...
Attachment 1: IMG_8626.JPG
IMG_8626.JPG
Attachment 2: IMG_8627.JPG
IMG_8627.JPG
Attachment 3: IMG_8628.JPG
IMG_8628.JPG
Attachment 4: IMG_8629.JPG
IMG_8629.JPG
  15495   Mon Jul 20 17:55:15 2020 gautamUpdateBHDIn-air BHD - preparing the LO path

The LO pickoff has been coupled into a fiber with ~90% MM (8 mW / 9 mW input). While I wait for the DCPD electronics to be found in the Cryo lab, I want to monitor the stability of the pointing, polarization etc, so I'd like to clear some space on the AP table that was occupied for the mode spectroscopy project. If there are no objections before 2pm tomorrow July 21 2020, I will commence this work.

  16530   Tue Dec 21 16:52:39 2021 AnchalSummaryElectronicsIn-air Sat Amp to Vacuum Flange cables laid for 7 new SOS

[Anchal, Yehonathan, Chub]

We today laid down 14 70 ft long DB25 cables from 1Y1 (6), 1Y0 (8) to ITMY Chamber (4), BS Chamber (6) and ITMX Chamber (4). The cables have been connected to respective satellite amplifier on the racks and the other ends are connected to the vacuum flange feedthru on ITMX for LO1 and PR2, while the others have been kept near the planned flange postions. LO1 is now ready to be connected to CDS by connecting the in-vacuum cable inside ITMX chamber to the OSEMs.

  7877   Mon Jan 7 00:08:16 2013 JenneHowToAlignmentIn-vac plan

List of things to do, in order:

* Remove BS heavy door.  Steve, please remove the BS door as soon as you have enough people to do so.  I will be a little late, since I have a dentist appointment, but please don't wait for me.  Jamie and Manasa can help you.  Put on a light door.

* Remove MC light doors, make aluminum foil tube (not light access connector, yet).

* Open laser shutter, lock PMC. (Required slight tweaking of input steering.) Confirm power level into vacuum <100mW.

* Lock MC and check spot positions of MC (quickly.  this shouldn't take all day, hopefully).

-------------------------------  End of work for Monday.  See following elog ------------------------------------------------

 

* Move TT1 to be as close as possible to the location indicated on the diagram, then align it. 

         * Make sure beam out of Faraday is hitting the center of the optic.

         * Make sure beam reflected off of TT1 hits center of PZT2.  Only use actuators for the final alignment, then confirm that they aren't close to the edge of their ranges.

         * Lock down TT1 with dog clamps.

* Put light access connector on MC.

* Swap PZT2 out with TT2.  Should be at correct spot, according to diagram, and beam should be hitting center of optic.  Alignment only to the ~few degree point here.

* Re-level BS table.

* Fix oplevs that need fixing.  (Manasa should have the plan on one of the diagrams).

* Put target on PRM cage.

* Align TT2 so that beam goes through PRM target.

* Open ITMX heavy door. (Probably Tuesday morning).

* Place freestanding target in front of PR2.  Ensure TT2 is aligned to go through PRM target, and hit center of PR2.  Again, save actuators for fine-tuning.

At this point, I think we should (temporarily) install one of the G&H mirrors as a flat mirror facing the PRM, and see if we can lock that cavity using REFL.  We will want to have already created a model for this case, to compare our observations to.  Or we could align the full PRMI, and try to lock that in air.

 

 

  16891   Mon Jun 6 09:37:16 2022 JCUpdateSUSInMatCalc

[Paco, JC]

Paco and I attempted to calculate the input matrices from May 24, 2022, but the OSEM data was all saturated and not very useful. Therefore, we decided to manually investigate the appropriate coil offsets for all BHD SUS. Before, the default offset kick was 30000 counts, but we found that LO1, AS1, AS4, and PR2 cannot take more than 5000 counts. As for LO2, SR2, and PR3 cannot take more than 2000 counts before saturating. Note that all these kick test were taken by kicking OSEM UL on all BHD Optics.

 

We started the freeSwing.py script on tmux freeSwing session for tomorrow at 1:00 am for only the 5000 count offset SUS.

 

  5924   Thu Nov 17 11:51:14 2011 JenneUpdateEnvironmentIncandescent vs. fluorescent lights?

I'm just on an elog roll this morning...

Again while poking around inside the IFO room, I noticed that they have replaced all of our incandescent lights with CFLs.  Do we care?  The point of having the incandescent lights on a separate switch from the big fluorescent lights was so that we could have only 60Hz lines, not wide-band noise if we want the lights on while locking. 

I'm not sure that we actually care, because more often we just turn off all the lights while trying to do serious locking, but if we do care, then someone needs to ask the custodial staff (or someone else?) to undo the change.

  5695   Wed Oct 19 12:06:26 2011 MirkoUpdateCDSIncluded the MC servo channel in CDS

[Jamie, Mirko]

Included the 'Servo' output from the D040180 in c1ioo, which I hoped would be a better measure of the MC length fluctuations. It goes into ADC6, labeled CH7 on the physical board.
Servo-output => C1:IOO-MC_SERVO. (Already present is Out1-output => C1:IOO-MC_F).
At low freq. the servo signal is about 4.5dB bigger. Both are recorded at 256Hz now which is the reason for the downward slope at about 100Hz.

MC_F_versus_MC_SERVO.png

Coh_MC_F_MC_SERVO.png

  3322   Thu Jul 29 17:11:16 2010 GopalUpdateCOMSOL TipsIncluding Gravity in COMSOL

[Gopal, Jan]

For the past couple of days, Jan and I have been discussing a major issue in COMSOL involving modeling both oscillatory and non-oscillatory forces simultaneously while using FDA. It turns out that he and I had run into the same problem at different times and with different projects. After discussing with an expert, Jan had decided in the past that this simple task was impossible via direct means.

The issue could still be resolved if there was a way for us to work on the Weak Form of the differential equations describing the system:

  • Usually, one must define weight as a body load in the negative-z direction. However, this problematically instantiates a new force in COMSOL, which is automatically driven over the range of frequencies during FDA.
  • Instead, we could define gravity as an anti-restoring force, since we assume that the base of the stack is fixed.
  • In other words, Fg = (ρ*g/L)*x + (ρ*g/L)*y for a point mass which is constrained on the bottom (for small angles).
  • Working in Weak Form then, we'd never have to define an explicit gravity load-- this could just be an extra couple of terms in the differential equation which are related entirely to the x- and y-vectors (well-defined for each mesh point). This would fool COMSOL into never tacking on the oscillatory term during FDA. 

According to current documentation however, Weak Form analysis is not yet possible in COMSOL 4.0. Jan suggested moving my work over to ANSYS or waiting for the 4.0 upgrade, but there's probably not enough time left in my SURF for either of these options. I suggested attempting a backwards-compatibility test to COMSOL 3.5; Jan and I will be exploring this option some time next week. 

  10634   Thu Oct 23 02:08:40 2014 JenneUpdateLSCIncreased DARM gain

I changed the carm_cm_up.sh script so that it requires fewer human interventions.  Rather than stopping and asking for things like "Press enter to confirm PRMI is locked", it checks for itself.  The sequence that we have in the up script works very reliably, so we don't need to babysit the first several steps anymore. 

Another innovation tonight that Q helped put in was servoing the CARM offset to get a certain arm power.  A failing of the script had been that depending on what the arm power was during transition over to sqrtInvTrans, the arm power was always different even if the digital offset value was the same.  So, now the script will servo (slowly!!) the offset such that the arm power goes to a preset value.

The biggest real IFO progress tonight was that I was able to actually measure the CARM and DARM loops (thanks ChrisW!), and so I discovered that even though we are using (TRX-TRY)/(TRX+TRY) for our IR DARM error signal, we needed to increase the digital gain for DARM as the CARM offset was reduced.  For ALS lock and DC trans diff up to arm powers of 3, we use the same ol' gain of 6.  However, between 3 - 6, we need a gain of 7.  Then, when we go to arm powers above 6 we need a gain of 7.5.  I was also measuring the CARM loop at each of these arm powers (4, 6, 7, 8, 9), but the gain of 4 that we use for sqrtInvTrans was still fine. 

So, the carm_cm_up script will do everything that it used to without any help (unless it fails to find IR resonance for ALS, or can't lock the PRMI, in which case it will ask for help), and then once it gets to these servo lines to slowly increase the arm power and increase the DARM gain, it will ask you to confirm before each step is taken.  The script should get you all the way to arm powers of 9, which is pretty much exactly 100pm according to Q's Mist plot that is posted.

The CARM and DARM loops (around the UGFs) don't seem to be appreciably changing shape as I increase the arm powers up to 9 (as long as I increase the DARM loop gain appropriately).  So, we may be able to go a little bit farther, but since we're at about 100pm, it might be time to look at whether we think REFL11 or REFLDC is going to be more promising in terms of loop stability for the rest of the way to resonance.


Here are some plots from this evening. 

First, the time I was able to get to and hold at arm powers of 9.  I have a striptool to show the long time trends, and then zooms of the lockloss.  I do not see any particular oscillations or anything that strikes me as the cause for the lockloss.  If anyone sees something, that would be helpful.

ArmPowers9_1am_22Oct2014.png

Lockloss_ArmsAt9_1am_22Oct2014.png

LocklossZoom_ArmsAt9_1am_22Oct2014.png

This next lockloss was interesting because the DARM started oscillating as soon as the normalization matrix elements were turned on for DARM on DC transmissions.  The script should be measuring values and putting in matrix elements that don't change the gain when they are turned on, but perhaps something didn't work as expected.  Anyhow, the arm powers were only 1ish at the time of lockloss.  There was some kind of glitch in the DARM_OUT (see 2nd plot below, and zoom in 3rd plot), but it doesn't seem to have caused the lockloss.

Lockloss_ArmsAt1ish_TransOscillation_110am_22Oct2014.png

LocklossZoom_ArmsAt1ish_TransOscillation_110am_22Oct2014.png

LocklossZoomGlitch_ArmsAt1ish_TransOscillation_110am_22Oct2014.png

  10637   Fri Oct 24 02:14:05 2014 JenneUpdateLSCIncreased DARM gain even more

[Jenne, Diego]

We spent the afternoon working on the new scan for IR resonance script.  It is getting much closer, although we need to work on a plan for the fine scanning at the end - so far, the result from the wavelet thing mis-estimates the true peak phase, and so if we jump to where it recommends, we are only at about half of the arm resonance.  So, in progress, but moving forward.

Tonight we repeated the process of reducing the CARM offset and measuring the DARM loop gain as we went.  I'm not sure if I just had the wrong numbers yesterday, or if the gains are changing day-by-day.  The gains that it wanted at given arm buildups were constant throughout this evening, but they are about a factor of 2 higher than yesterday.  If they really do change, we may need to implement a UGF servo for DARM.  New gains are in the carm_cm_up script.

We also actually saved our DARM loop measurements as a function of CARM offset (as indicated by arm buildups).  The loop stays the same through arm powers of 4.  However, once we get to arm powers of 6, the magnitude around 100 Hz starts to flatten out, and we get some weird features in the phase.  It's almost like the phase bubble has a peak growing out of it.  I saw these yesterday, and they just keep getting more pronounced as we go up to arm powers of 7, 8 and 9 (where we lost lock during the measurement).  The very last point in the power=9 trace was just before/during the lockloss, so I don't know if we trust it, or if it is real and telling us something important.  But, I think that it's time to see about getting both CARM and DARM onto a different set of error signals now that we're at about 100pm.

 DARM_23Oct2014.pdf

  2000   Thu Sep 24 21:04:15 2009 JenneUpdateMOPAIncreasing the power from the MOPA

[Jenne, Rana, Koji]

Since the MOPA has been having a bad few weeks (and got even more significantly worse in the last day or so), we opened up the MOPA box to increase the power.  This involved some adjusting of the NPRO, and some adjusting of the alignment between the NPRO and the Amplifier.  Afterward, the power out of the MOPA box was increased.  Hooray! 

Steps taken:

0.  Before we touched anything, the AMPMON was 2.26, PMC_Trans was 2.23, PSL-126MOPA_126MON was 152 (and when the photodiode was blocked, it's dark reading was 23).

1.  We took off the side panel of the MOPA box nearest the NPRO, to gain access to the potentiometers that control the NPRO settings.  We selectively changed some of the pots while watching PSL-126MOPA_126MON on Striptool.

2.  We adjusted the pot labeled "DTEMP" first. (You have to use a dental mirror to see the labels on the PCB, but they're there). We went 3.25 turns clockwise, and got the 126MON to 158. 

3. To give us some elbow room, we changed the PSL-126MOPA_126CURADJ from +10.000 to 0.000 so that we have some space to move around on the slider.  This changed 126MON to 142. The 126MOPA_CURMON was at 2.308.

4.  We tried adjusting the "USR_CUR" pot, which is labeled "POWER" on the back panel of the NPRO (you reach this pot through a hole in the back of the NPRO, not through the side which we took off, like all the other pots today).  This pot did nothing at all, so we left it in its original position.  This may have been disabled since we use the slider.

5.  We adjusted the CUR_SET pot, and got the 126MON up to 185.  This changed the 126MOPA_CURMON to 2. 772 and the AMPMON to 2.45

We decided that that was enough fiddling with the NPRO, and moved on to adjusting the alignment into the Amplifier.

6.  We teed off of the AMPMON photodiode so that we could see the DC values on a DMM.  When we used a T to connect both the DMM and the regular DAQ cable, the DMM read a value a factor of 2 smaller than when the DMM was connected directly to the PD.  This shouldn't happen.....it's something on the to-fix-someday list.

7.  Rana adjusted the 2 steering mirrors immediately in front of the amplifier, inside the MOPA box.  This changed the DMM reading from its original 0.204 to 0.210, and the AMPMON reading from 2.45 to 2.55. While this did help increase the power, the mirrors weren't really moved very much.

8.  We then noticed that the beam wasn't really well aligned onto the AMPMON PD.  When Rana leaned on the MOPA box, the PD's reading changed.  So we moved the PD a little bit to maximize its readings.  After this, the AMPMON read 2.68, and the DMM read 0.220.

9.  Then Rana adjusted the 2 waveplates in the path from the NPRO to the Amplifier.  The first waveplate in the path didn't really change anything.  Adjusting the 2nd waveplate gave us an AMPMON of 2.72, and a DMM reading of 0.222.

10.  We closed up the MOPA box, and locked the PMC.  Unfortunately, the PMC_Trans was only 1.78, down from the 2.26 when we began our activities.  Not so great, considering that in the end, the MOPA power went up from 2.26 to 2.72.

11.  Koji and I adjusted the steering mirrors in front of the PMC, but we could not get a transmission higher than 1.78.

12.  We came back to the control room, and changed the 126MOPA_126CURADJ slider to -2.263 which gives a 126MOPA_CURMON to 2.503.  This increased PMC_TRANS up to 2.1. 

13.  Koji did a bit more steering mirror adjustment, but didn't get any more improvement.

14.  Koji then did a scan of the FSS SLOW actuator, and found a better temperature place (~ -5.0)for the laser to sit in.  This place (presumably with less mode hopping) lets the PMC_TRANS get up to 2.3, almost 2.4.  We leave things at this place, with the 126MOPA_126CURADJ slider at -2.263. 

Now that the MOPA is putting out more power, we can adjust the waveplate before the PBS to determine how much power we dump, so that we have ~constant power all the time.

 

Also, the PMCR view on the Quad TVs in the Control Room has been changed so it actually is PMCR, not PMCT like it has been for a long time.

  2007   Sun Sep 27 12:52:56 2009 ranaUpdateMOPAIncreasing the power from the MOPA

This is a trend of the last 20 days. After our work with the NPRO, we have recovered only 5% in PMC trans power, although there's an apparent 15% increase in AMPMON.

The AMPMON increase is partly fake; the AMPMON PD has too much of an ND filter in front of it and it has a strong angle dependence. In the future, we should not use this filter in a permanent setup. This is not a humidity dependence.

The recovery of the refcav power mainly came from tweaking the two steering mirrors just before and just after the 21.5 MHz PC. I used those knobs because that is the part of the refcav path closest to the initial disturbance (NPRO).

BTW, the cost of a 1W Innolight NPRO is $35k and a 2W Innolight NPRO is $53k. Since Jenne is on fellowship this year, we can afford the 2W laser, but she has to be given priority in naming the laser.

Attachment 1: Picture_3.png
Picture_3.png
  14463   Sun Feb 17 17:35:04 2019 gautamSummaryLoss MeasurementInferred X arm loss

Summary:

To complete the story before moving on to ALS, I decided to measure the X arm loss. It is estimated to be 20 +/- 5 ppm. This is surprising to say the least, so I'm skeptical - the camera image of the ETMX spot when locked almost certainly looks brighter than in Oct 2016, but I don't have numerical proof. But I don't see any obvious red flags in the data quality/analysis yet. If true, this suggests that the "cleaning" of the Yarm optics actually did more harm than good, and if that's true, we should attempt to identify where in the procedure the problem lies - was it in my usage of non-optical grade solvents?

Details:

  1. Unlike the Y arm, the ratio \kappa = 1.006 \pm 0.002 is quite unambiguously greater than 1, which is already indicative of the loss being lower than for the Y arm. This is reliably repeatable over 15 datapoints at least.
  2. Attachment #1 shows the spectrum of the single-bounce off ITMX beam and compares it to ITMY - there is clearly a difference, and my intuition is to suspect some scatter / clipping, but I confirmed that on the AS table, in air, there is no clipping. So maybe it's something in vacuum? But I'm not sure how to explain its absence for the ITMX reflection. I didn't check the Michelson alignment since I misaligned ITMY before locking the XARM - so maybe there's a small shift in the axis of the X arm reflection relative to the Yarm because of the BS alignment. The other possibility is clipping at the BS?
  3. Attachment #2 shows the filtered time series for a short segment of the measurement. The X arm ASS is mostly well behaved, but the main thing preventing me from getting more statistics in is the familiar ETMX glitching problem, which while doesn't directly break the lock causes large swings in TRX. Given the recent experience with ETMY satellite box, I'm leaning towards blaming flaky electronics for this. If this weren't a problem, I'd run a spatial scan of ETMX, but I'm not going to attack this problem today.
  4. Attachments #3 and #4 show the posterior distributions for model parameters and loss respectively. 
  5. Data quality checks done so far (suggestions welcome):
    • Confirmed that there is no fringing from other ITM (in this case ITMY) / PRM / SRM / ETM in the single-bounce off ITMX config, by first macroscopically misaligning all these optics (the spots could be seen to move on the AS port PD, until they vanished, at some point presumably getting clipped in-vac), and then moving the optics around in PIT/YAW and looking for any effect in the fast time-series using NDScope.
    • Checked for slow drifts in locked / misaligned states - looks okay.
    • Checked centering on PDA520 using both o'scope plateau method and IR viewer - I believe the beam to be well centered.

Provisional conclusions:

  1. The actual act of venting / pumping down doesn't have nearly as large an effect on the round-trip loss as does working in chamber - the IX and EX chambers have not been opened since the 2016 vent.
  2. The solvent marks visible with the green flashlight on ETMY possibly signals the larger loss for the Y arm. 
Attachment 1: DQcheck_XARM.pdf
DQcheck_XARM.pdf
Attachment 2: consolidated.pdf
consolidated.pdf
Attachment 3: posterior_modelParams_XARM.pdf
posterior_modelParams_XARM.pdf
Attachment 4: posterior_Loss_XARM.pdf
posterior_Loss_XARM.pdf
  14454   Thu Feb 14 21:29:24 2019 gautamSummaryLoss MeasurementInferred Y arm loss

Summary:

From the measurements I have, the Y arm loss is estimated to be 58 +/- 12 ppm. The quoted values are the median (50th percentile) and the distance to the 25th and 75th quantiles. This is significantly worse than the ~25 ppm number Johannes had determined. The data quality is questionable, so I would want to get some better data and run it through this machinery and see what number that yields. I'll try and systematically fix the ASS tomorrow and give it another shot.

Model and analysis framework:

Johannes and I have cleaned up the equations used for this calculation - while we may make more edits, the v1 of the document lives here. The crux of it is that we would like to measure the quantity \kappa = \frac{P_L}{P_M}, where P_{L(M)} is the power reflected from the resonant cavity (just the ITM). This quantity can then be used to back out the round-trip loss in the resonant cavity, with further model parameters which are:

  1. ITM and ETM power transmissivities
  2. Modulation depths and mode-matching efficiency into the cavity
  3. The statistical uncertainty on the measurement of the quantity \kappa, call it \sigma_{\kappa}

If we ignore the 3rd for a start, we can calculate the "expected" value of \kappa as a function of the round-trip loss, for some assumed uncertainties on the above-mentioned model parameters. This is shown in the top plot in Attachment #1, and while this was generated using emcee, is consistent with the first order uncertainty propagation based result I posted in my previous elog on this subject. The actual samples of the model parameters used to generate these curves are shown in the bottom. What this is telling us is that even if we have no measurement uncertainty on \kappa, the systematic uncertainties are of the order of 5 ppm, for the assumed variation in model parameters.

The same machinery can be run backwards - assuming we have multiple measurements of \kappa, we then also have a sample variance, \sigma_{\kappa}. The uncertainty on the sample variance estimator is also known, and serves to quantify the prior distribution on the parameter \sigma_{\kappa} for our Monte-Carlo sampling. The parameter \sigma_{\kappa} itself is required to quantify the likelihood of a given set of model parameters, given our measurement. For the measurements I did this week, my best estimate of \kappa \pm \sigma_{\kappa} = 0.995 \pm 0.005. Plugging this in, and assuming uncorrelated gaussian uncertainties on the model parameters, I can back out the posterior distributions.

For convenience, I separate the parameters into two groups - (i) All the model parameters excluding the RT loss, and (ii) the RT loss. Attachment #2 and Attachment #3 show the priors (orange) and posteriors (black) of these quantities. 

Interpretations:

  1. This particular technique only gives us information about the RT loss - much less so about the other model parameters. This can be seen by the fact that the posteriors for the loss is significantly different from the prior for the loss, but not for the other parameters. Potentially, the power of the technique is improved if we throw other measurements at it, like ringdowns.
  2. If we want to reach the 5 ppm uncertainty target, we need to do better both on the measurement of the DC reflection signals, and also narrow down the uncertainties on the other model parameters.

Some assumptions:

So that the experts on MC analysis can correct me wheere I'm wrong.

  1. The prior distributions are truncated independent Gaussians - truncated to avoid sampling from unphysical regions (e.g. negative ITM transmission). I've not enforced the truncation analytically - i.e. I just assume a -infinity probability to samples drawn from the unphysical parts, but to be completely sure, the actual cavity equations enforce physicality independently (i.e. the MC generates a set of parameters which is input to another function, which checks for the feasibility before making an evaluation). One could argue that the priors on some of these should be different - e.g. uniform PDF for loss between some bounds? Jeffrey's prior for \sigma_{\kappa}?
  2. How reasonable is it to assume the model parameter uncertainties are uncorrelated? For exaple, \eta, \beta_1, \beta_2 are all determined from the ALS-controlled cavity scan
Attachment 1: modelPerturb.pdf
modelPerturb.pdf
Attachment 2: posterior_modelParams.pdf
posterior_modelParams.pdf
Attachment 3: posterior_Loss.pdf
posterior_Loss.pdf
  15163   Tue Jan 28 14:33:24 2020 gautamUpdatePSLInferred free-running frequency noise

To conclude my PMC noise investigations: Attachment #1 shows the PMC noise inferred from the calibrations earlier in this thread and the fitted OLTF for the PMC loop. Attachment #2 compares the frequency noise (inferred from the error point of the PMC servo) when the IMC is locked / unlocked. I don't know what to make of the fact that the PMC suggests improvement from ~20 Hz onwards already - does this mean that the NPRO noise model is wrong by 1 order of magnitude at 30 Hz?

  • The IMC was locked for the measurement shown in Attachment #1.
  • The in-loop spectra of the error (at the I/F output of the mixer) and control (at TP3) signals were measured with the SR785.
  • The control signal voltage monitors don't seem to work - neither the front panel LEMO nor the signals hooked up to the CDS system show me sensible shapes for the spectra between 1-3 Hz.
  • To convert in loop to free-running, I multiplied the measured error (control) signal spectra by \left | 1-L \right | (\left | \frac{L}{1-L} \right |), where L is the OLTF. THe control signal was pre-processed by multiplying by a pole at 11.3 Hz, corresponding to the LPF formed by the 63.3 kohm series resistor and the 225 nF PZT capacitance.
  • The "NPRO noise model" curve is 10^4/f Hz/rtHz.

While I initially thought the 1/f^2 rise below ~100 Hz is attributable to the IMC cavity length fluctuations, I found that this profile is present even in the measurement with the PSL shutter closed. I am not embarking on a detailed PMC noise budgeting project for now. Note however that we are not shot noise limited anywhere in this measurement band.

  • The measured TF (dots in Attachment #5) was fit with LISO (solid lines in Attachment #5) to allow inferring the out-of-loop servo noise by monitoring the in-loop noise (that plot to follow).
Attachment 1: inLoopNoise_IMClocked.pdf
inLoopNoise_IMClocked.pdf
Attachment 2: freqNoiseComparison.pdf
freqNoiseComparison.pdf
  16323   Mon Sep 13 17:05:04 2021 TegaSummaryPEMInfrasensing temperature sensor modbus configuration

Anchal mentioned it would be good to put more details about how I arrived at the values needed to configure the modbus drive for the temperature sensor, since this information is not in the manual and is hard to find on the internet, so here is a breakdown.

So the generic format is:

drvAsynIPPortConfigure("<TCP_PORT_NAME>","<UNIT_IP_ADDRESS>:502",0,0,1)
modbusInterposeConfig("<TCP_PORT_NAME>",0,5000,0)
drvModbusAsynConfigure("<PORT_NAME>","<TCP_PORT_NAME>",<slaveAddress>,<modbusFunction>,<modbusStartAddress>,<modbusLength>,<dataType>,<pollMsec>,<plcType>)

which in our case become:

drvAsynIPPortConfigure("c1pemxendtemp","192.168.113.240:502",0,0,1)
modbusInterposeConfig("c1pemxendtemp",0,5000,0)
drvModbusAsynConfigure("C1PEMXENDTEMP","c1pemxendtemp",0,4,199,2,0,1000,"ServerCheck")

As can be seen, the parameters of the first two functions "drvAsynIPPortConfigure" and "modbusInterposeConfig" are straight forward, so we restrict our discussion to the case of third function "drvModbusAsynConfigure". Well, after hours of trolling the internet, I was able to piece together a coherent picture of what needs doing and I have summarised them in the table below.

 

drvModbusAsynConfigure

Once the asyn IP or serial port driver has been created, and the modbusInterpose driver has been configured, a modbus port driver is created with the following command:

drvModbusAsynConfigure(portName,                # used by channel definitions in .db file to reference this unit)
                       tcpPortName,             # reference to portName created with drvAsynIPPortConfigure command
                       slaveAddress,            # 
                       modbusFunction,          # 
                       modbusStartAddress,      # 
                       modbusLength,            # length in dataType units
                       dataType,                # 
                       pollMsec,                # how frequently to request a value in [ms]
                       plcType);                #

drvModbusAsynConfigure command
Parameter Data type Description
portName string Name of the modbus port to be created.
 
tcpPortName string Name of the asyn IP or serial port previously created.

tcpPortName = { 192.168.113.240:502192.168.113.241:502192.168.113.242:502 }
 
slaveAddress int The address of the Modbus slave. This must match the configuration of the Modbus slave (PLC) for RTU and ASCII. For TCP the slave address is used for the "unit identifier", the last field in the MBAP header. The "unit identifier" is ignored by most PLCs, but may be required by some.

ServersCheck API ignores this value, as confirmed with pymodbus query, so set to default value: 
slaveAddress = 0
 
modbusFunction int

modbus supports the following 8 Modbus function codes:

Modbus Function Codes
Access Function description Function code
Bit access Read Coils 1
Bit access Read Discrete Inputs 2
Bit access Write Single Coil 5
Bit access Write Multiple Coils 15
16-bit word access Read Input Registers 4
16-bit word access Read Holding Registers 3
16-bit word access Write Single Register 6
16-bit word access Write Multiple Registers 16
modbusStartAddress int Start address for the Modbus data segment to be accessed.
(0-65535 decimal, 0-0177777 octal).

Modbus addresses are specified by a 16-bit integer address. The location of inputs and outputs within the 16-bit address space is not defined by the Modbus protocol, it is vendor-specific. Note that 16-bit Modbus addresses are commonly specified with an offset of 400001 (or 300001). This offset is not used by the modbus driver, it uses only the 16-bit address, not the offset.

For ServersCheck, the offset is "30001", so that

modbusStartAddress = 30200 - 30001 = 199

modbusLength int The length of the Modbus data segment to be accessed.
This is specified in bits for Modbus functions 1, 2, 5 and 15.
It is specified in 16-bit words for Modbus functions 3, 4, 6 and 16.
Length limit is 2000 for functions 1 and 2, 1968 for functions 5 and 15,
125 for functions 3 and 4, and 123 for functions 6 and 16.

ServersCheck uses two's complement 32-bits word (with big-endian byte order & little-endian word order) format to store floating-point data, as confirmed with pymodbus query, so that:

modbusLength = 2
 
modbusDataType int The modbusDataType is used to tell the driver the format of the Modbus data. The driver uses this information to convert the number between EPICS and Modbus. Data is transferred to and from EPICS as epicsUInt32, epicsInt32, and epicsFloat64 numbers.

Modbus data type:
0 = binary, twos-complement format
1 = binary, sign and magnitude format
2 = BCD, unsigned
3 = BCD, signed

Some Modbus devices (including ServersCheck) use floating point numbers, typically by storing a 32-bit float in two consecutive 16-bit registers. This is not supported by the Modbus specification, which only supports 16-bit registers and single-bit data. The modbus driver does not directly support reading such values, because the word order and floating point format is not specified.

Note that if it is desired to transmit BCD numbers untranslated to EPICS over the asynInt32 interface, then data type 0 should be used, because no translation is done in this case. 

For ServersCheck, we wish to transmit the untranslated data, so:

modbusDataType = 0
 
pollMsec int Polling delay time in msec for the polling thread for read functions.
For write functions, a non-zero value means that the Modbus data should
be read once when the port driver is first created.

ServersCheck recommends setting sensor polling interval between 1-5 seconds, so we can try:

pollMsec = 1000
 
plcType string Type of PLC (e.g. Koyo, Modicon, etc.).
This parameter is currently used only to print information in asynReport.
In the future it could be used to modify the driver behavior for a specific PLC.

plcType = "ServersCheck"
 

 

Useful links

https://nodus.ligo.caltech.edu:8081/40m/16214

https://nodus.ligo.caltech.edu:8081/40m/16269

https://nodus.ligo.caltech.edu:8081/40m/16270

https://nodus.ligo.caltech.edu:8081/40m/16274

 

http://manuals.serverscheck.com/InfraSensing_Sensors_Platform.pdf

http://manuals.serverscheck.com/InfraSensing_Modbus_manualv5.pdf

https://community.serverscheck.com/discussion/comment/7419#Comment_7419

 

https://wiki-40m.ligo.caltech.edu/CDS/SlowControls

https://www.slac.stanford.edu/grp/ssrl/spear/epics/site/modbus/modbusDoc.html#Creating_a_modbus_port_driver

 

https://github.com/riptideio/pymodbus

 

https://en.wikipedia.org/wiki/Modbus

https://deltamotion.com/support/webhelp/rmctools/Communications/Ethernet/Supported_Protocols/Ethernet_Modbus_TCP.htm

  16761   Thu Apr 7 11:47:22 2022 YehonathanUpdateBHDInitial BHD modeling: AS - LO mode matching

I begin modeling the initial BHD setup using Finesse. I started with copying C1_w_BHD.kat from the 40m/bhd repo and making changes to reflect the current BHD setup:

1. OMCs were removed.

2. Only 1 PD per BHD port was left.

3. Transmission of PR2 was changed to 2.2%. The PRG was calculated to be ~15.5.

4. Actual RoCs of new optics were dialed in (Yesterday me and Paco went into the cleanroom to measure the RoCs and they seem to match the datasheets).

Here's a table comparing the old (design?) RoCs with the new RoCs:

  New RoC Old RoC
LO1 5m 6m
LO2 inf inf
LO3 500mm 750mm
LO4 150mm -450mm
AS1 2m 2.8m
AS2 inf inf
AS3 200mm -2m
AS4 750mm 600mm
PR2 2000m -700m
PR3 1000m 1000m
SR3 1000m -700m

 

The changes looked quite alarming, especially for LO4 and AS3, so I wrote a script to calculate the mode matching between the LO and AS beams called AS_LO_ModeMatching.ipynb and pushed it into the repo. In the notebook a bright AS beam is created by creating a small asymmetry between the arms of ~ 0.003 degrees (~10pm). Amplitude detectors were put at the input ports of the BHD BS to calculate the fields in the AS and LO beams. In particular TEM00, TEM02 and TEM20 were measured for each beam.

The calculation shows that with the old RoCs the mode matching between the LO and AS beams is 99% while for the new RoCs it is ~ 50%.

  16766   Thu Apr 7 21:15:04 2022 YehonathanUpdateBHDInitial BHD modeling: AS - LO mode matching

Ok, it turns out these optics were purchased on purpose, as this elog shows. Jon considered building a mode-matching telescope with stock optics as an initial step before purchasing the custom optics (referred to as "design" optics in my elog).

I dialed in the new distances between the optics into the .kat file as described in this elog and pushed the changes to the repo. With the new distances, I got mode-matching of 87% for the full IFO and 89% for FPMI so there's probably no need to worry as the mode-matching with these optics was already designed.

Quote:

I begin modeling the initial BHD setup using Finesse. I started with copying C1_w_BHD.kat from the 40m/bhd repo and making changes to reflect the current BHD setup:

1. OMCs were removed.

2. Only 1 PD per BHD port was left.

3. Transmission of PR2 was changed to 2.2%. The PRG was calculated to be ~15.5.

4. Actual RoCs of new optics were dialed in (Yesterday me and Paco went into the cleanroom to measure the RoCs and they seem to match the datasheets).

Here's a table comparing the old (design?) RoCs with the new RoCs:

  New RoC Old RoC
LO1 5m 6m
LO2 inf inf
LO3 500mm 750mm
LO4 150mm -450mm
AS1 2m 2.8m
AS2 inf inf
AS3 200mm -2m
AS4 750mm 600mm
PR2 2000m -700m
PR3 1000m 1000m
SR3 1000m -700m

 

The changes looked quite alarming, especially for LO4 and AS3, so I wrote a script to calculate the mode matching between the LO and AS beams called AS_LO_ModeMatching.ipynb and pushed it into the repo. In the notebook a bright AS beam is created by creating a small asymmetry between the arms of ~ 0.003 degrees (~10pm). Amplitude detectors were put at the input ports of the BHD BS to calculate the fields in the AS and LO beams. In particular TEM00, TEM02 and TEM20 were measured for each beam.

The calculation shows that with the old RoCs the mode matching between the LO and AS beams is 99% while for the new RoCs it is ~ 50%.

 

  16858   Mon May 16 16:13:01 2022 YehonathanUpdateBHDInitial BHD modeling: Damped suspension model

I was finally able to set up a stable suspension model with the help of Yuta and I'm now ready to start doing some MICH noise budgeting with BHD readout. (Tip: turns out that in the zpk function in Matlab you should multiply the poles and zeros by -2*pi to match the zpk TFs in Foton)

I copied all the filters from the suspension MEDM screens into a Matlab. Those filters were concatenated with a single pendulum suspension TF with poles at [0.05e-1+1i, 0.05e-1-1i] and a gain of 4 N/kg.

I multiplied the OLTF with the real gains at the DAC/DAC/OSEMs/Coil Driver and Coils. I ignore whitening/dewhitening for now. The OLTF was calculated with no additional ad-hoc gain.

Attachment 1 shows the calculated open-loop transfer function.

Attachment 2 shows OLTF of ETMY measured last week.

Attachment 3 shows the step and impulse responses of the closed-loop system.

 

 

Attachment 1: Damped_SUS.png
Damped_SUS.png
Attachment 2: ETMY_SUSPOS_GOL.pdf
ETMY_SUSPOS_GOL.pdf ETMY_SUSPOS_GOL.pdf
Attachment 3: SUS_Response.png
SUS_Response.png
  3284   Sat Jul 24 13:13:41 2010 rana, steve, albertoUpdateGeneralInitial Crane Inspection reveals flaws: wiring and oil

The guy from KroneCrane (sp?) came today and started the crane inspection on the X End Crane. There were issues with our crane so he's going to resume on Monday. We turned off the MOPA fur the duration of the inspection.

  1. None of our cranes have oil in the gearbox and it seems that they never did since they have never been maintained. Sloppy installation job. The crane oiling guy is going to come in on Monday.
  2. They tried to test the X-End crane with 2500 lbs. (its a 1 ton crane). This tripped the thermal overload on the crane as intended with this test. Unfortunately, the thermal overload switch disabled the 'goes down' circuit instead of the 'goes up' circuit as it should. We double checked the wiring diagram to confirm our hypothesis. Seems the X-End crane was wired up incorrectly in the first place 16 years ago. We'll have to get this fixed.

The plan is that they will bring enough weight to test it at slightly over the rating (1 Ton + 10 %) and we'll retry the certification after the oiling on Monday.

  3290   Mon Jul 26 10:04:24 2010 steveUpdateGeneralInitial Crane Inspection reveals flaws: wiring, oil and imbalance

Quote:

The guy from KroneCrane (sp?) came today and started the crane inspection on the X End Crane. There were issues with our crane so he's going to resume on Monday. We turned off the MOPA fur the duration of the inspection.

  1. None of our cranes have oil in the gearbox and it seems that they never did since they have never been maintained. Sloppy installation job. The crane oiling guy is going to come in on Monday.
  2. They tried to test the X-End crane with 2500 lbs. (its a 1 ton crane). This tripped the thermal overload on the crane as intended with this test. Unfortunately, the thermal overload switch disabled the 'goes down' circuit instead of the 'goes up' circuit as it should. We double checked the wiring diagram to confirm our hypothesis. Seems the X-End crane was wired up incorrectly in the first place 16 years ago. We'll have to get this fixed.

The plan is that they will bring enough weight to test it at slightly over the rating (1 Ton + 10 %) and we'll retry the certification after the oiling on Monday.

 The south end crane has one more flaw. The wall cantilever is imbalanced: meaning it wants to rotate south ward, because its axis is off.

This effects the rope winding on the drum as it is shown on Atm2

Atm1 is showing Jay Swar of KoneCrane and the two 1250 lbs load that was used for the test. Overloading the crane at 125% is general practice at load testing.

It was good to see that the load brakes were working well at 2500 lbs. Finally we found a good service company! and thanks for Rana and Alberto

for coming in on Saturday.

Attachment 1: 2500.JPG
2500.JPG
Attachment 2: sedrum.JPG
sedrum.JPG
  360   Wed Mar 5 12:51:48 2008 JohnSummaryLSCInitial Ligo Arm finesse versus lambda
I've taken the coating recipes for the initial ligo arm cavity from Rana's web page (ligo.caltech/edu/~rana/mat/)
and plotted the finesse as a function of wavelength. There is some uncertainty over the indices of refraction but
the main conclusion remains unchanged - i.e. it appears that using other wavelengths will be difficult.
Stefan is looking at how to tune the layers of any new mirrors to make dichroic optics.
Attachment 1: FofLambdaLIGOI.jpg
FofLambdaLIGOI.jpg
  7599   Tue Oct 23 17:30:33 2012 jamie, nic, jenne, raji, manasaUpdateAlignmentInitial attempts to fix IFO alignment

We went into the vertex today to see about fixing the alignment.  The in-air access connector is in place, and we took heavy doors off of BS, ITMY, and ETMY chambers.

We started by looking at the pointing from the PZTs.  Manasa and Raji hooked up HV power supplies to the PZTs and set them to the middle of their ranges (75 V).

We installed a target on the BS cage, and new "free standing" targets made special by Steve for the SOSs on ITMY and ETMY.

Using a free-standing aperture target we looked at the beam height before PZT2.  It was a little high, so we adjusted it with PZT1.  Once that was done we looked at the beam height at PR2, and adjusted that height with PZT1.

We then tried to use the hysteresis in PR2 to adjust the beam height at ITMY.  Pushing just a little bit at the top or bottom of PR2 would repoint the beam in pitch.  This sort of works, but it's stupid.  Using this method we got the beam more or less centered vertically at ITMY.

We moved on to ETMY with the idea that we would again use the hysteresis in PR3 to get the vertical pointing to the ETM correct.  This was a good demonstration of just how stupid the tip-tilts really are.  Just touching slightly at the top or bottom or PR3 we could completely change the pointing at ETMY, by mili-radians (~4 cm over 40m).

At this point I cried foul.  This is not an acceptable situation.  Very little stimulation to the tip-tilts can repoint the beam inside the PR cavity.

Steve says that the TT weights, which will attach to the base of the TT mirror mounts and should help keep the mirrors vertical and not hysteretic, are being baked now and should be available tomorrow.  We therefore decided to stop what we were doing today, since we'll have to just redo it all again tomorrow once the weights are installed.

 

  12080   Fri Apr 15 23:11:49 2016 gautamUpdateGeneralInnolight 1W moved to SP table

I have moved the 1W Innolight + controller from the PSL table to the SP table for beam profiling.

  2810   Mon Apr 19 16:31:42 2010 KevinUpdatePSLInnolight 2W Laser

Koji and Kevin

We unpacked the Innolight 2W laser, took an inventory, and scanned the operations manual.

[Edit by KA]

The scanned PDFs are placed on the following wiki page

http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/PSL

We will measure the P-I curve, the mode profile, frequency actuator responses, and so on.

  2822   Tue Apr 20 20:15:37 2010 KevinUpdatePSLInnolight 2W Output Power vs Injection Current

Koji and Kevin measured the output power vs injection current for the Innolight 2W laser.

The threshold current is 0.75 A.

 

The following data was taken with the laser crystal temperature at 25.04ºC (dial setting: 0.12).

Injection Current (A) Dial Setting Output Power (mW)
0.000 0.0 1.2
0.744 3.66 1.1
0.753 3.72 4.6
0.851 4.22 102
0.954 4.74 219
1.051 5.22 355
1.151 5.71 512
1.249 6.18 692
1.350 6.64 901
1.451 7.08 1118
1.556 7.52 1352
1.654 7.92 1546
1.761 8.32 1720
1.853 8.67 1855
1.959 9.05 1989
2.098 9.50 2146

 

Attachment 1: PvsI_2W.jpg
PvsI_2W.jpg
  2828   Wed Apr 21 21:56:27 2010 KevinUpdatePSLInnolight 2W Vertical Beam Profile

Koji and Kevin measured the vertical beam profile of the Innolight 2W laser at one point.

This data was taken with the laser crystal temperature at 25.04°C and the injection current at 2.092A.

The distance from the razor blade to the flat black face on the front of the laser was 13.2cm.

The data was fit to the function y(x)=a*erf(sqrt(x)*(x-x0)/w)+b with the following results.

Reduced chi squared = 14.07

x0 = (1.964 +- 0.002) mm

w  = (0.216 +- 0.004) mm

a  = (3.39  +- 0.03) V

b  = (3.46  +- 0.03) V

Attachment 1: bp2.jpg
bp2.jpg
Attachment 2: bp2.dat
razor height (mm)   Voltage (V)
2.75    6.89
2.50    6.90
2.30    6.89
2.25    6.89
2.20    6.75
2.15    6.47
2.13    6.20
2.10    6.05
2.07    5.88
... 17 more lines ...
  2829   Wed Apr 21 22:11:48 2010 ranaUpdatePSLInnolight 2W Vertical Beam Profile

Back in Gainesville in 1997, I learned how to do this using the chopper wheel. We had to make the assumption that the wheel's blade was moving horizontally during the time of the chop.

One advantage is that the repetitive slices reduces the random errors by a lot - you can trigger the scope and average. Another advantage is that you can download the average scope trace using USB, floppy, or ethernet instead of pencil and paper.

But, I never analyzed it in enough detail to see if there was some kind of nasty systematic error.

  2830   Wed Apr 21 23:35:37 2010 KojiUpdatePSLInnolight 2W Vertical Beam Profile

Good fit. I assumed sqrt(x) is a typo of sqrt(2).

Quote:

Koji and Kevin measured the vertical beam profile of the Innolight 2W laser at one point.

This data was taken with the laser crystal temperature at 25.04°C and the injection current at 2.092A.

The distance from the razor blade to the flat black face on the front of the laser was 13.2cm.

The data was fit to the function y(x)=a*erf(sqrt(x)*(x-x0)/w)+b with the following results.

Reduced chi squared = 14.07

x0 = (1.964 +-  0.002) mm

w = (0.216 +- 0.004) mm

a = (3.39 +- 0.03) V

b = (3.46 +- 0.03) V

 

  2834   Thu Apr 22 21:42:24 2010 AlbertoUpdatePSLInnolight 2W Vertical Beam Profile

 

 What kind of fit did you use? How are the uncertainties in the parameters obtained?

  14556   Fri Apr 19 14:06:36 2019 gautamUpdatePSLInnolight NPRO shutoff

When I got back from lunch just now, I noticed that the PMC TRANS and REFL cameras were showing no spots. I went onto the PSL table, and saw that the NPRO was in fact turned off. I turned it back on.

The laser was definitely ON when I left for lunch around 130pm, and this happend around 140pm. Anjali says no one was in the lab in between. None of the FEs are dead, suggesting there wasn't a labwide power outage, and the EX and EY NPROs were not affected. I had pulled out the diagnostics connector logged by Acromag, I'm restoring it now in the hope we can get some more info on what exactly happened if this is a recurring event. So FSS_RMTEMP isn't working from now on. Sooner we get the PSL Acromag crate together, the better...

Attachment 1: Screenshot_from_2019-04-19_14-06-11.png
Screenshot_from_2019-04-19_14-06-11.png
  14560   Fri Apr 19 20:21:52 2019 gautamUpdatePSLInnolight NPRO shutoff

Happened again at ~730pm.

The NPRO diag channels don't really tell me what happened in a causal way, but the interlock channel seems suspicious. Why is the nominal value 0.04 V? From the manual, it looks like the TGUARD is an indication of deviations between the set temperature and actual diode laser temperature. Is it normal for it to be putting out 11V?

I'm not going to turn it on again right now while I ponder which of my hands I need to chop off.

Quote:
 

I'm restoring it now in the hope we can get some more info on what exactly happened if this is a recurring event.

Attachment 1: Screenshot_from_2019-04-19_20-27-04.png
Screenshot_from_2019-04-19_20-27-04.png
  14566   Wed Apr 24 16:06:44 2019 gautamUpdatePSLInnolight NPRO shutoff

After discussing with Koji, I turned the NPRO back on again, at ~4PM local time. I first dialled the injection current down to 0A. Then powered the control unit state to "ON". Then I ramped up the power by turning the front panel dial. Lasing started at 0.5A, and I saw no abrupt swings in the power (I used PMC REFL as a monitor, there were some mode flashes which are the dips seen in the power, and the x-axis is in units of time not pump current). PMC was relocked and IMC autolocker locked the IMC almost immediately.

Now we wait and watch I guess.

Attachment 1: PMCrefl.png
PMCrefl.png
  14577   Thu Apr 25 17:31:56 2019 gautamUpdatePSLInnolight NPRO shutoff

NPRO shutoff at ~1517  local time today afternoon. Again, not many clues from the NPRO diagnostics channel, but to my eye, the D1_POW channel shows the first variation from the "steady state", followed by the other channels. This is ~0.1 sec before the other channels register some change, so I don't know how much we can trust the synchronizaiton of the EPICS data streams. I won't turn it on again for now. I did check that the little fan on the back of the NPRO controller is still rotating.

gautam 10am 4/29: I also added a longer term trend of these diagnostic channels, no clear trends suggesting a fault are visible. The y-axis units for all plots are in Volts, and the data is sampled at 16 Hz.

Quote:

Now we wait and watch I guess.

Attachment 1: EdwinShutoff20190425.png
EdwinShutoff20190425.png
Attachment 2: EdwinShutdown_zoomOut.png
EdwinShutdown_zoomOut.png
  12109   Thu May 5 21:28:44 2016 gautamUpdateendtable upgradeInnolight PZT capacitance

I suggested in an earlier elog that after the repair of the NPRO, the PZT capacitance may have changed dramatically. This seems unlikely - I measured the PZT capacitance with the BK Precision LCR meter and found it to be 2.62 nF, which is in excellent agreement with the numbers from elogs 3640 and 4354 - but this makes me wonder how the old setup ever worked. If the PZT capacitance were indeed that value, then for the Pomona box design in elog 4354, and assuming the PM at ~216kHz which was the old modulation frequency was ~30rad/V as suggested by the data in this elog, we would have had a modulation depth of 0.75 if the Function Generator were set to output a Signal at 2Vpp (2Vpp * 0.5 * 0.05 * 30rad/V = 1.5rad pp)! Am I missing something here?

Instead of using an attenuator, we could instead change the capacitor in the pomona box from 47pF mica to 5pF mica to realize a modulation depth of ~0.2 at the new modulation frequency of 231.25 kHz. In any case, as elog 4354 suggests, the phase introduced by this high-pass filter is non-zero at the modulation frequency, so we may also want to install an all-pass filter which will allow us to control the demodulation phase. This should be easy enough to implement with an Op27 and passive components we have in hand...

 

  11961   Fri Jan 29 14:43:47 2016 SteveUpdateGreen LockingInnolight laser is 10 years old
Quote:

After adjusting the alignment of the two beams onto the PD, I managed to recover a stronger beatnote of ~ -10dBm. I managed to take some measurements with the PLL locked, and will put up a more detailed post later in the evening. I turned the IMC autolocker off, turned the 11MHz Marconi output off, and closed the PSL shutter for the duration of my work, but have reverted these to their nominal state now. The are a few extra cables running from the PSL table to the area near the IOO rack where I was doing the measurements from, I've left these as is for now in case I need to take some more data later in the evening...I

Innolight 1W 1064nm, sn 1634 was purchased in 9-18-2006 at CIT. It came to the 40m around 2010

It's diodes should be replaced, based on it's age and performance.

RIN and noise eater bad. I will get a quote on this job.

The Innolight Manual frequency noise plot is the same as Lightwave' elog 11956

Attachment 1: inno1W.pdf
inno1W.pdf
  11962   Fri Jan 29 16:55:27 2016 ranaUpdateGreen LockingInnolight laser is 10 years old

I don't think there's any evidence that the noise eater is bad. That would change the behavior of the relaxation oscillation which is at 1 MHz ?

  11963   Sat Jan 30 00:12:22 2016 gautamUpdateGreen LockingInnolight laser is 10 years old

 

Quote:

I don't think there's any evidence that the noise eater is bad. That would change the behavior of the relaxation oscillation which is at 1 MHz ?

While I was investigating the AM/PM ratio of the Innolight, I found that there was a pronounced peak in the RIN at ~400kHz, which did not change despite toggling the noise eater switch on the front panel (see plot attached). The plot in the manual suggests the relaxation oscillations should be around 600kHz, but given that the laser power has dropped by a factor of ~3, I think it's reasonable that the relaxation oscillations are now at ~400kHz? 

Attachment 1: RIN_comparison.pdf
RIN_comparison.pdf
  11964   Sat Jan 30 09:56:24 2016 KojiUpdateGreen LockingInnolight laser is 10 years old

It is strange that there is no difference between with and without NE, isn't it?

ELOG V3.1.3-