40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 327 of 346  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  15317   Sat May 2 02:35:18 2020 KojiUpdateALSASY M2 PZT damaged

Yes, we are supposed to have a few spare PI PZTs.

  14716   Mon Jul 1 20:27:44 2019 gautamUpdateASCASX tuning

Summary:

To practise the dither alignment servo tuning, I decided to make the ASX system work again (mainly because it has fewer DoFs and so I thought it'd be easier to manage). Setup is: dither PZT mirrors on EX table-->demodulate green transmission at the dither frequencies-->Servo the error signals to 0 by an integrator.

Details:

  1. Started by checking the dither lines are showing up with good SNR in GTRX. They are, see Attachment #1. The dither lines are at 18.23 Hz, 27.13 Hz, 53.49 Hz and 41.68 Hz, and all of them show up with SNR ~100.
  2. Hand-aligned the beam till I got a maximum of GTRX ~ 0.35. This is lower than the usual ~0.5 I am used to - possibilities are (i) in the process of plugging in the BNC cable to the rear of the EX laser for my PLL investigations, I disturbed the alignment into the SHG crystal ever so slightly and I now have less green light going into the cavity or (ii) there is an iris on the EX table just before the green beam goes into the vacuum on which it is getting clipped. IIRC, I had centered the GTRX camera view such that the spot was well centered in the field of view, but now I see substantial mis-centering in pitch. So the cavity alignment for IR could also be sub-optimal (although I saw TRX ~1.15). Anyways, I decided to push on.
  3. Introduced a deliberate offset in a given DoF, e.g. M1 PIT. Then I looked at the demodulated error signals (filtered through an RLP0.5 filter post demodulation, so the 2f component should be attenuated by 100 dB at least), and tuned the demod phase until most of the signal appeared in the I-phase, which is what is used for servoing. The Q-phase signals were ~x10 lower than their I-phase counterparts after the tuning.
  4. Checked the linearity of the error signal in response to misalignment of a given DoF. I judged it to be sufficiently linear for all four DoFs about the quadratic part of the GTRX variation.
  5. Tweaked the overall servo gains to have the error signals be driven to 0 in ~10 seconds.
  6. There was quite significant cross-coupling between the DoFs - why should this be? I can understand the PIT->YAW coupling because of imperfect mounting of the PZT mounted mirror in a rotational sense, but I don't really understand the M1->M2 coupling.
  7. Nevertheless, the servo appears to work - see Attachment #2.

The adjusted demod phases, servo gains were saved to the .snap file which gets called when we run the "DITHER ON" script. Also updated the StripTool template.

I plan to repeat similar characterization on the IR dither alignment servos. I think the tuning of the ASS settings can be done independently of figuring out the mystery of why the TRY level is so low.

  9018   Fri Aug 16 13:25:50 2013 KojiUpdateASSASX model/screen cleaning up

[Koji Manasa]

Yesterday we cleaned up the ASX model and screens to have more straight forward structure of the screen
and the channel names, and to correct mistakes in the model/screens.

The true motivation is that I suspect the excess LF noise of the X arm ALS can be caused by misalignment
and beam jitter coupling to the intensity noise of the beat. I wanted to see how the noise is affected by the alignment.
Currently X-end green is highly misaligned in pitch.

- Any string "XEND" was replaced by "XARM", as many components in the system is not localized at the end table.

- The name like "XARM-ITMX" was changed to "XARM-ITM". This makes easier to create the corresponding model for the other arm.

- There was some inconsistency between the MEDM screens and the ASX model. This was fixed.

- A template StripTool screen was created. It is currently saved in users/koji/template as ASX.stp.
  It will be moved to the script directory once it's usefulness is confirmed.


The next step is to go to the end table and manually adjust M2 mirror while M1 is controlled by the ASX.
The test mass dithering provides the error signal for this adjustment but the range of the PZT is not enough
to make the input spot position to be controlled. In the end, we need different kind of matching optics
in order to control the spot position. (But is that what we want? That makes any PZT drift significantly moves the beam.)

  8982   Wed Aug 7 22:18:43 2013 KojiUpdateASCASS update

While Gautam is working on the Xarm green ASS...

The EPICS monitor points for the ASS actuators were added to the ASS model.

This will be used for the offloading the ASS actuations to the alignment biases.
As this modification allowed us to monitor the actuation apart from the dithering,
now we can migrate the ASS actuation to the fast alignment offset on the suspension.
This modification to the offset moving scripts were also done.

Screenshot-Untitled_Window.png

  7100   Tue Aug 7 03:20:56 2012 JenneUpdateASSASS setup, on, off scripts written

I wrote new setup, on and off scripts for the arm ass.  They take the arm as an argument, so it's the same script for both arms.  Scripts are in ...../scripts/ASS/ , and have been checked in to the 40m svn.

So far the on script doesn't really do anything, since I haven't chosen values for the CLKGAINs of the lockins.  The old values were 30 for lockins 12, 14, 27, 29 and 250 for lockins 7, 9, 22, 24.  Unfortunately, I have no memory of which lockin means what in the old numbered system.  I'll have to look that up somehow.  Or, just dither the optics using some value and look at the spectrum to see the resulting SNR and just pick something that gives me reasonable SNR.

I modified the ASS model slightly:

* Added an overall gain to the ASS_DOF2 library part, between the matrix and the servo inputs so we can do soft startups.  Self - remember that the main ASS screen needs to be modified to reflect this!

* Rearranged the order that the demodulated signals go into the matrix.  I hadn't paid attention, and the old ordering had the transmission (TRX/TRY) demod signals interleaved with the LSC demod signals.  I've changed it to be all the TR signals, then all the LSC signals.  I think this makes more sense, since we will use these inputs separately, so now they're on different halves of the matrix.

  8980   Wed Aug 7 19:16:20 2013 JenneUpdateASCASS setting up accelerated more

I have furthered Koji's work, and moved the filter on/off state for all the filter banks also to the burt snapshot.  

Turning on the ASS is now much faster than it was originally, with the ezcawrites in series.

  8977   Wed Aug 7 15:32:37 2013 KojiUpdateASCASS setting up accelerated (slightly)

I moved bunch of ezcawrite from the ASS Dither On script to a snapshot file.

This accelerated a half of the "up" time but still switching part is not in the snapshot.

If you find anything wrong with ASS, please notify me.

  6677   Thu May 24 16:13:05 2012 yutaUpdateComputersASS scripts on new ubuntu machines

[Den, Yuta]

Background:
 ASS and many other scripts don't work on new ubuntu machines.

What we did:
1. Installed C-shell on rossa and rosalba(Ubuntu machine).
  sudo apt-get insall csh

2. Find out that
  /opt/rtcds/caltech/c1/scripts/AutoDither/alignY

runs, but
  /opt/rtcds/caltech/c1/scripts/medmrun /opt/rtcds/caltech/c1/scripts/AutoDither/alignY

doesn't run. It gives us the following error messages.

ezcawrite: error while loading shared libraries: libca.so: cannot open shared object file: No such file or directory
ezcaswitch: error while loading shared libraries: libca.so: cannot open shared object file: No such file or directory

Result:
 ASS scripts run on rossa and rosalba, but not with medmrun.
 At least ASS scripts run on pianosa(ubuntu machine) with medmrun. So we decided to wait for JAMIE to fix it.

  6684   Fri May 25 17:50:38 2012 JamieUpdateComputersASS scripts on new ubuntu machines

Quote:

[Den, Yuta]

Background:
 ASS and many other scripts don't work on new ubuntu machines.

What we did:
1. Installed C-shell on rossa and rosalba(Ubuntu machine).
  sudo apt-get insall csh

2. Find out that
  /opt/rtcds/caltech/c1/scripts/AutoDither/alignY

runs, but
  /opt/rtcds/caltech/c1/scripts/medmrun /opt/rtcds/caltech/c1/scripts/AutoDither/alignY

doesn't run. It gives us the following error messages.

ezcawrite: error while loading shared libraries: libca.so: cannot open shared object file: No such file or directory
ezcaswitch: error while loading shared libraries: libca.so: cannot open shared object file: No such file or directory

Result:
 ASS scripts run on rossa and rosalba, but not with medmrun.
 At least ASS scripts run on pianosa(ubuntu machine) with medmrun. So we decided to wait for JAMIE to fix it.

Apparently the environment was not being properly inherited by the scripts launched from medmrun.  We modified the medmrum script so that it executes things with an interactive shell ("bash -i -c ...") and this fixed the problem (by assuring that it sources all the interactive environment configs (i.e. ~/.bashrc)).  I'm still not sure why we were seeing different behavior on pianosa, but at least the solution we have now should be robust.

As a reminder, all scripts launched from MEDM should use medmrun:

/opt/rtcds/caltech/c1/scripts/medmrun
  5817   Sat Nov 5 00:04:23 2011 kiwamuUpdateASCASS scripts gone

Did somebody delete all the scripts in /opt/rtcds/caltech/c1/scripts/ASS ?

  5818   Sat Nov 5 00:24:13 2011 SureshUpdateASCASS scripts gone

Quote:

Did somebody delete all the scripts in /opt/rtcds/caltech/c1/scripts/ASS ?

 I have moved all the MC_ASS scripts to a directory called MC under ASS

 

  5821   Sat Nov 5 14:54:59 2011 KojiUpdateASCASS scripts gone

In any case, the daily backup of the scripts are found in /cvs/cds/caltech/scripts_archive

Quote:

Quote:

Did somebody delete all the scripts in /opt/rtcds/caltech/c1/scripts/ASS ?

 I have moved all the MC_ASS scripts to a directory called MC under ASS 

 

  10789   Fri Dec 12 04:33:49 2014 JenneUpdateASCASS retuned

[Rana, Jenne]

We decided that tonight was the night for ASS tuning. 

We started from choosing new frequencies, by looking at the transmission and the servo control signals spectra to find areas that weren't too full of peaks.  We chose to be above the OpLev UGF by at least a factor of ~2, so our lowest frequency is about 18Hz.  This way, even if the oplevs are retuned, or the gains are increased, the ASS should still function. 

We set the peak heights for the lowest frequency of each arm to have good SNR, and then calculated what the amplitude of the higher frequencies ought to be, such that the mirrors are moving about the same amount in all directions. 

We re-did the low pass filters, and eliminated the band pass filters in the demodulation part of the servo.  The band passes aren't strictly necessary, as long as you have adequate lowpassing, so we have turned them off, which gives us the freedom to change excitation frequencies at will.  We modified the lowpass filter so that we had more attenuation at 2Hz, since we spaced our excitation frequencies at least ~2.5 Hz apart.

The same lowpass filter is in every single demodulator filter bank (I's and Q's, for both length and transmission demodulation).  We are getting the gain hierarchy just by setting the servo gains appropriately. 

We ran ezcaservos to set the demodulation phase of each lockin, to minimize the Q-phase signal. 

We then tuned up the gains of the servos.  Rana did the Y arm, but for the X arm I tried to find the gains where the servos went unstable, and then reduced the gain by a factor of 2.  The Xarm is having trouble getting good alignment if you start with something less than about 0.7, so there is room for improvement.

Rana wrote a little shell script that will save the burt snapshot, if the gains need adjusting and they should be re-saved. 

The scripts have been modified (just with the new oscillator amplitudes - everything else is in the burt snapshots), so you should be able to run the start from nothing and the start from frozen scripts for both arms.  However, please watch them just in case, to make sure they don't run away.

  10807   Wed Dec 17 01:51:44 2014 rana, jenneUpdateASCASS retuned

Did a big reconfig to make the Y-arm work again since it was bad again.

  1. Undid Koji's topology change. The A2L loops now feedback to the arm mirrors to adjust the cavity axis. The cavity transmission signals now feedback to the input beam.
  2. The UGF of the Trans->Input beam servos is ~5-10x higher than the A2L servos.
  3. The Trans loops have a ~10-15 s settling time.
  4. The Input Matrix has been adjusted to fit with our intuition:The ETM tilt moves the beam equally on the ITM and ETM faces.
  5. The Output Matrix has also been adjusted to do like this: we're using an intuitive matrix inverse rather than one based on measurement. It turns out to be a reasonable guess and we can tune this later.
  6. Seems stable with many kinds of steps and misalignments. Seems not reliable if the arm power is less than ~0.5.
  7. Reducing the dither amplitudes to make the power fluctuation less than 5% made it much more stable.

With the arm aligned and the A2L signals all zeroed, we centered the beam on QPDY (after freezing the ASS outputs). I saw the beam going to the QPD on an IR card, along with a host of green spots. Seems bad to have green beams hitting the QPD alogn with the IR, so we are asking Steve to buy a bunch of the broad, dielectric, bandpass filters from Thorlabs (FL1064-10), so that we can also be immune to the EXIT sign. I wonder if its legal to make a baffle to block it on the bottom side?

P.S. Why is the Transmon QPD software different from the OL stuff? We should take the Kissel OL package and put it in place of our old OL junk as well as the Transmons.

  10812   Wed Dec 17 19:04:12 2014 jenneUpdateASCASS retuned

I made the Xarm follow the new (old) topology of Length -> test masses, and Trans -> input pointing.

It takes a really long time to converge (2+ min), since the input pointing loops actuate on the BS, which has an optical lever, which is slow.  So, everything has to be super duper slow for the input pointing to be fast relative to the test mass motion.

Also, between last night and this afternoon, I moved the green ASX stuff from a long list of ezca commands to a burt file, so turning it on is much faster now.  Also, I chose new frequencies to avoid intermodulation issues, set the lockin demodulation phases, and tuned all 4 loops.  So, now the green ASX should work for all 4 mirrors, no hand tuning required.  While I was working on it, I also removed the band pass filters, and made the low pass filters the same as we are using for the IR ASS.  The servos converge in about 30 seconds.

  10813   Wed Dec 17 19:31:55 2014 KojiUpdateASCASS retuned

I wonder what to do with the X arm.

The primary purpose of the ASS is to align the arm (=transmission), and the secondary purpose is to adjust the input pointing.

As the BS is the only steering actuator, we can't adjust two dof out of 8 dof.
In the old (my) topology, the spot position on ITMX was left unadjusted.

If my understanding of the latest configuration, the alignment of the cavity (=matching of the input axis with the cavity axis)
is deteriorated in order to move the cavity axis at the center of the two test masses. This is not what we want as this causes
deterioration of the power recycling gain.

  10946   Tue Jan 27 21:33:39 2015 KojiUpdateASCASS retuned

I checked the situation of ASS. I wanted to know how much we are away from the maximum transmittion.

Conclusion:
ASS makes the X arm shifted from the maximum transmission. This causes the contrast degraded by ~3%.
We need to fix the Xarm ASS so that it can maximize the transmission and ignor the spot centering at ITMX.


Conditioning before the measurement:

- ASDC offset was removed
- X&Y arm was aligned by ASS

With ASS:

Average transmission: 0.86
Pmax = 1045 +/- 9 cnts
Pmin = 22 +/- 4 cnts

==> Contrast = (Pmax - Pmin)/(Pmax+Pmin) = 0.960+/-0.007

After manual alignment of the X arm (ignoring spot centering):

Average transmission: 0.88
Pmax = 1103 +/- 11 cnts
Pmin = 5 +/- 1 cnts

==> Contrast = (Pmax - Pmin)/(Pmax+Pmin) = 0.991+/-0.002

  13033   Fri Jun 2 01:22:50 2017 gautamUpdateASSASS restoration work

I started by checking if shaking an optic in pitch really moves it in pitch - i.e. how much PIT to YAW coupling is there. The motivation being if we aren't really dithering the optics in orthogonal DoFs, the demodulated error signals carry mixed information which the dither alignment servos get confused by. First, I checked with a low frequency dither (~4Hz) and looked at the green transmission on the video monitors. The spot seemed to respond reasonably orthogonally to both pitch and yaw excitations on either ITMY or ETMY. But looking at the Oplev control signal spectra, there seems to be a significant amount of cross coupling. ITMY YAW, ETMY PIT, and ETMY YAW have the peak in the orthogonal degree of freedom at the excitation frequency roughly 20% of the height of the DoF being driven. But for ITMY PIT, the peaks in the orthogonal DoFs are almost of equal height. This remains true even when I changed the excitation frequencies to the nominal dither alignment servo frequencies.

I then tried to see if I could get parts of the ASS working. I tried to manually align the ITM, ETM and TTs as best as I could. There are many "alignment references" - prior to the coil driver board removal, I had centered all Oplevs and also checked that both X and Y green beams had nominal transmission levels (~0.4 for GTRY, ~0.5 for GTRX). Then there are the Transmon QPDs. After trying various combinations, I was able to get good IR transmission, and reasonable GTRY.

Next, I tried running the ASS loops that use error signals demodulated at the ETM dither frequencies (so actuation is on the ITM and TT1 as per the current output matrix which I did not touch for tonight). This worked reasonably well - Attachment #1 shows that the servos were able to recover good IR transmission when various optics in the Y arm were disturbed. I used the same oscillator frequencies as in the existing burt snapshot. But the amplitudes were tweaked.

Unfortunately I had no luck enabling the servos that demodulate the ITM dithers.

The plan for daytime work tomorrow is to check the linearity of the error signals in response to static misalignment of some optics, and then optimize the elements of the output matrix.

I am uploading a .zip file with Sensoray screen-grabs of all the test-masses in their best aligned state from tonight (except ITMX face, which for some reason I can't grab).

And for good measure, the Oplev spot positions - Attachment #3.

Quote:

While Gautam is working the restoration of Yarm ASS, I worked on Xarm.

 

  9081   Wed Aug 28 06:26:28 2013 manasaUpdateComputer Scripts / ProgramsASS req and snap files edited

[From yesterday] ASS for X arm was behaving slightly funny over the last couple of days. ASS could not correct the BS misalignment. Jenne pointed out that the LSC output matrix on the ASS medm screen set itself to zeroes whenever we ran the ASS_dither_ON script. I checked the burt request file: ASS_DITHER_ON.req  in /opt/rtcds/caltech/c1/scripts/ASS and found that the LSC output matrix channels were not added to it. I added these channels for both the X and Y arm. Following this, I also edited the corresponding snap file as well. This should now set the LSC matrix to the right values everytime we run the script.

  7135   Thu Aug 9 12:31:36 2012 JenneUpdateASSASS rebuilt again
I was (in between Eric's measurements) driving the YARM ASS dithers, and noticed that instead of driving ITMY PIT, I was driving ITMX PIT. I looked in the model, and when I re-did the model after an svn revert a few days ago, it looks like I got the shmem parts for the ITM PIT signals backwards. I have fixed that, rebuilt, installed and restarted the ass model.
  8657   Thu May 30 11:33:26 2013 JamieConfigurationComputer Scripts / ProgramsASS medm/model changes need to be committed to SVN

There are a lot of changes to the ASS stuff that have not been committed to the SVN:

controls@rossa:/opt/rtcds/userapps/release/isc/c1 0$ svn status | grep -v '?'
M       medm/c1als/C1ALS_X_SLOW.adl
D       medm/c1ass/C1ASS_TRY_YAW_LOCKIN.adl
D       medm/c1ass/ASS_SERVOS.adl
D       medm/c1ass/ctrl_yaw_mtrx.adl
D       medm/c1ass/C1ASS_QPDS.adl
D       medm/c1ass/C1ASS_SEN_YAW_MTRX.adl
M       medm/c1ass/C1ASS_XARM_SEN_MTRX.adl
D       medm/c1ass/SITEMODEL_LOCKINNAME.adl
D       medm/c1ass/C1ASS_TRX_YAW_LOCKIN.adl
D       medm/c1ass/C1ASS_LOCKIN1.adl
D       medm/c1ass/C1ASS_LOCKIN2.adl
D       medm/c1ass/C1ASS_LOCKIN3.adl
D       medm/c1ass/C1ASS_LOCKIN4.adl
D       medm/c1ass/C1ASS_LOCKIN5.adl
D       medm/c1ass/C1ASS_LOCKIN6.adl
D       medm/c1ass/C1ASS_LOCKIN7.adl
D       medm/c1ass/C1ASS_LOCKIN8.adl
D       medm/c1ass/C1ASS_LOCKIN9.adl
D       medm/c1ass/C1ASS_REFL11I_PIT_LOCKIN.adl
M       medm/c1ass/C1ASS.adl
D       medm/c1ass/C1ASS_LOCKIN10.adl
D       medm/c1ass/C1ASS_LOCKIN11.adl
D       medm/c1ass/C1ASS_LOCKIN12.adl
D       medm/c1ass/C1ASS_LOCKIN13.adl
D       medm/c1ass/C1ASS_LOCKIN14.adl
D       medm/c1ass/C1ASS_LOCKIN15.adl
D       medm/c1ass/sen_yaw_mtrx.adl
D       medm/c1ass/C1ASS_LOCKIN16.adl
D       medm/c1ass/C1ASS_LOCKIN17.adl
D       medm/c1ass/C1ASS_DOF_YAW.adl
D       medm/c1ass/C1ASS_LOCKIN18.adl
D       medm/c1ass/C1ASS_LOCKIN19.adl
D       medm/c1ass/C1ASS_TRY_PIT_LOCKIN.adl
D       medm/c1ass/ctrl_pit_mtrx.adl
D       medm/c1ass/C1ASS_SEN_PIT_MTRX.adl
D       medm/c1ass/C1ASS_LOCKIN20.adl
D       medm/c1ass/C1ASS_LOCKIN21.adl
D       medm/c1ass/C1ASS_LOCKIN22.adl
D       medm/c1ass/C1ASS_LOCKIN23.adl
D       medm/c1ass/C1ASS_LOCKIN24.adl
D       medm/c1ass/C1ASS_LOCKIN25.adl
D       medm/c1ass/C1ASS_LOCKIN26.adl
D       medm/c1ass/C1ASS_LOCKIN27.adl
D       medm/c1ass/C1ASS_TRX_PIT_LOCKIN.adl
D       medm/c1ass/C1ASS_LOCKIN28.adl
D       medm/c1ass/C1ASS_LOCKIN29.adl
D       medm/c1ass/C1ASS_XARM_QPDS.adl
D       medm/c1ass/C1ASS_YARM_QPDS.adl
M       medm/c1ass/C1ASS_XARM_OUT_MTRX.adl
D       medm/c1ass/ASS_SEN_MTRX.adl
D       medm/c1ass/ASS_LOCKINS.adl
D       medm/c1ass/sen_pit_mtrx.adl
D       medm/c1ass/C1ASS_REFL11I_YAW_LOCKIN.adl
D       medm/c1ass/C1ASS_LOCKIN30.adl
D       medm/c1ass/C1ASS_DOF_PIT.adl
M       models/c1ass.mdl
controls@rossa:/opt/rtcds/userapps/release/isc/c1 0$
  12140   Mon May 30 18:19:50 2016 JohannesUpdateCDSASS medm screen update

I noticed that the TRY button in the ASS main screen was linking to LSC_TRX instead of LSC_TRY. Gautam fixed it.

  7137   Thu Aug 9 23:50:09 2012 JenneUpdateASSASS matrix measured, first ASS test

Koji pointed out that I was being silly, and rather than actually misaligning the optics (by, say, changing their IFO Align sliders) I was changing the location of the actuation node by changing the coil output gains.  Now I see nice signals at the I_OUT of each of the demodulators (so far I've only looked at the YARM).

I've measured and inverted the matrix by taking the nominal values of the demodulator outputs when the optics are all by-hand optimally aligned, then one-by-one misaligning an optic's angle (pitch or yaw), and looking at the demod outputs that result.  Repeat with each misalignment DoF for each of the 4 rows of the matrix.  Then I set the pit/yaw coupling elements of the matrix to zero.  Then invert the matrix, put it in, and see what happens.  So far, the yaw DoFs converged to zero, but the pitch ones didn't.  I'll play with it more and think some more tomorrow.

  12869   Mon Mar 6 12:34:30 2017 johannesSummaryASSASS light injection scenarios

What we want from the light source for the AS port light injection:

  • Frequency control for locking and maintaining known offset from arm cavity resonances -> see below
  • Fast extinguishing light in the IFO -> AOM first order switching

We have four possible laser sources that we can use for the injection of 1064 nm from the back:

  • There are ~65 mW of IR power coming from the PSL doubling oven, of which ~2mW are used for the fiber beat box. The remaining light is currently dumped on the PSL table and would be available. It is picked off after the PMC and does not have any of the sidebands.
  • There is a ~200 mW Lightwave NPRO on the PSL table that is currently unused.
  • Koji said he has a ~500mW NPRO in the OMC lab that has no PZT actuation. I contacted a couple companies about fiber-coupled variable AOM frequency shifters that we can pair with this laser.
  • I don't think using the high power beam of the PSL itself is a good idea, especially if we want to map the loss on the optics, because' we'll need it for the dither locking

I think for maximum flexibility it's best to fiber-couple whichever source we choose on the PSL table and then just collimate it out of a fiber on the AS table. This way if we want to add fiber-coupled modulators of any kind it's a plug-and-play modification.

Different frequency control schemes are:

  • Modulate sidebands on the light and stabilize directly to the arm, using POX/Y or back-reflection at AS
    • Free-space resonant EOM
    • Free-space broadband EOM with Rich's resonant amplifier attachment
    • Fiber-coupled EOM
  • Offset phaselock:
    • PSL IR: Transfer mode-cleaner stability
      • Can lock arms while measurement in progress, but will have PSL IR light on PDs
    • Green from the end;
      • Broadly tunable laser frequency and no interference from IR.

Either way we'll need a few things:

  • Faraday Isolator
    • required for PDH locking, optional if we phaselock instead
  • AOM
    • We have free-space available, looking into fiber-coupled ones with frequency tuning
    • Fast switching electronics
  • Various fiber stuff
    • We have enough to set up the fiber coupling of one light source. I'm starting with the 200 mW NPRO but this is technically interchangable.

I'm working on how to best set this up at the AS port and interfere with normal operation as little as possible. Ideally we use a Faraday just like for squeezed light injection, but this requires some modification of the layout, although nothing that involves mode-matching.

 

 

  6979   Tue Jul 17 02:17:50 2012 JenneUpdateASCASS gains wrong?
I was checking on the ASS system, and I think that the gains on some of the loops may not be correct. An old symptom was that the commands in the script were not being executed when we changed over to Ubuntu. Now it seems that each command is working fine, but the loops are pushing the optics more out of alignment than anything. I flipped the sign on some of the loops and it helped, others it didn't. I need to measure some transfer functions and meditate on what they should look like. It will be really nice to have the alignment system working again.
  10719   Fri Nov 14 19:28:33 2014 JenneUpdateSUSASS gain reduced for Yarm

[Koji, Jenne]

We noticed last night that the yarm couldn't handle the old nominal gain for the ASS servos.  We were able to run the ASS using about 0.3 in the overall gain.  So, I have reduced the gain in each of the individual servos by a factor of 3, so that the scripts work, and can set the overall gain to 1.

  6723   Thu May 31 01:20:41 2012 JenneUpdateASSASS filter outputs are non-zero with no input

I was looking a little at ASS, while Yuta was doing some Green transmitted DC PD work, and I find that the output of some filters is totally insane with no deliberate input or excitation signals.

Note in the figure that the filter (which is a 2nd order butter bandpass in the C1:ASS-LOCKIN29_SIG filter bank) is ringing a lot - this needs fixing.  But, more disconcertingly, sometimes (not every time) the arm flashes, the input to the filter bank gets a ~1 sample long spike that is ~9,000,000 counts.  9 million is a lot of counts.  This is then making the filter go crazy.

Any ideas on how this can happen, and how we can stop / fix it?  It's certainly a CDS issue, but I'm not sure where or how.

  740   Fri Jul 25 17:32:46 2008 SharonUpdate ASS computer
So, it seems a bit too complicated getting the coefficients the way I wanted it to happen (simulink-.ini...).
I returned everything to the way it was and it's all working. The new plan is to choose the specific channel I want to find its instantanous coefficients, let the adaptive code run for a while, setting mu and tau to zero (freezing the coefficients), and exciting the noise signal channel taking the transfer function. This way I can find the filter I want to simulate with an IIR filter.
Once I have the mode cleaner to myself, I'll start posting results.
  383   Sun Mar 16 17:03:32 2008 robConfigurationCDSASS code change

I've updated the ass.mdl file in the directory:

/cvs/cds/caltech/users/alex/cds/advLigo/src/epics/simLink/

to get us started in the adaptive PEM noise subtraction.

After several iterations of remote help from Alex, the code compiles and runs, receives signals from the LSC, PEM, and MC2, and communicates with the suspension controllers. I've also adapted the .par file from the code generator, but haven't got the testpoints working with the new ASS code. There are no MEDM screens yet, and Matt's adaptive filter code has not been installed (there's a matrix as a placeholder).

Putting in the adaptive code should be simple, building the MEDM screens tedious, and getting the testpoints working uncertain. I noticed that the new testpoint.par file starts at a different channel number than the previous (working) version, which is strange. I probably have a script somewhere to change all these numbers by a constant offset, but I don't know if that's the actual problem--maybe stuff just needs to be rebooted.

The code receives as input the first 24 channels from the PEM ADCU, the eight suspension control signals from the LSC, and the output of the MCL filter from MC2. It outputs to the MCL filter input of each suspension (except MC2).
  2323   Tue Nov 24 18:24:54 2009 SanjitConfigurationAdaptive FilteringASS channels added to framebuilder

 

[Sanjit, Jenne, Rob, Joe]

 

We added and tested the following channels from "/cvs/cds/gds/param/tpchn_C3.par" to "/cvs/cds/caltech/chans/daq/C1ASS.ini" appending a "_2048" extension to the channel name (as the name of a channel in .ini and .par files must be different):

[C1:ASS-TOP_CORR_IN1_2048]
[C1:ASS-TOP_ERR_EMPH_IN1_2048]
[C1:ASS-TOP_PEM_10_IN1_2048]
[C1:ASS-TOP_PEM_11_IN1_2048]
[C1:ASS-TOP_PEM_12_IN1_2048]
[C1:ASS-TOP_PEM_15_IN1_2048]
[C1:ASS-TOP_PEM_16_IN1_2048]
[C1:ASS-TOP_PEM_17_IN1_2048]
[C1:ASS-TOP_PEM_18_IN1_2048]
[C1:ASS-TOP_PEM_19_IN1_2048]
[C1:ASS-TOP_PEM_20_IN1_2048]
[C1:ASS-TOP_PEM_24_IN1_2048]
[C1:ASS-TOP_PEM_2_IN1_2048]
[C1:ASS-TOP_PEM_3_IN1_2048]
[C1:ASS-TOP_PEM_4_IN1_2048]
 

These five-line entries for each channels in the .par file were manually copy pasted from the .ini file, should think about a smarter way...

The old .par file is kept as: /cvs/cds/caltech/chans/daq/C1ASS.ini.20Nov2009

The current one is also saved as: /cvs/cds/caltech/chans/daq/C1ASS.ini.24Nov2009

And, the current one is committed to the svn.

 

NOTE: In the first attempt, the channel names were mistakenly kept the same in both the .ini and .par files and this caused DAQ daemon to crash badly. It could only be recovered by hard reboot of the frame builder.  Important info here: Jenne's elog 2316

  11562   Thu Sep 3 00:29:45 2015 ranaUpdateASCASS X not working

ran the ON script several times and it kept pulling it away from good alignment, even when TRX was > 0.9.

Also, for what reason was this model run at 16 kHz?? Makes no sense to me to have a low frequency servo system run so high. Only makes for more digital precision noise, more CPU time, etc. Of course, running it at 2k would mean having to think about all of the AA filtering needed to go up/down from 2k to 16k.

  10745   Tue Dec 2 01:27:22 2014 diegoUpdateASCASS Scripts for arms

I updated the medm C1ASS page for the Arm scripts:

ON : same as before

FREEZE OUTPUTS: calls new FREEZE_DITHER.py script, which sets Common Gain and LO Amplitudes to 0, therefore freezing the current output values

START FROM FROZEN  OUTPUTS: calls new UNFREEZE_DITHER.py script, which sets Commong Gain and LO Amplitudes as in the DITHER_ASS_ON.py script, but no burt restore is performed

OFFLOAD OFFSETS: it's the old "SAVE OFFSETS", calls the WRITE_ASS_OFFSET.py script

OFF: same as before

StripTool: same as before

 

 

  6361   Tue Mar 6 00:13:20 2012 keikoUpdateLSCASI signal offset

Screenshot-Untitled_Window.png

AS55Q and AS55I signals. AS55Q is around zero while AS55I has a large offset which is about the signal amplitude. It is likely because of the RAM?

keiko, kiwamu

 

 

 

 

  10972   Wed Feb 4 14:30:05 2015 ericqUpdateLSCASDC Whitening Gain

At the lunch meeting, we were thinking about the exess high frequency content of the MICH control signal, which leads to railing against the FM output limiter and lock loss. I propsed that POPDC sensor/ADC noise was the culprit. 

In short, I was wrong. Just now, I locked the PRMI with a MICH offset as we normally do, and then froze the POPDC output. The MICH spectrum did not change in any noticible way. 

However, increasing the analog ASDC whitening gain showed a direct improvement of the error signal noise floor, and thus a reduction in the control signal spectrum. I.e. we have been suffereing from ASDC ADC noise.

We had previously set the ASDC whitening gain so that half fringe of the PRMI would be well within the ADC range, but since we're actually only ever going to 25%, I feel fine upping this gain. Interestingly, when increasing the whitening gain by 12dB,  the control signal spectrum has fallen by more like 20 dB in the 400Hz-1kHz region, which is great. 

The only potential hurdle I can think of is that when we start reducing the MICH offset at zero CARM offset, we may approach ADC saturation in ASDC before we can hand off to RF signals, in which case we would have to dynamically lower the whitening gain, which introduces offsets, which could get hairy. But, since MICH railing has been directly seen to lead to lock-loss, I'd rather solve that problem first. 

  13392   Wed Oct 18 17:34:09 2017 gautamUpdateSUSASDC

Summary:

The signal path for the ASDC signal is AS55 PD --> D990543 (interface board) --> D990694 (whitening board) --> D000076 (AA board) --> ADC Ch 31. Everything in this signal chain should be able to handle signals in the range +/- 10V, which should correspond to the full range of our +/-10V, 16bit ADCs. But the ASDC signal seems to saturate at ~2000 counts (i.e. turning up the analog whitening gain doesn't make the signal get any bigger than this). I investigated this a little more today.

Details:

  • The ASDC signal is derived from the AS55 photodiode. According to the schematic, the Op27 that supplies this voltage is powered by +/- 15V, so the output should be able to swing between at least +/- 12V.
  • The DC signal goes from the DB15 connector on the side of the PD to the LSC electronics rack, 1Y2, where it is interfaced with an LSC PD Interface Card, D990543. Again, per the schematic, the Op27 driving this voltage is powered by +/- 15V, and so the available output voltage swing should be greater than +/-12V.
  • The D990543 output is to its backplane connector. There is an adaptor board hooked up to the backplane that makes these outputs available to a LEMO connector. A LEMO-SMA cable then pipes this output to a D990694.
    • I decided to test the functionality of this board.
    • Disconnected the SMA ASDC input signal (CH8 on the board).
    • Drove that channel with an SR function generator and gradually turned up the Vpp of the input signal (sine wave at 145Hz).
    • Monitored the ASDC channel on dataviewer while doing this.
    • Saw that the ASDC signal saturated at ~2000 counts. Turning up the signal amplitude did not have any effect.
  • From the whitening board, the signal goes through an anti-aliasing module (D000076). The final stage LT1125s on these boards should also be supplied with +/-15V.

So the problem lies somewhere downstream of the D990694. There are other anomalous behaviours of this channel - e.g. engaging the analog whitening filters changes the DC offset of the signal. I am going to pull out this board to check it out.

Why does this matter? I want to calibrate the ASDC level (and eventually the other PD DC signals as well) into Watts. This is useful for IFO diagnostics, noise budgeting the shot noise level etc.

According to the AS55 schematic, the DC transimpedance is 66.7 ohms. I claim that the DC power on the AS55 photodiode during a DRMI (no arms) lock is ~1mW. The C30642 photodiode (InGaAs) responsivity is ~0.8 A/W. So I'd expect ~50mV to be the signal level into the ADC (assuming gain of all the other electronics in the signal chain at the start of this elog is unity). This corresponds to ~163 counts (since the ADC conversion factor is 2^16 counts over 20volts). The DC signal level I observed is ~200 counts. So things seem roughly consistent.

*Note: Despite my above statement, I don't think it is true that the AS110 PD has more light on it - the BS splitting the light between

AS55 and AS110 PDs is a 50-50 BS, and using the crude method of putting an Ophir power meter in front of both PDs and

monitoring the power while the Michelson was swinging around freely showed roughly the same maximum value.

  11108   Fri Mar 6 04:49:08 2015 JenneUpdateLSCAS55Q transition

[Jenne, Ranah]

We played around tonight with different possible ways of transitioning DARM to normalized AS55Q.  Before each try, we would use ezcaservo (or just eyeball it) to make sure that the normalized RF signals had a mean of zero, so that we knew we were pretty close to zero offset in both CARM and DARM.

We tried something that is similar in flavor to Kiwamu's self-locking technique - we summed in some normalized AS55Q to the DARM error point (using the DoF selector matrix that I created a few weeks ago), and then tried to engage a little low frequency boost.  We tried several times, but we never successfully made the transition.

In the end, we just did a direct transition over to normalized AS55Q, and lost lock after several seconds.  The buzzing that we hear didn't change noticeably after the transition, which indicates that most of the noise is due to CARM (which makes since, since it has a much smaller linewidth).  The problem with holding DARM is that occassionally we will have a CARM fluctuation that lets the arm power dip too low, and DARM's error signal isn't valid at low arm powers. So, we need to work on getting CARM stabilized before we will have a hope of holding on to DARM. 

Here's the lockloss plot from that last lock:

Also this evening, I scanned back and forth over the CARM zero crossing while locked on ALS, to see what the RF error signals looked like.  Normalized REFL55 seems to have much more high frequency noise near the edges of the linear range than does REFL11.  Also, the REFL 11 signal is much larger.  So, what I think I want to try to do is use ALS fool to lower the CARM noise by a bit, then make the DARM transition.  Then, we can come back to CARM and ramp up the gain. 

With these CARM sweeps, I think that I know the relative gain and sign between ALScomm and the normalized REFL signals, and the REFL signals versus the normalized versions.  I think that 100*REFL11I/(TRX+TRY) gives the same slope at the zero crossing as just plain REFL11I.  Same factor of 100 is true for REFL55I.  The REFL11 slope is 20,000 times larger than the ALS slope, while the REFL55 slope is -500 times the ALS slope (note that REFL55 has a minus sign).  We can probably trigger the Fool on when the arm powers are above 50, and trigger off when they're below 20.  For the zero crossings, the REFL55 threshold should be about 20, and the REFL11 threshold should be about 500. 

I also need to re-think the triggering logic for ALSfool.  We probably don't want the zero crossing logic to be able to un-trigger the lock, just in case we get an extra noise blip.  So, we want to trigger on with an AND, but only trigger off if the arm powers go too low.  Also, the zero crossing logic should look at the normalized error signals, not the plain signals.

We need to modify the ALSwatch logic so that it doesn't look at EPICS values for the thresholding.  There may be an updated filter module that includes a saturation monitor, but otherwise we can use the saturation monitor part that is in the OSC section of CDS_PARTS.  We'll set the threshold on this to match the limiter in the filter bank.  Then, if the filterbank output is constantly hitting the limiter, we should run the down scripts.

 

 

  11105   Thu Mar 5 21:42:05 2015 JenneUpdateLSCAS55Q flat at DARM zero crossing

I think we've seen this in simulations, but it's a little disheartening to see in real life.  AS55Q looks like it flattens out pretty significantly right around the DARM=0 point. 

Right now I have the arms held on ALS (CARM=-1*MC2, DARM=2*ETMY, as Q used last night), and the PRFPMI is on REFL165I&Q.  I have set CARM to be as close to zero offset as I can (so I get all the usual buzzing), and then I'm sweeping the DARM offset between +3 and -3 counts (roughly +/-3nm) with a 3 second ramp and looking at normalized AS55Q.  The channel called "DARM_B_ERR" is 0.006*AS55Q/(TRX + TRY).  The arm transmissions, as well as the ASDC are plotted as well - ASDC is scaled to fit on the same axes as the transmissions.

Anyhow, here's the time series of the DARM sweeps.  AS55 demod phase of -55 degrees seems to give the cleanest signal (within 5deg steps); this is the same phase that we've been using all week.

DARM_TimeSeries_5March2015.pdf

  13369   Mon Oct 9 22:18:34 2017 gautamUpdateLSCAS55Q Dark Noise

I measured the output voltage noise of the Q output of the AS55 Demod Board with the PSL shutter closed, using the SR785 (see Attachment #1). The measured noise is consistent with the expected number of ~120nV/rtHz around 100Hz. I had measured the gain of this board from RFPD input to Q output to be ~5.1: so if the PD dark noise is 16nV/rtHz, this would be amplified to ~80nV/rtHz. Still a discrepancy of ~50%. I didn't measure the noise with the PD input terminated. Added the noise of the demod board output with the RFPD input terminated. The level of ~100nV/rtHz seems consistent with the actual PD dark noise being ~80nV/rtHz, as their quadrature sum is around 130nV/rtHz. Need to dig up the schematics for the demod board + daughter board, and check against LISO, to see if this is consistent with what is expected.

Also - I think I was using the wrong value of the DC power on the AS55 photodiode for shot noise calculations - 13mW was for REFL55, not AS55. I did a crude measurement of the power by sticking the Ophir power meter (filter removed) in front of the AS55 PD with the Michelson flashing around, and noticed the maximum value registered was ~1.2mW. So in the DRMI lock, there would be ~2.4mW, which is 10x lower than the value I was assuming. I've made the correction in the NB code, for the next time the plot is generated. A more rigorous measurement would involve sticking the Ophir in front of the AS110 PD during a DRMI lock. The light from the AS port is split by a 50-50 BS to the AS55 and AS110 PDs (so measuring at AS110 is a reasonable proxy for power at AS55), and the AS110 signals are not used for triggering in the DRMI lock, so this is feasible.

 

  13370   Tue Oct 10 22:04:06 2017 ranaUpdateLSCAS55Q Dark Noise

how about calibrate the DC channels so that you can just get the acutal power levels from the trend data?

  13372   Wed Oct 11 14:42:03 2017 gautamUpdateLSCAS55Q Dark Noise

I keep adding traces to this plot, here is the most complete one I have now. Looks like the input noise to the D040179 (measured at "Q out" SMA jack of D990511 with RFPD input terminated) is ~10nV/rtHz. This supports the hypothesis that something is wonky on the daughter board, because the purple trace should only be the quad sum of the orange and green traces. I will pull it out and have a look.

Some other follow-ups on the questions raised at the meeting:

  1. Doesn't look like I've implemented thin film resistors on the input of the coil driver boards. De-whitening boards have the critical signal path resistors (judged as the ones with largest contribution as per LISO model) changed to thin film. Pictures are here.
  2. I think I didn't make a full elog of my demod board efficiency investigations, but from my notes and Attachment #4 of elog 12972, I calculated the gain in the signal path as the ratio of Vpp_out / Vpp_in.
Quote:

I measured the output voltage noise of the Q output of the AS55 Demod Board with the PSL shutter closed, using the SR785 (see Attachment #1). The measured noise is consistent with the expected number of ~120nV/rtHz around 100Hz. I had measured the gain of this board from RFPD input to Q output to be ~5.1: so if the PD dark noise is 16nV/rtHz, this would be amplified to ~80nV/rtHz. Still a discrepancy of ~50%. I didn't measure the noise with the PD input terminated. Added the noise of the demod board output with the RFPD input terminated. The level of ~100nV/rtHz seems consistent with the actual PD dark noise being ~80nV/rtHz, as their quadrature sum is around 130nV/rtHz. Need to dig up the schematics for the demod board + daughter board, and check against LISO, to see if this is consistent with what is expected.

Also - I think I was using the wrong value of the DC power on the AS55 photodiode for shot noise calculations - 13mW was for REFL55, not AS55. I did a crude measurement of the power by sticking the Ophir power meter (filter removed) in front of the AS55 PD with the Michelson flashing around, and noticed the maximum value registered was ~1.2mW. So in the DRMI lock, there would be ~2.4mW, which is 10x lower than the value I was assuming. I've made the correction in the NB code, for the next time the plot is generated. A more rigorous measurement would involve sticking the Ophir in front of the AS110 PD during a DRMI lock. The light from the AS port is split by a 50-50 BS to the AS55 and AS110 PDs (so measuring at AS110 is a reasonable proxy for power at AS55), and the AS110 signals are not used for triggering in the DRMI lock, so this is feasible.

 

 

  13374   Wed Oct 11 19:31:32 2017 gautamUpdateLSCAS55Q Dark Noise

I tried replacing the AD797s on the daughter board with OP27s, and saw no significant improvement in the electronics noise of the demod board. Note that according to LISO, in this configuration, the voltage noise of the Op27 is expected to dominate the total noise of the daughter board. Measurement condition was that the RFPD input was terminated, but the LO input was still being driven (SR785 input range is -50dBVpk for all traces, and the input ranging was set to "UpOnly"). Need to do a more systematic investigation to figure out where this excess noise is coming from. I will upload photos of the board later.

Quote:

This supports the hypothesis that something is wonky on the daughter board, because the purple trace should only be the quad sum of the orange and green traces. I will pull it out and have a look.

 

  13376   Thu Oct 12 01:50:11 2017 gautamUpdateLSCAS55Q Dark Noise

I worked on the daughter board a little more in the evening. I have somehow managed to make the dark noise ~25% worse [Attachment #1].

  • Earlier in the day, I had switched out both on-board AD797s for OP27. The latter has ~3x the input voltage noise, and LISO modeling suggests that this is the dominant contribution to the output voltage noise.
  • There are some differences in the actual components with which the board is stuffed, and the schematic. 
  • After updating the LISO model, I expect to get an output voltage noise of ~50nV/rtHz. But I measured ~2x this value (measured with LO input of demod board driven, RFPD input terminated).
  • While I had the board out, I replaced most of the installed thick-film resistors with thin film ones. For good measure, I also changed the AD829s.

After making all these changes, I re-installed the card in the eurocrate and repeated the measurement. The Q channel noise was close to the expected value (~50nV/rtHz), but the I channel is twice as noisy. I will continue this investigation tomorrow.

  13378   Thu Oct 12 12:17:28 2017 gautamUpdateLSCAS55Q Dark Noise

Here is the marked up schematic with the board as it is stuffed. Annoyingly, there is a capacitor (C1) which according to the schematic is supposed to be open, but is stuffed in our board. I can't find any elog about this, and its a pain to measure the value of this capacitance. I will upload all of this + LISO + noise model/measurements to a 40m AS55 daughter board DCC page.

 

  13380   Fri Oct 13 12:26:12 2017 gautamUpdateLSCAS55Q Dark Noise

Attachment #1 - Measured / modelled noises for AS55 demod board. I've plotted quadrature sum of the LISO trace with the SR785 noise floor with input terminated to ground via 50ohm. Note that these measurements were made after all the changes in the marked up schematic in the previous elog were implemented.

Both channels should be identical - I don't understand why the I channels are noisier than their Q counterparts. This is almost certainly a problem on the daughter board, as the orange traces are pretty much identical for both channels.

The dark red curves were measured by shorting the inputs to D040179 to ground via 50ohms using some Pomona minigrabbers - I wanted to avoid ripping the daughter board out, but this probably explains the excess noise compared to the green trace at low frequencies. All other measurements were made with the board installed in the LSC rack eurocrate, with the LO input driven at the nominal level (I didn't measure this yesterday but a measurement from ~6months ago says that this level is 1.5dBm).

  13382   Mon Oct 16 16:01:04 2017 gautamUpdateLSCAS55Q Dark Noise

Koji suggested looking at the output of the AS55 demod board on a fast oscilloscope to look for differences in the two channel outputs (if there is some high-frequency oscillations, for example, we could miss this information in the SR785 spectra). Besides, I was only looking at spectra out to a few kHz on the SR785. I grabbed this data with a 300MHz BW Tektronix oscilloscope (battery mode) today. Input impedance of both channels were set to 1Mohm, and the measurement was made with the RFPD input terminated, output of the daughter board is what is measured. The vertical scaling of the channels was set to the minimum allowed, 1mV/div.

Attachment #1 shows that there is indeed a visible difference between the two channels - the (noisier) I channel has a much larger DC offset of ~5mV compared to the Q channel (I tried switching channels on the O'scope and the larger DC offset remained on the I channel, so seems real). There is also some kind of oscillation going on in the I channel, although the frequency is pretty low, with the peaks spaced ~50us apart. Indeed, in the ASD of the acquired data, the excess power in the I channel at 20kHz and higher harmonics are evident (see Attachment #2). Anyway all of this points to something being anomalous on the daughter board I channel signal path - I will pull it out and monitor the outputs at various points along the signal path with the fast scope to see if I can narrow down what's going on where.

Quote:

Both channels should be identical - I don't understand why the I channels are noisier than their Q counterparts. This is almost certainly a problem on the daughter board, as the orange traces are pretty much identical for both channels.

 

  13384   Tue Oct 17 19:31:53 2017 gautamUpdateLSCAS55Q Dark Noise

[Koji, gautam]

We took a closer look at the AS55 demod board today. The procedure was to just be as thorough as possible, and check the behaviour of the circuit (both Transfer Function and Noise) stage by stage. Checking the transfer function was the key.

During this process, we found that the reason why the Q channels had lower noise than the I channels was because of the gain of the AD829 stage of the circuit was 0dB rather than 4dB (which is what it should be according to the component values used). Specifically, resistor R12, which is supposed to be 1.30kohm, was measured to be 1.03kohmfrown. Replacing this resistor, the transfer functions (see Attachment #1) and noise levels (see Attachment #2) match the expectations from LISO. Some notes:

  1. The daughter board essentially consists of 2 stages
    • OP27 stage, which has a design gain of 16dB ((=316ohm/50ohm) (flat at frequencies <100kHz).
    • AD829 stage, which has a design gain of 4dB (=1.3kohm/768ohm), and is a 2nd order Butterworth LPF with corner @ 1MHz.
    • So the overall gain of the daughter board is 20dB (i.e. x10) at audio frequencies.
  2. The output noise of D040179 is expected to be ~35nV/rtHz at 100Hz, and the measurement (made with inputs soldered together) is consistent with this value.
  3. The measured voltage noise at the input to D040179 (i.e. the output of the minicircuits mixer + SCLF-5 LPF) is ~9nV/rtHz.
  4. The output voltage noise of the demod board with RFPD input terminated then is expected to be the quadrature sum of the noise due to the D040179 electronics (i.e. 40nV/rtHz) and the input noise to the D040179 (i.e. 9nV/rtHz) multiplied by the gain of the daughter board (i.e. x10) == \sqrt{40^2 + 90^2} \approx 98nV/\sqrt{\mathrm{Hz}}.
  5. To calculate the "dark noise" contribution of AS55 to MICH displacement noise, we have to further add the photodiode dark noise contribution: this gets us up to \sqrt{98^2 + 80^2} \approx 130nV/\sqrt{\mathrm{Hz}}. This is consistent with the measurement (see Attachment #2).
  6. Assming the whitened ADC noise level is much below this (should only be ~10nV/rtHz), and given the measured sensing element of 6.2e8 V/m, this means that the dark noise sets a maximum achievable sensitivity of 2e-16m/rtHz.

To figure out what (if anything) is to be done next, we need to first figure out what is the goal. In the end, we care about DARM and not MICH. The optical gain for the former is ~300x the latter, so the dark noise contribution gets scaled by this factor (giving us a number of 7e-19 m/rtHz). There are certainly many noises above that level which have to be handled first. Indeed, looking at the DARM spectrum from DRFPMI lock back in March 2016, it looks like the current 1f DRMI (with coils de-whitened) Michelson sensitivity is within a factor of 2 of DARM in the full lock (albeit with vertex DoFs on 3f signals, and no coil de-whitening). Koji pointed out that we need to consider the photodiode resonant circuit itself too.

TODO: Upload all this onto the DCC

  5463   Mon Sep 19 16:20:35 2011 kiwamuUpdateLSCAS55 whitening gain decreased

The gain of whitening filters on AS55 was decreased from 21 dB to 0 dB for the Y arm locking.

 

- - (Background)- -

Since the modulation depths became bigger from the past (#5462), the PDH signal from Y arm was saturated in the path of AS55.

Due to the saturation the lock of the Y arm became quite difficult so I decreased the gain of of the whitening filter from 21 dB to 0 dB.

In this condition, a required gain in C1:LSC-YARM_GAIN is about -0.3, which is 10 times bigger from the default number.

For the MICH locking tonight, it may need to be back to a big gain.

  8092   Fri Feb 15 21:22:29 2013 yutaUpdateElectronicsAS55 replaced with POP55 PD

I temporarily replaced AS55 PD with PD labeled "POP55(POY55)".
I think POP55 is working because I could lock MI with this PD using AS55_Q_ERR as an error signal. I rotated I/Q phase (C1:LSC-AS55_PHASE_R) to 70 deg by minimizing ASDC during MI lock.

POP55 PD was freely sitting on the ITMX table.
I will leave AS55 PD at free space of the AP table. Someone, please look into it.

  4572   Wed Apr 27 15:34:38 2011 kiwamuUpdateElectronicsAS55 demod board with new 90 deg splitter : healthy

A new 90 deg splitter, PSCQ-2-51W, has been installed on another demod board called AS55.

It shows a reasonably close 90 degree separation between the I and Q signals at 55 MHz with various LO and RF power.

So far we have ordered only three PSCQ-2-51Ws for test. Now we will order some more for the other demodulators.

 Some plots will be posted later.

  4395   Thu Mar 10 01:31:37 2011 KevinUpdateElectronicsAS55 Characterizations

I measured the transfer function, shot noise, and dark spectrum of AS55.

From the shot noise measurement, the RF transimpedance is (556.3 +- 0.8) Ohms and the dark current is (2.39 +- 0.01) mA. The dark noise agrees with the approximate value calculated from the circuit components.

There are no anomalous oscillations when there is no light on the photodiode. I am working on fitting the transfer function in LISO but the other plots are on the wiki at http://blue.ligo-wa.caltech.edu:8000/40m/Electronics/AS55

ELOG V3.1.3-