40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 215 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  5272   Fri Aug 19 23:41:20 2011 JennyUpdatePSLRelocking NPRO to reference cavity.

Quote:

I am trying again to measure a temperature step response on the reference cavity on the PSL table.

I have been working to relock the NPRO to the cavity. I unblocked the laser beam, reassembled the setup described in my previous elog entry: 5202. I then did the following:

1) Monitored error signal (from LB1005 PDH servo), transmitted signal, and control signal sent to drive PZT on oscilloscope.

2) With loop open, swept through 0,0-mode resonance, saw a peak in the transmission, saw an accompanying error signal similar to the signal shown in 5202.

3) Tried to lock. Swept the gain on the LB1005 and could not find a gain that would make it lock. Tried changing the PI-corner freq. from 10 kHz to 30 kHz and back and still could not lock.

4) Noticed that the open loop error signal displayed on the scope was DC-offset from zero. Changed the offset to zero the error signal.

5) Tried to lock again and succeeded.

6) Noticed that upon closing the loop, the error signal became offset from zero again. Turning on the integrator on the LB1005 increased DC-offset.

7) Reduced the gain on the SR560 being used as a low pass filter from 5 to 1. Readjusted the open loop error signal offset on the LB1005.

8) Closed the loop and locked. Closing the loop then caused a much smaller DC change in the signal than I had seen with the larger gain (now around 3mV). RMS fluctuations in error signal are now 1 mV (well within the linear region of the error signal).

9) Noticed transmission has a strange distorted harmonic oscillation in it a 1MHz. (Modulation freq is 230kHz, so it's not that). Checked reflected signal and also saw a strange oscillation--in a sawtooth-like pattern.

 

I intend to

1) Post oscilloscope traces here showing transmitted and reflected signal when locked.

2) Look upstream to see if the sawtooth-like oscillation is in the laser beam before it enters the cavity:

  • Sweep the temperature of the laser so that the beam is no longer resonating in the cavity.
  • Compare the reflected signal off the cavity to the signal detected before being directed into the cavity (using the PDA255 that I used for measuring the AM response of the PZT) both with and and without the frequency modulation.

3) At some point, try to close the slow digital loop, perhaps readjusting the gain.

4) Try to measure a temperature step response.

I decided to go forward and try to close the digital loop in spite of the unexplained oscillations in the transmission.

1) Plugged the 20dB attenuator into the slow port on the laser drive. This pushed the laser out of lock and, for some reason, made the laser temperature stop responding to sweeping the set point manually with the knob.

2) Plugged the output from the digital system into the slow port (with the attenuator still in place).

3) Displayed the beam seen by the camera on a monitor in the control room

4) Stepped the laser temperature using MEDM until finding the 0,1 mode. Locked to that mode.

5) Closed the digital loop (input to slow laser drive attenuated 20dB attenuator). Gain 0.010

6) Loop appeared stable for 30 minutes, then temperature began shooting off. I opened the loop, cleared history, reduced the gain to 0.008, and started it again. Loop appears stable after 15 minutes of watching. I'm going to leave it for a few hours, then come back to check on it and, if it's stable, step the can temperature.

  5468   Mon Sep 19 20:56:36 2011 PaulSummarySUSRemaining SRM and ITMY OSEMs calibrations

 

I've now taken data for the pitch and yaw calibrations for the OSEMs of SRM and ITMY. Until such time as I know what the calibrated oplev noise spectra are like, I'm leaving the servo gains at zero.

I estimate the length of the lever arm from SRM to measurement position to be 3.06m, and the length of the lever arm from the ITMY to the measurement position to be 3.13m.

From the fits shown on the attached plots, this gives the following calibration factors for the SRM and ITMY OSEMs pitch and yaw counts (i.e. counts from channels such as SUS-ITMY_ULSEN_SW2 multiplied by a matrix of 1s and -1s) to pitch and yaw angle:

 

SRM PITCH: 1 OSEMs pitch count = 11.74 microradians

SRM YAW: 1 OSEMs yaw count = 12.73 microradians

 

ITMY PITCH: 1 OSEMs pitch count = 13.18 microradians

ITMY YAW: 1 OSEMs yaw count = 13.52 microradians

 

Next step is to do some DC offsets with the oplev paths back in place to get the final calibration between OSEMs counts and oplev counts, thus finally getting a conversion factor from oplev counts to radians.

I noticed while taking these measurements that the DC offsets I put on ITMY caused around 5 times larger change in angle than those on the SRM. The different path length is not enough to account for this, so I propose that the actuation is working differently for the two. I guess this should be taken into account when designing the output matrices (unless the control is passed through a different output matrix than the DC offsets?). I'll quantify the difference shortly, and write a conversion factor between output alignment count (e.g. SUS-ITMY_PIT_COMM) and angle.

 

 

Attachment 1: SRM_PITCH_calib_curve.png
SRM_PITCH_calib_curve.png
Attachment 2: SRM_YAW_calib_curve.png
SRM_YAW_calib_curve.png
Attachment 3: ITMY_PITCH_calib_curve.png
ITMY_PITCH_calib_curve.png
Attachment 4: ITMY_YAW_calib_curve.png
ITMY_YAW_calib_curve.png
  16519   Fri Dec 17 12:32:35 2021 KojiUpdateSUSRemaining task for 2021

Anything else? Feel free to edit this entry.

- SUS: AS1 hanging

- SUS: PR3/SR2/LO2 3/4" thick optic hanging

v Electronics chain check (From DAC to the end of the in-air cable / From the end of the in-air cable to the ADC)
[ELOG 16522]

- Long cable installation (4x 70ft)

- In-air cable connection to the flange

- In-vac wiring (connecting LO1 OSEMs)

- LO1 OSEM insertion/alignment

- LO1 Damping test

 

  16522   Fri Dec 17 19:19:42 2021 KojiUpdateSUSRemaining task for 2021

I had the fear that any mistake in the electronics chain could have been the show stopper.

So I quickly checked the signal assignments for the ADC and DAC chains.

I had initial confusion (see below), but it was confirmed that the electronics chains (at least for LO1) are correct.

Note: One 70ft cable is left around the 1Y0 rack

 


There are a few points to be fixed:

- It looks like the ADC/DAC card # assignment has been messed up.

CDS ADC0 -> Cable label ADC1 -> AA A1 -> ...
CDS ADC1 -> Cable label ADC0 -> AA A0 -> ...
CDS DAC0 -> Cable label DAC2 -> AI D2 -> ...
CDS DAC1 -> Cable label DAC0 -> AI D0 -> ...
CDS DAC2 -> Cable label DAC1 -> AI D1 -> ...
(What is going on here... please confirm and correct as they become straight forward)

Once this puzzle was solved I could confirm reasonable connections from the end of the 70 cables to the ADC/DAC.

- We also want to change the ADC card assignment. The face OSEM readings must be assigned to ADC1 and the side OSEM readings to ADC0.
  My system wiring diagram needs to be fixed accordingly too.
  This is because the last channel of the first ADC (ADC0) is not available for us and is used for DuoTone.

Attachment 1: PXL_20211218_030145356.MP.jpg
PXL_20211218_030145356.MP.jpg
  16525   Sun Dec 19 07:52:51 2021 AnchalUpdateSUSRemaining task for 2021

The I/O chassis reassigns the ADC and DAC indices on every power cycle. When we moved it, it must have changed it from the order we had. We were aware of this fact and decided to reconnect the I/O chassis to AA/AI to relect the correct order. We forgot to do that but this is not an error, it is expected behavior and can be solved easily.

Quote:

I had the fear that any mistake in the electronics chain could have been the show stopper.

So I quickly checked the signal assignments for the ADC and DAC chains.

I had initial confusion (see below), but it was confirmed that the electronics chains (at least for LO1) are correct.

Note: One 70ft cable is left around the 1Y0 rack

 


There are a few points to be fixed:

- It looks like the ADC/DAC card # assignment has been messed up.

CDS ADC0 -> Cable label ADC1 -> AA A1 -> ...
CDS ADC1 -> Cable label ADC0 -> AA A0 -> ...
CDS DAC0 -> Cable label DAC2 -> AI D2 -> ...
CDS DAC1 -> Cable label DAC0 -> AI D0 -> ...
CDS DAC2 -> Cable label DAC1 -> AI D1 -> ...
(What is going on here... please confirm and correct as they become straight forward)

Once this puzzle was solved I could confirm reasonable connections from the end of the 70 cables to the ADC/DAC.

- We also want to change the ADC card assignment. The face OSEM readings must be assigned to ADC1 and the side OSEM readings to ADC0.
  My system wiring diagram needs to be fixed accordingly too.
  This is because the last channel of the first ADC (ADC0) is not available for us and is used for DuoTone.

 

  16534   Wed Dec 22 18:16:23 2021 KojiUpdateSUSRemaining task for 2021

The in-vacuum installation team has reported that the side OSEMs of ITMX and LO1 are going to be interfering if place LO1 at the planned location.
I confirmed that ITMX has the side magnet on the other side (Attachment 1 ITMX photo taken on 2016/7/21). So we can do this swap.

The ITMX side OSEM is sticking out most. By doing this operation, we will recover most of the space between the ITMX and LO1. (Attachment 2)

Attachment 1: ITMX_2016_07_21.jpg
ITMX_2016_07_21.jpg
Attachment 2: Screen_Shot_2021-12-22_at_18.03.42.png
Screen_Shot_2021-12-22_at_18.03.42.png
  2074   Fri Oct 9 03:53:56 2009 JenneUpdateAdaptive FilteringRemaking the ASS

The c1ass computer, which is now used for the OAF system, has many remnants from the days when it was actually used as an ASS.  These PIT and YAW filter banks and other things were taking up a lot of unnecessary space, so I deleted them in the ass.mdl file.  These files are all backed up, so we can always revert back to an older version when we want some Alignment Stabilization again someday.  I then did a make ass, following the instructions on the 40m Wiki -> Computers and Scripts -> Simulink to Front-End Code page.  Rana moved some things around, most notably all of the things (like the ASS screens) which were only in ...../users/alex/.... are now in ....../caltech/cds/advLigo/..... .  This required a few restarts of the c1ass machine (after a couple different versions of the simulink diagram....one to make sure we knew how to do it, and then again actually deleting the unused portions).

The big lesson of the night was that there are 2 signal paths for the PEM channels.  As is shown in Figure 3 in the mevans document, the PEM channels get the matching filters when they go to the adaptation algorithm, but when they go to the FIR filter, they do not get the matching filters. This is implemented by taking the output of the giant PEM matrix, and having a duplicate of each of the channels "selected for adaptation", one which gets filtered through the PEM_N_ADPT banks, and one which goes straight (in code-land) to the FIR filter.  So, it seems like all the filters which we had been including in the input side of the matrix for matching purposes need to be put in the output side.  One of the AA32 filters needs to stay in the input side, for actual anti imaging of the PEM channels, then we put the AA32 and AI32 which are for matching the ERR_EMPH and CORR filter banks up in the PEM_N_ADAPT banks.  Rana and I made these filters, and they are now turned on appropriately with the OAF down script (so that all the filters are ready and waiting for the OAF to be turned on).

A little success with getting the 3Hz peak reduced, but not a lot beyond that.  Tomorrow I'll put the accelerometers back where they used to be to see if they help out at all.

  11563   Thu Sep 3 00:45:25 2015 IgnacioUpdateIOORemeasured MC2 to MCL TF + Improved subtraction performance

Today, I remeasured the transfer function for MC2 to MCL in order to improve the subtraction performance for MCL and to quantify just how precisely it needs to be.

Here is the fit, and the measured coherence. Data is also attached here: TF.zip

 

OMG, I forgot to post the data and any residuals. LOL!

The transfer function was fitted using vectfit with a weighting based on coherence being greater than 0.95.

I then used the following filters to do FF on MCL online:

Here are the results:

Performance has definelty increased when compared to previous filters. The reason why I think we still have poor performance at 3 Hz, is 1) When I remeasured the transfer function, Eric and I were expecting to see a difference on its shape due to the whitening filters that were loaded a couple days ago. 2) Assuming the transfer function is correct, there is poor coherence at 3 Hz 3) The predicted IIR subtraction is worst at this frequency.

Attachment 1: TF.zip
  8498   Fri Apr 26 20:43:51 2013 JenneUpdateLSCRemeasuring the Schnupp asymmetry

[Jenne, Annalisa, with guidance from Koji]

We took data to remeasure the Schnupp asymmetry, using the Valera method that Jamie described in elog 4821

1  First, we locked the arms each with their PO(X,Y) signals, to get the alignment of each arm. 

2.  Then, we locked the Xarm with AS55I (Yarm optics, and PRM very misaligned, more than the misalign script).  Since AS55 was saturating, I changed the analog gain from 24dB to 21dB. (After work was completed, the analog gain was put back to the nominal 24dB for both I&Q.)

3.  We set up the Lockin similar to Jamie's description, with a few differences.  We used the same f = 103.1313, but used ampl=10cts.  Sin and cos gain were each 100.  We changed the lowpass filter from 0.1Hz to 0.05Hz (so each measurement had a settling time of at least 20sec).  We were using LSC-Lockin4, so the Lockin matrix was set so Lockin4 was reading from AS55Q, and the LSC output matrix was such that we were actuating on the ETM (X, then Y when we switched arms later).

4.  By hand, we roughly found the zero crossing of the lockin-q output (which corresponded also to zero of the lockin-I, since this is the place where all of the PDH signal was in AS55I, and the lockin was reading AS55Q). 

5.  We took points separated by 0.2 degrees, plus and minus 1 degree from the zero-crossing phase we had found (i.e., for the Xarm, we roughly found the zero crossing at -14.39 deg, so took data from -15.39 to -13.39degrees).  For each phase, we took 5 measurements (using ezcaread), at least 20 seconds apart.  After moving the phase, we waited at least ~40 seconds (watching the lockin outputs on striptool, they had completely settled after 30 or 40 seconds).

6.  We then repeated steps 2, 4 and 5 for the Y arm.  The lockin setup didn't change, except that now we actuate on ETMY.

We did a quick estimate calculation, from our rough zero-crossings to get a rough measurement of the Schnupp asymmetry.  DeltaPhi = (-14.39 -   -19.79) = 5.40 . This gives us (using F_sideband = 5*11066134, the current 11MHz marconi freq) a rough Schnupp asymmetry of 4 cm. 

Analysis to follow.

EDIT, JCD:  The Xarm gain at this time was -0.160, and the Yarm gain was -0.170

  8528   Fri May 3 17:32:59 2013 JenneUpdateLSCRemeasuring the Schnupp asymmetry

I have looked at / analyzed the Schnupp data that Annalisa and I took last week, as well as some more Yarm data that I took this week.

I only have one set of Xarm data, but 3 sets of Yarm data.  I had intended to do careful error analysis of the data, but from the 3 sets of Yarm data, the variance in the answer I get using any one of the Yarm sets is much larger than the error in a single measurement.

 Xarm_SchnuppData_April2013.png

Yarm_SchnuppData_April2013.png

Using the central Yarm zero crossing, I get a Schnupp asymmetry of 3.9cm.  The other 2 Yarm data points give Schnupp asymmetries of 3.7cm and 4.1cm, so I'm claiming a value of 3.9 +\- 0.2cm . This is within error of Jamie's measurement of 3.64 ± 0.32 cm (elog 4821).

  1738   Mon Jul 13 15:48:05 2009 ranaOmnistructureEnvironmentRemoval of the cold air deflection device for the MOPA chiller
Around 2 PM today, I removed the blue flap which has been deflecting the cold air from the AC down into the laser chiller.
Let's watch the laser trends for a few days to see if there's any effect.
  1740   Mon Jul 13 23:03:14 2009 rob, albertoOmnistructureEnvironmentRemoval of the cold air deflection device for the MOPA chiller

Quote:
Around 2 PM today, I removed the blue flap which has been deflecting the cold air from the AC down into the laser chiller.
Let's watch the laser trends for a few days to see if there's any effect.


Alberto has moved us to stage 2 of this experiment: turning off the AC.

The situation at the control room computers with the AC on minus the blue flap is untenable--it's too cold and the air flow has an unpleasant eye-drying effect.
  1741   Tue Jul 14 00:32:46 2009 rob, albertoOmnistructureEnvironmentRemoval of the cold air deflection device for the MOPA chiller

Quote:

Quote:
Around 2 PM today, I removed the blue flap which has been deflecting the cold air from the AC down into the laser chiller.
Let's watch the laser trends for a few days to see if there's any effect.


Alberto has moved us to stage 2 of this experiment: turning off the AC.

The situation at the control room computers with the AC on minus the blue flap is untenable--it's too cold and the air flow has an unpleasant eye-drying effect.


I turned the AC back on because the temperature of the room was going up so also that of the laser chiller.
  1745   Tue Jul 14 17:48:20 2009 JenneOmnistructureEnvironmentRemoval of the cold air deflection device for the MOPA chiller

Quote:

Quote:

Quote:
Around 2 PM today, I removed the blue flap which has been deflecting the cold air from the AC down into the laser chiller.
Let's watch the laser trends for a few days to see if there's any effect.


Alberto has moved us to stage 2 of this experiment: turning off the AC.

The situation at the control room computers with the AC on minus the blue flap is untenable--it's too cold and the air flow has an unpleasant eye-drying effect.


I turned the AC back on because the temperature of the room was going up so also that of the laser chiller.


I reinstalled the blue-flap technology on the AC, because the MOPA power was dropping like a rock. A light-ish rock since it wasn't going down too fast, but the alarms started going a little while ago because PMC trans was too low, because the power was getting a little low. The laser water chiller is reading 21.97C, which is higher than it normally does/did before the AC shenanigans (It usually reads 20.00C).

Attached is a look-back of 18 hours, during which you can see in the AMPMON the time that Rana removed the blue flap around 2pm yesterday and the AMPMON changes a little bit, but not drastically, the time around 11pm when the AC was turned off, and AMPMON goes down pretty fast, and about 12:30am, when Alberto turned the AC back on, and AMPMON starts to recover. I think that the AMPMON starts to go down again in the morning because it's been crazy hot here in Pasadena, so the room might be getting warmer, especially with the laser chiller-chiller not actively chilling the laser chiller (by not being pointed at the water chiller), so the water isn't getting as cold, and the HTEMP started to go up.

In the last few minutes of having put the blue flap back on the AC, the laser chiller is already reading a lower temperature, and the AMPMON is starting to recover.
Attachment 1: ACeffectonLASER2.png
ACeffectonLASER2.png
  572   Thu Jun 26 10:56:15 2008 Max JonesUpdatePEMRemoved Magnetometer
I removed the Bartington Magnetometer on the x arm to one of the outside benches. I'll be trying to determine if and how it works today. It makes a horrible high pitched sound which is due to the fact that the battery is probably 16 yrs old. It still works with ac power though and I want to see if it is still operating correctly before I ask to buy a new battery. Sorry for the bother.
  7246   Tue Aug 21 22:54:47 2012 JenneUpdateLockingRemoved beam dump from POY path

POY was looking funny, and the YARM wasn't locking.  It looked like POY wasn't seeing any light at all.  I went to check, and it looks like a beam dump got accidentally placed in the POY path during oplev adjustments this morning.  POY is back, locking continues.

  16676   Wed Feb 23 15:08:57 2022 AnchalUpdateGeneralRemoved extra beamsplitter in MC WFS path

As discussed in the meeting, I removed the extra beam splitter that dumps most of the beam going towards WFS photodiodes. This beam splitter needs to be placed back in position before increasing the input power to IMC at nominal level. This is to get sufficient light on the WFS photodiodes so that we can keep IMC locked for more than 3 days. Currently IMC is unlocked and misaligned. I have marked the position of this beam splitter on the table, so putting it back in should be easy. Right now, I'm trying to align the mode cleaner back and start the WFS loops once we get it locked.

  4561   Fri Apr 22 12:07:38 2011 josephb, steveUpdateCDSRemoved hanging D-sub to SCSI in 1X2

Problem:

Way back, Jay had D-sub to SCSI adapters made to adapt our existing Sander box AA filters to the new SCSI based IO chassis.  However, these did not fit inside the box.

At the time, we simply left the cards outside hanging, which was a hack and needed to be replaced.

Solution:

Steve modified a black AA filter box so that it could fit the D-sub to SCSI adapter board on it, plus strain relief the SCSI cable, rather than let it hang.  The back of the box was cut, and an extending piece of metal attached to the bottom of the box.  The adapter board was screwed into the box, the SCSI plugged in, then the SCSI cable is clamped to the extending metal as well.

This modification will be propagated to the 3 remaining AA filter boards using the D-sub to SCSI adapter.

  4590   Fri Apr 29 14:36:36 2011 josephb, steveUpdateCDSRemoved hanging D-sub to SCSI in 1X5

Quote:

Problem:

Way back, Jay had D-sub to SCSI adapters made to adapt our existing Sander box AA filters to the new SCSI based IO chassis.  However, these did not fit inside the box.

At the time, we simply left the cards outside hanging, which was a hack and needed to be replaced.

Solution:

Steve modified a black AA filter box so that it could fit the D-sub to SCSI adapter board on it, plus strain relief the SCSI cable, rather than let it hang.  The back of the box was cut, and an extending piece of metal attached to the bottom of the box.  The adapter board was screwed into the box, the SCSI plugged in, then the SCSI cable is clamped to the extending metal as well.

This modification will be propagated to the 3 remaining AA filter boards using the D-sub to SCSI adapter.

 The same modification was carried out at 1X5 for PRM & SRM.

Note:  D68L8EX-850Hz  are removed  and bypassed in 7 channels.

Attachment 1: P1070621.JPG
P1070621.JPG
  3080   Wed Jun 16 11:31:19 2010 josephbSummaryComputersRemoved scaling fonts from medm on Allegra

Because it was driving me crazy while working on the new medm screens for the simulated plant, I went and removed the aliased font entries in /usr/share/X11/fonts/misc/fonts.alias that are associated with medm.  Specifically I removed the lines  starting with widgetDM_.  I made a backup in the same directory called fonts.alias.bak with the old lines.

Medm now behaves the same on op440m, rosalba, and allegra - i.e. it can't find the widgetDM_ scalable fonts and defaults to a legible fixed font.

  17184   Tue Oct 11 16:52:42 2022 AnchalUpdateIOORenaming WFS channels to match LIGO site conventions

[Tega, Anchal]

c1mcs and c1ioo models have been updated to add new acquisition of data.


IOO:WFS channels

We found from https://ldvw.ligo.caltech.edu/ldvw/view that following channels with "WFS" in them are acquired at the sites:

  • :IOO-WFS1_IP
  • :IOO-WFS1_IY
  • :IOO-WFS2_IP
  • :IOO-WFS2_IY

These are most probably error signals of WFS1 and WFS2. At 40m, we have following channel names instead:

  • C1:IOO-WFS1_I_PIT_OUT
  • C1:IOO-WFS1_I_YAW_OUT
  • C1:IOO-WFS2_I_PIT_OUT
  • C1:IOO-WFS2_I_YAW_OUT

And similar for Q outputs as well. We also have chosen quadrature signals (signals after sensing matrix) at:

  • C1:IOO-WFS1_PIT_OUT
  • C1:IOO-WFS1_YAW_OUT
  • C1:IOO-WFS2_PIT_OUT
  • C1:IOO-WFS2_YAW_OUT

We added following testpoints and are acquiruing them at 1024 Hz:

  • C1:IOO-WFS1_IP  (same as C1:IOO-WFS1_I_PIT_OUT)
  • C1:IOO-WFS1_IY  (same as C1:IOO-WFS1_I_YAW_OUT)
  • C1:IOO-WFS2_IP  (same as C1:IOO-WFS2_I_PIT_OUT)
  • C1:IOO-WFS2_IY  (same as C1:IOO-WFS2_I_YAW_OUT)

IOO-MC_TRANS

For the transmission QPD at MC2, we found following acquired channels at the site:

  • :IOO-MC_TRANS_DC
  • :IOO-MC_TRANS_P
  • :IOO-MC_TRANS_Y

We created testpoints in c1mcs.mdl to add these channel names and acquire them. Following channels are now available at 1024 Hz:

  • C1:IOO-MC_TRANS_DC
  • C1:IOO-MC_TRANS_P
  • C1:IOO-MC_TRANS_Y

We started acquiring following channels for the 6 error signals at 1024 Hz:

  • C1:IOO-WFS1_PIT_IN1
  • C1:IOO-WFS1_YAW_IN1
  • C1:IOO-WFS2_PIT_IN1
  • C1:IOO-WFS2_YAW_IN1
  • C1:IOO-MC2_TRANS_PIT_IN1
  • C1:IOO-MC2_TRANS_YAW_IN1

We started acquiring following 6 control signals at 1024 Hz as well:

  • C1:IOO-MC1_PIT_OUT
  • C1:IOO-MC1_YAW_OUT
  • C1:IOO-MC2_PIT_OUT
  • C1:IOO-MC2_YAW_OUT
  • C1:IOO-MC3_PIT_OUT
  • C1:IOO-MC3_YAW_OUT

RXA: useful to know that you have to append "_DQ" to all of the channel names above if you want to find them with nds2-client.


Other changes:

In order to get C1:IOO-MC_TRANS_[DC/P/Y], we had to get rid of same named EPICS output channels in the model. These were been acquired at 16 Hz before this way. We then updated medm screens and autolocker config file. For slow outputs of these channels, we are using C1:IOO-MC_TRANS_[PIT/YAW/SUMFILT]_OUTPUT now. We had to restart daqd service for changes to take effect. This can be done by sshing into fb1 and running:

sudo systemctl restart rts-daqd

Now there is a convinient button present in FE overview status medm screen to restart DAQD service by a simple click.

  2806   Mon Apr 19 07:38:07 2010 ranaHowToElectronicsRepair and Calibration of SR560: s/n 59650

Frank noticed that this particular SR560 had an offset on the output which was unzeroable by the usual method of tuning the trim pot accessible through the front panel.

I tried to zero the offset using the trimpots inside, but it became clear that the offset was due to a damaged FET, so Steve ordered ~20 of the (now obsolete*) NPD5564.

I replaced this part and adjusted the offsets and balanced the CMRR of the differential inputs mostly according to the manual (p. 17). There are a few notes that should be added to the procedure:

  1. It can sometimes be that the gain proscribed by the manual is too high and saturates the output for large offsets. If that's the case, simply lower the gain, trim the offset, then return the gain to the specified value and trim again.
  2. The limit in trimming the offset is the stick slip resolution in the trim pot. This can potentially leave the whole preamp in an acoustically sensitive state. I tapped the pots with a screwdriver after tuning to make sure it was in more of a 'sticky' rather than 'slippy' region of the knob. A better design would allow for more filtering of the pot.
  3. In the CMRR tuning procedure it says to 'null sine wave output' but it should really say 'null the sine wave component at the drive frequency'. The best CMRR tuning uses a 1 kHz drive and leaves a residual 2 kHz signal due to the distortion imbalance (of the FETs I think).
  4. The CMRR tuning upsets the DC offset trim and vice versa. The best tuning is gotten by iterating slightly (go back and forth once or twice between the offset and CMRR tuning procedures).

It looks like its working fine now. Steve's ordering some IF3602 (low-noise, balanced FET pair from Interfet) to see if we can drop the SR560's input noise to the sub-nV level.

Noise measured with the input terminated with a BNC short (not 50 Ohms) G=100, DC coupled, low-noise mode:

Input referred noise (nV/rHz)
f e_n

0.1

200
1 44
10 8
100 5
1000 5
10000 4
  9560   Thu Jan 16 21:38:13 2014 ericqUpdateLSCRepeat of PRC length measurement

[ericq,Jenne]

Since we don't have agreement between the measurements we made the other day and the earlier estimations, I wanted to repeat the demodulation angle measurement. We had to do a few things to keep the PRMI locked, since in the last few days, it hasn't been stable enough.

The mode cleaner had been very fussy lately; the WFS were pushing in a way that caused fast oscillations of the transmission and reflection powers. I turned off the servos, manually aligned the mode cleaner to transmission of about 15k and refl of about .4, centered the beams on the WFS QPDs, and turned the loops back on. Things were much stable after that. Also, Jenne noticed that the PMC loop had walked the laser PZT temperature to a bad place, and fixed it.

After aligning the carrier locked PRMI, the last piece needed to get things stable enough for sideband locking was turning off the angular damping on the PRM suspension screen (this was turned back on when we were done). Waiting until evening noise levels probably helped too. We used a 1000 count MICH excitation in the PRMI case, and recorded data for about a minute in one degree steps around the demodulation phase that looked to put the excitation entirely within the Q of the PD. Also, we notched out the excitation frequency in the MICH servo bank for today's measurement; I think it's outside of the loop bandwidth anyways, but it's good to be sure. 

Jenne and I pondered a bit whether changing the AS55 demodulation phase while it (AS55 Q) is being used as the MICH control signal introduces subtleties that we haven't anticipated, but couldn't come up with anything concrete. Changing the angle from the what maximizes the Q just looks like a slight change in MICH gain, and shouldn't affect the phase of the excitation signal on the PD...

In any case, the data have been recorded, and the results will follow soon. 

  15966   Thu Mar 25 16:02:15 2021 gautamSummarySUSRepeated measurement of coil Rs & Ls for PRM/BS

Method

Since I am mainly concerned with the actuator part of the OSEM, I chose to do this measurement at the output cables for the coil drivers in 1X4. See schematic for pin-mapping. There are several parts in between my measurement point and the actual coils but I figured it's a good check to figure out if measurements made from this point yield sensible results. The slow bias voltages were ramped off under damping (to avoid un-necessarily kicking the optics when disconnecting cables) and then the suspension watchdogs were shutdown for the duration of the measurement.

I used an LCR meter to measure R and L - as prescribed by Koji, the probe leads were shorted and the readback nulled to return 0. Then for R, I corroborated the values measured with the LCR meter against a Fluke DMM (they turned out to be within +/- 0.5 ohms of the value reported by the BK Precision LCR meter which I think is reasonable).

Result

                   PRM
Pin1-9 (UL)   / R = 30.6Ω / L=3.23mH  
Pin2-10 (LL)  / R = 30.3Ω / L=3.24mH
Pin3-11 (UR) / R = 30.6Ω / L=3.25mH
Pin4-12 (LR) / R = 31.8Ω / L=3.22mH
Pin5-13 (SD) / R = 30.0Ω / L=3.25mH

                       BS
Pin1-9 (UL)   / R = 31.7Ω / L=3.29mH
Pin2-10 (LL)  / R = 29.7Ω / L=3.26mH
Pin3-11 (UR) / R = 29.8Ω / L=3.30mH
Pin4-12 (LR) / R = 29.7Ω / L=3.27mH
Pin5-13 (SD) / R = 29.0Ω / L=3.24mH

Conclusions

On the basis of this measurement, I see no problems with the OSEM actuators - the wire resistances to the flange seem comparable to the nominal OSEM resistance of ~13 ohms, but this isn't outrageous I guess. But I don't know how to reconcile this with Koji's measurement at the flange - I guess I can't definitively rule out the wire resistance being 30 ohms and the OSEMs being ~1 ohm as Koji measured. How to reconcile this with the funky PRM actuator measurement? Possibilities, the way I see it, are:

  1. Magnets on PRM are weird in some way. Note that the free-swinging measurement for the PRM showed some unexpected features.
  2. The imbalance is coming from one of the drive chain - could be a busted current buffer for example.
  3. The measurement technique was wrong.
  9335   Mon Nov 4 12:07:55 2013 DmassOmnistructureGeneralReplaced Broken Drill Bits

I broke a small bit while using the 40m drill press to vent some 1/4-20 screws for the cryo experiment.

I replaced it and refilled the small bit row in the bit index I was using; there were ~10 missing sizes

  9202   Fri Oct 4 12:33:27 2013 MasayukiUpdateSUSReplaced the laser for Optical Lever of ETMY

[Steve, Masayuki]

We replaced the laser for optical lever of ETMY. And also we aligned the path so that beam spot hits the center for each optics. I attached the spectrum of the SUS-ETMY_OPLEV_SUM, the red curve is with old laser, and blue curve is with the new laser. We also measured without laser so as to measure the QPD dark noise (green curve). The change is significant, and seems much closer to other oplev spectrum.(Brown curve is the oplev spectrum of ITMY)

The new laser is:

Manufacture name: JDSU, Model number: 1103P, Serial number: PA892324

The injection power is 3.7 mW and the out coming power is 197 uW (measured just before the QPD). The output value of the SUS-ETMY_OPLEV_SUM is about 8500.

First we measure 2 spectrum ( including the dark noise). After that we replace the laser and align the optical lever path. We changed the post of one of the mirror (just before the QPD) because the hight was too low. Inside of the chamber is darker than before - actually we had scattering light inside the chamber before. We dumped the reflected light from QPD. And then we measured the spectrum of the oplev output. I also aligned oplev of ETMY after restoring the YARM configuration using IFO configure screen.

We don't know actually what was the problem, laser quality or the scattering light or some clipping. But the oplev seems to be better.

Steve:  Atm2 shows increased gains correction later for UGF elog 9206

Attachment 1: OPLEV_SUM.pdf
OPLEV_SUM.pdf
Attachment 2: ETMYoplev.png
ETMYoplev.png
  9203   Fri Oct 4 14:36:44 2013 ranaUpdateSUSReplaced the laser for Optical Lever of ETMY

  That's good, but please no more Oplev work. We want to do all of it at once and to make no more changes until we have all the parts (e.g. dumps and correct lenses) in hand and then talk over what the new design will be. I don't want to tune the beam size and loop shape every week.

  9206   Sun Oct 6 18:37:43 2013 ranaUpdateSUSReplaced the laser for Optical Lever of ETMY

I centered the ETMY OL today and found that the UGF was around 3-4x too LOW after the laser swap and re-alignment. That's why the Y arm has been shaking so much today.

NO more OL work without loop measurements and noise measurements.

web-burnt-toast.jpg

  9212   Mon Oct 7 10:51:18 2013 SteveUpdateSUSReplaced the laser for Optical Lever of ETMY

 Just plot.

RA: I'm not sure how to interperet this; I think that the SUM channel is divided by the SUM so that this is supposed to be RIN, but not sure. Can someone please take a look into the SUS model and then explain in the elog what the SUM normalization algorithm is?

Attachment 1: ETMXoplevETMY.png
ETMXoplevETMY.png
Attachment 2: oplevSettings.png
oplevSettings.png
  8125   Wed Feb 20 23:25:50 2013 ZachSummaryElectronicsReplacement for the AD743: OPA140 and OPA827

I have found two great FET input chips that rival the storied, discontinued AD743. In some ways, they are even better. These parts are the OPA140 and the OPA827.

Below is a plot of the input-referred voltage noise of the two op amps with Rsource = 0, along with several others for comparison. The smooth traces are LISO models. The LT1128 and AD797 are BJT-input parts, so their voltage noise is naturally better. However, the performance you see here for the FET parts is the same you would expect for very large source impedances, due to their extremely low current noise by comparison. I have included the BJTs so that you can see what their performance is like in an absolute sense. I have also included a "measured" trace of the LT1128, since in practice their low-frequency noise can be quite higher than the spec (see, for example, Rana's evaluation of the Busby Box). The ADA4627 is another part I was looking into before, the LT1012 is a less-than-great FET chip, and the AD797 a less-than-great BJT.

As you can see, the OPA140 actually outperforms the AD743 at low frequencies, though it is ~2x worse at high frequencies. The OPA827 comes close to the AD743 at high frequencies, but is a bit worse at low ones. Both the OPA140 and OPA827 have the same low-frequency RMS spec, so I was hoping it would be a better all-around part, but, unfortunately, it seems not to be.

The TI chips also have a few more things on the AD743:

  • Input current noise @ 1kHz
    • AD743: 6.9 fA/rtHz
    • OPA827: 2.2 fA/rtHz
    • OPA140: 0.8 fA/rtHz (!)
  • Input bias (offset) current, typ
    • AD743: 30 pA (40 pA) --- only for Vsupply = ±5 V
    • OPA827: ±3 pA (±3 pA) --- up to ±18V
    • OPA140: ±0.5 pA (±0.5 pA) (!) --- up to ±18V
  • Supply
    • Both OPA140 and OPA827 can be fed single supplies up to 36V absolute maximum
    • The OPA140 is a rail-to-rail op amp

These characteristics make both parts exceptionally well suited for very-high source impedance applications, such as very-low-frequency AC-coupling preamplifiers or ultra-low-noise current sources.

 ULN_opamp_comparison_2_20_13.png

(Apologies---the SR785 I was using had some annoying non-stationary peaks coming in. I verified that they did not affect the broadband floor).

R.I.P., AD743

  8151   Sat Feb 23 18:01:38 2013 ZachSummaryElectronicsReplacement for the AD743: OPA140 and OPA827

Rana suggested that I measure the OPA827 and OPA140 noise with high source impedance so as to see if we could find the low-frequency current noise corner. Below is a plot of both parts with Rs = 0, 10k, and 100k.

As you can see, both parts are thermal noise limited down to 0.1 Hz for up to Rs = 100k or greater. Given that the broadband current noise level for each part is ~0.5-1 fA/rtHz, this puts an upper limit to the 1/f corner of <100 Hz. This is where the AD743 corner is, so that sounds reasonable. Perhaps I will check with even higher impedance to see if I can find it. I am not sure yet what to make of the ~10-20 kHz instability with high source impedance.

OPA140_OPA827_noise_vs_Rs.png

EDIT: The datasheets claim that they are Johnson noise limited up to 1 Mohm, but this is only for the broadband floor, I'd guess, so it doesn't really say anything about the low frequency corner.

Screen_Shot_2013-02-24_at_12.12.23_PM.png Screen_Shot_2013-02-24_at_12.12.43_PM.png

Quote:

I have found two great FET input chips that rival the storied, discontinued AD743. In some ways, they are even better. These parts are the OPA140 and the OPA827.

 

  8153   Sun Feb 24 16:49:00 2013 ranaSummaryElectronicsReplacement for the AD743: OPA140 and OPA827

  This looks pretty good already. Not sure if we can even measure anything reasonable below 0.1 Hz without a lot of thermal shielding.

The 10-20 kHz oscillation may just be the loop shape of the opamp. I think you saw similar effects when using the AD743 with high impedance for the OSEM testing.

  12239   Fri Jul 1 17:51:28 2016 PrafulSummaryElectronicsReplacing DIMM on Optimus

There has been an ongoing memory error in optimus with the following messages:

controls@optimus|~ >
Message from syslogd@optimus at Jun 30 14:57:48 ...
 kernel:[1292439.705127] [Hardware Error]: Corrected error, no action required.

Message from syslogd@optimus at Jun 30 14:57:48 ...
 kernel:[1292439.705174] [Hardware Error]: CPU:24 (10:4:2) MC4_STATUS[Over|CE|MiscV|-|AddrV|CECC]: 0xdc04410032080a13

Message from syslogd@optimus at Jun 30 14:57:48 ...
 kernel:[1292439.705237] [Hardware Error]: MC4_ADDR: 0x0000001ad2bd06d0

Message from syslogd@optimus at Jun 30 14:57:48 ...
 kernel:[1292439.705264] [Hardware Error]: MC4 Error (node 6): DRAM ECC error detected on the NB.

Message from syslogd@optimus at Jun 30 14:57:48 ...
 kernel:[1292439.705323] [Hardware Error]: cache level: L3/GEN, mem/io: MEM, mem-tx: RD, part-proc: RES (no timeout)

Optimus is a Sun Fire X4600 M2 Split-Plane server. Based on this message, the issue seems to be in memory controller (MC) 6, chip set row (csrow) 7, channel 0. I got this same result again after installing edac-utils and running edac-util -v, which gave me:

mc6: csrow7: mc#6csrow#7channel#0: 287 Corrected Errors 

and said that all other DIMMs were working fine with 0 errors. Each MC has 4 csrows numbered 4-7. I shut off optimus and checked inside and found that it consists of 8 CPU slots lined up horizontally, each with 4 DIMMs stacked vertically and 4 empty DIMM slots beneath. I'm thinking that each of the 8 CPU slots has its own memory controller (0-7) and that the csrow corresponds to the position in the vertical stack, with csrow 7 being the topmost DIMM in the stack. This would mean that MC 6, csrow 7 would be the 7th memory controller, topmost DIMM. The channel would then correspond to which one of the DIMMs in the pair is faulty although if the DIMM was replaced, both channels 0 and 1 would be switched out. Here are some sources that I used:

http://docs.oracle.com/cd/E19121-01/sf.x4600/819-4342-18/html/z40007f01291423.html#i1287456

https://siliconmechanics.zendesk.com/hc/en-us/articles/208891966-Identify-Bad-DIMM-from-EDAC

http://martinstumpf.com/how-to-diagnose-memory-errors-on-amd-x86_64-using-edac/

I'll find the exact part needed to replace soon.

  12275   Fri Jul 8 15:44:07 2016 PrafulUpdateElectronicsReplacing DIMM on Optimus

Optimus' memory errors are back so I found the exact DIMM model needed to replace: http://www.ebay.com/itm/Lot-of-10-Samsung-4GB-2Rx4-PC2-5300P-555-12-L0-M393T5160QZA-CE6-ECC-Memory-/201604698112?hash=item2ef0939000:g:EgEAAOSwqBJXWFZh I'm not sure what website would be the best for buying new DIMMs but this is the part we need: Samsung 4GB 2Rx4 PC2-5300P-555-12-L0 M393T5160QZA-CE6.

  12613   Mon Nov 14 14:21:06 2016 gautamSummaryCDSReplacing DIMM on Optimus

I replaced the suspected faulty DIMM earlier today (actually I replaced a pair of them as per the Sun Fire X4600 manual). I did things in the following sequence, which was the recommended set of steps according to the maintenance manual and also the set of graphics on the top panel of the unit:

  1. Checked that Optimus was shut down
  2. Removed the power cables from the back to cut the standby power. Two of the fan units near the front of the chassis were displaying fault lights, perhaps this has been the case since the most recent power outage after which I did not reboot Optimus
  3. Took off the top cover, removed CPU 6 (labelled "G" in the unit). The manual recommends finding faulty DIMMs by looking for an LED that is supposed to indicate the location of the bad card, but I couldn't find any such LEDs in the unit we have, perhaps this is an addition to the newer modules?
  4. Replaced the topmost (w.r.t the orientation the CPU normally sits inside the chassis) DIMM card with one of the new ones Steve ordered
  5. Put everything back together, powered Optimus up again. Reboot went smoothly, fan unit fault lights which I mentioned earlier did not light up on the reboot so that doesn't look like an issue.

I then checked for memory errors using edac-utils, and over the last couple of hours, found no errors (corrected or otherwise, see Praful's earlier elog for the error messages that we were getting prior to the DIMM swap)- I guess we will need to monitor this for a while more before we can say that the issue has been resolved.

Looking at dmesg after the reboot, I noticed the following error messages (not related to the memory issue I think):

[   19.375865] k10temp 0000:00:18.3: unreliable CPU thermal sensor; monitoring disabled
[   19.375996] k10temp 0000:00:19.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376234] k10temp 0000:00:1a.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376362] k10temp 0000:00:1b.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376673] k10temp 0000:00:1c.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376816] k10temp 0000:00:1d.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376960] k10temp 0000:00:1e.3: unreliable CPU thermal sensor; monitoring disabled
[   19.377152] k10temp 0000:00:1f.3: unreliable CPU thermal sensor; monitoring disabled

I wonder if this could explain why the fans on Optimus often go into overdrive and make a racket? For the moment, the fan volume seems normal, comparable to the other SunFire X4600s we have running like megatron and FB...

  12615   Mon Nov 14 19:32:51 2016 ranaSummaryCDSReplacing DIMM on Optimus

I did apt-get update and then apt-get upgrade on optimus. All systems are nominal.

  15577   Wed Sep 16 12:03:07 2020 JonUpdateVACReplacing pressure gauges

Assembled is the list of dead pressure gauges. Their locations are also circled in Attachment 1.

Gauge Type Location
CC1 Cold cathode Main volume
CC3 Cold cathode Pumpspool 
CC4 Cold cathode RGA chamber
CCMC Cold cathode IMC beamline near MC2
P1b Pirani Main volume
PTP1 Pirani TP1 foreline

For replacements, I recommend we consider the Agilent FRG-700 Pirani Inverted Magnetron Gauge. It uses dual sensing techniques to cover a broad pressure range from 3e-9 torr to atmosphere in a single unit. Although these are more expensive, I think we would net save money by not having to purchase two separate gauges (Pirani + hot/cold cathode) for each location. It would also simplify the digital controls and interlocking to have a streamlined set of pressure readbacks.

For controllers, there are two options with either serial RS232/485 or Ethernet outputs. We probably want the Agilent XGS-600, as it can handle all the gauges in our system (up to 12) in a single controller and no new software development is needed to interface it with the slow controls.

Attachment 1: vac_gauges.png
vac_gauges.png
  15692   Wed Dec 2 12:27:49 2020 JonUpdateVACReplacing pressure gauges

Now that the new Agilent full-range gauges (FRGs) have been received, I'm putting together an installation plan. Since my last planning note in Sept. (ELOG 15577), two more gauges appear to be malfunctioning: CC2 and PAN. Those are taken into account, as well. Below are the proposed changes for all the sensors in the system.

In summary:

  • Four of the FRGs will replace CC1/2/3/4.
  • The fifth FRG will replace CCMC if the 15.6 m cable (the longest available) will reach that location.
  • P2 and P3 will be moved to replace PTP1 and PAN, as they will be redundant once the new FRGs are installed.

Required hardware:

  • 3x CF 2.75" blanks
  • 10x CF 2.75" gaskets
  • Bolts and nut plates
Volume Sensor Location Status Proposed Action
Main P1a functioning leave
Main P1b local readback only leave
Main CC1 dead replace with FRG
Main CCMC dead replace with FRG*
Pumpspool PTP1 dead replace with P2
Pumpspool P2 functioning replace with 2.75" CF blank
Pumpspool CC2 intermittent replace with FRG
Pumpspool PTP2 functioning leave
Pumpspool P3 functioning replace with 2.75" CF blank
Pumpspool CC3 dead replace with FRG
Pumpspool PTP3 functioning leave
Pumpspool PRP functioning leave
RGA P4 functioning leave
RGA CC4 dead replace with FRG
RGA IG1 dead replace with 2.75" CF blank
Annuli PAN intermittent replace with P3
Annuli PASE functioning leave
Annuli PASV functioning leave
Annuli PABS functioning leave
Annuli PAEV functioning leave
Annuli PAEE functioning leave

 

Quote:

For replacements, I recommend we consider the Agilent FRG-700 Pirani Inverted Magnetron Gauge. It uses dual sensing techniques to cover a broad pressure range from 3e-9 torr to atmosphere in a single unit. Although these are more expensive, I think we would net save money by not having to purchase two separate gauges (Pirani + hot/cold cathode) for each location. It would also simplify the digital controls and interlocking to have a streamlined set of pressure readbacks.

For controllers, there are two options with either serial RS232/485 or Ethernet outputs. We probably want the Agilent XGS-600, as it can handle all the gauges in our system (up to 12) in a single controller and no new software development is needed to interface it with the slow controls.

 

  15703   Thu Dec 3 14:53:58 2020 JonUpdateVACReplacing pressure gauges

Update to the gauge replacement plan (15692), based on Jordan's walk-through today. He confirmed:

  • All of the gauges being replaced are mounted via 2.75" ConFlat flange. The new FRGs have the same footprint, so no adapters are required.
  • The longest Agilent cable (50 ft) will NOT reach the CCMC location. The fifth FRG will have to be installed somewhere closer to the X-end.

Based on this info (and also info from Gautam that the PAN gauge is still working), I've updated the plan as follows. In summary, I now propose we install the fifth FRG in the TP1 foreline (PTP1 location) and leave P2 and P3 where they are, as they are no longer needed elsewhere. Any comments on this plan? I plan to order all the necessary gaskets, blanks, etc. tomorrow.

Volume Sensor Location Status Proposed Action
Main P1a functioning leave
Main P1b local readback only leave
Main CC1 dead replace with FRG
Main CCMC dead remove; cap with 2.75" CF blank
Pumpspool PTP1 dead replace with FRG
Pumpspool P2 functioning leave
Pumpspool CC2 dead replace with FRG
Pumpspool PTP2 functioning leave
Pumpspool P3 functioning leave
Pumpspool CC3 dead replace with FRG
Pumpspool PTP3 functioning leave
Pumpspool PRP functioning leave
RGA P4 functioning leave
RGA CC4 dead replace with FRG
RGA IG1 dead remove; cap with 2.75" CF blank
Annuli PAN functioning leave
Annuli PASE functioning leave
Annuli PASV functioning leave
Annuli PABS functioning leave
Annuli PAEV functioning leave
Annuli PAEE functioning leave
  15158   Mon Jan 27 14:01:01 2020 JordanConfigurationGeneralRepurposed Sorenson Power Supply

The 24 V Sorenson (2nd from bottom) in the small rack west of 1x2 was repurposed to 12V 600 mA, and was run to a terminal block on the north side of 1X1. Cables were routed underneath 1X1 and 1X2 to the terminal blocks. 12V was then routed to the PSL table and banana clip terminals were added.

  17268   Tue Nov 15 17:08:59 2022 PacoUpdateBHDRequest for estimates

[Yehonathan, Yuta, Paco]

We would like to estimate:

  • LO phase sensitivty (for RF55 + audio dither scheme), as a function of RF demod angle (both I and Q); not to be confused with audio dither angle.
  • LO phase sensitivity (for all schemes like in Attachment #2 of this previous post) but with some nonzero MICH offset.
  • LO phase sensitivity (for RF55 + audio dither scheme) but with the uBHDBS (44:56) values from this post.
  1681   Tue Jun 16 20:03:41 2009 AlbertoUpdateElectronicsRequirements on Wenzel Multiplier

For the 40m Upgrade, we plan to eliminate the Mach-Zehnder and replace it with a single EOM driven by all three modulation frequencies that we'll need: f1=11MHz, f2=5*f1=55MHz, fmc=29.5MHz.

A frequency generator will produce the three frequencies and with some other electronics we'll properly combine and feed them to the EOM.

The frequency generator will have two crystals to produce the f1 and fmc signals. The f2 modulation will be obtained by a frequency multiplier (5x) from the f1.

The frequency multiplier, for the way it works, will inevitably introduce some unwanted harmonics into the signals. These will show up as extra modulation frequencies in the EOM.

In order to quantify the effects of such unwanted harmonics on the interferometer and thus to let us set some limits on their amplitude, I ran some simulations with Optickle. The way the EOM is represented is by three RF modulators in series. In order to introduce the unwanted harmonics, I just added an RF modulator in series for each of them. I also made sure not to leave any space in between the modulators, so not to introduce phase shifts.

To check the effect at DC I looked at the sensing matrix and at the error signals. I considered the 3f error signals that we plan to use for the short DOFs and looked at how they depend on the CARM offset. I repeated the simulations for several possible amplitude of the unwanted harmonics. Some results are shown in the plots attached to this entry. 'ga' is the amplitude ratio of the unwanted
harmonics relative to the amplitude of the 11 & 55 MHz modulations.

Comparing to the case where there are no unwanted harmonics (ga = 0), one can see that not considerable effect on the error signals for amplitudes 40dB smaller than that of the main sidebands. Above that value, the REFL31I signals, that we're going to use to control PRCL, will start to be distorted: gain and linearity range change.

So 40 dB of attenuation in the unwanted harmonics is probably the minimum requirement on the frequency multiplier, although 60dB would provide a safer margin.

I'm still thinking how to evaluate any AC effect on the IFO.

 

** TODO: Plot DC sweeps with a wider range (+/- 20 pm). Also plot swept sines to look for changes in TFs out to ~10 kHz.

Attachment 1: SummaryOfResult.pdf
SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf
  3274   Fri Jul 23 10:16:44 2010 josephbUpdateCDSRerouted RFM around c1lsc, took RFM card out of c1lsc

 I re-routed around the c1lsc machine this morning.  I turned the crate off, and disconnected the transmission fiber from  c1lsc (which went to the receiver on c1asc).  I then took the receiving fiber from c1lsc and plugged it into the receiver on c1asc. 

I pulled out the c1lsc computer from the VME crate and pulled out the RFM card, which I needed for the CDS upgrade.  I then replaced the lsc card back in the crate and turned it back on.  Since there hasn't been a working version of the LSC code on linux1 since I overwrote it with the new CDS lsc code, this shouldn't have any significant impact on the interferometer.

I've confirmed that the RFM network seems to be in a good state (the only red lights on the RFM timing and status medm screen are LSC, ASC, and ETMX).  Fast channels can still be seen with dataviewer and fb40m appears to still be happy.

The RFM card has found its new home in the SUS IO Chassis.  The short fiber that used to go between c1asc and c1lsc is now on the top shelf of the new 1X3 rack.

  3283   Fri Jul 23 21:35:48 2010 ranaUpdateCDSRerouted RFM around c1lsc, took RFM card out of c1lsc

 I just realized that an unfortunate casualty of this LSC work was the deletion of the slow controls for the LSC which we still use (some sort of AUX processor). For example, the modulation

depth slider for the MC is now in an unknown state.

  3289   Mon Jul 26 10:02:42 2010 josephbUpdateCDSRerouted RFM around c1lsc, took RFM card out of c1lsc

If you're refering to just the medm screen,  those can be restored from the SVN.  As we're moving to a new directory structure, starting with /opt/rtcds/caltech/c1/, the old LSC screens can all be put back in the /cvs/cds/caltech/medm/c1/lsc directory if desired.

The slow lsc aux crate, c1iscaux2, is still working, and those channels are still available.  I confirmed that one was still updating. As a quick test, I went to the SVN and pulled out the C1LSC_RFADJUST.adl file, renamed it to C1LSC_RFadjust.adl and placed it in /cvs/cds/caltech/medm/c1/lsc/, and checked it linked properly from the C1IOO_ModeCleaner.adl file.  I haven't touched the modulation depths, as I didn't want to mess with the mode cleaner, but if I get an OK, we can test that today and confirm that modulation depth control is still working.

Quote:

 I just realized that an unfortunate casualty of this LSC work was the deletion of the slow controls for the LSC which we still use (some sort of AUX processor). For example, the modulation

depth slider for the MC is now in an unknown state.

 

  16340   Thu Sep 16 20:18:13 2021 AnchalUpdateGeneralReset

Fridge brought back inside.

Quote:

Put outside.

Quote:

It happened again. Defrosting required.

 

 

Attachment 1: PXL_20210917_031633702.jpg
PXL_20210917_031633702.jpg
  10743   Mon Dec 1 17:43:22 2014 JenneUpdateLSCReset Yarm trans normalization

After Koji and I reset the transmission normalizations last Friday, he did some alignment work that increased the Yarm power.  So, I had set the transmission normalization when we weren't really at full Yarm power.  Today I reset the normalization so that instead of ~1.2, the Y transmission PDs read ~1.0.

  1021   Thu Oct 2 18:56:19 2008 ranaSummarySUSResistivity of Suspension Wire
Bob and Steve measured the resistance of the suspension wire today:
OD     = 0.0036" =  0.091 mm
Length = 46"     = 1168.4 mm
Resistance     =   33.3 Ohms

resistivity = R * pi * (OD/2)^2
              ----------------- = 1.85e-7 Ohm-meters
                  Length 


This was a batch of California Fine Wire from 2001 (same as used at LHO and LLO).

By comparison the standard tabulated resistivity for steels is (http://hypertextbook.com/facts/2006/UmranUgur.shtml):
                  resistivity (Ohm-meter x 10^-7)
-------------     ----------------
304 Stainless       7.2
316 Stainless       7.4
Cast Steel          1.6

This is all to see whether or not the 60 Hz fields produce forces on the suspension wires via coupling with the Earth's DC field.

TBD
  888   Tue Aug 26 18:19:16 2008 ranaOmnistructureElectronicsResistor Noise at the 40m
As Stefan points out in his recent ISS ilog entries at LLO, Daniel Sigg recently wrote a
recommendation memo on resistor and capacitor
choices: T070016.

While working on the PMC I have had to use leaded resistors and wondered about the noise. As it turns
out we have the RN series of 1/4 W resistors from Stackpole Electronics. The RN series are
metal film resistors (datasheet attached); metal film is what Sigg recommends for lowest flicker
noise.

So we are OK for using the Stackpole 1/4 W leaded resistors in low noise circuits.
Attachment 1: SEI-RN_RNM.pdf
SEI-RN_RNM.pdf SEI-RN_RNM.pdf
  37   Wed Oct 31 09:45:28 2007 waldmanOtherOMCResolution to DAQland saga
[Jay, Sam]

We did a rough accounting for the linear delay this morning and it comes out more or less correct. The 10 kHz 3rd order butterworth AA/AI filter gives ~90 degrees of phase at 6 kHz, or 42 microseconds. Taken together, the two AA and AI filters are worth 80 microseconds. The 1.5 sample digital delay is worth 1.5/32768 = 45 microseconds. The remaining 160 - 125 = 35 microseconds is most likely taken up by the 64 kHz to 32 kHz decimation routine, assuming this isn't accounted for already in the 1.5 sample digital delay.

It remains to be seen whether this phase delay is good enough to lock the laser to the OMC cavity
ELOG V3.1.3-