40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 323 of 326  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  4494   Wed Apr 6 19:36:32 2011 AidanSummaryGreen Locking(In)sanity check of Green PD - some inconsistencies

I moved the Hartmut Green PD to the Jenne laser bench to try to determine if the response at RF was reasonable or somehow very much smaller than it should be. It was set up as shown in the attached diagram. The first pass at this was by comparing the ratio of the RF photocurrent of the green PD to the RF photocurrent of the New Focus 1611 InGaAs PD. That ratio (at a sufficiently low frequency) should be the same as the ratio the DC photocurrents of the two PDs.

Using the network analyzer I measured the ratio of the voltages of the two RF signals (and then scaled each of these by the respective transimpedances of the PDs: 700 Ohms for the 1611 and 240 Ohms for the Harmut PD). The resulting ratio is shown in the attached plot.

I measured the DC voltages from each PD and scaled those by the transimpedances to get the photocurrent (10 kOhm for the 1611 and 80 Ohm effective for the Harmut PD). The ratio of the DC photocurrents was 0.37. This is roughly 3x the ratio of the RF photocurrents at 500kHz (=0.14). This discrepancy is uncomfortably large.

 The full set of measurements is given in the table below:

Measurement Value
DC voltage from Hartmut PD 6.5mV (checked by turning laser on and off and measuring the difference)
DC voltage from 1611 InGaAs PD 2.20V
Transimpedance of Harmut PD at DC 80 Ohm (effective)
Transimpedance of Harmut PD at RF 240 Ohm
Transimpedance of 1611 InGaAs at DC 10 KOhm
Transimpedance of 1611 InGaAs at RF 700 Ohm
Incident Power on Hartmut PD (100% on PD area) 0.28mW (measured by Ophir power meter)
Incident Power on 1611 InGaAs (<100% on PD area) 0.64mW
Responsivity of Silicon PD at 1064nm 0.02 A/W (estimate)
Responsivity of 1611 New Focus PD at 1064nm ~0.8 A/W
   

There is one other troubling point: using the estimate of responsivity on the Harmut PD * incident power * transimpedance at DC = (0.02A/W) * (0.28mW) * (80 V/A) = 0.45 mV.

But the measured DC voltage is 6.5mV = inconsistent.

Attachment 1: PD_measurement.png
PD_measurement.png
Attachment 2: plot_PD_RF_ratios.pdf
plot_PD_RF_ratios.pdf
  4500   Thu Apr 7 16:09:17 2011 AidanSummaryGreen Locking(In)sanity check of Green PD - some inconsistencies

I think I had underestimated the responsivity of the Silicon PD at 1064nm. The previous value was based on a rough search online for the responsivity of Silicon (I couldn't find the product number of the actual PD we are using). For instance, the PDA100A Si detector from Thorlabs has a responsivity of 0.35-0.4A/W at 1064nm. 

If we calculate the responsivity of the Hartmut PD from the measurements I made today (input power = 0.300mW, output voltage = 5.56mV, effective transimpedance = 80 Ohms), then the responsivity at 1064nm is 0.23 A/W which is not an unreasonable number given the response of the Thorlabs detector.

Quote:

Measurement Value
Responsivity of Silicon PD at 1064nm 0.02 A/W (estimate)
Responsivity of 1611 New Focus PD at 1064nm ~0.8 A/W
   

There is one other troubling point: using the estimate of responsivity on the Harmut PD * incident power * transimpedance at DC = (0.02A/W) * (0.28mW) * (80 V/A) = 0.45 mV.

But the measured DC voltage is 6.5mV = inconsistent.

 

  4501   Thu Apr 7 19:28:02 2011 KojiSummaryGreen Locking(In)sanity check of Green PD - some inconsistencies

Responsivity of SGD-444A

Quote:

For instance, the PDA100A Si detector from Thorlabs has a responsivity of 0.35-0.4A/W at 1064nm.

 

Attachment 1: SGD-444A.png
SGD-444A.png
  9854   Fri Apr 25 10:43:57 2014 KojiUpdateLSC(Fixed) Y end whitening board

I went to WB and found the last spare module of D990399 revB. We need to thank Frank for his foresight.

The original (=broken) board had various modifications from this revB.
I had to check the schemaric diagram and the difference between the boards and migrate some of the SMD components from left to right.


Here is the deciphered features of the QPD whitening board:
- The input stage is a VGA amp (AD602). It has the internal input impedance of 100 Ohm. The series resister
  of 909 Ohm gives us 1/10 voltage division! It is more tricky as the QPD (D990272) has the output impedances of 50Ohm
  (for the both side of the differential out) and on resistance of MAX333A. So it could have been deviated by ~10% from the nominal.

- Variable gain control: The input has 1/10 voltage division. The gain is fixed at the unity. In total the gain of the variable control stage is 1/10.
  This gives us the gain range of +42dB/-22dB for +10V/-10V. The actual range is limited to be -10~30dB.

- Whitening stages. Each channel has two sets of the whitening path and the bypass path.
  They could be switched by binary control inputs but I permanently enabled the whitening by pulling the MAX333 control inputs to the ground.
  The whitening zero and pole are at 4.02Hz and 40.6Hz.

  Each bypass path has an additional cap of 220pF in parallel to 35.7kOhm (R101 and R103 for CH1), resulting in the pole at 20.2kHz.
  Each whitening paths had a 5.6nF cap (C53 and C64). This cap was replaced with 350pF, resulting in the move of the pole freq from 800Hz to 12.7kHz.

- There are two anti-aliasing stages which were designed for 2kHz sampling rate. They are identical sallen key 2nd-order LPFs with fc=766Hz and Q=0.74 (~ butterworth).
  As all of these caps were removed, they are just voltage followers now.

- The final stage (AD620) has the gain resister of 16.5k. The gain is 1+(49.4k/16.5k) = 3.99.

- The 4pin lemo connector (J8) was removed from the board. We instead installed an isolated BNC connector on the panel for the thorlabs PD serving as the high gain PD.

- There is a daughter board for the high gain PD. This seems to be the butterworth low pass filter with fc=~30kHz.
  The differential output of the daughter board is connected to pin 17 and 18 of J10 (S5 Out and Rtn).

- The input of the daughter board is differential (AD620). Therefore the LEMO connectros next to the BNC were wrapped with Kapton tapes for isolation.

Board test at the workbench.

- The test required two dual power supply as the unit requires +/-5V and +/-15V.

- The four channels were tested with the signal injection. 1kHz input yielded 20mVpp across the AD602 input. The output of the 1st whitening stage was
  60mVpp. This makes sense as the gain of the AD620 is -10dB (1/10 and 10dB). The output of the 2nd whitening stage was 600mVpp.
  Finally the output of the output stage was confirmed to be 2400mVpp. This was confirmed for four channels.

- The daughter board output was also checked. The gain is the unity and flat upto ~10kHz.

Board installation

- Jenne installed the module. This time there was no smoke.


Gain mystery

- It was not sure how the whitening gains have been given.

- The corresponding database entry was found in /cvs/cds/caltech/target/c1auxey/ETMYaux.db as

grecord(ao,"C1:ASC-QPDY_S1WhiteGain")
grecord(ao,"C1:ASC-QPDY_S2WhiteGain")
grecord(ao,"C1:ASC-QPDY_S3WhiteGain")
grecord(ao,"C1:ASC-QPDY_S4WhiteGain")

- The gains for S2-S4 were set to be 30. However, C1:ASC-QPDY_S1WhiteGain was set to be 8.62068.
And it was not writable.

- After some investigation, it was found that the database was wrong. The DAC channel was changed from S100 to S0.
The corrected entry is shown here.

grecord(ao,"C1:ASC-QPDY_S1WhiteGain")
{
        field(DESC,"Whitening gain for QPDY Seg 1")
        field(DTYP,"VMIVME-4116")
        field(OUT,"#C0 S0 @")
        field(PREC,"1")
        field(EGUF,"42")
        field(EGUL,"-22")
        field(EGU,"dB")
        field(LINR,"LINEAR")
        field(DRVH,"30")
        field(DRVL,"-10")
        field(HOPR,"30")
        field(LOPR,"-10")
}

- Once c1auxey was rebooted, the S1 whitening gain became writable. Now all of the channels were set to be +30dB (max).

 

Attachment 1: D990399-B_40m.pdf
D990399-B_40m.pdf D990399-B_40m.pdf D990399-B_40m.pdf
Attachment 2: P4245552.JPG
P4245552.JPG
Attachment 3: P4245553.JPG
P4245553.JPG
Attachment 4: P4245551.JPG
P4245551.JPG
  10785   Thu Dec 11 18:12:46 2014 ericqUpdateLSC(Fixed) Y end whitening board

Quote:

Gain mystery

- It was not sure how the whitening gains have been given.

- The corresponding database entry was found in /cvs/cds/caltech/target/c1auxey/ETMYaux.db as

grecord(ao,"C1:ASC-QPDY_S1WhiteGain")
grecord(ao,"C1:ASC-QPDY_S2WhiteGain")
grecord(ao,"C1:ASC-QPDY_S3WhiteGain")
grecord(ao,"C1:ASC-QPDY_S4WhiteGain")

- The gains for S2-S4 were set to be 30. However, C1:ASC-QPDY_S1WhiteGain was set to be 8.62068.
And it was not writable.

- After some investigation, it was found that the database was wrong. The DAC channel was changed from S100 to S0.
The corrected entry is shown here.

grecord(ao,"C1:ASC-QPDY_S1WhiteGain")
{
        field(DESC,"Whitening gain for QPDY Seg 1")
        field(DTYP,"VMIVME-4116")
        field(OUT,"#C0 S0 @")
        field(PREC,"1")
        field(EGUF,"42")
        field(EGUL,"-22")
        field(EGU,"dB")
        field(LINR,"LINEAR")
        field(DRVH,"30")
        field(DRVL,"-10")
        field(HOPR,"30")
        field(LOPR,"-10")
}

- Once c1auxey was rebooted, the S1 whitening gain became writable. Now all of the channels were set to be +30dB (max). 

This exact situation was happening at ETMX. I did the exact same change to the database, now I can read and write all four gain segments.

  2065   Wed Oct 7 19:23:49 2009 JenneUpdateAdaptive Filtering(Final?) PEM cabling changes

Quote:

 Here's a plot of the spectra of the seismometers and MCL. The coherence shows which axes are aligned right now: MC1_X is coherent with GUR_NS which means that its mis-oriented.

I've now swapped the "MC1" cables: so the old "NS" now goes into EW and the old EW now goes into NS. VERT is unchanged.

Also fixed the channel names - the Guralp previously named MC1 is now GUR1 and the other one is GUR2. Also no more EW, NS, & VERT. Its all XYZ.

DAQD restarted with the new channel names.

 I spiffed up the order of the cables / sensors plugged into the PEM ADCU.  Now all of the seismometers are labeled as Rana left them, and the 2 Guralp's have their sets of 3 channels next to eachother in channel-number-land.  None of the accelerometer names/cabling have changed recently.  In the table, Cable-label refers to the physical tag tied to the end of the cables plugged into the ADCU...they are meant to be descriptive of what seismometer channels they are hooked up to, and then the names change to something useful for us when they come into the DAQ system.  Also, the labels of input channels on the ASS_TOP_PEM screen have been updated accordingly.

 

Channel Name Channel Number on ADCU and OAF PEM list Cable-label .ini channel number
C1:SEIS-GUR2_X 2 Gur2 EW 15001
C1:SEIS-GUR2_Y 3 Gur2 NS 15002
C1:SEIS-GUR2_Z 4 Gur2 Vert 15003
C1:SEIS-GUR1_X 10 Gur1 EW 15009
C1:SEIS-GUR1_Y 11 Gur1 NS 15010
C1:SEIS-GUR1_Z 12 Gur1 Vert 15011
C1:SEIS-RANGER_Y 24 Ranger

15023

 

  4631   Thu May 5 00:08:59 2011 JenneUpdateLSC(Almost) New Screens for RFPDs

I modified C1LSC.mdl to use the CDSphase blocks, which automatically calculate the R and D phase rotation for us.  Now each of the RFPDs has 2 channels in place of the old IQ_MTRX channels:  C1:LSC-RFPD_PHASE_R and C1:LSC-RFPD_PHASE_D.

I have not yet compiled / rebooted / done CDS magic to actually make these installed.  So far the change is only in the simulink model.

I was going to wait until morning to compile/reboot/magic, so I can do it under Joe's supervision.

In the meantime, I also modified the RFPD screens.  They have white boxes for the _R and _D channels just now, but that's because the new model hasn't been put in.  They now look like phase rotators, instead of Koji's temporary matrix.

Still to do:  Find the EPICS database where the phase rotation calculation is done (you give it an angle, it gives you sin(angle) and cos(angle) ).  I want to put a "90-angle" in the database so that we can type in the measured relative phase between I and Q, and it will calculate how many more degrees it needs to get to 90deg. 

 

  2745   Wed Mar 31 19:29:58 2010 HartmutUpdateElectronics(1cm-) Si PD transfer functions update

Recorded transfer functions for the 1cm Si-PD as described on p. 2708

for different biases. I put the plots in there, to keep the info in one place,

where the label on the PD case (which Steve made without asking him) points

to.

I talked to some people recently about the fact that the responsivity (A/W) of the PD

changes even at DC for different biases. I tested this again and should be more precise about this:

The first time I observed this was in the transfer functions as shown on p. 2708.

With 'DC' I meant 'low frequency' there, as you can still see an effect of the bias as low as 100kHz.

Then at one point I saw the responsivity changing with bias also at true DC.

However, it turned out that this is only the case if the photocurrent is too high.

If the photocurrent is 4mA, you need 400mV bias to get the max. responsivity.

For 2mA photocurrent, the responsivity is already maximal for 0V bias.

An effect for relative low frequencies remains however.

The DC check of responsivity was done with white light from a bulb.

 

 

  9289   Fri Oct 25 04:03:40 2013 MasayukiUpdateLSC'scope and spectrum analyser for REFL165

As Jenne's Elog we want to see Spectrum and time series of REFL 165 (our PRMI LSC locking PD) to see if the signal is saturated while bring the arms into resonance.
I started to connect the spectrum analyser and the 'scope to REFL165 output.

Directional coupler (Mini=-circuits ZMDC-10-2 ZMDC-20-3) was connected just before the dimod boad input. The main output of coupler is plugged into demod board's input.The other output of the coupler is connected to AG4395A using BNC cable.

The spectrum analyser output can be read using netgpibdata in control room. The IP address is 192.168.113.108 and the GPIB address is 17. For this I dissconected the network hub from another AG4395A, which is at the front of 1X2 lack.

I didn't connected the 300 MHz 'scope right now, but tomorrow it will be connected using power splitter and also be able to get data by internet. For connect 'scope to network, I disconected the network hub from SR785.

  9295   Fri Oct 25 21:36:51 2013 MasayukiUpdateLSC'scope and spectrum analyser for REFL165

Quote:

As Jenne's Elog we want to see Spectrum and time series of REFL 165 (our PRMI LSC locking PD) to see if the signal is saturated while bring the arms into resonance.
I started to connect the spectrum analyser and the 'scope to REFL165 output.

Directional coupler (Mini=-circuits ZMDC-10-2 ZMDC-20-3) was connected just before the dimod boad input. The main output of coupler is plugged into demod board's input.The other output of the coupler is connected to AG4395A using BNC cable.

The spectrum analyser output can be read using netgpibdata in control room. The IP address is 192.168.113.108 and the GPIB address is 17. For this I dissconected the network hub from another AG4395A, which is at the front of 1X2 lack.

I didn't connected the 300 MHz 'scope right now, but tomorrow it will be connected using power splitter and also be able to get data by internet. For connect 'scope to network, I disconected the network hub from SR785.

[Jenne, Masayuki]

We changed the Directional coupler from ZMDC-20-3 to ZMDC-20-5-S+ because that coupler seemed to introduce some high frequency noise.

  9304   Mon Oct 28 14:24:01 2013 MasayukiUpdateLSC'scope and spectrum analyser for REFL165

 

 I connected the 'scope between REFL165 output and demod board input. I split the signal from coupler using the splitter (Mini-Circuits ZFSC-2-5). One signal is going to 'scope CH1 and the other is going to spectrum analyzer. I connected the 'scope to 40MARS. The IP adress is 192.168.113.25. I connected that by cabling from 1X2.

 

  4642   Thu May 5 15:26:52 2011 Leo SingerConfigurationComputers'glue' installed on some control room computers

I installed 'glue' on Rossa, Allegra, and Rosalba.  This is a Python module that includes a facility for LIGO_LW XML files.  Oddly, I couldn't find the glue package on Pianosa.

  8011   Wed Feb 6 15:11:21 2013 JenneUpdateElectronics"Temporary" power supply situation

[Jenne, Yuta, Rana, Steve, Manasa]

We have taken stock of the lab "temporary" power supply situation, and things look much better.

This morning, I removed 2 unused power supplies and a function generator from the PSL table - these had been used for MC ringdown things.

I also removed the non-connected cables that had been used for the RAMMON setup, and the EOM temperature controller circuit.

This afternoon, Yuta removed the 2 HV power supplies that were used to keep PZT2 working near the end of its life.  Since we now have the active TTs, these have been turned off for a while, and just needed to be removed.

Manasa removed the power supply under the POP/POX table that was powering the amplifier for POP22.  If we are going to continue using a Thorlabs PD for POP22, then we need to make a twisted pair of wires (~20 feet) to get power from 1X1.  If we are going to (finally) install a gold RF PD, then that will not be necessary.

I removed the power supply sitting near the bottom of the LSC rack, for another amplifier for POP22 (with minicircuits filters attached).  Again, if we get a gold RF PD, we can remove the filters and amplifier.  If not, we can use the existing twisted pair of wires, and plug them into the rack rather than a power supply. 

The power supply under the NE corner of the PSL table was no longer in use.  It was most recently used for amplifiers for the green beat PDs, as Yuta mentioned in elog 6862, those were moved over to 1X2.  In elog 8008 I mentioned that Yuta and I moved those amplifiers over to rack power.

The HV supply, the function generator and the OSA controllers that were on top of the short OMC rack next to the AS table have all been removed.  We need to come up with a better place for the OSAs, since we need to re-install them.  The power supply and the function generator (which was used just for a voltage offset) were formerly used for the output steering PZTs, but lately we have just been using those mirrors as fixed mirrors, since we don't need to steer into the OMC.  Some day, we will replace those mirrors with the output steering active tip tilts, and re-commission the OMC....someday.

The power supply for the amplifier set (that goes with the set of minicircuits filters) for the RAMMON PD (which took light from the IPPOS path) has been removed.  If we determine that we need RAMMON back, we will have to make a twisted pair to power those amplifiers.

SUMMARY:

* If we don't install a gold RF PD for POP22, we need a 20ft twisted pair for +15/GND.

* Also, if we don't install a gold RF PD for POP22, we need to plug the amplifier at the LSC rack into the rack power (twisted pair already exists).

* If we need RAMMON back, we will need a twisted pair to power those amplifiers.

* All other power supplies have been removed, and put away.  We currently have 0 "temporary" power supplies in use in the lab!

  1015   Wed Oct 1 12:05:58 2008 AlbertoConfigurationComputers"StochMon" added to the Alarm Handler
John, Alberto,

we added the four channels of the RF Amplitude Monitor (aka StochMon) to the Alarm HAndler. First we modified the 40m.alh file just copying some lines and switching the name of the channels to the ones we wanted. Than we also added a few lines to the database file ioo.db in order to define the alrm levels. So far I used just test values for the thresholds of green, yellow and red states and need to update to some reasonable ones. To do that I need to calibrate those EPICS channels. I have the old data saved and I'm now trying to figure out how to properly change the database file.
  1016   Wed Oct 1 12:09:25 2008 AlbertoConfigurationComputers"StochMon" added to the Alarm Handler

Quote:
John, Alberto,

we added the four channels of the RF Amplitude Monitor (aka StochMon) to the Alarm HAndler. So far I used just test values for the thresholds of green, yellow and red states and need to update to some reasonable ones. To do that I need to calibrate those EPICS channels. I have the old data saved and I'm now trying to figure out how to properly change the database file.


John, Yoichi, Alberto

We restarted the C1iool0 computer both directly by the main key and remotely via telnet. We had to do it a couple of times and in one occasion the computer didn't restart properly and had connection problem with the newtowrk. We had to call Alex that did just the same thing, but used the CTRL+X command to reboot. It worked and the Alarm Handler now includes the StochMon.
  8202   Thu Feb 28 14:51:43 2013 JenneUpdatePEM"Rock Monster" causing low frequency noise

Manasa and I have been wondering why the low frequency seismic noise has been different in the last few days/weeks.  I went over to visit the Rock Monster, a.k.a. the Earth Surface Dynamics Laboratory next door, and the grad student turned it up for me (increased water flow significantly) for a few minutes.  Then I came back to look at the BLRMS, and you can see the low frequency increase a few minutes ago, when he turned it up on high.  He said that they run it on low almost all the time, 9am-5pm ish, and on high for an hour or so at a time periodically during the day.

RockMonsterOn_ForFewMinutes.png

  412   Thu Apr 3 18:46:04 2008 AndreyConfigurationComputers"Network switch board" and "c1pem1 crate" were touched

While working with the weather station, I did two things that potentially (with a very small probability) might influence the smooth work of other processors/computers.
I did the following on Wednesday, April 2nd, in times between 1PM and 3PM.

(1) I turned off for several seconds and returned into the initial position the switch-key on the rack with computer (processor) 'c1pem1' in order to reboot processor 'c1pem1'. The turning off/on of that key-switch was repeated several times.

(2) I pulled gently the whole "Network-Switch Board" towards me in order to replace an ethernet cat 5 cable going into the board form the processor 'c1pem1'. Some other connections of other ethernet cables might be flimsy, and then other people in 40-meter might have problems with computers other than 'c1pem1'. It should not happen, but in case of extraordinary behaviour of any other computer in our lab, people should check the connectors on the network-switch board. It is located near the middle of Y-arm. See picture.
Attachment 1: Computer_Rack.JPG
Computer_Rack.JPG
  5779   Tue Nov 1 19:26:38 2011 ZachUpdateSUS"Dr. SUS" progress

EDIT: Ran Jamie's NDS2 reset method and it's still not serving up MC data.

I am debugging the SUS input matrix diagonalization code (which I have affectionately termed "Dr. SUS") offline by running everything except the actual writing of the matrices (%writeSUSinmat()) in a sandbox directory. Some notes:

  • nodus doesn't know NDS2, but this isn't a problem given Kiwamu's reply, since we don't want to push results to the elog. I will still have the script push "optics kicked---don't touch" alerts to the elog, but I realized this can be done easily from a remote computer via in-script SSH commands. My next choice was pianosa, but even though she knows NDS2, she spits out MEX errors when I try to get data. Third stop was allegra, and she plays nice 
  • NDS2 is unable to read the MC mirror sensor data. Data from all other optics are retrieved without a problem. I verified that raw data was being written by plotting playback data in dataviewer, and I tried various times and the problem persisted. I suspect the problem is on the NDS2 server side:

The most recent entry in .../users/jzweizig/nds2-mafalda/channel_history shows nothing for MC1 2 or 3

 

mafalda:channel_history>more C-R-999986048-178368.cls | grep SENSOR
C1:SUS-BS_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-BS_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-BS_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-BS_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-BS_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-ETMX_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-ETMX_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-ETMX_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-ETMX_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-ETMX_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-ETMY_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-ETMY_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-ETMY_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-ETMY_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-ETMY_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-ITMX_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-ITMX_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-ITMX_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-ITMX_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-ITMX_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-ITMY_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-ITMY_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-ITMY_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-ITMY_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-ITMY_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-PRM_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-PRM_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-PRM_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-PRM_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-PRM_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-SRM_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-SRM_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-SRM_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-SRM_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-SRM_SENSOR_UR raw 0 real_4 2048 C-R

 

  5781   Wed Nov 2 01:53:08 2011 ZachUpdateSUS"Dr. SUS" progress

Now that NDS2 is working, I was able to run all parts of diagAllSUS (except for the matrix writing) without errors. Barring issues with standard commands (freeswing, turnOnWatchDogs.csh, caput, etc.), Dr. SUS should be ready to go.

As requested, I have suppressed the generation of an elog post containing the results of the diagonalization.

Dr. SUS will run on allegra as a cron job at 8:00am on Sundays:

 

 

allegra:peakFit>crontab -l

 

PATH=/bin/:/usr/bin/:/cvs/cds/caltech/apps/linux64/matlab/bin/:/cvs/cds/caltech/apps/linux/gds/bin/:/cvs/cds/caltech/apps/linux/tds/bin/

 

PWD=/cvs/cds/caltech/apps/linux/gds/lib/

 

LD_LIBRARY_PATH=/cvs/cds/caltech/apps/linux/gds/lib

 

01 05 * * 0 cat /cvs/cds/caltech/users/kiwamu/work/20091026_OMC-LSC-diag/src/OMC_LSC_timing.m | matlab -nosplash -nodesktop > /dev/null

0 8 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/runDrSUS

Also: should these variable definitions really be here?

 

 

  5784   Wed Nov 2 11:29:04 2011 not ZachUpdateSUS"Dr. SUS" progress

Quote:

Now that NDS2 is working, I was able to run all parts of diagAllSUS (except for the matrix writing) without errors. Barring issues with standard commands (freeswing, turnOnWatchDogs.csh, caput, etc.), Dr. SUS should be ready to go.

As requested, I have suppressed the generation of an elog post containing the results of the diagonalization.

Dr. SUS will run on allegra as a cron job at 8:00am on Sundays:

allegra:peakFit>crontab -l

PATH=/bin/:/usr/bin/:/cvs/cds/caltech/apps/linux64/matlab/bin/:/cvs/cds/caltech/apps/linux/gds/bin/:/cvs/cds/caltech/apps/linux/tds/bin/

PWD=/cvs/cds/caltech/apps/linux/gds/lib/

LD_LIBRARY_PATH=/cvs/cds/caltech/apps/linux/gds/lib

01 05 * * 0 cat /cvs/cds/caltech/users/kiwamu/work/20091026_OMC-LSC-diag/src/OMC_LSC_timing.m | matlab -nosplash -nodesktop > /dev/null

 

0 8 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/runDrSUS

Also: should these variable definitions really be here? 

Cron starts with only a very minimal PATH.  However, this shouldn't be an issue if you specify the full path to the commands.

The rest of the env vars should probably not be there.

Also, Zach:  using /cvs/cds is now forbidden.  We need to put this script in the right place.

  8370   Thu Mar 28 23:06:48 2013 AnnalisaUpdateAuxiliary locking"Alberto" NPRO laser again on PSL table

 "Alberto"NPRO laser has been moved again on PSL table in order to make a measurement of the beat note varying also the PSL temperature.

It is useful because if the PSL temperature would drift  we have to know which is the NPRO temperature that returns the beat.

I'm going to measure it tomorrow.

 

 

  4765   Wed May 25 19:19:11 2011 JamieConfigurationCDS!!!CHECK IN YOUR MODELS!!!

!!!CHECK IN MODEL CHANGES!!!

Today I found three models that were modified, but not checked in to the SVN repository:

M       sus/c1/models/lib/sus_single.mdl
M       isc/c1/models/c1lsc.mdl
M       isc/c1/models/c1mcp.mdl

I checked in the c1lsc model, since I think it was just the change that Kiwamu made in http://nodus.ligo.caltech.edu:8080/40m/4749.  I left the others, since I have no idea what they are or who made them.

Please please please remember to commit your model changes to the SVN after you're done.  This is particularly important for important models, such as c1lsc.  If you don't check in your changes I can pretty much guarantee that at some point you will loose them.

 

  4668   Mon May 9 16:58:23 2011 JamieBureaucracyCDS!!!!REMEMBER TO COMMIT YOUR MODIFICATIONS!!!!

Whenever you modify any of the front-end code in /opt/rtds/caltech/c1/userapps, such as models, scripts or medm screens, REMEMBER TO COMMIT YOUR CHANGES, WITH A LOG MESSAGE!!!

cd /opt/rtcds/caltech/c1/userapps/trunk
svn commit path/to/modified/file

If you forget to commit things, they may be purged and you will loose your work.  ALWAYS COMMIT!

Things to note and watch out for:

  • When you commit, make sure you specify explicitly the path to the file that you are committing.  This repository is shared by all LIGO sites, including the sites (LHO and LLO) so you really want to make sure you're not committing anything that affects anything other than "c1" (ie. the 40m)
  • Only commit one file at a time, unless the changes to multiple files are tightly coupled.
  • Never commit without specifying the path to the file that you are committing.  Other people may be working on other files in the repository, and you don't want to commit their work with yours.
  • YOU MUST LEAVE A LOG MESSAGE.  Your log message should be specific to the file you have modified, and should be clear and verbose to explain exactly what you have done.
  • Use the "svn status" command to give you an overview of what is going on in the working directory.  This will tell you which files have been modified.  See "svn help status" for more information.

If you have questions ASK.  Don't force things.

  4669   Mon May 9 17:21:13 2011 JamieBureaucracyCDS!!!!REMEMBER TO COMMIT YOUR MODIFICATIONS!!!!

Also, remember to update the svn working copy before you begin doing any work, to make sure you're working on the most recent version:

cd /opt/rtcds/caltech/c1/userapps/trunk
svn update
  1363   Fri Mar 6 01:04:49 2009 Kiwamu IZUMIConfigurationIOO!! lock-in amp disconnected !!

The power supply of a lock-in amp, which is on the Y-arm side of PSL clean room, was pulled out by my mistake.

Then I reconnected it, but I don't know whether it is re-adjusted properly.

I'm sorry about this. If you are using that amp, it should be checked.

  12144   Wed Jun 1 15:01:56 2016 SteveUpdateSUS wire standoffs update

There are some issues with 5 mm sapphire prism Atm5. It will cause  interference between one of the prisms and the Side OSEM.

Here are some drawings to see the issues with larger wire standoff.

The 2 mm prism will work.with a 1 mm longer dumbell.

Quotes requested from http://photomachining.com/laser-micromachining-photomachining-contact.html and http://www.optocity.com/ 

 

 

Attachment 1: 06011603.PDF
06011603.PDF
Attachment 2: 06011602.PDF
06011602.PDF
Attachment 3: sapphire_stand_off_v2.pdf
sapphire_stand_off_v2.pdf
Attachment 4: side_OSEM_ETMY.jpg
side_OSEM_ETMY.jpg
Attachment 5: 5p2wsf.png
5p2wsf.png
  12146   Thu Jun 2 16:35:44 2016 KojiUpdateSUS wire standoffs update

Gap of the prism from the mirror

Sag: s = R(1-Cos[ArcSin[d/2/R]])

- Mirror curvature sag for 2mm prism (R=37.75mm): s=13um

- Minimum gap: 20um => s=33um => R=15mm

- Nominal gap: 35um => s=48um => R=10mm

- Maximum gap: 50um => s=63um => R=8mm


The second figure shows somewhat realistic arrangement of the pieces

Attachment 1: sapphire_stand_off_v3.pdf
sapphire_stand_off_v3.pdf
Attachment 2: arrangement-v3.pdf
arrangement-v3.pdf
  12454   Tue Aug 30 15:44:28 2016 SteveUpdateSUS wire standoffs update

100 Sapphire prisms ordered. Delivery date 9-30-2016

~60 deg. prisms,

Size A=B=C=2 mm, length 5 mm

Material: sapphire

Surface quality: 5 micron RMS

Tolerances: +- 0.1 mm

This prism will be used as a mechanical component

No crystal orientation required

 

Quote:

There are some issues with 5 mm sapphire prism Atm5. It will cause  interference between one of the prisms and the Side OSEM.

Here are some drawings to see the issues with larger wire standoff.

The 2 mm prism will work.with a 1 mm longer dumbell.

Quotes requested from http://photomachining.com/laser-micromachining-photomachining-contact.html and http://www.optocity.com/ 

 

 

 

  12550   Tue Oct 11 10:38:51 2016 SteveUpdateSUS wire standoffs update

100 Sapphire prizms arrived.

 

Attachment 1: A028_-_20161010_170319.jpg
A028_-_20161010_170319.jpg
Attachment 2: A027_-_20161010_170202.jpg
A027_-_20161010_170202.jpg
  12760   Fri Jan 27 14:50:04 2017 SteveUpdateSUS wire standoffs update

The 3 pieces of Sapphire v-groove test cuts are back. They look good. The suspension wire 0.0017" ( 43 micron ) is show on some of the pictures.

  12761   Fri Jan 27 15:36:17 2017 KojiUpdateSUS wire standoffs update

Very nice! I got excited.

  • Don't you ask Calum and co to check the groove size with their microscopes? Just give the samples and the wire.
  • Do we want to make a simple "guitar" setup to measure the vibration Qs with Al piece, glass prism, ungrooved Sapphire, this grooved sapphire, grooved ruby, etc?
  12846   Thu Feb 23 09:32:20 2017 KojiUpdateSUS wire standoffs update

Kyle took high quality images of  the three sapphire prisms using the microscope @Downs. He analyzed the images to see the radius of the groove.

They all look sufficiently sharp for a 46um steel wire. Thumbs up.
I am curious to see how the wire Q is with grooved sapphires, ungrooved sapphires, grooved ruby, grooved aluminum stand off, and so on.

Attachment 1: Sapphire_prism_1(A015).png
Sapphire_prism_1(A015).png
Attachment 2: Sapphire_prism_2(A016).png
Sapphire_prism_2(A016).png
Attachment 3: Sapphire_prism_3(A014).png
Sapphire_prism_3(A014).png
  13030   Thu Jun 1 16:21:55 2017 SteveUpdateSUS wire standoffs update

Ruby wire standoff received from China. I looked one of them with our small USB camera.  They did a good job. The  long edges of the prism are chipped.

The v-groove cutter must avoid them. Pictures will follow.

 

  12346   Thu Jul 28 08:42:36 2016 SteveUpdateSUS wire clamp

The clamp is in the machine for milling off the grooves. It's condition is normal. The edges needs some 800 sand paper so it is not sharp anywhere.

How did those nicks get on the edge? Fortunatelly they did not aligned with the wire.

 

Attachment 1: e12342.jpg
e12342.jpg
  10076   Thu Jun 19 17:28:19 2014 SteveUpdatePSL window device is ready for test

The window is at the north west corner of the  PSL enclosure.

The 1 mm thick BK7 window is AR coated both side R <0.08%,  W2-PW1-1004-1064-0

The PZT stack is 0.75" OD, 0.25" thick with  ~ 6 mm ID,  motion range 2.5 micron at 200V

Soft silicon rubber isolation.

 

RXA: This is the opto-mechanical phase shifter that Steve has built for diagnosing scattered light problems. We put it into the reflected light path of any of the cavities and see if it can move the scattering noise from DC up to a higher frequency. e.g.:

The paper on this from GEO

Attachment 1: softW2.jpg
softW2.jpg
Attachment 2: softW2b.jpg
softW2b.jpg
  9443   Thu Dec 5 11:06:43 2013 SteveUpdateCameras viewport video ccd cameras are all covered

Quote:

Quote:

Can't we somehow hook up this camera to the MUX with the movie mode?
I think both the MUX and the sensoray are compatible with the color video signal.
Only the old CRT is B/W.

 Watek 902H ccd with Tamron M118FM50 lens is hooked up to MUX  Please be careful! In this set up the lens is close to the view port glass window! 

 PRM-BS & Faraday video ccd  cameras  covered as shown. These thin wall metalized ducts are perfect for blocking light in both direction.

They are very light and give you easy access to adjustment.

Attachment 1: PRMcamera.jpg
PRMcamera.jpg
Attachment 2: PRMcameraCover.jpg
PRMcameraCover.jpg
Attachment 3: FaradayCameraCover.jpg
FaradayCameraCover.jpg
  1459   Wed Apr 8 09:36:20 2009 steveConfigurationVAC valve condition changed to BG to calibrate the RGA

Vacuum normal valve condition was changed to accommodate SRS-RGA calibration.

 

The annulus valves were closed to free TP3 to pump on the RGA
VM1 was closed to isolate the RGA from the IFO.
 
 
VM3 opened to TP3.
 
This condition is called back ground (BG) mode. It is where we can calibrate and see the RGA background without the IFO.
  14028   Thu Jun 28 08:09:51 2018 SteveUpdateCDS vacuum pneumatic N2 pressure

The fardest I can go back on channel C1: Vac_N2pres is  320 days

C1:Vac-CC1_Hornet Presuure gauge started logging Feb. 23, 2018

Did you update the " low N2 message"  email addresses?

 

Quote:

I moved the N2 check script and the disk usage checking script from the (sudo) crontab of nodus no to the controls user crontab on megatron yes.

 

Attachment 1: 320d_N2.png
320d_N2.png
  14029   Thu Jun 28 10:28:27 2018 ranaUpdateCDS vacuum pneumatic N2 pressure

we disabled logging the N2 Pressure to a text file, since it was filling up disk space. Now it just sends an email to our 40m mailing list, so we'll all get a warning.

The crontab uses the 'bash' version of output redirection '2>&1', which redirects stdout and stderr, but probably we just want stderr, since stdout contains messages without issues and will just fill up again.

  11695   Fri Oct 16 18:27:52 2015 SteveUpdateVAC vacuum normal condition

Vacuum normal configuration with VM1-closed, VM2-open valve positions. Power load normal 24V 0.2A

Maglev rotation 560 Hz at room temp body temp.

"NO COMM" error message on medm screen. Gauge controller pressures are read able.

All vac comp LEDs are green. We have to reboot on Monday to enable communication.

 

Attachment 1: oct16Fpm2015.png
oct16Fpm2015.png
  9514   Thu Jan 2 10:50:24 2014 SteveUpdateVAC vacuum monitor is still blank

 The date is correct on this monitor.

Last stored RGA scan data Dec 20, 2013

IFO pressure at CC1 5.8e-6 Torr

Valve configuration: Vacuum Normal, confirmable only by manual checking of position indicators and pressure gauge controllers  readouts

 

Attachment 1: Help.png
Help.png
Attachment 2: vacation.png
vacation.png
Attachment 3: 20131220lastRGAscan.png
20131220lastRGAscan.png
  9515   Thu Jan 2 13:35:06 2014 KojiUpdateVAC vacuum monitor is still blank

We probably need to restart the machine, but I didn't want to touch c1vac1 and c1vac2. 

  9581   Tue Jan 28 11:13:50 2014 KojiUpdateVAC vacuum monitor is still blank

[Steve Koji]

We pushed the reset button of c1vac1 and c1vac2 and the vacuum screen is back.

First, we pushed the reset button of c1vac1 and pushed the one on c1vac2.
This did not bring c1vac2 up. We pushed the reset of c1vac2 again and now everything of the vacuum screen is back.

  12209   Tue Jun 21 14:12:10 2016 SteveUpdatePEM vacuum envelope wiped

I wiped down the cranes with wet towel and Mario our janitor did the chamber tops with the tubes.

The optical tabels were not touched.

The outside temp peaked at 44 C yesterday

 

Attachment 1: 60dPEM.png
60dPEM.png
  9582   Tue Jan 28 16:26:40 2014 SteveUpdateVAC vacuum computers are back without safety

Quote:

[Steve Koji]

We pushed the reset button of c1vac1 and c1vac2 and the vacuum screen is back.

First, we pushed the reset button of c1vac1 and pushed the one on c1vac2.
This did not bring c1vac2 up. We pushed the reset of c1vac2 again and now everything of the vacuum screen is back.

 1, Reset works

 2, Default values are lost. They actually reversed into open and turn on everything when power recycle c1vac1, c1vac2 or 24V dc power supply. This can vent the IFO in an event of power failure!

      It's may be the time to go back to an isolated, vacuum controller only computer.

 

The present valve configuration at Atm1

a, all annuloses are vented

b, valve cables disconnected at: VC1 and 4 IP gate valves

c, the RGA is off and it is pumped by the Maglev through VM2

d, cryo pump is being roughed with TP3  It's outgassing rate was 25 mTorr / min

e, Roughing hose is disconnected

Attachment 1: c1vac1_vac2areback.png
c1vac1_vac2areback.png
  9599   Wed Feb 5 08:14:59 2014 SteveUpdateVAC vacuum computers are back without safety

Quote:

 

 1, Reset works

 2, Default values are lost. They actually reversed into open and turn on everything when power recycle c1vac1, c1vac2 or 24V dc power supply. This can vent the IFO in an event of power failure!

      It's may be the time to go back to an isolated, vacuum controller only computer.

 

The present valve configuration at Atm1

a, all annuloses are vented

b, valve cables disconnected at: VC1 and 4 IP gate valves

c, the RGA is off and it is pumped by the Maglev through VM2

d, cryo pump is being roughed with TP3  It's outgassing rate was 25 mTorr / min

e, Roughing hose is disconnected

 Vacuum checks before pump down:

1, check intermittent contact issue in black relay box

2, reconnect cable to ion pumps and vent them to atm before pump down

3, repeat power shutdown-reboot at atmosphere

  8356   Tue Mar 26 16:36:24 2013 SteveUpdate40m Upgrading table leveling mounts go here

Quote:

Steve's suggestion for how to level the end table using "swivel leveling mounts":

end-tabel-leveling.png

 

1, level table with 4 swivels, lock nuts  3/16 -vertical alignment    2, lock this position with 4 x 1/4-20 (these are in place already) to hold table in horizontal direction

   Adjustable mount is here to compensate for bad tilting  floor <http://www.mcmaster.com/#6111K52>  

      See grouting plans of the past   http://nodus.ligo.caltech.edu:8080/40m/7248

Attachment 1: optabSTAND.PDF
optabSTAND.PDF
Attachment 2: swivvelMountEE.jpg
swivvelMountEE.jpg
  8372   Fri Mar 29 16:30:27 2013 SteveUpdate40m Upgrading table leveling mounts go here

Quote:

Quote:

Steve's suggestion for how to level the end table using "swivel leveling mounts":

end-tabel-leveling.png

 

1, level table with 4 swivels, lock nuts  3/16 -vertical alignment    2, lock this position with 4 x 1/4-20 (these are in place already) to hold table in horizontal direction

   Adjustable mount is here to compensate for bad tilting  floor <http://www.mcmaster.com/#6111K52>  

      See grouting plans of the past   http://nodus.ligo.caltech.edu:8080/40m/7248

 

  9257   Tue Oct 22 10:12:33 2013 SteveUpdatePEM south arm AC intake duct checked

  The 4th week of no wet mopping of the floor  and no wet wiping  the vacuum envelope.

 

We cleaned the intakes of the south arm IFO air condition. The bottom duct have quite a bit accumulation Atm1

See wet wiped contrast on Atm2

We found 3 holes around pipes ( coming from CES ) on the east wall that has to be sealed.

After closer examination of these holes, they are sealed off well.

Attachment 1: PEM0.5micron60d.png
PEM0.5micron60d.png
Attachment 2: southArmIntakeNorth.jpg
southArmIntakeNorth.jpg
Attachment 3: SouthArmMidIntakeWipe.jpg
SouthArmMidIntakeWipe.jpg
  2701   Tue Mar 23 10:11:13 2010 steveUpdatePEM small air cond unit failed yesterday

Old control room air condition failed yesterday around noon. It was blowing 80-85F hot air for about 2-3 hours at racks 1Y4-7 and the entry room 103

Attachment 1: 20datm.jpg
20datm.jpg
ELOG V3.1.3-