40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 75 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  11121   Sun Mar 8 13:51:41 2015 ranaUpdateLSCError signal blending for CARM/DARM transitions

According to the official rules, we only need 8 seconds to declare it "locked".

I wonder if the double cavity pole compensation filter for CARM was on for all the attempts yesterday? IF it looks like it will not saturate, it would be more stable to have the whitening on for REFL11 / AS55. Since on Friday, I set the REFL165 demod phase just by minimizing the MICH control signal with the arms on resonance, we ought to check out the PRMI degeneracy with the ETMs misaligned.

Speaking of signal mixing: Although we weren't able to get the carrier term cancelled in the 3*f1 signals by the relative mod phase method, I wonder if we can do it by mixing the 3*f1 and 3*f2 signals in the input matrix. Might help to keep the PRMI more stable, if that's an issue.


P.S. I have done some scripts directory / SVN cleanup. Adding some directories that were not in (like lockloss) and then removing stuff from the repo using 'svn rm --keep-local  filenames' for the image and data files.

  11122   Mon Mar 9 14:14:32 2015 JenneUpdateLSCError signal blending for CARM/DARM transitions

Here is a longer stretch of data, from the first RF-only lock on Saturday night.  Unfortunately daqd had died about 400 seconds before the lockloss, so I can't show the RF signals coming on.  

ALS was on the _A channels for CARM and DARM, so when those go to zero (about -300 seconds for CARM, and about -200 seconds for DARM), we're using RF signals only for the error signals.

CARM noise definitely improves, but holy smokes does DARM start to look good!  Although, right at the end it starts to look like REFL11I is getting bigger.  Not sure why, but we'll have to watch out for this.

 


Here's the equivalent plot for the second lock stretch. This is the one that was handled by the carm_up script. It looks like I had about 150 seconds of RF-only lock here. 

DARM error is getting bigger with time jnear the end, even though I wasn't working on alignment here.  Zooming in, DARM is oscillating at 16.4 Hz, which is the bounce frequency.  I thought I had my bounce/roll filters on, but somehow it still got a little rung up.  It just rings up to a steady state though, it's not getting huge, so I don't know that it was the cause of the lockloss.

 

Attachment 1: First-ever_RFonly_lock_7March2015.png
First-ever_RFonly_lock_7March2015.png
Attachment 2: Second-ever_RFonly_lock_7March2015.png
Second-ever_RFonly_lock_7March2015.png
  8401   Wed Apr 3 14:46:17 2013 GabrieleSummaryLSCError signal simulation in PRMI

Here is a summary of a simulation of the error signal behavior in the PRMI configuration. The main parameters are:
L_PRC = 6.7538 m
Schnup = 0.0342 m
fmod1 = 11.065399e6 Hz
fmod2 = 5 * fmod1

prmi_prclsweep_pop22.pngprmi_prclsweep_pop110.png

These two plots shows the response of the POP22 and POP110 signals (in almost arbitrary units) to a PRCL sweep around the resonance. The splitting of the 55 sideband peaks is well visible in the second plot. It is due to the fact that the 55MHz sidebands are not perfectly matched to the PRC length

prmi_michsweep_pop22.pngprmi_michsweep_pop110.png

The same thing when sweeping MICH. The peaks are wider and it is not possible to see the splitting.

prmi_prclsweep_errsig_not_tunedphase.pngprmi_michsweep_errsig_not_tunedphase.png

These are the error signals (REFL11_I/Q and REFL_55_I/Q) as a function of the PRCL (left) and MICH (right) sweep. Here the demodulation phases are not properly tuned. This is just to show that when the phase is wrong, you can get multiple zero crossings (in this case only in the Q signals, but in general also in I) close to resonance.

prmi_prclsweep_errsig_tunedphase.pngprmi_michsweep_errsig_tunedphase.png

If the phases are tuned in order to maximize the slope of the I signals with respect to PRCL, one gets these "optimized phase" responses. It is that the phase does not correspond to the one that makes the PRCL peak to peak signal small in Q. The Q signals are indeed flat around resonance for a PRCL motion, but they deviate quite a lot from zero when moving more far from resonance. Moreover, both the REFL_55 error signals (I for PRCL and Q for MICH) are crossing again zero at two additional positions, but those are quite far from the resonance point.

prmi_prclsweep_triggering.pngprmi_michsweep_triggering.png

These plots just show the PRCL and MICH error signals together with the POP22 and POP110 signals, to give an idea of the level of triggering that might be needed to be inside the linear range. It seems that if we trigger on POP22 when using the REFL55 signal we loose a bit of linear range, but not that much.

prmi_prclsweep_linearized_signals.pngprmi_michsweep_linearized_signals.png

If you reached this point it means you're really interested in this topic, or maybe you have nothing better to do... However, this plot shows the effect of linearization of the error signal, obtained dividing them by the proper POP22/110 signal. The linear range is increased, but unfortunately for the 55 signals, the additional zero crossing I was mentioning before creates two sharp features. Those are however quite outside the triggering region, so they should not be harmful.

Attachment 1: prmi_michsweep_pop22.png
prmi_michsweep_pop22.png
Attachment 2: prmi_michsweep_pop110.png
prmi_michsweep_pop110.png
  8537   Tue May 7 16:21:01 2013 JenneSummaryLSCError signal simulation in PRMI

I asked Gabriele why it looked like for the PRCL sweep REFL 55 I&Q were zero at zero, but for the MICH sweep only REFL55 I was zero.  He took a look at his code, and found that he was not at the correct locking point.  Here is his email back to me:

I found the reason for the not zero value. Indeed, if you could zoom into the PRCL sweep, you would see that the error signals does not cross zero exactly at PRCL=0, but instead some 50 pm away from zero. This is enough to change a lot the PRCL signal when sweeping MICH. If I put PRCL to the correct zero point, and I sweep MICH, I now get everything at zero. I'm sending again the plots.

The fact that such a small detuning is enough to change PRCL signal when sweeping MICH is due, I believe, to the fact that MICH optical gain is much smaller than PRCL one.

Here are the redone plots:

Phase not tuned:

michsweep_errsigs_phasenottuned.pngprclsweep_errsigs_phasenottuned.png

 

Phase tuned:

michsweep_errsigs_tunedphase.pngprclsweep_errsigs_tunedphase.png

POP22 resonance for MICH and PRCL:

michsweep_pop22.pngprclsweep_pop22.png

POP110 resonance for MICH and PRCL:

michsweep_pop110.pngprclsweep_pop110.png

  10887   Tue Jan 13 00:42:15 2015 JenneUpdateLSCError signals for MICH with variable finesse technique

In order to know where we should try to make the transition from REFL##Q to ASDC for MICH, I did a quick Optickle simulation to see what the error signals will look like.

The idea is to try to lock the PRMI on a single REFL diode (ex. REFL33 I&Q) with some MICH offset, and then transition over to ASDC.  As soon as we have completed the transition, we can engage the normalization matrix to normalize ASDC by POPDC, and also increase the MICH offset if we want.  Unfortunately, we do not as yet have the ability in our model to independently normalize different error signals, and then blend them, so we have to turn on the normalization after we've transitioned.

Here is the situation for PRMI-only:

You can see that REFL33Q has a slightly wider range than REFL165Q.  It seems like we can perhaps try to make the transition around -15nm or so.  Note that the error signals are not quite symmetric about 0nm, so we can use that to help determine what + and - mean.  We expect that we need to add about 1nm offset to REFL33Q to get a true minimum in ASDC, so the sign of the digital offset that we need will tell us if there is a sign flip or not between the digital offset and this x-axis. 

After we get this to work (hopefully in the next hour or so....), we will want to try the same thing with the arms held off resonance. 

Usually we lock the PRMI at an offset of about 3nm:

However we could do it lower, perhaps around 1nm (which is where we currently are doing our CARM/DARM ALS->IR signals transitions):

At some point, we will arrive at 0nm CARM offset, when we'll want to transition back to RF signals (although probably we could jump straight to a 1f signal, not plotted):

The moral of the story here is that I'm not sure how we were ever successfully locking MICH on REFL165Q, unless my phase-setting in Optickle is way off.  Certainly it looks like we should be sticking with REFL33 for PRFPMI.  Also, since we have an offset in REFL33Q anyway (which we have seen and have commented on before), at 3nm CARM offset it looks like we could try to just do the jump without any extra digital offset.  Here's a zoom of the 3nm situation:

  8250   Thu Mar 7 12:39:12 2013 JenneUpdateLockingErudite discussion on PRMI locking

[Rana, Jenne, Yuta] (late last night)

After some trouble getting the PRMI to lock with REFL55 I&Q last night, we began to think about the size of signals everywhere, and the coupling of the sidebands in the different cavity configurations.  We have determined that it is possible that the Q phase signal is too small everywhere, so the PRMI will never be easy to lock. The Q phase will be smaller than iLIGO equivalents since the modulation frequencies are lower, and we have a small Schnupp asymmetry. The calculations of signals at each port were all done for the DRMI case, where sidebands get recycled more, so signals get larger.  If locking the PRMI is "hopeless" due to very small signals, we should stop trying, move on with other things, and come back to the corner when we have the DRMI ready. In order to figure out if it is reasonable to keep working on the PRMI, we must calculate the size of all of our signals at each port, and convert them into real units (if we expect a 1mVpp signal at REFL11Q, we're not going to successfully lock MICH with that).

So, we should:

* Calculate sideband signals at AS and REFL, for 11 and 55 MHz, for the PRMI case.

* Convert those signals into physical units (Watts -> Amps -> Volts).

* In parallel, work on dual arm ALS, and FPMI locking.

   * Try using ALS CARM for frequency stabilization.

   * Hand off from ALS CARM and DARM to PSL.

* To do ALS-FPMI, we should:

     * Use A2L to center the IR spots on all arm cavity mirrors.

     * Align green beams to the arms.

    * For each arm, determine which frequency (arm green or PSL green) is higher.

          * Lock the arm in green, align Beat PD. 

          * Push ETM, watch beat in the phase tracker.

          * Repeat for other arm.

     * Use ALS input matrix to construct CARM and DARM signals.

         * Check by shaking ALS-CARM, watch both X and Y beat signals - if they move in the same direction, we were right, but if they move in opposite directions we have flipped CARM and DARM.

    * Send the ALS-CARM signal to MC2, or the analog common mode board.

  8251   Thu Mar 7 16:55:28 2013 KojiUpdateLockingErudite discussion on PRMI locking

PRMI for the sidebands may have different situation. Investigate our wiki to find our the simulation result.

Also I'm not confident how much is the modulation depth at 55MHz is.

  13023   Wed May 31 14:23:42 2017 jigyasaUpdateComputer Scripts / ProgramsEstablishing the EPICs channels for the GigE

To set up the EPICs channels for the GigE, Gautam and I followed the steps in the elog by him  8957 .

We copied the 11 required channels from scripts/GigE/SnapPy/example_camera.db to c1cam.db that we created, however due to conflicts with the existing CAM-AS_PORT channels, the channels could not be accessed.

We later changed the database file to Video.db and on restarting the slow machine, it was verified that the channels indeed could be written to and read from.

11 channels were added

C1: CAM-MC1_X (X centroid position)
C1: CAM-MC1_Y (Y centroid position)
C1: CAM-MC1_WX (Gaussian width in the X direction)
C1: CAM-MC1_WY (Gaussian width in the Y direction)
C1: CAM-MC1_XY (Gaussian width along XY line)
C1: CAM-MC1_SUM (Pixel sum)
C1: CAM-MC1_EXP (Exposure time in microseconds)
C1: CAM-MC1_SNAP (Control signal for taking snapshots)
C1: CAM-MC1_FILE(File name for image to saved to - time stamp automatically appended)
C1: CAM-MC1_RELOAD (Reloads configuration file)
C1: CAM-MC1_AUTO (1 means autoexposure on, 0 means autoexposure off)

The procedure followed –

  • Add the channel names to the file C0EDCU.ini (path = /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini).
  • Make a database (.db) file so that these channels are actually recorded (path = /cvs/cds/caltech/target/c1aux/Video.db).
  • Restarted the slow machine. FB
  • Verify that the channels indeed exist and can be read and written to using ezcaread and ezcawrite.

GV: Initially, I made a new directory called c1cam in /cvs/cds/caltech/target/ and made a .db file in there. However, the channels were not accessible after re-starting FB (attempting to read these channels threw up the "Channel does not exist" error). On digging a little further, I saw that there were already some "C1:CAM-AS_PORT" channels in C0EDCU.ini. The corresponding database records were defined inside /cvs/cds/caltech/target/c1aux/Video.db. So I just added the new records there. I also had to uncomment out the dummy channel in C0EDCU.ini to keep an even number of channels. Restarting FB still did not allow read/write access to the channels. Looking through the files in /cvs/cds/caltech/target/c1aux, I suspected that the epics database records are loaded when the machine is first booted up - so on a hunch I re-started c1aux by keying the crate, and this did the trick. The channels can now be read / written to (tested using Python cdsutils).

  9490   Wed Dec 18 17:28:50 2013 GabrieleSummaryLSCEstimate of the PRC length error

Measurement 

Looking back at what I did in april (see log #8411) I realized that it is possible to get an estimate of how much the PRC length is wrong looking at the splitting of the sideband resonant peak as visible in the POP_110_I signal. With the help of Jenne the PRMI was aligned and left swinging. The first plot shows a typical example of the peak splitting of 55MHz sidebands. This is much larger than what was observed in April.

When the sidebands resonate inside the PRC they get a differential dephasing given by 

dPhi = 4*pi*f_mod/c * dL

where dL is the cavity length error with respect to the one that makes the sidebands perfectly resonant when the arms are not there. This is not exactly the error we are interested in, since we should take into account the shift from anti-resonance of the SBs in the arm cavities.

Nevertheless, I can measure the splitting of the peak in units of the peaks full width at half maximum (FWHM). I did this fitting few peaks with the sum of two Airy peaks. Here is an example of the result

data_fit2.png

The average splitting is 1.8 times the FWHM. Knowing the PRC finesse, one can determine the length error:

dL = c / (4 * f_mod * Finesse) * (dPhi / FWHM)

Assuming a finesse of 60, I get a length error of 4 cm.

To get another estimate, we kicked the PRM in order to get some almost linear sweeps of the PRC length. Here is one of the best results:

data_kick.png

The distance between consecutive peaks is the free spectral range (FSR) of the PRC cavity. Again, I can measure the peak splitting in units of the FSR and determine the length error:

dL = c / (4 * f_mod) * (dPhi / FSR)

The result is again a length error of 4 cm.

Simulation

An error of 4 cm seems pretty big. Therefore I set up a quick simulation with MIST to check if this makes sense. Indeed, if I simulate a PRMI with the 40m parameters and move the PRC length from the optimal one, I get the following result for POP_110_I, which is consistent with the measurement.

pop110_vs_dL.png

 

 Therefore, we can quite confidently assume that the PRC is off by 4 cm with respect to the position that would make the 55 MHz sideband resonant without arms. Unfortunately, it is not possible with this technique to infere the direction of the error.

 

 

 

 

 

 

Attachment 3: pop110_vs_dL.png
pop110_vs_dL.png
  9493   Thu Dec 19 12:51:57 2013 JenneSummaryLSCEstimate of the sign of the PRC length error

My hunch is that the PRC is SHORT by a few cm, not long. 

In my Optickle simulation, the sidebands are not perfectly co-resonating in the PRMI when the arms are not locked.  See Fig 1, which is the fields in the PRMI using the design PRC length.  If I add 5cm to the PRC length, I get Fig 2, where the peaks are about the same separation, but the upper and lower sidebands have swapped sides of the 0 mark.  However, if I remove 5cm from the PRC length, I get Fig 3, where the peaks are much farther apart than in Fig 1.  This case looks more similar to the data that Gabriele plotted in his elog entry, where the peaks are separated by at least a linewidth.  This is not at all conclusive, but it's a guess for which direction we need to move.  Obviously doing an actual measurement will be better. 

My tummy feelings also agree with this simulation:  When we flipped PR3 (the only optic change in the PRC since Gabriele and I measured the 55MHz peak separation in April), since the HR side of the optic is now at the back, we had to push the whole suspension cage forward to get the beam aligned to the Yarm.  Conversely, however, transmitting through the glass substrate adds to the optical path length.  So, my tummy feelings may be wrong.

Figure 1, PRC at design length, PRMI sweep:

DesignLength.png

Figure 2, PRC 5cm longer than design length:

Plus5cm.png

Figure 3, PRC 5cm shorter than design length:

Minus5cm.png

 

  9495   Thu Dec 19 18:33:25 2013 GabrieleSummaryLSCEstimate of the sign of the PRC length error

Maybe I'm getting confused, but I still believe there is no way to decide the direction from yesterday's measurement.

Let's say for example that the arm sideband detuning from antiresonance is equivalent to a PRC length change of +1cm away from the position of ideal resonance of the sidebands without arms. Then we can get a measured separation of the sidebands, without arms, corresponding to 5cm both if the PRC is off by +4cm or by -6cm...

  10706   Wed Nov 12 22:22:11 2014 KojiSummaryIOOEstimation of the angular jitter imposed by the TTs

[Koji, Rana, Jenne]

One coil of the TT produce 36nrad/rtHz at DC.

- C1:IOO-TT2_UL_EXC was excited with 5 count_pk at 0.04Hz.

- LSC_TRY exhibited the symmetric reduction of the transmission from 0.95 to 0.90.

1 - (theta/theta0)^2 /2 = 0.90 / 0.95

=> theta / theta0 = 0.32

- 40m beam waist radius is 3.1mm. This means the divergence angle is 1.1e-4 rad.

=> 1.1e-4*0.32 = 3.6e-5 rad

=> 3.6e-5/5 = 7.2 urad/count (per coil)

- DAC noise 1/sqrt(12 fs), where fs is the sampling rate (fs = 16384)

=> 0.002 cnt/rtHz

- One coil causes 7.2u*0.002 = 14 nrad/rtHz (at DC)

- One suspension cause 29 nrad/rtHz (at DC)

Attachment 1: 03.png
03.png
  444   Thu Apr 24 22:06:47 2008 AndreySummaryComputersEthernet Cables and Hubs
Today in the morning (between 8.30AM and noon) Joe and I were working on understanding which ethernet cables connect "processors controlling the work of equipment in the interferometer room" and "Internet hub in the computer room".

Firstly, we took off several times the blue ethernet cables from the router located near ETMX in the morning. We were trying to understand which port in the hub is responsible for the interaction with that processor.

Secondly, we were working on reviving the connection with the computer controlling vacuum in the interferometer.

Later in the middle of the day (around 2PM) Joe continued some work with ethernet cables without me. We plan on continuing the cable work on Friday morning. A better and more detailed elog will appear then.
  7691   Thu Nov 8 22:04:43 2012 CharlesUpdateElectronicsEthernet Illuminator Control

Configured ethernet controlled power strips to have static IP addresses: 192.168.113.110, 192.168.113.111 and 192.168.113.112.

Wrote a python script to interact with the power strips that can turn individual sockets on or off via telnet.

This functionality will be implemented on the control room computer GUIs in short order.

  7698   Mon Nov 12 23:38:50 2012 CharlesUpdateElectronicsEthernet Illuminator Control

Quote:

Configured ethernet controlled power strips to have static IP addresses: 192.168.113.110, 192.168.113.111 and 192.168.113.112.

Wrote a python script to interact with the power strips that can turn individual sockets on or off via telnet.

This functionality will be implemented on the control room computer GUIs in short order.

 The ethernet power strips have been installed. 192.168.113.110 is on ETMX, 192.168.113.111 is on ETMY and 192.168.113.112 is on the vertex. I have also written an EPICS file "illuminator_control.adl" (currently stored in my named directory) that allows a user to turn individual sockets on and off at each of the three locations. Some short tests have indicated that everything is in working order.

Currently, no illuminators are hooked up to the power strips. However, the power control will most likely be ready for use tomorrow, granted I can find and use extension cords so that the illuminators might reach their respective power strips.

  7701   Tue Nov 13 00:27:50 2012 JenneUpdateElectronicsEthernet Illuminator Control

Quote:

 

 The ethernet power strips have been installed. 192.168.113.110 is on ETMX, 192.168.113.111 is on ETMY and 192.168.113.112 is on the vertex. I have also written an EPICS file "illuminator_control.adl" (currently stored in my named directory) that allows a user to turn individual sockets on and off at each of the three locations. Some short tests have indicated that everything is in working order.

Currently, no illuminators are hooked up to the power strips. However, the power control will most likely be ready for use tomorrow, granted I can find and use extension cords so that the illuminators might reach their respective power strips.

 I'm sure Charles meant to also say that he connected the ETM power strips to the ethernet switches in those racks.  For the vertex, the ethernet switch is in 1X2, but there isn't space in there, so the power switch was installed in 1Y2.  The vertex ethernet cable is along the overhead inside cable tray.

I'm not sure what we want to do about connecting the new power strips to the illuminators.  No illuminator is close enough that its built-in cable can reach the power strip, so we'll need extension cables or some such.  Charles is going to ask Steve about the plan tomorrow.

  14414   Wed Jan 23 18:11:56 2019 gautamUpdateElectronicsEthernet Power Strip IP conflict

For the last week, I noticed that I was unable to turn the EY chamber illuminator on using the remote python scripts. This was turning out to be really annoying, having to turn the light on/off manually. Today, I looked into the problem and found that there is a conflict in the IP addresses of the EY Ethernet Strip (which Chas assigned a static IP but did not include detailed procedures forno) and the vertex area laptop, paola. The failure of the python control of the power strip coincided exactly with when Chub and I turned on paola for working at the IY chamber - but how was I supposed to know these events are correlated? I tried shutting down paola , power cycling the Ethernet power strip, and restarting the bind9 services on chiara, but remote control of the ethernet power strip remains elusive. I suspect reconfiguring the static IP for the Ethernet switch will require some serial port enabled device...

  14418   Fri Jan 25 12:49:53 2019 gautamUpdateElectronicsEthernet Power Strip IP conflict resolved

To avoid the annoying excercise of having to manually toggle the illuminators, I solved the IP conflict. Made a wiki page for the ethernet power strips since the documentation was woeful (the way the power strips are mounted in the racks, you can't even see the manufacturer/model/make). All chamber illuminators can now be turned on/off by the MEDM scripts yes. Note that there is a web interface available too, which can be useful in case of some python socket issues. The main lesson is: avoid using the "reset" button on the power strips, it destroys the static IP config.


Unrelated to this work: The EY laptop, asia, won't boot up anymore, with a "Fan Error" message being the red flag. I've temporarily recommissioned the vacuum rack laptop, belladonna, to be the EY machine for this vent. Can we get 3 netbooks that actually work and don't need to be tethered to a power strip for the VEA?

  3852   Wed Nov 3 09:32:00 2010 ranaSummaryCDSEurocard board swapping

When swapping Eurocard boards, it is safest to first turn down the power supplies and then do the swapping.

Otherwise, it is sometimes the case that people plug in the board slowly and/or asymmetrically. This can cause the opamp to see one of the power supply rails without the other (e.g. +15 but not -15).

This can destroy some opamps. The true danger is that there may be damage to the board which you do not notice for several months, thereby leaving a timebomb for the next person.

Don't be an electronics terrorist!

  4903   Tue Jun 28 22:07:46 2011 JamieHowToSAFETYEurocrate extender card fried (ie. Jamie did a very bad thing)

IMPORTANT ELECTRONICS SAFETY LESSON TO FOLLOW

Yesterday, I fried the +15 V power supply rail on one of the Eurocrate extender cards while I was checking out the binary switching in the 1X5 rack.  I will describe what I did it in the hopes that everyone else will be less stupid than me.

I wanted to monitor the voltage across a resistor on the suspension OSEM whitening board.  Since I knew that both sides of the resistor would be at non-zero voltage (including possibly at the power-supply rail), I used a battery-operated scope with floating inputs, so that the scope would not try to pull the probe shield to ground.  That should be OK, although not recommended, as you'll see, because you must be very careful to make sure that the scopes inputs are indeed floating.

Let's call the original signal 'A'.  The trouble came when I then connected another signal (B), whose shield was connected to the ground on the whitening board, to the scope.  Apparently the grounds on the scope inputs are connected, or were in the configuration I was using.  When I connected the signal B, B's ground shorted A's shield to ground, which had been sitting at the +15V rail.  That short circuit then fried the +15V supply line on the extender card I was using (escaping magic smoke was detected).  Thankfully this only blew the extender card, and not the Eurocrate or the Eurocrate power supply or the whitening board or the scope etc, all of which would have been much worse.

The moral of the story is to be very careful when connecting power supply voltages to the shield or ground of a scope.  In short, don't do it.  I didn't ultimately need to, since I could have found other ways to measure the same signal.

 

  8167   Tue Feb 26 09:55:46 2013 SteveUpdateSAFETYEvan receives safety training

Evan got 40m specific safety training today.

  6505   Sat Apr 7 01:45:02 2012 Mike J.UpdateComputersEven Better Hysteresis Model and Plots

 The new hysteresis model is slightly based on the SHO equation, but with the force being out of phase with the position by an amount of hysteresis {x(t)=Amp*sin(freq*t), F(t)=Amp*sin(freq*t+Hyst)}. The new model can be found at /users/mjenson/matlab/hyst_v_3.mdl.  Pictures are: new hysteresis model, x(t) subsystem in new model[xh''(t) only lacks -1 multiplier and includes hysteresis variable], new plots.

 hyst_v_3.pnghyst_v_3-x(t).pnghyst_v3.png

  9674   Tue Feb 25 18:16:22 2014 JenneSummaryLSCEven more violin filters

A new violin mode at 1303 Hz was ringing up this afternoon.  Rana and I added a notch for this.

RXA: while the mode at 1303.6 Hz was ringing down, I used the narrowband DTT technique to measure the Q (after turning on the notch in SUS-PRM_LSC). So its another frequency in the PRM (not the BS).

The time that it takes for 2 -foldings is 652 s, which implies that Q = pi*f*tau = 1.3e6. This seems too high by a factor of ~10, so my guess is that there is still some feedback path happening. The previous bandstop filter was centered around 1285 Hz and seems also weird that the PRM would have 2 violin modes with such different frequencies. Is the mirror rotated around the optic axis such that the standoffs are not at the same height?

Attachment 1: PRMvio2.png
PRMvio2.png
  2189   Fri Nov 6 00:40:29 2009 AlbertoUpdateLSCEverything put back as it was

I disconnected the setup for the arm cavity TF measurement. I opened the scitation switch on the ISS medm screen. I reconnected the OMC ISS EXC cable to the breakout box on the floor.

The photodiode on the Y end is stilll connected.

Also the RFAm (whish is not disbaled anymore) still has a 50% beam splitter before it.

I'm also running the Align Full IFO script.

  2217   Mon Nov 9 15:11:02 2009 AlbertoUpdateLSCEverything put back as it was

Quote:

I disconnected the setup for the arm cavity TF measurement. I opened the scitation switch on the ISS medm screen. I reconnected the OMC ISS EXC cable to the breakout box on the floor.

The photodiode on the Y end is stilll connected.

Also the RFAm (whish is not disbaled anymore) still has a 50% beam splitter before it.

I'm also running the Align Full IFO script.

 

I removed the beam splitter and the PDA 255.

the beam path to the RFAM photodiode is clear again.

  4187   Sat Jan 22 01:56:04 2011 SureshUpdateGreen LockingExamining the stability of VCO PLL at low frequencies

[Kiwamu, Suresh, Rana]

Our goal:

        We wished to determine the performance of the VCO PLL at low frequencies,. 

The procedure we followed:

        The scheme is to use the Marconi (locked to Rb Clock) as an 80MHz reference and lock to it using the PLL. 

        We set up the VCO PLL as in the diagram shown in the attachment and obtained the spectra shown below.

Results:

          We need to figure out the PLL servo gain profile in order to build the Inv PLL filter....

 

   

 

 

VCO_PLL_stability.png

 

 

  4188   Sat Jan 22 02:03:55 2011 KojiUpdateGreen LockingExamining the stability of VCO PLL at low frequencies

Damn. If this figure is true, we were looking at wrong signal. We should look at the feedback signal to the VCO.

  3090   Sat Jun 19 17:31:48 2010 ranaDAQCDSExcess Noise in C1:IOO-MC_DRUM1 fixed by reboot

I was getting an excess noise in the C1:IOO-MC_DRUM1 channel - it was a flat spectrum of 10 cts/rHz (corresponding to 600 uV/rHz).

I tried a few things, but eventually had to power cycle the crate with c1iovme in order to recover the standard ADC noise level of 3x10^-3 cts/rHz with a 1/sqrt(f) knee at 10 Hz.

I checked the gain of the channel by injecting a 2 Vpp sine wave at 137.035 Hz. 2Vpp as measured on a scope gives 31919 cts instead of the expected 32768, giving a 2.5% error from what we would have naively calculated.

Even so, the noise in this channel is very surprisingly good: 0.003 / (31919 / 2) = 187 nV /rHz.  The best noise I have previously seen from an ICS-110B channel is 800 nV/rHz. What's going on here?

  6007   Fri Nov 25 18:45:31 2011 Den, RanaSummarySUSExcess Noise in Digital Filtering

We are now trying to understand why the coherence between SUS-X_SUSPOS_IN1 and SUS-X_SUSPOS_OUT is lost below 1 Hz for X = MC1, MC2, MC3, BS, ITMX, ITMY, ETMX, ETMY, SRM. It is OKEY only for PRM but the different filteres are used there. For PRM - 30:0.0 and Bounce Roll, for all others - 30:0.0 and Cheby. The transfer functions between these two signals plotted in foton and fft tools are also not the same.

If we switch off all the filters between these 2 signals, than the coherence is one. If one of the filters is switched on, everything is also fine. But if there are several present, than they filter the signal in unexpected way.

Moreover it seems that the coherence is dependent on the input signal. The coherence is better with local dumping than without.

Attachment 1: FiltNoise.png
FiltNoise.png
  6008   Fri Nov 25 19:45:36 2011 Mirco, DenSummarySUSExcess Noise in Digital Filtering

Quote:

We are now trying to understand why the coherence between SUS-X_SUSPOS_IN1 and SUS-X_SUSPOS_OUT is lost below 1 Hz for X = MC1, MC2, MC3, BS, ITMX, ITMY, ETMX, ETMY, SRM. It is OKEY only for PRM but the different filteres are used there. For PRM - 30:0.0 and Bounce Roll, for all others - 30:0.0 and Cheby. The transfer functions between these two signals plotted in foton and fft tools are also not the same.

If we switch off all the filters between these 2 signals, than the coherence is one. If one of the filters is switched on, everything is also fine. But if there are several present, than they filter the signal in unexpected way.

Moreover it seems that the coherence is dependent on the input signal. The coherence is better with local dumping than without.

 We have done the following on the c1sus and c1lsc computers : provided excitation, let the signal pass through filters 30:0.0 and Cheby and plotted the coherence between in and out signals.

c1sus computer - coherence is corrupted

c1lsc computer - coherence is not corrupted

Attachment 1: sus_coh-crop.pdf
sus_coh-crop.pdf
Attachment 2: lsc_coh-crop.pdf
lsc_coh-crop.pdf
  15641   Fri Oct 23 16:41:06 2020 KojiUpdateIOOExcess laser freq noise investigation

[Koji, Rana]

We wanted to track down the excess noise seen in MC_F and other places (see the previous report by Gautam)


Setup1: The IMC was locked and MC_F signal between 500 and 1500Hz was observed. The DTT template was saved as /users/Templates/MC/MCF_noise_201023.xml

- Suspected mech resonance/jitter coupled with clipping or any other imperfections. Poked the various optics and optomechanics on the table. Basically no change. If we tap the laser chassis and the optics close to the laser source, we occasionally unlocked the IMC

- When we touched (lifted) the Innolight controller box from the shelf, for the first time we saw a significant change in the shape of the noise spectrum. The peak around the 700Hz shited towards lower frequency by a few %. Other peaks have no obvious change in the shapes and the heights.

- While observing the MC_F signal on the laptop, we went to the back of the laser controller. Placing a hand close to the fan clearly changes the peak frequency lower. By temporarily disconnecting the fan from the power supply for a short moment, the 700Hz peak could be eliminated. We also tried to see the noise level with the slow thermal servo and diagnosis DB cable disconnected, but we didn't see any significant change of the noise level.


Setup 2: Using the ALS phase tracker, we can observe the relative freq noise of the PSL laser and the ETMY AUX laser without any servo involved. This way we can freely disconnect any cables from the lasers. The measurement template for DTT was saved as /users/Templates/ALS/Y_ALS_FINE_PHASE_OUT_102320.xml

- Noise spectrum before disconnecting the cable (REF0, RMS REF1)

- The Fast PZT input to the PSL was disconnected => This made all the peaks (including the 700Hz) disappeared (REF2, RMS REF3)

- The Fast PZT input was restored as before, then the chain was disconnected at the input of the HV PZT driver (Thorlabs) => Again, this made the peaks disappeared (REF4, RMS REF5)

- The chain was disconnected at the input of the TTFSS box => Again, this made the peaks disappeared (REF6, RMS REF7)

- Disconnected the demod input and the AO cables from the IMC servo board => This made the peaks came back (REF8)

- Disconnected all the input/peripheral cables from the IMC servo board except for the connection to the TTFSS box => Still the excess noise was observed  (REF9)

- In addition to the above, the cable to the FSS box was disconnected but the ground was still touching the MC servo board => This made the peaks disappeared (REF10)

The conclusion is that the noise is injected from the main circuit of the IMC servo board.


Next time we will check if the backplane connection is doing something wrong. Also, we'll test if the presence of the RF signals does something bad to the IMC board via EMI and RFI.

We have reverted the connection and tested if we lock the IMC and Y arm. ==> We saw at least they were locked for a short period. The things are still stabilizing, but left them turned on so they keep trying to lock automatically for the night.

Attachment 1: plot.pdf
plot.pdf
  15643   Mon Oct 26 13:35:58 2020 KojiUpdateIOOExcess laser freq noise investigation

In fact, the problem was the grounding issue (presumably on the IOO racks).
A temporary differential receiver at the TTFSS side was built using an SR560 and a few ponoma cables. This removed the structures ~850Hz.


The MC Servo Output was disconnected from the TTFSS box and monitored with SR785. The 850Hz structure was kept visible no matter what cables, including all the acromag DB cables, were removed. This made me suspicious about the measurement setup. The SR785 was connected to an AC power strip under the SP table and this was too far from the IOO rack.

The SR785 was connected to the AC power strip on 1X2, and now the difference becomes clear. No matter if the acromag cables are connected or not, the connection (particularly ground connection) between the MC servo module and the TTFSS box causes the MC servo output contaminated. (Comparison between Blue and Orange of Attachment #1). During the measurement, the EPICS switch for the fast path was disengaged (=no signal) and the VCO gain (...so called. It's just the MC Servo Gain) was set to be 0dB.

To test if the differential receiving of the MC Servo Output at the PSL helps to reduce this noise, I've built a simple (hacky) differential receiver using an SR560. (Attachment #2)
This kept the noise level same as the disconnected case (Comparison between Green and Orange of Attachment #1, I don't think the difference between them is not significant), while the IMC is locked as before.
Note that we can see that the 36kHz line was significantly reduced. Did we remove this annoying noise?

After talking with Gautam, we decided to leave this configuration while the SE-Diff cable was replaced with a more robust one. (See Attachment #3)


The PSL laser frequency performance was evakluated in the following two ways as we did last week:
1) Use the beat frequency of the free running PSL and the Y-end laser (Attachment #4). The PSL shutter was closed and thus the IMC was not locked.
2) Use the IMC MCF while the IMC was locked. (Attachment #5)

For both cases, the improvement was confirmed.


I also tried to check the reported issue by Gautam on this elog. He used 1Hz BW, but I cheated with 16Hz BW and 10x12.8kHz span PSDs. (Attachment #6)

For the measurement, IN1 GAIN of the IMC Servo was set to be 0dB and the OUT2 was switched to monitor the IN1 noise, while IN1 was terminated by a 50Ohm.

As I mentioned above, the AC power of SR785 was taken from a 1X2 power strip. Is this the reason for the power line forest look less severe compared to the previous case???
Anyway, I tried to use the same differential receiving technique (but with gain of x100) to see if this helps. The differential receiver helped to reduce the structure above 50kHz. The floor noise level was observed to be higher. I didn't pursue this any further, but the forest of the power line looked like a part of the measurement noise. This is indicative that the grounding condition on 1X2 is really not great and we need to review the configuration of the acromag grounding.

Attachment 1: MC_Servo_Output.pdf
MC_Servo_Output.pdf
Attachment 2: 20201026135735_IMG_0175.jpg
20201026135735_IMG_0175.jpg
Attachment 3: 20201026153435_IMG_0176.jpg
20201026153435_IMG_0176.jpg
Attachment 4: Screen_Shot_2020-10-26_at_1.15.54_PM.png
Screen_Shot_2020-10-26_at_1.15.54_PM.png
Attachment 5: Screen_Shot_2020-10-26_at_1.35.19_PM.png
Screen_Shot_2020-10-26_at_1.35.19_PM.png
Attachment 6: MC_Servo_Error_Mon.pdf
MC_Servo_Error_Mon.pdf
  15644   Mon Oct 26 17:26:26 2020 gautamUpdateIOOExcess laser freq noise investigation

Apart from the questionable wiring on the Acromags, one other important difference is in the way the connections were made between the old VME crates to the Eurocrate backplanes, and how we do it now. The thick cables had their sheilds connected to the eurocrate ground (or at least, there was a dedicated ground lug on those cables which we screwed on to the ground terminals on the Eurocrate backplanes). However, in our current configuration, we interface the Acromag ADCs and DACs to the backplane via these adaptor boards. The shields of the DSUB cables are presumably NOT connected to the Eurocrate grounds. This should also be investigated as one potential cause of the grounding issue - while on some of the Eurocrate modules, the P1/P2 connectors may have either the "A" or "C" row of connectors shorted to ground, some may not, and the TTFSS may suffer from such an issue?

Note that we have this problem in all of the slow machines that were upgraded to Acromag (if this turns out to be the issue). 

Quote:

In fact, the problem was the grounding issue (presumably on the IOO racks).

  15259   Fri Mar 6 01:19:19 2020 gautamUpdateIOOExcess laser frequency noise

Summary:

Sometime between 1PM and 6PM on Tuesday, excess laser frequency noise shows up in MCF at around 800 Hz, as shown in Attachment #1. Sigh.

Details:

While I show the MCF spectrum here, I confirmed that this noise is not injected by the IMC loop (with the PSL shutter closed, and the IMC servo board disconnected from the feedback path to the NPRO, the PMC error and control points still show the elevated noise, see Attachment #2). I don't think the problem is from the PMC loop - see Attachment #3 which is the ALS beat out-of-loop noise with the PMC unlocked (the PSL beam doesn't see the cavity before it gets to the ALS setup, and we only actuate on the cavity length for that loop, so this wasn't even really necessary).

Was there some work on the PSL table on Tuesday afternoon that can explain this

Attachment 1: MCF.pdf
MCF.pdf
Attachment 2: ExcessFreqNoise.pdf
ExcessFreqNoise.pdf
Attachment 3: ALSnoise.pdf
ALSnoise.pdf
  15260   Fri Mar 6 16:33:11 2020 gautamUpdateIOOExcess laser frequency noise

I did some preliminary debugging of this, and have localized the problem to the output path (after MC slow) on the IMC Servo card. Basically, I monitored the spectrum of the ALS beat frequency fluctuations under a few different conditions: 

  • With the BNC to the NPRO PZT disconnected, there is no noise. So the laser and the FSS phase correction EOM (which the ALS beat pickoff sees) are not responsible.
  • With the input to the Koji summing box disconnected, still no excess - so the summing box + Thorlabs HV driver are not responsible.
  • With the TTFSS output connected to the summing box, but with the input switch to the TTFSS box disabled (isolating the on-PSL table parts of the FSS system), still no excess.
  • With the input to the TTFSS enabled, and the BNC output of the IMC Servo card disconnected at 1X2, still no excess.
  • Finally, when I connect the BNC cable, the excess starts to show up.

Toggling C1:IOO-MC_FASTSW, which supposedly isolates the post-MC slow (a.k.a. MCL) part of the servo, I see no difference. I am also reasonably confident this switch itself works, because I can break the IMC lock by toggling it. So pending a more detailed investigation, I am forced to conclude that the problem originates in the part of the IMC servo board after the MCL pickoff. Some cabling was removed at 1X2 on Tuesday between the times when there was no excess and when it showed up, but it's hard to imagine how this could have created this particular problem.

  16329   Tue Sep 14 17:19:38 2021 PacoSummaryPEMExcess seismic noise in 0.1 - 0.3 Hz band

For the past couple of days the 0.1 to 0.3 Hz RMS seismic noise along BS-X has increased. Attachment 1 shows the hour trend in the last ~ 10 days. We'll keep monitoring it, but one thing to note is how uncorrelated it seems to be from other frequency bands. The vertical axis in the plot is in um / s

Attachment 1: SEIS_2021-09-14_17-33-12.png
SEIS_2021-09-14_17-33-12.png
  16331   Tue Sep 14 19:12:03 2021 KojiSummaryPEMExcess seismic noise in 0.1 - 0.3 Hz band

Looks like this increase is correlated for BS/EX/EY. So it is likely to be real.

Comparison between 9/15 (UTC) (Attachment 1) and 9/10 (UTC) (Attachment 2)

Attachment 1: C1-ALL_393F21_SPECTRUM-1315699218-86400.png
C1-ALL_393F21_SPECTRUM-1315699218-86400.png
Attachment 2: C1-ALL_393F21_SPECTRUM-1315267218-86400.png
C1-ALL_393F21_SPECTRUM-1315267218-86400.png
  5623   Wed Oct 5 18:31:02 2011 KatrinUpdateGreen LockingExchanged mirror on YARM table

On the Green YARM end table the second mirror behind the laser has been exchanged.

Reason: The light is impinging on the mirror under an angle of  about 10 degrees, but the old mirror was coated for angle of incidence (aoi) of 45°.

Thus it was more like a beam splitter. The new mirror is a 1" Goock & Housego mirror which has a better performance for an aoi of 10 degree.

Realignment through Faraday Isolator and SHG cristall as well as 532nm isolator is almost finished.

  8900   Tue Jul 23 04:07:48 2013 gautamUpdateCDSExcitation points set up on c1scx

 

 In light of recent events and the decision to test the piezo tip-tilts for green beam steering on the X-end table, I have set up 8 excitation points to channels 8 through 15 of the DAC on c1scx (as was done earlier for the DAC at 1Y4 with Jenne's help) in order to verify that the pin-outs of the DAC interface board. I have not yet compiled the model or restarted the computer, and will do these tomorrow, after which I will do the test. The channels are named YYY_CHAN9 etc. 

 

 

 

 

  8909   Tue Jul 23 16:47:01 2013 gautamUpdateCDSExcitation points set up on c1scx

 I just compiled and installed the model with the excitation points on c1scx and then restarted framebuilder. The channels I set up are now showing up in the awggui dropdown menu. I will do the tests on the DAC channels shortly.

Just to keep things on record, these are the steps I followed:

  • opened the model c1scx (path: /opt/rtcds/userapps/release/sus/c1/models) with MATLAB
  • Added 8 excitation points and saved the model. A copy has been saved as c1scx.mdl.r2010b because of the recent upgrade to r2013a. 
  • ssh to c1iscex (computer running the model c1scx). 
  • Entered the following sequence of commands in terminal: rtcds make c1scx ,  rtcds install c1scx , rtcds start c1scx 
  • ssh to framebuilder, and restarted the framebuilder by entering telnet fb 8088   and then   shutdown.
  1708   Sat Jun 27 03:16:16 2009 ClaraUpdatePEMExciting microphone things!

So, I'm double-posting, but I figured the last post was long enough as it was, and this is about something different. After double and triple checking the XLR cables, I hooked up the microphone setup (mic---preamp---output) to the oscilloscope to figure out what kind of voltage would register with loud noises. So, I clapped and shouted and forgot to warn the other people in the lab what I was doing (sorry guys) and discovered that, even on the lowest gain setting, my loud noises were generation 2-3 times as much voltage as the ADC can handle (2V). And, since our XLR cables are so freaking long, we probably want to go for a higher gain, which puts us at something like 20 times too much voltage. I doubt this is really necessary, but it's late (early) and I got camera-happy, so I'm going to share anyway:

mic_voltage_out.png

So, to deal with this issue, I made some nifty voltage dividers. Hopefully they are small enough to fit side-by-side in the ports without needing extra cableage. Anyway, they should prevent the voltage from getting larger than 2V at the output even if the mic setup is producing 50V. Seeing as my screaming as loud as I could about 2mm away from the mic at full gain could only produce 45V, I think this should be pretty safe. I put the ADC in parallel with a 25.5 kOhm resistor, which should have a noise like 10^-8 V/rHz. This is a lot smaller than 1 uV/rHz (the noise in the ADC, if I understood Rana's explanation correctly), so the voltage dividers should pose a noise issue. Now for pictures.

voltage_dividers.png

I opened one so you can see its innards.

voltage_divider_sketch.png

In case the diagram on the box was too small to decipher...

And finally, I came up with a name scheme for the mics and pre-amps. We now have two Bluebird (bacteriophage) mics named Bonnie and Butch Cassidy. Their preamps are, naturally, Clyde and The Sundance Kid. Sadly, no photos. I know it's disappointing. Also, before anyone gives me crap for putting the labels on the mics upside-down, they are meant to be hung or mounted from high things, and the location (and stiffness) of the cable prevents us from simply standing them up. So they will more than likely be in some kind of upsidedownish position.

  15763   Thu Jan 14 11:46:20 2021 gautamUpdateCDSExpansion chassis from LHO

I picked the boxes up this morning. The inventory per Fil's email looks accurate. Some comments:

  1. They shipped the chassis and mounting parts (we should still get rails to mount these on, they're pretty heavy to just be supported on 4 rack nuts on the front). idk if we still need the two empty chassis that were requested from Rich.
  2. Regarding the fibers - one of the fibers is pre-2012. These are known to fail (according to Rolf). One of the two that LHO shipped is from 2012 (judging by S/N, I can't find an online lookup for the serial number), the other is 2011. IIRC, Rolf offered us some fibers so we may want to take him up on that. We may also be able to use copper cables if the distances b/w server and expansion chassis are short.
  3. The units are fitted with a +24V DC input power connector and not the AC power supplies that we have on all the rest of the chassis. This is probably just gonna be a matter of convenience, whether we want to stick to this scheme or revert to the AC input adaptor we have on all the other units. idk what the current draw will be from the Sorensen - I tested that the boards get power, and with noi ADCs/DACs/BIOs, the chassis draws ~1A (read off from DCPS display, not measured with a DMM). ~Half of this is for the cooling fans It seems like KT @ LLO has offered to ship AC power supplies so maybe we want to take them up on that offer.
  4. Without the host side OSSI PCIe card, timing interface board, and supermicro servers that actually have enough PCIe slots, we still can't actually run any meaningful test. I ran just a basic diagnostic that the chassis can be powered on, and the indicator LEDs and cooling fans run.
  5. Some photos of the contents are here. The units are stored along the east arm pending installation.

    >     Koji,
    >
    >     Barebones on this order.
    >
    >        1. Main PCIe board
    >        2. Backplane (Interface board)
    >        3. Power Board
    >        4. Fiber (One Stop) Interface Card, chassis side only
    >        5. Two One Stop Fibers
    >        6. No Timing Interface
    >        7. No Binary Cards.
    >        8. No ADC or DAC cards
    >
    >     Fil Clara
    >       
  15764   Thu Jan 14 12:19:43 2021 JonUpdateCDSExpansion chassis from LHO

That's fine, we didn't actually request those. We bought and already have in hand new PCIe x4 cables for the chassis-host connection. They're 3 m copper cables, which was based on the assumption of the time that host and chassis would be installed in the same rack.

Quote:
  1. Regarding the fibers - one of the fibers is pre-2012. These are known to fail (according to Rolf). One of the two that LHO shipped is from 2012 (judging by S/N, I can't find an online lookup for the serial number), the other is 2011. IIRC, Rolf offered us some fibers so we may want to take him up on that. We may also be able to use copper cables if the distances b/w server and expansion chassis are short.
  15766   Fri Jan 15 15:06:42 2021 JonUpdateCDSExpansion chassis from LHO

Koji asked me assemble a detailed breakdown of the parts received from LHO, which I do based on the high-res photos that Gautam posted of the shipment.

Parts in hand:

Qty Part Note(s)
2 Chassis body  
2 Power board and cooling fans As noted in 15763, these have the standard LIGO +24V input connector which we may want to change
2 IO interface backplane  
2 PCIe backplane  
2 Chassis-side OSS PCIe x4 card  
2 CX4 fiber cables These were not requested and are not needed

Parts still needed:

Qty Part Note(s)
2 Host-side OSS PCIe x4 card These were requested but missing from the LHO shipment 
2 Timing slave These were not originally requested, but we have recently learned they will be replaced at LHO soon

Issue with PCIe slots in new FEs

Also, I looked into the mix-up regarding the number of PCIe slots in the new Supermicro servers. The motherboard actually has six PCIe slots and is on the CDS list of boards known to be compatible. The mistake (mine) was in selecting a low-profile (1U) chassis that only exposes one of these slots. But at least it's not a fundamental limitation.

One option is to install an external PCIe expansion chassis that would be rack-mounted right above the FE. It is automatically configured by the system BIOS, so doesn't require any special drivers. It also supports hot-swapping of PCIe cards. There are also cheap ribbon-cable riser cards that would allow more cards to be connected for testing, although this is not as great for permanent mounting.

It may still be better to use the machines offered by Keith Thorne from LLO, as they're more powerful anyway. But if there is going to be an extended delay before those can be received, we should be able to use the machines we already have in conjunction with one of these PCIe expansion options.

  15767   Fri Jan 15 16:54:57 2021 gautamUpdateCDSExpansion chassis from LHO

Can you please provide a link to this "list of boards"? The only document I can find is T1800302. In that, under "Basic Requirements" (before considering specific motherboards), it is specified that the processor should be clocked @ >3GHz. The 3 new supermicros we have are clocked at 1.7 GHz. X10SRi-F boards are used according to that doc, but the processor is clocked at 3.6 or 3.2 GHz.

Please also confirm that there are no conflicts w.r.t. the generation of PCIe slots, and the interfaces (Dolphin, OSSI) we are planning to use - the new machines we have are "PCIe 2.0" (though i have no idea if this is the same as Gen 2). 

Quote:

The motherboard actually has six PCIe slots and is on the CDS list of boards known to be compatible.

As for the CX4 cable - I still think it's good to have these on hand. Not good to be in a situation later where FE and expansion chassis have to be in different racks, and the copper cable can't be used.

Attachment 1: Screenshot_2021-01-15_17-00-06.png
Screenshot_2021-01-15_17-00-06.png
  15770   Tue Jan 19 13:19:24 2021 JonUpdateCDSExpansion chassis from LHO

Indeed T1800302 is the document I was alluding to, but I completely missed the statement about >3 GHz speed. There is an option for 3.4 GHz processors on the X10SRi-F board, but back in 2019 I chose against it because it would double the cost of the systems. At the time I thought I had saved us $5k. Hopefully we can get the LLO machines in the near term---but if not, I wonder if it's worth testing one of these to see whether the performance is tolerable.

Can you please provide a link to this "list of boards"? The only document I can find is T1800302....

I confirm that PCIe 2.0 motherboards are backwards compatible with PCIe 1.x cards, so there's no hardware issue. My main concern is whether the obsolete Dolphin drivers (requiring linux kernel <=3.x) will work on a new system, albeit one running Debian 8. The OSS PCIe card is automatically configured by the BIOS, so no external drivers are required for that one.

Please also confirm that there are no conflicts w.r.t. the generation of PCIe slots, and the interfaces (Dolphin, OSSI) we are planning to use - the new machines we have are "PCIe 2.0" (though i have no idea if this is the same as Gen 2). 

  7905   Wed Jan 16 18:08:06 2013 JenneUpdateLockingExpected PRC gains

I was calculating the power recycling gains we expect for different versions of the PRC, and I am a little concerned that we aren't going to have much gain with the new LaserOptik mirrors.

I'm using

                       t_PRM^2

G =  -------------------------------------------

       (1 - r_PRM * r_PR2 * r_PR3 * r_end)^2

 

from eqn 11.20 in Siegman.

r_end is either the ITM (for a symmetric Michelson) or the flat mirror that we'll put in (for the PR-flat test case).

r = sqrt( R ) = sqrt( 1 - T ) for mirrors whose power transmission is the quoted value.

 

Some values: 

t_PRM^2 = T_PRM = 0.055   --------->   r_PRM = sqrt( 1 - 0.055 )

T_G&H = 20e-6   ---->   r_G&H = sqrt( 1 - 20e-6 )

T_LaserOptic = 0.015 (see elog 7624 where Raji measured this...1.5% was the best that she measured for P polarization.  Elog 7644 has more data, with 3.1% for 40deg AoI) -------> r_LasOpt = sqrt( 1 - 0.015 ) or sqrt( 1 - 0.031)

T_ITM = 0.014 -----------> r_ITM = sqrt( 1 - 0.014 )

 

Some calculations with 1.5% LaserOptik transmission:

G_PRC_2G&H = 45

G_PRC_G&H_LasOpt = 31

G_PRM_flatG&H = 51

With the 3% LaserOptik transmission:

G_PRC_G&H_LasOpt = 22

G_PRM_flatG&H = 30

More ideal case of just PRM, flat mirror (either ITM or G&H), ignoring the folding mirrors:

G_PRM_ITM = 45

G_PRM_flatG&H = 70

 

Punchline:

If the LaserOptik mirror has 1.5% transmission at ~45 degrees, the regular PRC expected gain goes down to 31, from 45 with both folding mirrors as G&Hs.

  7909   Wed Jan 16 20:27:16 2013 ranaUpdateLockingExpected PRC gains

Why would we use such a bad optic in our recycling cavity? Is 1.5% the spec for these mirrors? Is this the requirement that Kiwamu calculated somehow? Did anyone confirm this measurement?

I can't believe that we'll have low noise performance in a RC where we dump so much power.

  7910   Thu Jan 17 00:17:31 2013 JenneUpdateLockingExpected PRC gains

Quote:

Why would we use such a bad optic in our recycling cavity? Is 1.5% the spec for these mirrors? Is this the requirement that Kiwamu calculated somehow? Did anyone confirm this measurement?

I can't believe that we'll have low noise performance in a RC where we dump so much power.

 Yeah, Koji mentioned in response to Raji's measurements several months ago that the LaserOptic mirros were pretty far out of spec. We should probably redo the measurement to confirm.

  3224   Wed Jul 14 19:36:17 2010 GopalUpdateOptic StacksExperimental Confirmation of COMSOL Analysis

I experimentally determined the spring constant of a single Vitol spring in order to obtain a rough estimate for the natural frequency of single-stack oscillation.

The procedure basically involved stacking metal bars of known mass onto the Vitol and using a caliper to measure deviations from the equilibrium length.

The plot below shows that, for small compressions, the response is linear to an R-squared of 0.98.

Untitled.png

The experimental spring constant came out to be about 270 lb/ft, or 3900 N/m.

Previous documents have listed that the top stack takes on a load of approximately 43 kg. per individual spring. A bit of calculation yields an experimental resonant frequency of 9.5 Hz.

Compared with the theoretical COMSOL first harmonic of about 7.5 Hz, there is a reasonable amount of error. Of course, I used this calculation as a simple ballpark estimate: errors from misplacement onto the Viton were minimized through use of a level, but were still inevitable on the mm scale. Since the two methods yield answers with the same order of magnitude, we are ready to move forward and build the remaining layers of the stack.

ELOG V3.1.3-