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
  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

  10105   Wed Jun 25 20:45:04 2014 NichinUpdateElectronicsAS55 Bodeplot

 [Nichin]

I finally did carry out a measurement on the network analyzer. This proves that the previous system will work properly. Just the optical splitter problem is to be taken care of.

For this, after Elog 10102, I did not touch any of the tables or photodiodes. Only turned on the laser at 1Y1 and took readings from the NA located nearby. I switched off the laser after measurements. The power to REF PD remains on.

I plotted transimpedence plots in the usual way and got ridiculous values of 15 ohms at 55MHz. Obviously there is the problem of varying amount of power illuminating the REF PD and AS55.

So, I just plotted the bode plots of transfer function got from the NA to check if the characteristics of AS55 looks as it was supposed to be and Yes! I got a nice peak at 55MHz.

 

Acquiring data

 RACK 1Y1

  • Diode Laser driving current: 240mA 
  • The following conditions were set on Network Analyzer Agilent 4395:

 

1) Frequency sweep range: 1MHz to 100 MHz.

2) Number of Points sampled in  the range: 801

3) Type of sweep: Linear

  • Set the NA to give the corresponding transfer function value (output of AS55 over output of 1611) and also Phase response in degrees.
  • Save the data into floppy disk for processing on the computer.

 

 

The experimental values obtained were:

DC output voltage of REF PD: 7.48V

DC output voltage of AS55: 53.7mV

Power incident on REF PD and AS55 respectively: 2.4mW  and 1.6mW

Taking the DC transimpedence of AS55 as 66.2 ohms (from schematic given at D1300586-v1) and for REF PD as 1E04 ohms

Hence, Responsivity for REF PD and AS55 respectively are:  0.312 A/W and 0.51 A/W

 

The data and code used are in the zip file.

  16608   Thu Jan 20 18:16:29 2022 AnchalUpdateBHDAS4 set to trigger free swing test

AS4 is set to go through a free swinging test at 10 pm tonight. We have used this script (Git/40m/scripts/SUS/InMatCalc/freeSwing.py) reliably in the past so we expect no issues, it has a error catching block to restore all changes at the end of the test or if something goes wrong.

To access the test, on allegra, type:

tmux a -t AS4

Then you can kill the script if required by Ctrl-C, it will restore all changes while exiting.

  16589   Fri Jan 14 17:33:10 2022 YehonathanUpdateBHDAS4 resurrection

{Yehonathan, Anchal}

Came this morning, the gluing of the magnets was 100% successful. Side blocks, counterweights were assembled. We suspend AS4 and adjust the roll balance and the magnet height (attachments 1,2). OpLev was slightly realigned.

The pitch was balanced. We had to compensate for the pitch shift due to the locking of the counterweights. Once we got good pitch balance, the motion spectrum was taken (attachment 3). Major peaks are at 755mHz, 953mHz, 1040mHz.

Previous peaks were 755mHz, 964mHz, and 1.062Hz so not much has changed. We pushed back the OSEMs, adjusted OSEM plate and locked it tightly. We lock the EQ stops and transfer AS4 to the vacuum chamber in foil. We open the foil inside the chamber. No magnets were broken. Everything seems to be intact. We connect the OSEMs to CDS.

  16590   Fri Jan 14 18:12:47 2022 AnchalSummaryBHDAS4 placed in ITMY Chamber, OSEMs connected

AS4 was succesfully suspended and trasported to ITMY chamber (40m/16589). We placed it near the door to make it easy to tune the OSEMs. We connected the OSEMs and found that the LL OSEM is not responding. Even though the the OSEMs are completely out right now, there was no signal on this OSEM. This could be an issue in either at the LED driver circuit or the PD circuit in AS4 Sat Amp box, or it could be the OSEM that is bad. We'll investigate further next day. For now, we recorded the full brightness reading for the OSEMs:

  • UL: 32767  -> 16383
  • UR: 29420 -> 14710
  • LR: 30100 -> 15050
  • SD: 29222 -> 14611

Another thing to note is that UL value above is not changing at all. I checked the CDS screen and the the ADC input is overflowing in complete bright position of the OSEM.

  16594   Tue Jan 18 18:19:22 2022 KojiSummaryBHDAS4 placed in ITMY Chamber, OSEMs connected

AS4 satellite amplifier D1002818 / D080276 troubleshoot

I dug into the circuit to see what/where things were wrong.

- UL saturation issue: The open light voltage at the TIA output (I-V out) was 10.4V. It seemed that the photocurrent of 86uA was simply a little too much for the transimpedance gain of 121kOhm. So the R18 was replaced to 100kOhm. This made the I-V out to be 8.6V and the ADC input count to be 28200 (Attachment 1). This modification was done on the unit S2100742 CH1 (LEFT CH1)

- Non responding LL issue: Now moved on to LL (LEFT CH2). The basic circuit test didn't reveal any problem. So the DSUB25 cables were swapped at the vacuum feedthru flange. The result is shown in Attachment 2. LL OSEM issue was moved to the 2nd ch of the right channel of the sat amp (CH6). This is means that the problem is somewhere in the vacuum chamber (including the vacuum feedthru). We need to check the in-vacuum cable and the OSEM. We can test the OSEM by swapping the position of the OSEM connector between LL and UL (for example).

 

  16604   Thu Jan 20 16:42:55 2022 PacoUpdateBHDAS4 OSEMs installation - part 2

[Paco]

Turns out, the shifting was likely due to the table level. Because I didn't take care the first time to "zero" the level of the table as I tuned the OSEMs, the installation was b o g u s. So today I took time to,

a) Shift AS4 close to the center of the table.

b) Use the clean level tool to pick a plane of reference. To do this, I iteratively placed two counterweights (from the ETMX flow bench) in two locations in the breadboard such that I nominally balanced the table under this configuration to zome reference plane z0. The counterweight placement is of course temporary, and as soon as we make further changes such as final placement of AS4 SOS, or installation of AS1, their positions will need to change to recover z=z0.

c) Install OSEMs until I was happy with the damping. ** Here, I noticed the new suspension screens had been misconfigured (probably c1sus2 rebooted and we don't have any BURT), so quickly restored the input and output matrices.


SUSPENSION STATUS UPDATED HERE

  16596   Wed Jan 19 12:56:52 2022 PacoSummaryBHDAS4 OSEMs installation

[Paco, Tega, Anchal]

Today, we started work on AS4 SOS by checking the OSEM and cable. Swapping the connection preserved the failure (no counts) so we swapped the long OSEM for a short one that we knew was working instead, and this solved the issue. We proceeded to swap in a "yellow label", long OSEM in place and then noticed the top plate had issues with the OSEM threads. We took out the bolt and inspected its thread, and even borrowed the screw from PR2 plate but saw the same effect. Even using a silver plated setscrew such as the SD OSEM one resulted in trouble... Then, we decided to not keep trying weird things, and took our sweet time to remove the UL, UR OSEMs, top earthquake stops, and top plate carefully in-situ. Then, we continued the surgery by installing a new top plate which we borrowed from the clean room (the only difference is the OSEM aperture barrels are teflon (?) rather than stainless. The operation was a success, and we moved on to OSEM installation.

After reaching a good place with the OSEM installation, where most sensors were at 50% brightness level and we were happy with the damping action (!!), we fixed all EQ stops and proceeded to push the SOS to its nominal placement. Then upong releasing the EQ stops, we found out that the sensor readings were shifted.

  16581   Thu Jan 13 12:29:27 2022 AnchalSummaryBHDAS4 LR magnet broke

After the debacle with AS1 (40m/16580), we decided the put the PEEK earthquake stop by first removing the lower OSEM plate and then doing it. So I unfastened AS4 from its position with the earthquake stops in place and moved the suspension to the center of the table. Then I carefully removed the bottom OSEM plate. But I found out that the LR magnet is broken and lying on the floor of the suspension sad. Given my past on the same day, it could be me breaking it again during the moving of the suspension of taking off the OSEM plate or there is a small chance that this break happened before. Regardless of fault, this meant we have to resuspend AS4 again as well. So we transported AS4 back to the clean room and the work on it's re-suspension has begun.

  16613   Fri Jan 21 16:40:10 2022 AnchalUpdateBHDAS4 Input Matrix Diagonalization performed.

The free swinging test was successful. I ran the input matrix diagonalization code (/opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/sus_diagonalization.py) on the AS4 free-swinging data collected last night. The logfile and results are stored in /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/AS4 directory. Attachment 1 shows the power spectral density of the DOF basis data (POS, PIT, YAW, SIDE) before and after the diagonalization. Attachment 2 shows the fitted peaks.


Free Swinging Resonances Peak Fits
  Resonant Frequency [Hz] Q A
POS 1.025 337 3647
PIT 0.792 112 3637
YAW 0.682 227 1228
SIDE 0.993 164 3094

AS4 New Input Matrix
  UL UR LR LL SIDE
POS
0.844
0.707
0.115
0.253
-1.646
PIT
0.122
0.262
-1.319
-1.459
0.214
YAW
1.087
-0.901
-0.874
1.114
0.016
SIDE
0.622
0.934
0.357
0.045
3.822

The new matrix was loaded on AS4 input matrix and this resulted in no control loop oscillations at least. I'll compare the performance of the loops in future soon.

 

  16616   Mon Jan 24 17:12:27 2022 ranaUpdateBHDAS4 Input Matrix Diagonalization performed.

I think our suspension input matrix diagonalization is not so robust usually because we only choose a inverting matrix which gives the best separation for a single suspension alignment.

i.e. we have seen in the past that adjusting the bias for the alignment makes the matrix inversion not work well. Sometime people turn OFF the alignment bias before making the ringdown and that makes the whole measurement invalid.

This is because the sensitivity of the OSEMs to longitudinal and/or transverse motion is significantly different for different alignment.

I wonder if there's a way we can choose a better matrix by putting in random gain errors on the shadow sensor signals and then finding the matrix which gives the best diag under an ensemble of gain errors.

  16619   Mon Jan 24 20:48:48 2022 AnchalUpdateBHDAS4 Input Matrix Diagonalization performed.

I agree. That's an interesting idea. But does that mean that there is an always working inverse matrix solution or that any solution will be vulnerable to the alignment biases.

I think we can also calculate the matrix rotation required as a function of dc biases and do that rotation in the simulimk model.

Quote:

I think our suspension input matrix diagonalization is not so robust usually because we only choose a inverting matrix which gives the best separation for a single suspension alignment.

i.e. we have seen in the past that adjusting the bias for the alignment makes the matrix inversion not work well. Sometime people turn OFF the alignment bias before making the ringdown and that makes the whole measurement invalid.

This is because the sensitivity of the OSEMs to longitudinal and/or transverse motion is significantly different for different alignment.

I wonder if there's a way we can choose a better matrix by putting in random gain errors on the shadow sensor signals and then finding the matrix which gives the best diag under an ensemble of gain errors.

 

  6488   Thu Apr 5 06:27:51 2012 kiwamuUpdateLSCAS110 sideband monitor installed

[Jenne / Kiwamu]

 We have installed a broad band PD in the AS path in order to monitor the 110 MHz signal associated with the SRC.

The PD is currently connected to the POP110 demodulation board and it seems working fine.

I know this is confusing but right now the signal appears as "POP110" in the LSC front end model.

 


  • Installed a 50% BS at the AS path
    • The AS beam is split to two path - one goes to AS55 and the other goes to the OSA.
    • The new BS is installed on the way of the OSA branch therefore AS55 isn't affected by the new BS.
  • Installed a PDA10A
    • This is a silicon diode with a bandwidth of 150 MHz, and is fast enough to detect the 110 MHz signals.
    • The 110 MHz signal seems going up to approximately -40 dBm according to a coarse measurement with an RF spectrum analyzer.
    • Also a SMA-style high pass filter, HPF-100, was attached to the output to cut off unnecessary sidebands (e.g. 11, 22 MHz and etc.)
  • Put a long BNC cable, which goes from the PD to LSC rack.
    • The end of the cable at the LSC rack was directly connected to the POP110 demod board.
    • The actual POP110 signal path is currently terminated by a 50 Ohm load and therefore this signal  is unavailable.
  • Adjustment of the demodulation phase
    • The demod phase was adjusted to be 7 deg in the EPICS screen. This phase minimize the Q-signal.
    • Locking PRMI with sidebands resonating makes the AS110 signal ~ a few counts and this level is still noticeable.
    • Perhaps we may need to put an RF amplifier to get the signal bigger.
  4576   Wed Apr 27 21:08:08 2011 ranaUpdateLSCAS11

I worked on AS_11 today. Its ready for its noise / optical gain calibrations. I have left it on Suresh's desk.

AS11.png

This was one of the 24.5 MHz Black Box (Ben Abbott) style RFPDs rescued from LLO. The tunable inductor that was installed was too small to get the frequency down to 11 MHz and so I swapped in one of the shielded, ferrite core ones from our '7mm' CoilCraft kit. It had a range of 1.2 - 1.8 uH according to the datasheet.

I wasn't able to simulataneously get the peak at 11.06 MHz and the notch at 59.3 MHz and so I took Koji's advice and tuned the peak best. The plot above shows how the notch is slightly off. I think its not a problem; to get it better we would have to change out the inductor for the "2-omega" notch, but I was too lazy. The thinking is that its more important to have the gain be symmetric around the signal readout frequency so as to not imbalance the audio sidebands.

Since this one is going to be AS_11, we think that the 22 MHz signal will be tiny: the transmission of the 11 MHz sidebands to the dark port is small. If we later want to put in a 22 MHz notch anyway, there is space to do this via the 'active notch' pads around the MAX4107.

For the above plot, I used the Jenne laser. The DC output of the PD was ~30 mV (~0.6 mA). The RF drive to the laser was -10 dBm: no saturations. I have calibrated out the cable responses, but not using the 1811 setup, so the absolute calibration has yet to be done.

Also, it needs some new stickers. It would be handy if someone can figure out how to get some sheets of stickers that we can put into the printer. Then we can laser printer all of the data onto the stickers and stick them to the RFPD box.

  16632   Fri Jan 28 16:35:18 2022 AnchalSummaryBHDAS1, PR2 and PR3 set to trigger free swing test

AS1, PR2 and PR3 are set to o go through a free swinging test at 3 am. We have used this script (Git/40m/scripts/SUS/InMatCalc/freeSwing.py) reliably in the past so we expect no issues, it has a error catching block to restore all changes at the end of the test or if something goes wrong.

To access the test, on allegra, type:

tmux a -t AS1
tmux a -t PR2
tmux a -t PR3

Then you can kill the script if required by Ctrl-C, it will restore all changes while exiting.

 

  16599   Wed Jan 19 18:15:34 2022 YehonathanUpdateBHDAS1 resurrection

Today I suspended AS1. Anchal helped me with the initial hanging of the optics. Attachments 1,2 show the roll balance and side magnet height. Attachment 3 shows the motion spectra.

The major peaks are at 668mHz, 821mHz, 985mHz.

For some reason, I was not able to balance the pitch with 2 counterweights as I did with the rest of the thin optics (and AS1 before). Inserting the weights all the way was not enough to bring the reflection up to the iris aperture that was used for preliminary balancing. I was able to do so with a single counterweight (attachment 4). I'm afraid something is wrong here but couldn't find anything obvious. It is also worth noting that the yaw resonance 668mHz is different from the 755mHz we got in all the other optics. Maybe one or more of the wires are not clamped correctly on the side blocks?

The OSEMs were pushed into the OSEM plate and the plates were adjusted such that the magnets are at the center of the face OSEMs. The wires were clamped and cut from the winches. The SOS is ready for installation.

Also, I added a link to the OSEM assignments spreadsheet to the suspension wiki.

I uploaded some pictures of the PEEK EQ stops, both on the thick and thin optics, to the Google Photos account.

  16603   Thu Jan 20 12:10:51 2022 YehonathanUpdateBHDAS1 resurrection

I was wondering whether I should take AS1 down to redo the wire clamping on the side blocks. I decided to take the OpLev spectrum again to be more certain. Attachments 1,2,3 show 3 spectra taken at different times.

They all show the same peaks 744mHz, 810mHz, 1Hz. So I think something went wrong with yesterday's measurement. I will not take AS1 down for now. We still need to apply some glue to the counterweight.

  16722   Thu Mar 10 10:05:49 2022 PacoUpdateSUSAS1 free swing test

[Paco, Ian]

  • Begin free swinging test for AS1 at 10:05 AM, set for ~ 2.04 hours.
    • Test failed because damping failed to disable.
  • Restart free swinging test for AS1 at 15:06, set for 2.04 hours.
    • Success (Attachment #1 shows the DOF input matrix diagonalization effect)

Of slight concern is the side to other degrees of freedom coupling, but this is definitely an improvement from last time.

ELOG V3.1.3-