40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  PSL, Page 36 of 52  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  746   Sat Dec 3 01:12:00 2011 taraNotesopticV-block for faraday isolator

     I replaced the isolator mount with the V block I drew. The height is a bit to high. I'll send it back to the machine shop to reduce the height.

 

  211   Tue Jul 13 11:35:12 2010 MeganSummaryVCOVCO Frequency Response

We measured the frequency response of the VCO and fit it with a linear curve to give an idea of the frequency response around 80MHz. This shows that the general trend is not linear, but can be approximated within 1V applied to the VCO.

Attachment 1: VCOFreqResponse.png
VCOFreqResponse.png
  258   Fri Aug 6 11:51:47 2010 MeganDailyProgress VCO Measurements

Yesterday we set up channels to record the noise of the locked signal generators. After a while playing with channels and filters and everything, the results are that the missing factor might be somewhere in the calibration of the data in 40m because this data fits where we would expect it to, slightly above the electronic noise converted to phase noise at low frequencies and much higher at high frequencies.

I tried to check the calibration in 40m this morning, but Jenna had the rubidium clocks hooked up and was collecting data with that, but I might be able to go back this afternoon and get something to see if it's in the calibration of rad/count.

Attachment 1: NoiseComparison.png
NoiseComparison.png
  249   Mon Aug 2 12:16:04 2010 MeganNotes VCO Model on SVN

The model I made of the VCO is now on the svn, in the filter folder in liso, listed as VCODriverNoise.fil

  207   Sun Jul 11 00:52:14 2010 MeganSummaryVCOVCO Noise

I graphed the VCO phase noise with the previously measured data - the data I have seems to be a bit higher. I also converted the phase noise into frequency noise for both VCOs and the previous measurement. Just for reference, "VCO 1" is the one that we were measuring the noise of the different parts of the VCO and that has its lid off.  "VCO 2" is the one we brought over from the PSL lab that is currently still in one piece.

Attachment 1: PhaseNoisePreviousMeasure.png
PhaseNoisePreviousMeasure.png
Attachment 2: FrequencyNoisePreviousMeasure.png
FrequencyNoisePreviousMeasure.png
  223   Thu Jul 15 18:18:49 2010 MeganDailyProgressVCOVCO Noise Update

I re-measured the noise at TP7 using the Busby Low Noise Box and measured the instrument noise of the box - the noise is lower at high frequencies, but much higher at low frequencies. There is a possibility some of this came from old batteries - they measured 7.4 V, but we were 2 short in 40m so I couldn't replace them. I will try to get new batteries tomorrow and see if that affects it at all.

I also changed the couple of things that were wrong with the model and have the revised model as well as its resultant graph attached.

I subtracted the noise of the other amplifier from the previous measurement of the noise at TP7 and compared it with the new model and they line up almost perfectly except around 10 Hz, where they're a little off.

Attachment 1: BusbyNoise.png
BusbyNoise.png
Attachment 2: CorrectModelMeasured.png
CorrectModelMeasured.png
Attachment 3: NoiseAll.fil
# All noise
  # Naming convention due to repeat pin numbers
    # All points not at a test point labelled with n number of the next test pin _ pin number ie n6_3
    # All test points labelled by TP(number) ie TP4
    # All points with no pin number labelled with preceding pin number, following pin number ie n7_26 (between 2 and 6)

# Wide SW to amplifier

  # Up to TP6

... 82 more lines ...
Attachment 4: CompleteModel.png
CompleteModel.png
  224   Thu Jul 15 19:04:45 2010 FrankDailyProgressVCOVCO Noise Update

looks quite good.

You can take the two new batteries out of the FET preamp box if you can't find more (the ones we replaced last week).

i had a quick look onto your new data. If you subtract the busby box noise floor from the new data you are almost there...

Quote:

I re-measured the noise at TP7 using the Busby Low Noise Box and measured the instrument noise of the box - the noise is lower at high frequencies, but much higher at low frequencies. There is a possibility some of this came from old batteries - they measured 7.4 V, but we were 2 short in 40m so I couldn't replace them. I will try to get new batteries tomorrow and see if that affects it at all.

I also changed the couple of things that were wrong with the model and have the revised model as well as its resultant graph attached.

I subtracted the noise of the other amplifier from the previous measurement of the noise at TP7 and compared it with the new model and they line up almost perfectly except around 10 Hz, where they're a little off.

 

  195   Thu Jul 1 13:49:58 2010 MeganNotesVCOVCO Output Amplitude Depending on Modlevel Input

I measured the output amplitude of the VCO with different Modlevel voltage inputs (from 0 V to 5 V) by measuring the RMS voltage on the oscilloscope. While I was varying the voltage input, I discovered the sine wave is very distorted between roughly 0.8 V and 3.5 V of modlevel input. Extra peaks started appearing that disappeared or became less prominent when below or above that range. The graphs show the output of the VCO in dBm and voltage (input impedance of 50 Ohms), accounting for the 19 dBm attenuation added to the output of the VCO.

I also started measuring the phase noise of the complete, unmodified VCO so we have a reference for the noise of the modified version when we are done with that. It is all set up right now and I should be able to start recording data on the computer soon. After we have a reference of the noise of the unmodified VCO, we will modify the VCO and see how it affects the noise level - hopefully it drops.

Attachment 1: Output_vs_Modlevel_Voltage.png
Output_vs_Modlevel_Voltage.png
  198   Wed Jul 7 10:44:39 2010 MeganSummaryVCOVCO Output vs Input

I redid one of the graphs for the output of the VCO vs the input voltage to make sure I didn't miscalculate. I got the same graph when accounting for the 19dBm attenuation at the output of the VCO. I also made a graph of the output RMS voltage ignoring the attenuation - the total output ranged from 13mV to 918mV, while the voltage added by taking the attenuation into account is 1.9929V.

I used the equation N dBm = 10*log(Vrms2/50/0.001) to solve for the voltage associated with 19 dBm.

Attachment 1: VCOOutputvsInput.png
VCOOutputvsInput.png
  214   Wed Jul 14 19:07:17 2010 MeganDailyProgressVCOVCO Update

I replace R3 and R7 with thin film resistors (according to LISO they have the greatest contribution of the resistors at lower frequencies) and re-measured the electronic noise of the driver. It was almost identical to the noise I previously measured, and so for now am not going to replace the other resistors because it does not seem to have a large effect.

I have been playing around with the LISO model more and will hopefully have an easy-to-use version to upload soon. I'm going to work with more of the data that I have to see what it tells us and will post various graphs tomorrow.

  89   Thu Mar 11 22:45:58 2010 Tara ChalermsongsakLaserRC noiseVCO f noise

I measured the VCO noise again.  2 methods that I tried

1) Measuring noise from a) suppressed signal (signal from pre-amp which is fed back to IFR2023) and b) error signal ((beat signal coming out of the mixer)) and match them together

Setup for 1)

ifr2023b,  carrier f = 79.994620 Hz, power =    7.0 dBm,     FMdevn = 500kHz

mixer     Mini Circuit ZFM-3-S+   (Lo input = 7dBm, RF input = -1.05 dBm)

pre amp, SR560, Gain inv10, low pass at 1Hz

 

2) Lowering the unity gain frequency and measuring only the error signal (beat signal coming out of the mixer)

Setup for 2)

ifr2023b,  carrier f = 79.995 316 Hz, power =    7.0 dBm,     FMdevn = 1kHz

mixer     Mini Circuit ZFM-3-S+   (Lo input = 7dBm, RF input = -1.05 dBm)

pre amp, SR560, Gain inv20, low pass at 0.03Hz

 

Converting V/rHz to f/ rHz

1)The feed back signal can be convert to freq noise by using the calibration from last week, which is 0.35 MHz/V, since two setups on IFR2023 are similar.

We can obtain the calibration by giving input voltage to the LO and see how the carrier freq changes.

 

2) For the  error signal out of the mixer, disconnect the feedback signal and measure the slope of the signal output. That will be [V/rad] calibration.

Then we can convert V/rHz -> rad / rHz , multiply by the corresponding f to get f/rHz

 Red and Green plot are from the 1st method,

Blue plot if from the 2nd method.

The results between two methods are not even close to each other, I'll check tomorrow to see if I did something wrong,

Attachment 1: VCO_noise.png
VCO_noise.png
  462   Tue Feb 1 20:47:14 2011 FrankNotesDAQVCO feedback signal now recording

added the VCO feedback signal to the FB. We had it connected but not written into the frames so far

Channel name is C3:PSL-ACAV_VCOMON

  662   Mon Aug 29 22:41:54 2011 taaDailyProgressVCOVCO for RCAV loop

I prepared the VCO for RCAV loop. The signal output is quite distorted. I'll try another VCO to see if it will give better signal.

 

       A VCO is used for driving an AOM to shift the frequency of the laser beam. For RCAV loop, we have a LIGO prototype VCO to drive the AOM.  The VCO was not ready to be used when I first got it. A couple of calbes got detached from connections, and I didn't know the power input level. I could not find the schematic yet, Peter helped me figure out the power input, which is +/- 24V and how to fix the unattached cable. 

 vco1.jpg

Fig1: detached connections. Now they are fixed.

    Once the box was fixed and the cable for power supply was ready, I checked the signal output. The output was high passed, and attenuated with 24dB attenuator. The signal did not look quite good compared to the LIGO VCO box we have been using, see fig 2 and 3.

IMG_1947.JPGIMG_1948.JPG

 fig 2. Left) signal from the prototype VCO for RCAV. It is quite distorted.              Right) signal from the current VCO box (the good one) for ACAV. 

 

   There are also another 80 MHz VCO (fixed frequency). I'll check that VCO if it has better output. We don't really want to use the fixed frequency because we have to tune the frequency later for lower the beat frequency.

 

 

  680   Fri Sep 16 23:47:52 2011 FrankNotesBEATVCO frequency

11:47pm : the current VCO frequency @26.5degC is ~71.294MHz still slightly drifting towards higher frequencies - will wait a few more minutes before i step it up.

11:56pm : now 71.318MHz @26.5degC

12:27am : now 71.373MHz

12:42am : now 71.394MHz

1:54am : now already 71.497MHz

2:39pm : now steady at 71.858MHz

  21   Mon Nov 30 15:01:40 2009 FrankElectronicsVCOVCO tuning

measured frequency tuning vs wideband input of VCO for calibration of measured spectra. graph coming soon...

Rana: measured spectra? Has there actually been a beat frequency measured after all these years???

  22   Sun Dec 6 13:20:52 2009 FrankElectronicsVCOVCO tuning

measured frequency tuning vs wideband input of VCO for calibration of measured spectra. graph coming soon...

Rana: measured spectra? Has there actually been a beat frequency measured after all these years???

 no, i mean i re-measured the slope of the frequency modulation input of the VCO with a lot more points. The  coefficient (MHz/V) changes a lot over the input range from -5V to 5V (internal gain of 2). We need this to calibrate the spectrum of the feedback-signal (into the VCO) for the 2nd cavity.

vco-tuning.jpg

Attachment 2: vco-tuning.ps
vco-tuning.ps
  476   Mon Feb 7 18:13:31 2011 FrankSummaryVCOVCO tuning - fitted function

tried to fit  the tuning of the VCO in order to calibrate the VCO tuning voltage into frequency shift.
I've only fitted it down to -4.3V using 5 degrees as there is no change in frequency below that point anymore.
Will add an EPICS software channel which contains the calibrated data.

Linear model Poly5:
     f(x) = p1*x^5 + p2*x^4 + p3*x^3 + p4*x^2 + p5*x + p6
Coefficients:
       p1 =   0.0005513
       p2 =   -0.003731
       p3 =   -0.005932
       p4 =    -0.02587
       p5 =       1.406
       p6 =       79.99

vco-tuning_fit1.png

Using 9 degrees the fit is not as good in the valid region for the 5 degrees, but covers the entire range from -5V to 5V

Linear model Poly9:
     f(x) = p1*x^9 + p2*x^8 + p3*x^7 + p4*x^6 +
                    p5*x^5 + p6*x^4 + p7*x^3 + p8*x^2 + p9*x + p10
Coefficients:
       p1 =   4.16e-006
       p2 = -1.095e-006
       p3 =  -0.0003138
       p4 =   0.0003221
       p5 =    0.007185
       p6 =    -0.01047
       p7 =    -0.05412
       p8 =    0.006482
       p9 =       1.498
       p10 =       79.97

vco-tuning_fit2.png

  293   Wed Aug 18 20:04:53 2010 FrankSummaryDAQVME 3123 card NOT broken

it turned out that the ADC card is not broken. Instead it's a common-mode range problem of the inputs.
As we are using several PDs on the table powered by individual (non-grounded) power supplies (Thorlabs photodiodes), these signals are floating around.
And turns out that for some reason since a couple of days the common-mode voltage was sometimes larger than the input can handle (+/-12V) and so strange things happen to the signals from time to time.
In order to fix that i added 1MOhm resistors from the negative input to analog ground of the adc-card to prevent that input from floating around. The negative input is usually ground as all our signal are single-ended referred-to-ground signals; there are no differential transmitted signals for those devices) and so this should work fine. I only added one resistor per device connected to the DAQ, meaning the temp box with four signals has only one (the first one) connected to ground as all other ones have the same ground and so they can't floaf different anymore.

That fixed all problems...

  867   Mon Mar 5 20:41:21 2012 FrankNotesDAQVME crate rebooted

crate rebooted after applying some fixes to the channel database - AOM VCO feedback is now back being monitored (uncalibrated for now as we change the range of the marconi from time to time)

  • chamber temp dropped by ~10mK
  • temp control script restarted, heater set to initial value of 1.75
  248   Fri Jul 30 13:23:29 2010 FrankNotesDAQVMIC 3123 connections (J4 and J5) (16bit adc)

- personal notes -

list of current connections to the VMIC 3123 card in the PSL rack:

J-4:

LO/HI

2/14 : FSS_RCTRANSPD

16/3 : ACAV_RCTRANSPD

5/17 : PMC_PMCTRANSPD

19/6 :

8/20 :

22/9 :

11/23 :

25/12 :

J-5: no connections

 25/12 : "TEST" , test input, shorted

 

list of old connections to the VMIC 3123 card in the PSL rack according to document D980535-C-C:

J-4:

2/14 : FSS_MIXERM

3/16 : FSS_SLOWM

5/17 : PMC_PMCTRANSPD

6/19 : FSS_MINCOMEAS

8/20 : ISS_ISERR

9/22 : PMC_PMCERR

12/25 : FSS_RMTEMP

 

J-5:

2/14 : FSS_RCTEMP

3/16 : FSS_RCTRANSPD

  296   Wed Aug 18 20:27:00 2010 FrankNotesDAQVMIC3123 address jumper settings for 1st card in PSL crate

jumper.jpg

  2395   Tue Aug 20 11:19:35 2019 anchalDailyProgressTempCtrlVac Can Heater Circuit repaired

See CTN:2394 for the symptoms and investigation. Open this post at CTN:2395 to see the chain of previous work on this circuit.


Fixes:

  • I replaced the OPA140. This didn't solve the issue.
  • I also replaced the IRF630 MOSFET. For the heat sink, I just used the mica pad and no extra thermal glue.
  • I retouched the solder joints at some places.

Present State:

  • As usual, the sense resistor (1 Ohm) is getting very hot. The MOSFET is not unusually hot after about 10 min of supplying 1.5 A of current.
  • This circuit should be ideally printed on PCB with thick traces and a proper design for heat dissipation. We need to get out of this workaround protoboard circuit! Can be a starter project for a new student or an undergrad.
  • The signal input and heater output all are unnecessarily complicated different kinds of connectors. Particularly from DAC to the box, it could be a much simpler twisted pair of wires.
  • I noticed now that the Sorenson power supply was supposed to be exclusively used for these can heate drivers. It is presently being used for driving EOMs also. I'll switch the EOM drivers to the other Kepco supplies.
  • I checked for oscillations in the heater circuit as mentioned before. Seems like the steps taken before are still working file and I couldn't see any oscillations across the sense resistor.
Attachment 1: CircuitCloseup.jpg
CircuitCloseup.jpg
Attachment 2: BoxOverview.jpg
BoxOverview.jpg
  2394   Mon Aug 19 15:54:51 2019 anchalSummaryTempCtrlVac Can Heater Driver not working!

I had aligned the North Cavity before the weekend and was about to align south one today when I saw that the modematching on the North Cavity has fallen to 20%. This is a tell-tale sign of vacuum can temperature changing too much. When I checked, indeed the temperature sensors were railing to their lower most value of 26.599 Celcius. Same for both in-loop and out of loop sensors. While the table top temperature sensor was giving a meaningful value.


Investigation begins

I first checked point by point the temperature sensor board LIGO-D1800304. From ADC all the way back to the AD590s.The two sensors were indeed giving a voltage of 4.8 V through a transimpeadance of 16.25k  which meant 295.385 uA of current corresponding to 22.23 Celcius. So indeed the sensors were telling me that the can had cooled down to almost room temperature over the past 2 days.


Framebuilder logs

I checked the framebuilder logs to figure out what has happened. The temperature was being stabalized at 34.38 Celcius by the PID script. At around 15;20:25 Aug 16, 2019 PDT, the temperature starts decaying. Infact, I should use this data in future to calculate current time constant of temperature decay of the can through the insulation. The table temperature was around 19 Celcius all this time. I found out that FB4 is not recording the channels that I have added later. I need to look into this as well.

Attached is the decay plot of the temperature


Possible points of problem

After a deep search through elog, CTN:2043 and CTN:2045 are the most relevant latest post. Kira and Kevin worked on this heater drier circuit and I'm doubting that something blew up in this circuit CTN:1903. I guess this would be my first point of attack.

Another possibility is that the heater load got disconnected. Well, I just checked the resistances and I get values of 38, 70, 70 and 38 Ohms. These are the right values according to CTN:1750. This is not the issue.

Lastly, the worst possible issue would be that the temperature sensors are reporting wrong temperature. But looking at the the properexponential decay of temperature reported by them, I would first assume that they are working fine.


Code and Data

Attachment 1: VacCanInloopTemp.pdf
VacCanInloopTemp.pdf
  2397   Wed Aug 21 10:28:58 2019 anchalSummaryTempCtrlVacuum Can Step Response

Utilizing the fact that the heater stopped last Friday, I fitted the day to extract out a time constant for cooling down of the Vacuum Can through the present insulation. Attached is the fit. The time constant has come out to 2.298 +/- 0.001 hr.

Quote:

Infact, I should use this data in future to calculate current time constant of temperature decay of the can through the insulation.

Code and Data

Attachment 1: VacCanInloopTempDecayFit.pdf
VacCanInloopTempDecayFit.pdf
  2349   Wed May 22 17:48:49 2019 anchalDailyProgressTempCtrlVacuum Can Temp Sensors restarted with new board

I installed the new board LIGO-D1800304 with an external voltage regulator and breakout box for handling acromag channels. See attached photos. The transimpedance amplifiers required a parallel capacitor in the feedback path for avoiding oscillations. Since these are temperature sensors and we do not care much about high-frequency noise, I added 1 nF capacitors at the COMIT3,9 and 11 positions. This should give us a bandwidth of 10 kHz. The channels are as follow:

CH No on Board EPICS Channel Name Temperature Conversion Function (ºC) Range (ºC)
1 C3:PSL-TEMP_TABLE = V/0.810875 + 27.30248869 13.860-40.745
2 C3:PSL-TEMP_VACCAN_INLOOP = V/1.625 + 33.3115385 26.604-40.020
3 C3:PSL-TEMP_VACCAN_OOL = V/1.625 + 33.3115385 26.604-40.020

Vacuum Can Temperature Control

With the new sensors, I have set relay autotune test to happen overnight with relay amplitude of 0.75V and 0.75 offset for 16 hrs. This should tell us optimal PID parameters. Hopefully, these measures will make the can temperature stable enough which I'll try to set around 33 degrees (my guess setpoint to keep good enough cooling rate). Then with Andrew's new script, the cavity temperature control was pretty good and hopefully we'll lower the overall drift of beatnote.

Attachment 1: Temp-Sensor-Box.jpeg
Temp-Sensor-Box.jpeg
Attachment 2: BreakoutBox.jpeg
BreakoutBox.jpeg
  2406   Fri Aug 30 17:31:56 2019 anchalDailyProgressTempCtrlVacuum Can Temperature Control Setpoint Step Test

Following Rana's test done in 40m:1986, I have programmed the lab to go through a similar test. Following things will happen:

  • At 3:30 am (roughly 30 minutes after the daily beatnote measurement), the cavity heater PID will be switched off.
  • The heating actuation will remain at what it was.
  • The setpoint of Vacuum Can temperature control will increase by 1^\circ C
  • Wait for 8 hrs.
  • The setpoint of Vacuum Can temperature control will decrease by 2^\circ C.
  • Wait for 8 hrs.
  • The setpoint of Vacuum Can temperature control will return to nominal value.
  • Repeat this next day until Sep 3rd is reached.

So this will happen three times. In between, the cavity heater PID control will have 7.5 hrs to stabilize the beatnote frequency and at 3:00 am as usual beatnote measurement will happen.

All channels are being recorded at FB4 in QIL so we can look back the relevant channels after the test is over. Putting a sticky note in QIL for not to interrupt FB4.

  2410   Wed Sep 4 11:04:08 2019 anchalDailyProgressTempCtrlVacuum Can Temperature Control Setpoint Step Test - Results

Attached are the results of this step test.

  • The Vacuum Can Temperature PID reached the setpoint almost immediately.
  • The out-of-loop sensor has a different offset but shows same 1-degree change as an in-loop sensor.
  • In the FSS Slowout Voltages which control the NPRO Laser temperatures, we can see that South Slow PID goes to a steady-state more smoothly and without much oscillations.
  • While the North Slow PID shows some oscillations. I'm not sure what can be concluded from this observation.
  • Note that the cavity heater PID was switched off during these measurements but the heaters were left on to the values they were at before switching PID off.
  • The second attachment is an exponential decay fit of the slow voltage values after the two steps on each day on each path.
  • The values of these time constants vary from 3 hrs to 4 hrs depending on the day and path.
  • I was unable to convert the slow voltages to cavity temperature reliably. I found some estimates in CTN:2027 but they were not replied to positively. And the absolute value is still unknown, so this conversion would hardly give any new insight.
  • However, since temperature change would be some constant number only, it wouldn't affect the time constant estimate done here.

Code and Data

Attachment 1: VacCanStepResponse.pdf
VacCanStepResponse.pdf VacCanStepResponse.pdf VacCanStepResponse.pdf
Attachment 2: VacCanStepResponseFit.pdf
VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf
  2411   Wed Sep 4 11:49:02 2019 ranaDailyProgressTempCtrlVacuum Can Temperature Control Setpoint Step Test - Results

yes, but convert all frequencies into cavity temperature so that there's a single y-axis

  2415   Thu Sep 5 11:15:06 2019 anchalDailyProgressTempCtrlVacuum Can Temperature Control Setpoint Step Test - Results

I used the calibration of North and South NPRO control voltage to frequency change from CTN:1948.

Then using the following formula:

\frac{\Delta T}{\Delta V} = \frac{S[\frac{Hz}{V}]}{-\alpha [\frac{1}{K}]\frac{c[\frac{m}{s}]}{\lambda [m]}}

where S is the calibration slope for NPRO from volts to the frequency

\alpha is the coefficient of thermal expansion of fused silica, 5.5\times10^{-7} K^{-1}

c is the speed of light 299792458 m/s

The offset was adjusted so that at t=0, the cavity temperatures is the same as the vacuum can in-loop temperature sensor reading at t=0.

This gave for the South Cavity -22.456 K/V and for the North Cavity -23.489 K/V

The South Cavity temperature changed 0.511 K, 0.539 K, and 0.565 K in the first step on the three days. Mean response to the first step is 0.538 K.

The North Cavity temperature changed 0.520 K, 0.574 K, and 0.639 K in the first step on the three days. Mean response to the first step is 0.578 K.

The South Cavity temperature changed -0.878 K, -0.860 K, and -0.863 K in the second step on the three days. Mean response to the second step is -0.867 K.

The North Cavity temperature changed -0.903 K, -0.933 K, and -0.910 K in the second step on the three days. Mean response to the second step is -0.915 K.


Code and Data


Edit Fri Sep 6 12:01:49 2019 anchal in RED above.

Found out that there is a bored hole in the spacer so the laser doesn't travel in fused silica actually. So the refractive index used above is wrong.

Updated calculations and plots for the same.

Attachment 1: VacCanStepResponseTempAxis.pdf
VacCanStepResponseTempAxis.pdf VacCanStepResponseTempAxis.pdf VacCanStepResponseTempAxis.pdf
  2285   Thu Jan 17 11:55:12 2019 anchalSummaryTempCtrlVacuum Can Temperature Sensors (AD590) transimpedance amplifier board noise test

I wanted to take a direct spectrum noise measurement of the circuit. However, if I have simply hooked the output of the circuit to SR785, I wouldn't know if the noise is coming due to temperature fluctuations or due to circuit noise itself. So I made a quick subtraction circuit of unity gain with an OP27 and subtracted different pairs of channels and then took their spectrum using SR785.


Method:

  • First I shorted the input to the subtraction circuit and measured the spectrum. This gave me an estimate of output noise due to this additional circuit and SR785 measurement.

  • I assumed the gain of the subtraction circuit is just 1 so, the output noise of the circuit under test wasn't assumed to get amplified from subtraction circuit.

  • Then I took measurements of the difference of signals for each pair from CH0, CH1, and CH3 in both permutations. All measured spectrums are plotted in the first plot.

  • I used both permutations to nullify any effect of different gains in positive and negative inputs of the subtraction circuit due to slightly different resistor values.

  • Then I averaged the spectrum from the 2 permutations of difference and subtracted output noise of the subtraction circuit measured earlier in quadrature. These are plotted in 2nd plot.

  • Then for the Circuit 1 which was insulated from the environment, assuming the two circuits have identical noise, I divided by sqrt(2) to get individual channels output noise.

  • I subtracted this insulated individual channels output noise from the difference noise with 'open to environment' channel in quadrature to get an estimate of noise when the circuit is open to the environment.

  • The individual channel output noises are plotted in Plot 3.


Conclusions:

  • There is a high peak at 60 Hz because of AC frequency. I am not sure about the origin of the 7 Hz peak. Other peaks look like reflections during the measurement.

  • There is about a factor of 2 improvement by insulating the box.

  • The circuit is designed for 1.625 mV/mK transduction.

  • Since EPICS channels are read at 16 Hz rate, we should be interested in the 0-16 Hz bandwidth. In this bandwidth, voltage output noise for the insulated channel is 0.79 mVrms and 'open to environment' channel is 1.74 mVrms.

  • So the noise wouldn't harm the designed 1mK sensitivity. In practice, even if these estimates are bad, the circuit should be ok for our needs.

  • So the only thing that can endanger our precision really would be temperature drift of circuit components on which we have already invested enough money and time during design.

  • So agreeing with Andrew, I'm going to go ahead and install these new circuits and directly see their performance towards improving BN spectrum as we think the Vacuum Can temperature is oscillating more than lab temperature due to poor circuits presently employed.

Attachment 1: Vacuum_Can_Temperature_Sensor_Transimpedance_Circuit_Noise_Analysis.pdf
Vacuum_Can_Temperature_Sensor_Transimpedance_Circuit_Noise_Analysis.pdf Vacuum_Can_Temperature_Sensor_Transimpedance_Circuit_Noise_Analysis.pdf Vacuum_Can_Temperature_Sensor_Transimpedance_Circuit_Noise_Analysis.pdf
Attachment 2: VCTMPSNS_Noise.zip
  2270   Tue Dec 25 11:45:15 2018 anchalDailyProgressTempCtrlVacuum Can Temperature Sensors (AD590) transimpedance amplifier board test

Yesterday, I put two boards of LIGO-D1800304 with two pairs of circuits populated in each of them for testing.


Circuit 1:

  • Installed inside an aluminum box and shielded with thermacol to keep it safe from external temperature fluctuations as much as possible.
  • Driven by externally regulated 15V power supply.
  • Channels C3:PSL-VCTMPSNS_0 and C3:PSL-VCTMPSNS_1 carry output signals from these boards

            


Circuit 2:

  • Kept open to the environment to see how much environmental fluctuations would affect the readings with respect to Circuit 1.
  • Driven by externally regulated 15V power supply.
  • Channels C3:PSL-VCTMPSNS_2 and C3:PSL-VCTMPSNS_13 carry output signals from these boards

 


Sensors:

  • All four AD590 sensors are taped next to each other near the center of a large copper block with aluminum tape.
  • The power regulator of the above circuits is also taped to one end of this copper block away from sensors using kapton tape.
  • The power regulators are inside here to increase the temperature of the block to bring it within the sensing range of transimpedance amplifier boards (26 ^\circ C to 44 ^\circ C roughly).

      


As of today, I see that all sensors have reached a temperature which is within the sensing range of boards. However, I see different readings on them, probably due to different actual resistor value on each copy of circuit. The channels are being saved by fb4. I'll pull out time series data after some more time when we can safely assume that everything has thermalized. The fluctuations in the difference of these signals would tell us about environmental coupling and the board noise and precision itself.

Attachment 5: CopperBlock.jpg
CopperBlock.jpg
  2274   Fri Jan 4 19:17:00 2019 anchalSummaryTempCtrlVacuum Can Temperature Sensors (AD590) transimpedance amplifier board test - RESULTS

Over the break, the test of Vacuum Can Temperature Sensors transimpedance circuit was running and fb4 has logged the values. PFA time series data from fb4. See PSL:2270 for experiment details.

To reiterate:

  • Channel 0 and 1 are from the same board (Circuit 1) which is enclosed inside an aluminum box which is sitting inside a thermacol box. So this circuit should be well insulated from environmental fluctuations
  • Channel 2 and 3 are on another board (Circuit 2) which is in the open.

As seen in timeseries data, something is wrong in Ch2 data as it is fluctuating too much arbitrarily. I'll see what went worng in this particular circuit. Thankfully, I had an extra circuit on same board which is recorded in channel 3 so that we can compare the channels.


Inferences:

  • In terms of fluctuations over small periods, it seems both circuits perform similarly with no noticeable drift.
  • The EPICs channels are updating at 10 Hz while I found that fb4 records channels at 16 Hz. Due to this, I think we can not really do fft properly.
  • Standard deviation of a 1minute time series data for the three channels came out to be, Ch0 -> 22.5 mV , Ch1 -> 18.0 mV and Ch3 -> 15.0 mV
  • The boards are designed to have a response of 1.625 mV/mK. So either temperature is fluctuating by around 20-30 mK or the boards are 20 times worse than the design.
  • Also, clearly the offsets of each board are very different. This could be because of the difference in thin film resistor values at the adder stage or reference voltage chips.
  • There are visible offset jumps in the time series data. I'm not sure this is due to any gap in the recording which fb4 didn't understand or something actually happened. But these are periodic themselves with a period of about 2 hrs.
  • Since fb4 is running again properly now, I'll check back timeseries data of tonight.
  • Next, I'll try to make some controlled heating environment and a precise temperature sensor so that we can see if different AD590s have different slopes for temperature changes.

Edit: Fri Jan 11 11:24:11 2019

Added lighter plots. The plots now have mean value (averaged over 1 minute of data) with the shaded region showing one sigma uncertainty region. I've added the jupyter notebook in .zip file.

Attachment 1: VacCanTemSensorTest_Time_Series_Data_1229716818_to_1229904318.pdf
VacCanTemSensorTest_Time_Series_Data_1229716818_to_1229904318.pdf VacCanTemSensorTest_Time_Series_Data_1229716818_to_1229904318.pdf VacCanTemSensorTest_Time_Series_Data_1229716818_to_1229904318.pdf VacCanTemSensorTest_Time_Series_Data_1229716818_to_1229904318.pdf VacCanTemSensorTest_Time_Series_Data_1229716818_to_1229904318.pdf
Attachment 2: VCTemperatureSensorsTest.zip
  1220   Mon Jul 1 15:14:35 2013 EvanNotesTempCtrlVacuum can temperature noise: theoretical and Comsol results

Quote:

Tara, Rana and I had a discussion last week about how much temperature noise from the outside of the CTN vacuum can actually makes its way to the copper radiation shield surrounding the reference cavities. In the first attachment I've attempted a first-principles calculation of this response assuming that the steel surface of the can is subjected to a uniform, fluctuating temperature. I've also assumed a plane parallel geometry rather than a cylindrical geometry just to make the math a bit easier. (In this attachment, I've said that the steady-state temperature of the inner steel surface can be taken to be the average of the outer temperature and the copper temperature, but thinking about it now it's probably almost identical to just the outer temperature. Despite what is says in the attachment, for the subsequent plots I've taken the steel temperature to be a uniform 35 C and the copper temperature to be 40 C.)

I find that the thermal response of the copper shield with regard to temperature fluctuation on the outside of the can is (as one might expect) a product of (1) the exponential damping of the temperature fluctuation as it propagates through the steel, and (2) the thermal response of the copper itself, which has a single-pole low-pass behavior. Effect (1) is just the thermal response of a half- infinite conductor, and is treated in chapter 11 of Fetter and Walecka's theoretical mechanics book. Effect (2) is found by computing the steady-state net radiation flux between the steel and the copper, then applying a harmonic perturbation to this flux and computing how much power is absorbed by the copper according to Q = mCΔT. In other words, I've applied a harmonic perturbation to the lumped capacitance model described by eq. 5.16 in the heat transfer textbook by Bergman, Lavine, et al. (6th ed.). The only sticking point is that their power balance formula [ρ cV dT/dt = −ε2σA(T22 − T12)] is formulated for a grey body in equilibrium with a blackbody, rather than for two grey bodies. So in my calculation, instead of ε2 I have an effective emissivity involving both ε1 and ε2.

The second attachment shows the magnitude of the transfer function. In the third attachment I've estimated the temperature noise from the AD590 and the NTC thermistor (as given in Rana's post, PSL #1205), and then plotted the temperature noise at the copper shield assuming the outside of the can is stabilized to the noise level of the AD590. It appears that this residual noise is below the noise of the NTC thermistor for frequencies above 10−4 Hz. I'm trying to get a Comsol model up and running to confirm this.

There is a mistake in the calculation above; the emissivity ε2 should not appear in power balance involving the absorption of jn by the copper, since jis already a net flux describing the intensity of radiation flowing into the copper. The thermal time constant of the copper is therefore d2ρ2cp2/4ε′σTb3.

I ran a 1D Comsol model of this parallel plate calculation. The geometry and materials are as described above. For the boundary condition at the outside (left) surface of the steel, I chose a step function in time that starts at 303 K and ends at 308 K. For the inner (right) surface of the steel and the left surface of the copper, I used surface-to-surface radiation conditions, with emissivities specified as above. For the right surface of the copper I chose perfect thermal insulation. This corresponds to enforcing T b = Td in my calculation. For a cylindrical geometry with no reference cavity present, we know by symmetry that the next flux at the inner surface of the copper shield must be zero as long as the copper is a uniform temperature; this corresponds to a perfectly insulating boundary condition.

The time constant is the time required for the copper shield to rise to 63% of the difference between its initial and final temperatures (which here is 306.16 K). From this, I find that Comsol gives the thermal time constant as 21300 s (see first attachment); my calculation gives 21200 s. As a check, I also tried different emissivities. For both emissivities equal to 1, Comsol gives 1300 s and my calculation gives 1200 s; for ε1 = 1 and ε 2 = 0.15, Comsol gives 8500 s and my calculation gives 7800 s; and for ε1  = 0.08 and ε2 = 1, Comsol gives 13900 s and my calculation gives 14600 s.

At this point I don't have an explanation as to why Comsol doesn't show the exponential suppression of the temperature fluctuations in the steel. But even without this effect, the residual AD590 noise at the copper shield is still below the NTC thermistor noise for frequencies above 2×10−4 Hz (second attachment).

Attachment 1: comsol_stepresp.pdf
comsol_stepresp.pdf
Attachment 2: copper_timeconst.pdf
copper_timeconst.pdf
  1218   Sun Jun 30 22:22:52 2013 EvanNotesTempCtrlVacuum can temperature noise: theoretical calculation

Tara, Rana and I had a discussion last week about how much temperature noise from the outside of the CTN vacuum can actually makes its way to the copper radiation shield surrounding the reference cavities. In the first attachment I've attempted a first-principles calculation of this response assuming that the steel surface of the can is subjected to a uniform, fluctuating temperature. I've also assumed a plane parallel geometry rather than a cylindrical geometry just to make the math a bit easier. (In this attachment, I've said that the steady-state temperature of the inner steel surface can be taken to be the average of the outer temperature and the copper temperature, but thinking about it now it's probably almost identical to just the outer temperature. Despite what is says in the attachment, for the subsequent plots I've taken the steel temperature to be a uniform 35 C and the copper temperature to be 40 C.)

I find that the thermal response of the copper shield with regard to temperature fluctuation on the outside of the can is (as one might expect) a product of (1) the exponential damping of the temperature fluctuation as it propagates through the steel, and (2) the thermal response of the copper itself, which has a single-pole low-pass behavior. Effect (1) is just the thermal response of a half- infinite conductor, and is treated in chapter 11 of Fetter and Walecka's theoretical mechanics book. Effect (2) is found by computing the steady-state net radiation flux between the steel and the copper, then applying a harmonic perturbation to this flux and computing how much power is absorbed by the copper according to Q = mCΔT. In other words, I've applied a harmonic perturbation to the lumped capacitance model described by eq. 5.16 in the heat transfer textbook by Bergman, Lavine, et al. (6th ed.). The only sticking point is that their power balance formula [ρcV dT/dt = −ε2σA(T22 − T12)] is formulated for a grey body in equilibrium with a blackbody, rather than for two grey bodies. So in my calculation, instead of ε2 I have an effective emissivity involving both ε1 and ε2.

The second attachment shows the magnitude of the transfer function. In the third attachment I've estimated the temperature noise from the AD590 and the NTC thermistor (as given in Rana's post, PSL #1205), and then plotted the temperature noise at the copper shield assuming the outside of the can is stabilized to the noise level of the AD590. It appears that this residual noise is below the noise of the NTC thermistor for frequencies above 10−4 Hz. I'm trying to get a Comsol model up and running to confirm this.

Attachment 1: vacuum_can.jpg
vacuum_can.jpg
Attachment 2: transfer_thetab.pdf
transfer_thetab.pdf
Attachment 3: temp_suppression.pdf
temp_suppression.pdf
  1756   Fri Nov 4 12:59:11 2016 awadeMiscDrawingsVacuum tank view port masking shields

I have asked Eddie to have a look at some masking shields for the vacuum tank's 8" viewports.  He will look at the drawings and seek out someone to build and polish them. This is to help with reducing the emissivity as viewed from inside the tank looking towards the viewports.  Fused silica has a epsilon>0.75, a shiny mask coving all but the spots where light is coupled in/out should improve the radiative thermal isolation from the tank.

I've attached the drawings of my initial sketch. In the process I also did an update of all the Solidworks assemblies that we have in the SVN, these were largly drawn in the student version of Solidworks and were useless for generating drawings and assemblies.  I have now updated all the parts and assemblies, there are now no student version files. All of these has been updated in (root)/trunk/CTNLab/current/drawings/dual_refcav/ of the 40m SVN . In an effort to reduce the entropy of this directory, I have broken the reference cavity drawings into subassembly folders so individual sub-systems can be edited separately. 

Is 0.5" a big enough hole for our beams to get in/out?

To get the drawings follow instuctions here: https://wiki-40m.ligo.caltech.edu/How_To/Use_the_SVN_archive

Attachment 1: AssembledEndShield.PDF
AssembledEndShield.PDF
Attachment 2: EndMaskShieldingWindow.PDF
EndMaskShieldingWindow.PDF
Attachment 3: FixingBlocks.PDF
FixingBlocks.PDF
Attachment 4: Fully_Assembled_Tank_Stack_And_Cavites_ExplodedView.PDF
Fully_Assembled_Tank_Stack_And_Cavites_ExplodedView.PDF
Attachment 5: spingyband.PDF
spingyband.PDF
  1858   Mon Aug 14 16:34:45 2017 awade, CraigDailyProgressBEATVoltage offsets on unterminated slow frequency control on Lightwave lasers

Craig refound the BN this morning for the pre-cavity beat note detector.  Level is -41 dBm @ 360 MHz with northSlow = 39.7679 V and southSlow = 49.5736 (at the new laser controller calibration). This was with the EPICS slow controls unplugged at the front.  When I went to plug them back into the slow controls, both set to zero volts, the beat note went away.

After some trouble shooting I stuck a multimeter on the slow inputs and found that the slow inputs to the lasers' frequency control have a offset when unterminated.  North slow voltage offset is 3.151 V and south is -0.927 V (this is at the above temperature settings). These voltages change with the above setpoint temperatures unless the input is terminated or a voltage is applied.

The manual seems to suggest that the slow frequency BNC is an offset to the set point temperature. However, it seems like the BNC voltage input overrides the set point value rather than adding/subtracting from it.  If override is the case then full range of the laser frequency tuning should happen from -10 to +10 V on the slow inputs.  I will modify the relevant EPICS channels from -2 to 7 V to their full range of ±10 V.

---

Laser setpoint temperatures were reset back to the center of their range (48.0010 C South and 44.8010 C north).  The equivalent slow input voltages to reach the same 360 MHz BN is -1.2270 V south and 4.0870 V north. No more tuning on the laser controlers.  Epics channels from this point forward.

 

Attachment 1: 2017-08-14_16.14.12.jpg
2017-08-14_16.14.12.jpg
Attachment 2: 2017-08-14_16.14.25.jpg
2017-08-14_16.14.25.jpg
  752   Thu Dec 8 15:03:10 2011 FrankNotesComputersWD green drives suck

again (for the third time now) one of the Western Digital Caviar Green WD15EARS 1.5TB disks failed. We already had two failing in the ATF, now the one in this computer failed too. (WDC WD15EARS)

PLZ DO NOT USE THOSE DRIVES IN FRAMEBUILDERS IN THE FUTURE. THEY WILL CAUSE ONLY TROUBLE.

  763   Sun Dec 11 17:43:09 2011 ranaNotesComputersWD green drives suck

Quote:

again (for the third time now) one of the Western Digital Caviar Green WD15EARS 1.5TB disks failed. We already had two failing in the ATF, now the one in this computer failed too. (WDC WD15EARS)

PLZ DO NOT USE THOSE DRIVES IN FRAMEBUILDERS IN THE FUTURE. THEY WILL CAUSE ONLY TROUBLE.

 Google's drive failure report: SMART is not so smart.

  2231   Sat Sep 8 17:34:54 2018 awadeMiscComputersWS1 CPU fan dead

WS1, the main computer in the PSL lab died last night.  On reboot bios screen says that CPU fan died.  

I opened the computer up and had a look.  Bearings on main CPU fan were a bit stiff.  I wiggled them a bit and it now spins, with some noise, when booted.  

I'll order a replacement CPU fan KDE1209PTVX 12V, 7.0 W and replace pronto.

Main CPU fan
Main CPU fan, bearings nearing end of life.

---

Also there was no backup of this computer.  Almost all the stuff is kept in Git version control, but we should get these computers back on scripted backups.

 

---

Edit Sat Sep 8 18:28:19 2018: Rebooted and restarted frequency counter. Beat note has drifted off to 750 MHz.  Will take a while to bring it back in.

Fan has been reordered, will arive Friday next week.

  2234   Mon Sep 17 14:08:56 2018 awadeMiscComputersWS1 CPU fan replaced

Found that WS1 had died again.  CPU fan seized up again.

Replaced and computer restarted fine. WS1 up and running normally.

Quote:

WS1, the main computer in the PSL lab died last night.  On reboot bios screen says that CPU fan died.  

I opened the computer up and had a look.  Bearings on main CPU fan were a bit stiff.  I wiggled them a bit and it now spins, with some noise, when booted.  

I'll order a replacement CPU fan KDE1209PTVX 12V, 7.0 W and replace pronto.

Main CPU fan
Main CPU fan, bearings nearing end of life.

---

Also there was no backup of this computer.  Almost all the stuff is kept in Git version control, but we should get these computers back on scripted backups.

 

---

Edit Sat Sep 8 18:28:19 2018: Rebooted and restarted frequency counter. Beat note has drifted off to 750 MHz.  Will take a while to bring it back in.

Fan has been reordered, will arive Friday next week.

 

  2116   Sun Mar 4 17:33:01 2018 awadeDailyProgressComputersWS1 Up

Workstation is back.  I was able to fully restore medm screens, scripts and noisebudget from Git on WS1.  Good version control is the way to go it seems.

Can't say the same for Criag's Apache noise budget stuff.  I found a SATA to USB converter and am able to mount the WS3 HD directly onto WS1.  The original HD  is intact so all the original stuff is accessible.  We just need to move it into place on the new computer.  I've left the WS3 machine HD plugged in and it is mounted in /media/controls/. 

Quote:

I just tried to ssh into ws3 only to find it unresponsive.  I was going to check the router but then found that the computer seemed to be off.

On closer inspection the computer seems to have some kind of power issue.  At the moment all I am seeing is a blinking amber power light on the box. One LED indicator is on on the motherboard, otherwise there are no fans or HD spinning. 

I have sequentially pulled the DVD drive, HD and RAM.  Fans won't spin up.  Various forums suggest that its either a motherboard issue or a power supply issue.  Given that we are seeing the basic amber flashing LED on the front panel I would hazard a guess that its not the power supply.

WS3 is a computer that Larry Wallace gave me that had been retired from desktop use.  Don't think this is worth days of diagnosis and, more importantly, days of down time to fix it.  I had made a clone of the computer, but that isn't much use if we need to recover to a completely different computer. For now I am going to pull ws2 from the QIL lab and attempt to get it going as the interface computer in the PSL lab.  All the important medm screens and python scripts were committed to Gitlab so we should be good. WS2 was running an old CentOS (Redhat) operation system, no out of service period.  I will switch out its HD for a fresh 250 Gb and do a fresh install of debian as a start.

Edit Sun Mar 4 00:13:37 2018: Scratch using WS2 as a stop gap machine, it won't boot from USB and the CDROM drive is busted.  We're going to have to use WS1 for now, it already has Debian installed and LIGO tools (I think).

Edit Sun Mar 4 12:48:39 2018: Last night I ended up just moving WS1 into the PSL lab.  I had previously installed Debian and all the LIGO tools (see ATF:2181) which is now come in handy.  I've changed the machine's IP to 10.0.1.34 and we can now SSH remotly using the ussual gateway address and port 22. We may want to reporpose the 'gateway' box as it is not currently in use as a ssh landing point.

 

  2369   Mon Jul 22 19:11:54 2019 anchalNotesComputersWS1 upgraded to Debian 9, still showing some glitches

Last week, the default GNOME Classic desktop environment of WS1 started giving hiccups. I was unable to see any medm screens. I restarted the computer assuming that will solve it but then I was unable to login from the graphical user interface. That was weird as I was able to ssh into the computer and do whatever I want. So it seemed that some graphics engine was unable to run. On login screen, after typing in the correct password, a black screen would appear and it would go back to the login screen. This is mentioned in various forums on the internet as "login loop". Taking advice and directions from Jamie, I tried to troubleshoot this to the best of my ability but we both were unsure in the end what was the problem. Our best guess is that installation of LSCsof package upgraded some graphics library beyond the capability of the present system. I tried all different desktop environments and I was able to login only through GNOME on Wayland (supposedly bleeding edge for debian 8). Another mystery is that I found medm uninstalled from the computer. I installed it back with:
sudo apt-get install medm

And I found that GNOME on Wayland is still usable option. After some more discussion with Jamie, I decided to upgrade the OS to next stable version debian 9. I followed the instructions on:
https://phoenixnap.com/kb/how-to-upgrade-debian-8-jessie-to-debian-9-stretch

to dot and have successfully upgraded to debian 9. However, still only "GNOME on Wayland" is the only desktop environment through which we can login without facing a login loop

On another note, I found today that clicking the scroll button over a medm channel screen (which ideally displays the channel name) freezes the computer. The mouse pointer disappears and the computer does not respond to anything. Again, I can ssh into the computer and do anything. This problem goes away on restart.

So bottom line is, the overall system environment of ws1 is becoming messy and old and ideally we should do a clean install of a new os (something like Jon did in QIL). But I was heavily discouraged for doing so as it seemed it will take a lot of time to setup a new workstation.


Present Status

Due to recent cleanup and upgrades in our computer environment in lab, this workstation ws1 is a mere looking window in the experiment. There are no active scripts that it runs (except a precavity beatnote reading) and the experiment can be carried out without it present as well. However, it is nice to keep a computer loaded with EPICS, nds2, python environments and a screen to carry out day-t-day functioning of the lab.

  2371   Mon Jul 22 20:55:41 2019 ranaNotesComputersWS1 upgraded to Debian 9, still showing some glitches

beware the Debian zealots! All the workstations at the 40m are SL7.

If you really can only use Debian, you could just clone the new workstation that Jon setup in QIL.

 

  2114   Sat Mar 3 23:25:37 2018 awadeDailyProgressComputersWS3 Down

I just tried to ssh into ws3 only to find it unresponsive.  I was going to check the router but then found that the computer seemed to be off.

On closer inspection the computer seems to have some kind of power issue.  At the moment all I am seeing is a blinking amber power light on the box. One LED indicator is on on the motherboard, otherwise there are no fans or HD spinning. 

I have sequentially pulled the DVD drive, HD and RAM.  Fans won't spin up.  Various forums suggest that its either a motherboard issue or a power supply issue.  Given that we are seeing the basic amber flashing LED on the front panel I would hazard a guess that its not the power supply.

WS3 is a computer that Larry Wallace gave me that had been retired from desktop use.  Don't think this is worth days of diagnosis and, more importantly, days of down time to fix it.  I had made a clone of the computer, but that isn't much use if we need to recover to a completely different computer. For now I am going to pull ws2 from the QIL lab and attempt to get it going as the interface computer in the PSL lab.  All the important medm screens and python scripts were committed to Gitlab so we should be good. WS2 was running an old CentOS (Redhat) operation system, no out of service period.  I will switch out its HD for a fresh 250 Gb and do a fresh install of debian as a start.

Edit Sun Mar 4 00:13:37 2018: Scratch using WS2 as a stop gap machine, it won't boot from USB and the CDROM drive is busted.  We're going to have to use WS1 for now, it already has Debian installed and LIGO tools (I think).

Edit Sun Mar 4 12:48:39 2018: Last night I ended up just moving WS1 into the PSL lab.  I had previously installed Debian and all the LIGO tools (see ATF:2181) which is now come in handy.  I've changed the machine's IP to 10.0.1.34 and we can now SSH remotly using the ussual gateway address and port 22. We may want to reporpose the 'gateway' box as it is not currently in use as a ssh landing point.

  2100   Thu Feb 22 15:15:20 2018 awade, CraigMiscSafetyWater leak in the lab

We have a steady drip of water coming down from the recently updated pipes.  Apparently the pipe is cracked all the way up to the ceiling.

We've shut down the UPS and all the circuits around that corner of the lab.  Facilities people are here looking into the issue. 

There was quite a lot of water pooled around the west side of the optical table. Craig has mopped this up, although it did get under the table legs and under the tiles.  All the electrical stuff under the table was on racks off the ground. Dripping is coming from pipes directly above the rack but it appears that none of it has made it into the rack itself.  We are removing all the very valuable electronics (e.g. marconi and oscilloscopes) and none appear to have water on or around them.

Lasers are shut down.

 

  2103   Fri Feb 23 13:15:22 2018 awadeMiscSafetyWater leak in the lab

Checked the piping again this morning.  The water is just a slow drip now. The facilities people put duct tape around the pipe crack and isolated the source of water on the floor above.  Don't think its safe yet to turn the rack back on, given the proximity of the water and the quality of the patch job. 

I called facilities to find out what the status of the job was and the timelines for fixing.  They didn't have the poly pipe in stock and have reordered. The earliest they can get to starting on the job will be Monday.  The guy responsible is away today.  We should call ext 4969 (Caltech plumbing shop) early on Monday to get an update on expected completion time of the job. Until then we should redirect effort into SURF search, noise budgeting, scatter modeling, PID modeling, FSS sub-noise budget etc.

 

Quote:

We have a steady drip of water coming down from the recently updated pipes.  Apparently the pipe is cracked all the way up to the ceiling.

We've shut down the UPS and all the circuits around that corner of the lab.  Facilities people are here looking into the issue. 

There was quite a lot of water pooled around the west side of the optical table. Craig has mopped this up, although it did get under the table legs and under the tiles.  All the electrical stuff under the table was on racks off the ground. Dripping is coming from pipes directly above the rack but it appears that none of it has made it into the rack itself.  We are removing all the very valuable electronics (e.g. marconi and oscilloscopes) and none appear to have water on or around them.

Lasers are shut down.

 

 

  2106   Mon Feb 26 14:16:38 2018 awadeMiscSafetyWater leak in the lab

I called facilities.  They say with their new purchase approval process, and lead time on parts, that they expect the repair jobs on piping would start early next week.  

There will be a bit of manual alterations to the through hole coming down into the ceiling so we need to do some dust mitigation.  I will order some more cling wrap and salvage some of the plastic sheeting from the last episode.

Quote:

Checked the piping again this morning.  The water is just a slow drip now. The facilities people put duct tape around the pipe crack and isolated the source of water on the floor above.  Don't think its safe yet to turn the rack back on, given the proximity of the water and the quality of the patch job. 

I called facilities to find out what the status of the job was and the timelines for fixing.  They didn't have the poly pipe in stock and have reordered. The earliest they can get to starting on the job will be Monday.  The guy responsible is away today.  We should call ext 4969 (Caltech plumbing shop) early on Monday to get an update on expected completion time of the job. Until then we should redirect effort into SURF search, noise budgeting, scatter modeling, PID modeling, FSS sub-noise budget etc.

 

  443   Mon Dec 27 10:10:39 2010 JanSummaryPEMWeekly plots; T240 on PSL table

I am just posting the time-frequency plots for a week-long summary. The data was collected between 2010-12-18 UTC 00:00 and 2010-12-25 UTC 00:00 (7 full days). Although least important to us, I am always most fascinated by the natural (microseismic) sources and not so much by anthropogenic (microtremor) sources. You could go on now and generate bifrequency plots, ultra-low frequency spectral variations and so on. These results would help to distinguish natural sources from local disturbances and can help to identify signals that are much weaker than the spectral density.

I will continue to acquire the data from the table for another week. Then I will move the seismometer from the table to the ground just for a day or so to check what the table does to the particle trajectories. Then it will go back to my lab.

Plot12.jpgPlot10.jpg

Attachment 1: Plot8.jpg
Plot8.jpg
  447   Mon Jan 10 13:28:36 2011 JanSummaryPEMWeekly plots; start date 2010-12-25

These two plots are just for completeness. In a few minutes I will be able to post the plots for the third week, which could be more interesting since it contains the transition from table to ground. I don't understand why the low-frequency disturbance is "out of phase" with the high-frequency one. It's maybe the last sign of Tara before he left, so he seems to be out of synch with the rest of the world.

Plot10.jpgPlot12.jpg

  448   Mon Jan 10 14:27:11 2011 JanSummaryPEMWeekly plots; starting date 01/01/2011

 So I don't know what's going on, but the table is doing something really terrible. Maybe it vibrates as a response to ventilation, whereas the coupling of ventilation to ground is comparatively weak. Anyway, this is the end of PSL seismic measurements. Data will be kept on one of the machines in 058f. In principle, I could convert the data into frames and copy it to another location, but it may be too much work. I can always easily produce .mat files with averaged spectra etc. Let me know.

Plot7.jpgPlot9.jpg

ELOG V3.1.3-