40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 45 of 329  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  9671   Tue Feb 25 16:07:33 2014 ericqUpdateLSCChanging PRCL offset changes REFL 165 degeneracy

 And glossing over the MICH offset, here's the PRC offset plots in displacement, rather than radians.

The simulation is actually slightly different now. I now use nominal ITM T values (T=.014) instead of the random R=.99 I had in place. 

MICHvPRCLangle_wOffset.pdfMICHvPRCLangle_wOffset_fullscale.pdf

(correction: Field Power should be Field Amplitude in the first plot)

  9676   Wed Feb 26 01:49:08 2014 JenneUpdateLSCChanging PRCL offset changes REFL 165 degeneracy

I have measured the sensing matrix at a variety of PRCL offset values.

DemodPhaseSeparation.pdf

During this each measurement, I also took a 20 second average of the POP 2f signals and the ASDC signal:

POP_AS_PDvalues.pdf

All of this data was taken during a single lock stretch. 

If / when I do this again, I want to go out to larger offsets.  I won't take as many points, but I do want to see how far I can go before I lose lock, and what the phase separation looks like at larger offset values (this time, I stopped at +700 counts which is about 0.7nm, to start checking the negative values. MC has been unhappy, so I wasn't able to take very many negative offset values.) 

I conclude that these sensing matrix measurements do see changes in the phase separation with PRCL length offset (what we saw / said yesterday), but that they do not line up with Q's simulation from this afternoon in elog 9671.

The simulation says that we shouldn't be seeing large phase changes until we get out to several nanometers, however the measurement is showing that we get large phase chnages with picometer scale offsets.  Yesterday, Rana and I said that the offsets due to RAM were small (of order picometer), and that they were therefore likely not important (elog 9668).  However, now it seems that the RAM is causing significant length offsets which then cause poor MICH/PRCL phase separation.

To Do List:

* Confirm MIST simulation with Optickle.

* Look at sensing matrix data pre-lockins (in the raw sensors).

* Check that there is no clipping anywhere in the REFL path (at least out of vacuum), and that the beam is sufficiently small on all 4 REFL diodes.

* Calculate the new PRC g-factor with the new length.

  3633   Fri Oct 1 11:33:15 2010 josephb, alexConfigurationCDSChanging gds code to the new working version

Alex is installing the newly compiled gds code (compiled on Centos 5.5 on Rosalba) which does in fact include the ezca type tools. 

At the moment we don't have a solaris compile, although that should be done at somepoint in the future.  It means the gds tools (diaggui, foton, etc) won't work on op440m.  On the bright side, this newer gds code has a foton that doesn't seem to crash all the time on Linux.

 

  517   Wed Jun 4 13:46:42 2008 josephbConfigurationCamerasChanging incident angle images
Attached are images from the GC650 and GC750 when the incident angle was varied from 0 tilt (normal incidence) to 5,10, and 20 degrees. Each time the beam was realigned via the last turning mirror to be on roughly the same spot. This light was a pickoff of the PSL table light just before it leaves the table.

Images include the raw data, fit to the data, residual normalized by peak power "w(1)", and normalized by the individual bin power.

The first pdf includes 0 degrees (normal) and ~5 degrees of tilt for the GC650 (CCD) camera.

The second pdf includes ~10 and ~20 degrees of tilt images for the GC650 (CCD) camera.

The third pdf includes 0 and ~5 degrees of tilt for the GC750 (CMOS) camera.

The fourth pdf includes ~10 and ~20 degrees of tilt for the GC750 (CMOS) camera.

Things to note:
1) GC750 camera seems to have a structure on the camera itself, somewhat circular in nature. One possible explanation is the camera was damage at a previous juncture due to too much light. Need to check earlier images for this problem.
2) GC650 has "bands" which change direction and thickness with angle. Also at higher incidence angle, the sensitivity seems to drop (unlike the GC750 where overall power level seems to stay constant with increasing angle of incidence).
3) GC650 seems to have a higher noise floor,seen from the last plot of each pdf (where each pixel of the residual is normalized by the power in the corresponding pixel of the fit).
Attachment 1: GC650_0dg_5dg.pdf
GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf
Attachment 2: GC650_10dg_20dg.pdf
GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf
Attachment 3: GC750_0dg_5dg.pdf
GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf
Attachment 4: GC750_10dg_20dg.pdf
GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf
  1579   Wed May 13 02:53:12 2009 robSummaryloreChannel Hopping: That ancient enemy (MC problems)

We were stymied tonight by a problem which began late this afternoon.  The MC would periodically go angularly unstable, breaking lock and tripping the MC2 watchdogs.  Suspicion fell naturally upon McWFS.

Eventually I traced the problem to the MC3 SIDE damping, which appeared to not work--it wouldn't actually damp, and the Vmon values did not correspond to the SDSEN outputs.  Suspicion fell on the coil driver.

Looking at the LEMO monitors on the MC3 coil driver, with the damping engaged, showed clear bit resolution at the 100mV level, indicating a digital/DAC problem.  Rebooting c1sosvme, which acquires all the OSEM sensor signals and actually does the side damping, resolved the issue. 

  1582   Wed May 13 14:43:29 2009 robSummaryloreChannel Hopping: That ancient enemy (MC problems)

Quote:

We were stymied tonight by a problem which began late this afternoon.  The MC would periodically go angularly unstable, breaking lock and tripping the MC2 watchdogs.  Suspicion fell naturally upon McWFS.

Eventually I traced the problem to the MC3 SIDE damping, which appeared to not work--it wouldn't actually damp, and the Vmon values did not correspond to the SDSEN outputs.  Suspicion fell on the coil driver.

Looking at the LEMO monitors on the MC3 coil driver, with the damping engaged, showed clear bit resolution at the 100mV level, indicating a digital/DAC problem.  Rebooting c1sosvme, which acquires all the OSEM sensor signals and actually does the side damping, resolved the issue. 

 Lies!  The problem was not resolved. The plot shows a 2-day trend, with the onset of the problem yesterday clearly visible as well as the ineffectiveness of the soft-reboot done yesterday.   So we'll try a hard-reboot.

Attachment 1: MC3sidemon.png
MC3sidemon.png
  1583   Wed May 13 21:15:04 2009 ranaSummarySUSChannel Hopping: That ancient enemy (MC problems)
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.
  1584   Thu May 14 00:15:39 2009 robSummarySUSChannel Hopping: That ancient enemy (MC problems)

Quote:
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.


This started around April 23, around the time that TP1 failed and we switched to the cryopump, and also when there was a mag 4 earthquake in LA. My money's on the EQ. But I don't know how.
Attachment 1: sidemon.png
sidemon.png
  1587   Thu May 14 16:07:20 2009 peteSummarySUSChannel Hopping: That ancient enemy (MC problems)

Quote:

Quote:
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.


This started around April 23, around the time that TP1 failed and we switched to the cryopump, and also when there was a mag 4 earthquake in LA. My money's on the EQ. But I don't know how.


I wonder if this is still a problem. It has been quiet for a day now. I've attached a day-long trend. Let's see what happens.
Attachment 1: mc3_5days.jpg
mc3_5days.jpg
  13662   Wed Feb 28 21:14:34 2018 gautamSummaryPEMChannel admin

Since we decided to use the Acromag for readback of the temperature sensor for Kira's seismometer temperature control, I enabled logging of the channel Johannes had reserved for this purpose last week. Kira has made the physical connection of a temperature sensor to the BNC input for this channel - it reads back -2.92 V right now, which is around what I remember it being when Kira was doing her benchtop tests. I edited C0EDCU.ini to enable logging of this channel at 16 Hz. Presumably, a study of the ADC noise of the Acromag at low frequencies has to be made to ensure appropriate whitening (if any) can be added. Channel name is C1:PEM-SEIS_EX_TEMP_MON. Similarly, there is C1:PEM_SEIS_EX_TEMP_CTRL which is meant to be the control channel for the servoing. Calibration of the temperature sensor readback into temperature units remains. It also remains to be verified if we can have these slow EPICS channels integrated with a fast control model, or if the PID temperature control will be purely custom-script based as we have for the FSS slow loop.

I removed the fast channels I had setup temporarily in c1als. Recompilation and restart of the model went smoothly.

Quote:
 I then made a "PEM" namespace block inside the c1als model, and placed a single CDS filter module inside it (this can be used for calibration purposes). The filter module is named "C1:PEM-SEIS_EX_TEMP", and has the usual CDSfilt channels available. I DQ'ed the output of the filter module (@256 Hz, probably too high, but I'm holding off on a recompile for now). Recompilation and model restart of c1als went smoothly. 
 
Attachment 1: tempSensData.png
tempSensData.png
  13873   Mon May 21 15:34:19 2018 gautamConfigurationElectronicsChannel hijacking history

Since we've been hijacking channels like there is no tomorrow for the AUX-PLL setup, I'm documenting the channel names here. The next time c1psl requires a reboot, I'll rename these channels to something more sensible. To find the channel mapping, Koji suggested I use this. Has worked well for us so far... We've labelled all pairs of wires pulled out of the cross connects and insulation taped the stripped ends, in case we ever need to go back to the original config.

Previously unused C1PSL Channels now used for AUX PLL

Channel name AI/AO Function
C1:PSL-126MOPA_126CURADJ AO Slow temperature control
C1:PSL-FSS_RFADJ AO Servo trigger TTL
C1:PSL-126MOPA_126PWR AI PLL error signal monitor
C1:PSL-126MOPA_DMON AI PLL control signal monitor
C1:PSL-FSS_PHCON AO

To mitigate integrator railing

  4152   Thu Jan 13 16:41:07 2011 josephbUpdateCDSChannel names for LSC updated

I renamed most of the filter banks in the c1lsc model.  The input filters are now labeled based on the RF photodiode's name, plus I or Q.  The last set of filters in the OM subsystem (output matrix) have had the TO removed, and are now sensibly named ETMX, ETMY, etc.

We also removed the redundant filter banks between the LSCMTRX and the LSC_OM_MTRX.  There is now only one set, the DARM, CARM, etc ones.

The webview of the LSC model can be found here.

  14744   Wed Jul 10 14:57:01 2019 KojiSummaryCDSChannel recipe for iscaux upgrade

The list of the iscaux channels and pin assignments were posted to google drive.
The spreadsheet can be viewable by the link sent to the 40m ML. It was shared with foteee@gmail for full access.

Summary

  • We need
    4 ADC modules
    5 DAC modules
    5 Binary I/O modules
  • Be aware that there are bundled multiple digital I/O channels such as "mbboDirect" and "mbbi".
  • The full db record of the new channels need to be inferred from the existing channels.

Necessary electronics modification

1. D990694 whitening filter modification (4 modules)

This module shares the fast and slow channels on the top DIN96pin (P1) connector. Also, the whitening selector (done by an analog signal per channel) is assigned over 17pin of the P1 connector, resulting in the necessity of the second DSUB cable. By migrating the fast channels, we can swap the cable from the P1 to P2.  Also, the whitening selectors are concentrated on the first Dsub. (See Attachment1 P1)

2. D040180 / D1500308 Common Mode Board

CM servo board itself doesn't need any modification. The CM board uses P1 and P2. So we need to manufacture a special connector for CM Board P2. (cf The adapter board for P1 T1800260). See also D1700058.

3. D990543A1 LSC Photodiode Interface

PD I/F board has the DC mon channels spread over the 16pin limit. P1 21A can be connected to 6A so that we can accommdate it in the first Dsub.
Also the board uses AD797s. This is not necessary. We can replace them to OP27s. I actually don't know what is happening to those bias control, temp mon, enable, and status. These features should be disables at the I/F and the PDs. (See Attachment2 P1)

Attachment 1: D990694-B.pdf
D990694-B.pdf D990694-B.pdf D990694-B.pdf D990694-B.pdf D990694-B.pdf D990694-B.pdf D990694-B.pdf D990694-B.pdf
Attachment 2: D990543A1.PDF
D990543A1.PDF D990543A1.PDF D990543A1.PDF
  13710   Tue Mar 27 11:11:16 2018 KiraUpdatePEMChannel setup

[Kira, Gautam]

We setup the channels for PID control of the seismometer can. First, we ssh into c1auxex and went to /cvs/cds/caltech/target/c1auxex2 and found ETMXaux.db. We then added in new soft channels that we named C1:PEM-SEIS_EX_TEMP_SLOWKP, C1:PEM-SEIS_EX_TEMP_SLOWKI, C1:PEM-SEIS_EX_TEMP_SLOWKD that will control the proportional, integral and differential gain respectively. These channels are used in the script FSSSlow.py for PID control. We then had to restart the system, but first we turned off the LSC mode and then shut down the watchdog on the X end. After doing the restart, we disabled the OPLEV as well before restarting the watchdog. Then, we enabled the LSC mode again. This is done to not damage any of the optics during the restart. The restart is done by using sudo systemctl restart modbusIOC.service and restarted with sudo systemctl status modbusIOC.service. Then, we made sure that the channels existed and could be read and writtten to, so we tried z read [channel name] and it read 0.0. We then did z write [channel name] 5, and it wrote 5 to that channel. Now that the channels work, we can implement the PID script and check to make sure that it works as well.

  8911   Tue Jul 23 19:38:58 2013 gautamUpdateCDSCharacterisation of DAC at 1X9

 

 I just finished carrying out the same checks for the DAC at 1X9 (with channels 9 through 16 that are unused as of now) as those I had done for the DAC at 1Y4, as the hardware prep up till now was done with the characterisation of the DAC at 1Y4. Conclusions:

  • The accessible range of output voltage are -10 V to +10V w.r.t ground --> No change needs to be made to the gain of the HV amplifier stage on the PZT Driver Board
  • The pin-outs of the DAC Adaptor Board at 1X9 is identical to that at 1Y4 --> Custom ribbons do not need to be modified.
  • The PSD of the DAC output has a peak at 64 kHz --> Notches on AI Board do not need to be moved again.

I will now proceed to install various pieces of hardware (AI Board, PZT driver board, HV Power Supply and cabling) at 1X9, while not making the connection to the PZTs till I receive the go ahead. 

  3197   Mon Jul 12 15:49:56 2010 nancyUpdateSUSCharacterisation of the QPD

I and koji setup the measurement of the QPD response to the pitch and yaw displacements of the beam spot.

We did this using a 100mW 1064nm laser. Its power was attenuated to ~ 1.9mW, and the spot size at the QPD position was 6000-7000 um .

The QPD was put on a translation stage, using which, the center of teh QPD wrt the beam spot could be moved in pitch and yaw.

Following are the measurements :

For yaw

:fullyaw.jpg

The slope of teh linear region is -8356 /inch

yaw_linear.jpg

 For pitch

fullpitch.jpg

The slope of the linear region in this is 9085/inch

 

pitch_linear.jpg

 

  3198   Mon Jul 12 17:05:30 2010 nancyUpdateSUSCharacterisation of the QPD

Quote:

I and koji setup the measurement of the QPD response to the pitch and yaw displacements of the beam spot.

We did this using a 100mW 1064nm laser. Its power was attenuated to ~ 1.9mW, and the spot size at the QPD position was 6000-7000 um .

The QPD was put on a translation stage, using which, the center of teh QPD wrt the beam spot could be moved in pitch and yaw.

Following are the measurements :

 

 The old plots looked horrible, and so here is a new plot

plot.png

The slopes and other stats are

Pitch

Linear model Poly1:
     f(x) = p1*x + p2
Coefficients (with 95% confidence bounds):
       p1 =        8550  (7684, 9417)
       p2 =       -2148  (-2390, -1906)

Goodness of fit:
  SSE: 9944
  R-square: 0.9923
  Adjusted R-square: 0.9907
  RMSE: 44.59

Yaw

Linear model Poly1:
     f(x) = p1*x + p2
Coefficients (with 95% confidence bounds):
       p1 =       -8310  (-8958, -7662)
       p2 =        2084  (1916, 2252)

Goodness of fit:
  SSE: 6923
  R-square: 0.9954
  Adjusted R-square: 0.9945
  RMSE: 37.21

Attachment 1: plot.png
plot.png
  14111   Sat Jul 28 22:16:49 2018 John MartynUpdate Characterization of Transimpedance Amplifier

Kevin and I meaured the transfer function of the photodiode circuit using the Jenne laser and agilent in the 40m lab. The attached figures depict our measured transfer function over the modulation frequency ranges of 30kHz-30MHz and 1kHz-30MHz when the power of the laser was set to 69 and 95 μW. These plots indicate a clear roll off frequency around 300 kHz. In addition, the plots beginning at 1kHz display unstable behavior at frequencies below 30kHz. I am not sure why there is such a sharp change in the transfer function around 30kHz, but I suspect this to be due to an issue with the agilent or photodiode. 

Attachment 1: PD_TF1.pdf
PD_TF1.pdf
Attachment 2: PD_TF2.pdf
PD_TF2.pdf
Attachment 3: PD_and_TIA_Transfer_Function_Measurements.zip
  14112   Sun Jul 29 00:59:54 2018 KojiUpdateElectronicsCharacterization of Transimpedance Amplifier

You have this measurement problem when the IF bandwidth is larger than the measurement frequency. I suspect the IF bandwidth is 30kHz.

  10036   Fri Jun 13 11:33:55 2014 AkhilUpdateElectronicsCharacterization of UFC-6000 RF Frequency Counter

 Goal:

To characterize the Mini-Circuits RF FC (Model UFC-6000) and plot Bode Plots at varying Modulation frequencies.

Work Done:

Here are the list of measurements(files attached) taken from FC using SRS(Model DS345) Synthesized Function Generator for a Sinusoidal signal at different Modulation Frequencies ranging from 0.01 Hz to 1 KHz:

Carrier Frequency                          Modulation Depth                                                        Attached measurement Folder 

5 MHz                                                     Δ f = 5 MHz                                                                            Bode_5

10 MHz                                                   Δ f = 10 MHz                                                                          Bode_10

20 MHz                                                   Δ f = 20 MHz                                                                           Bode_20 

 

The measured data will be used to estimate:

1) Transfer Function of FC 

2) Quantization noise from Power Spectral Density(PSD) vs Hz

 

To Do Next:

1)Complete interfacing the Pi with EPICS.

2)Make bode plots (Matlab script attached) and PSD plots and estimate the control parameters for optimal design of FOLL PID loop.

 

 

Attachment 1: Bode_Plots.zip
  10238   Fri Jul 18 17:10:57 2014 NichinSummaryElectronicsCharacterization of demodulator boards.

Rack 1Y2, I took transfer function measurements for each of the following demodulator boards: REFL11, REFL33, REFL55, REFL165, AS55, POP22, POX11 and POY11.

What I did:

1) Removed the wire at PD Input to demodulator board.

2) Put the MOD output from network analyzer into PD input of board.

3) Ran a sweep from 100kHz to 100MHz.

4) Measured the transfer function between PD RF MON and PD Input. (The PD RF MON signal came out of the RF multiplexer, so the mux is included as well )

5) Put the original wire back at PD Input.

Results:

The plots clearly show an attenuation of 20dB (factor of 10) for all the demodulator boards. This explains why my transimpedance measurements are off by 10 times.

Note: for REFL 165, there was an extra 100MHz high pass filter installed at PD Input. I did not remove this and made my measurements along with this.

To Do:

a) Modify the PDFR system to calibrate out this attenuation.

b) Measure the transfer function between the input and output of RF mux, so that we can have just the transfer function between PD input an PD RF MON (for documentation's sake)

 

Attachment 1: Demodulators_TF.pdf
Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf
  10252   Tue Jul 22 15:50:35 2014 NichinSummaryElectronicsCharacterization of demodulator boards.

Quote:

Rack 1Y2, I took transfer function measurements for each of the following demodulator boards: REFL11, REFL33, REFL55, REFL165, AS55, POP22, POX11 and POY11.

What I did:

1) Removed the wire at PD Input to demodulator board.

2) Put the MOD output from network analyzer into PD input of board.

3) Ran a sweep from 100kHz to 100MHz.

4) Measured the transfer function between PD RF MON and PD Input. (The PD RF MON signal came out of the RF multiplexer, so the mux is included as well )

5) Put the original wire back at PD Input.

Results:

The plots clearly show an attenuation of 20dB (factor of 10) for all the demodulator boards. This explains why my transimpedance measurements are off by 10 times.

Note: for REFL 165, there was an extra 100MHz high pass filter installed at PD Input. I did not remove this and made my measurements along with this.

To Do:

a) Modify the PDFR system to calibrate out this attenuation.

b) Measure the transfer function between the input and output of RF mux, so that we can have just the transfer function between PD input an PD RF MON (for documentation's sake)

 

I repeated the exact steps above and made sure everything was back where it should be after I was done.

Reason I had to retake the measurements:

My script for acquiring data from the AG4395A network analyzer was such that it first acquired the magnitude data from channel 1 and then recorded phase data from channel 2 without holding its trace. Hence the phase and magnitude data were not exactly in sync with each other. So, when I tried to fit the data to a model using vector fitting, I ended up with very bad results.

I have now changed every single script relating to the network analyzer to just get the real and imaginary data in one go and then calculate the phase using this data.

The fitting process is now in progress and results will be up shortly.

Attachment 1: Demodulators_TF.pdf
Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf
  10263   Wed Jul 23 11:54:27 2014 NichinUpdateElectronicsCharacterization of demodulator boards.

Quote:

 

I repeated the exact steps above and made sure everything was back where it should be after I was done.

Reason I had to retake the measurements:

My script for acquiring data from the AG4395A network analyzer was such that it first acquired the magnitude data from channel 1 and then recorded phase data from channel 2 without holding its trace. Hence the phase and magnitude data were not exactly in sync with each other. So, when I tried to fit the data to a model using vector fitting, I ended up with very bad results.

I have now changed every single script relating to the network analyzer to just get the real and imaginary data in one go and then calculate the phase using this data.

The fitting process is now in progress and results will be up shortly.

The plots in the previous Elog includes delay and a little attenuation by RF cables and the RF mux.

Today I separately calculated the delay and attenuation for an RG405 cable (550 cm) and the RF mux(using really small RF cables). These delays should be accounted for when fitting the transfer function of Demodulator boards and transimpedance of PDs.

The plots are in both semilogx and linear.

Attachment 1: 1.pdf
1.pdf 1.pdf
Attachment 2: 2.pdf
2.pdf 2.pdf
  5849   Wed Nov 9 14:49:07 2011 kiwamuSummaryLSCCharacterization of the Power Recycled Michelson

EDIT by KI:

  The definition of the recycling gain is wrong here.

See the latest entry (#5875)

 

Here is a summary about the Power Recycled Michelson (PRMI).

It seems the mode matching is also one of the greatest contributor on the low recycling gain.

 

 

 (Estimated parameters)

    Loss = 5.3% (or effective reflectivity of  93.28% in Michleson) => Under coupling !!

     +  Mode matching efficiency = 47.4 %  => Really bad !!

   With these values we end up with a recycling gain of 7 and a normalized REFLDC of  0.5 as observed (#5773).

Also according the incident beam scan measurement (#5773) the loss is NOT a local effect like a clipping, it is more like uniformly distributed thing.

As for the mode matching, the number indicates that approximately the half of the incident light is coming back to the REFL port without interacting with PRMI.

This is bad because the non-mode-matched light, which is just a junk light, is entering into the photo detectors unnecessarily.

In the worst scenario, those junk light may create a funny signal, for example a signal sensitive to the alignment of PRM.

 

(Estimation method)

The method to estimate the loss and the MM (Mode-Matching efficiency) is essentially the same as before (#5541).

One difference from the previous estimation is that the I used more realistic parameters on the transmissivity of ITMs and PRM :

     PRM : T = 5.637 %  (see the 40m wiki)

     ITM : T = 1.384 %  (see the 40m wiki)

 

 In addition to the basic calculations I also made plots which are handy for figuring out where we are.

Quantities we can measure are the reflected light from PRMI and the recycling gain using the REFL PD and the POY PD respectively.

So I wanted to see how the loss and MM can be estimated from the measured REFL DC and recycling gain.

The plots below are the ones.

contour_loss.png   contour_MM.png

[Loss map]

 The first figure shows a contour map of the loss as a function of the measured REFL DC and recycling gain.

The white area is a place where no proper solutions can be found (for example MM can get to more than 100 or loss becomes negative).

The star mark in the plot corresponds to the place where we are now. Obviously the loss is about 5%.

If we somehow decrease the amount of the loss the star mark will mostly go up in the plot.

[MM map]
 The second figure shows a contour map of the MM as a function of the measured REFL DC and recycling gain. 

The X and Y axis are exactly the same as that of the first plot. Again the star mark represents the place where we are.

We are currently at MM=47%

 

(Solutions)

Here are some solutions to bring the recycling gain higher.

We don't work on these things immediately since it requires opening of the chambers again and it will take some times.

But we should think about those options and prepare some stuff for a coming vent.

  + Refinement of the position of the mode matching telescopes.  => The Recycling gain can go up to 15.

     => Assuming the loss in the cavity doesn't change, the star mark in the first plot will go to the left hand side along the "0.05" black solid line.

     => However PRMI will be still under coupled.

     => Needs an estimation about which way we move the telescopes.

 + Locate the place of the dominant loss source and reduce it somehow.

    => The recycling gain will be more than 18 if the loss reduces by a factor of more than 5.

    => Needs a clever way to find it otherwise we have to do it in the classical way (i.e. white light and trying to find dirty surfaces)

  5851   Wed Nov 9 16:29:36 2011 KojiSummaryLSCCharacterization of the Power Recycled Michelson

Difficult to understand.

The mode matching does not change the recycling gain. It changes the coupling of the incident light into the cavity.
It changes the reflected and accumulated power, but the recycling gain is not affected.

The recycling gain is determined by the optical configuration and the optical loss in the cavity.

In the actual measurement, of course, we should take both of the loss and the mode matching into account.
But this is the issue of the measurement method.

The essential questions are:
How much is the actual recycling gain? And how does it affect the signal extraction?

  5875   Fri Nov 11 14:55:47 2011 kiwamuSummaryLSCCharacterization of the Power Recycled Michelson : take 2

Quote from #5851

The recycling gain is determined by the optical configuration and the optical loss in the cavity.

How much is the actual recycling gain? And how does it affect the signal extraction?

 As Koji pointed out I made a wrong definition on the recycling gain of PRMI (Power-Recycled Michelson Interferomter).

In the correct definition the estimated recycling gain is 15.
In order to answer Koji's second question,which is about the effect on the signal extraction,
I need to scratch my head for a while.
( Give me some time..)
 
The value what I called "Recycling gain" must have been called "measured power build up" or something like that.
For clarity I put the definitions of the quantities.
    Recycling gain :      rec_gain.png 

   Reflectivity of PRMI (measured by REFLDC): refl.png

    Power build up (measured by POY DC) : pbu.png

    Mode Matching (MM) efficiency :  MM.png

    Loss in the PRMI cavity : loss.png

 


 (Results of Measurement and Estimation)

     Estimated recycling gain = 15

     Estimated MM efficiency = 47.4%

     Estimated Loss = 5.3%

     Measured power build Up = 7

     Measured reflectivity of PRMI = 0.5

  3419   Fri Aug 13 09:41:00 2010 nancyOmnistructureComputersCharger for dell laptop

 I have taken the charger for the dark gray dell laptop from its station, and have labelled the information there too.

Will keep it back tonight.

  16196   Wed Jun 9 18:29:13 2021 Anchal, PacoSummaryALSCheck for saturation in ITMX SOS Driver

We did a quick check to make sure there is no saturation in the C1:SUS-ITMX_LSC_EXC analog path. For this, we looked at the SOS driver output monitors from the 1X4 chassis near MC2 on a scope. We found that even with 600 x 10 = 6000 counts of our 619 Hz excitation these outputs in particular are not saturating (highest mon signal was UL coil with 5.2 Vpp). In comparison, the calibration trials we have done before had 600 counts of amplitude, so we can safely increase our oscillator strength by that much yes


Things that remain to be investigated -->

  • What is the actual saturation level?
  • Two-tone intermodulation?
  14060   Thu Jul 12 21:16:25 2018 aaronUpdateOMCChecking OMC Electronics

In preparation for tomorrow's vent, I'm checking some of the OMC-related electronics we plan to use.

First up is the HV Piezo Driver (D060283).

(well, technically the first up was the Kepco HV power supply... but I quickly tested that its output works up to 300V on a multimeter. The power supply for OMC-L-PZT is all good!)

According to the DCC, the nominal HV supply for this board is 200V; the board itself is printed with "+400V MAX", and the label on the HV supply says it was run at 250V. For now I'm applying 200V. I'm also supplying +-15V from a Tektronix supply.

I used two DB25 breakout boards to look at the pins for the DC and AC voltage monitors (OMC_Vmon_+/-, pins 1/6, and OMC_Vmon_AC+/-, pins 2 and 7) on a scope. I hooked up a DS345 function generator to the piezo drive inputn (pins 1,6). According to the 2013 diagram from the DCC, there is just one drive input, and an alternative "dither in" BNC that can override the DAC drive signal. I leave the alternative dither floating and am just talking to the DAC pins.

Aspects of the system seem to work. For example, I can apply a sine wave at the input, and watch on the AC monitor FFT as I shift the frequency. However, anything I do at DC seems to be filtered out. The DC output is always 150V (as long as 200V comes from the supply). I also notice that the sign of the DC mon is negative (when the Vmon_+ pin is kept high on the scope), even though when I measure the voltage directly with a multimeter the voltage has the expected (+) polarity.

A few things to try:

  • The DC_Readout electronics scheme on the wiki has separate oscillator and control inputs. This diagram has lied to us in the past and is older, and the traces on top of the breadboard seem to only go to pins 1 and 6, but I'm going to first try to apply a voltage across pins 2 and 7 in case there actually is a separate control I'm ignoring.
    • Driving on these pins seems to do nothing

On further investigation this was the key clue. I had the wrong DCC document, this is an old version of this board, the actual board we are using is version A1 of D060283-x0 (one of the "other files")

Gautam and Koji returned at this point and we started going through the testpoints of the board, before quickly realizing that the DC voltage wasn't making it to the board. Turns out the cable was a "NULL" cable, so indeed the AC wasn't passing. We swapped out the cable, and tested the circuit with 30V from the HV supply to trim the voltage reference at U14. The minimum voltage we could get is 5V, due to the voltage divider to ground made by R39. We confirmed that the board, powered with 200V, can drive a sine wave and the DC and AC mons behave as expected.

  14072   Sat Jul 14 16:04:34 2018 aaronUpdateOMCChecking OMC Electronics

Next check is the DCPD/OMMT Satellite Box

I traced a cable from the OMC electrical feedthrough flanges to find the DCPD/OMMT Satellite Box (D060105). I couldn't find the DCC number or mention of the box anywhere except this old elog.

Gautam and I supplied the box with power and tested what we think is the bias for the PD, but don't read any bias... we tracked down the problem to a suspicious cable, labelled.

We confirmed that the board supplies the +5V bias that Rich told us we should supply to the PDs.

We tested the TFs for the board from the PD input pins to output pins with a 100kHz low pass (attached, sorry no phase plots). The TFs look flat as expected. The unfiltered outputs of the board appear bandpassed; we couldn't identify why this was from the circuit diagram but didn't worry too much about it, as we can plan to use the low passed outputs.

Attachment 1: Screenshot_2018-07-14_17.53.40.png
Screenshot_2018-07-14_17.53.40.png
Attachment 2: Screenshot_2018-07-14_17.57.17.png
Screenshot_2018-07-14_17.57.17.png
  4904   Tue Jun 28 22:36:04 2011 JamieUpdateSUSChecking binary switching of SUS whitening filter

I have been checking the binary output switching for the SUS whitening filters. It appears that the whitening switching is working for (almost) all the vertex suspensions (BS, ITMX, ITMY, PRM, SRM), but not for the ETMs.

The table below lists the output from my switch-checking script (attached). The script uses the SUS digital lockin to drive one coil and measure the same coil's OSEM response, repeating for each coil/OSEM pair. I used a lockin drive frequency of about 10 Hz, at which the whitening filter should have 10 db of gain.

All but one of the vertex OSEMS show the proper response (~10db gain at 10Hz) when the whitening is switched on from the digital controls. ITMY UL appears to not be switching, which I fear is due to my electronics fail noted in my previous log post.  The ETMs are clearly not switching at all.

I will try to get the ETM switching working tomorrow, as well as try to asses what can be done about the ITMY UL switch.  After that I will work on confirming the coil drive dewhite switching.

lockin settings

freq: 10.123 Hz
amp: 10000
I/Q filters: 0.1 Hz LP, 4-pole butterworth

response

BS
ul : 3.31084503062 = 10.3987770676 db
ll : 3.34162124753 = 10.4791444741 db
sd : 3.43226254574 = 10.7116100229 db
lr : 3.28602651913 = 10.3334212798 db
ur : 3.29361593249 = 10.3534590969 db

ITMX
ul : 3.37499773336 = 10.5654697099 db
ll : 3.2760924572  = 10.3071229966 db
sd : 3.13374799272 =  9.9212813757 db
lr : 3.28133776018 = 10.3210187243 db
ur : 3.37250879937 = 10.5590618297 db

ITMY
ul : 0.99486434364 = -0.0447226830807 db
ll : 3.39420873724 = 10.6147709414 db
sd : 3.88698713176 = 11.7922620572 db
lr : 3.357123865   = 10.5193473069 db
ur : 3.37876008179 = 10.5751470918 db

PRM
ul : 3.26758918055 = 10.2845489876 db
ll : 3.32023820566 = 10.4233848529 db
sd : 3.25205538857 = 10.2431586766 db
lr : 3.24610681962 = 10.227256141  db
ur : 3.31311970305 = 10.4047425446 db

SRM
ul : 3.30506423619 = 10.3835980943 db
ll : 3.28152094133 = 10.3215036019 db
sd : 3.08566647696 =  9.7869796462 db
lr : 3.30298270419 = 10.378125991  db
ur : 3.3012249406  = 10.3735023505 db

ETMX
ul : 0.99903400106 = -0.00839461539757 db
ll : 0.99849991349 = -0.0130393683795 db
sd : 1.00314092883 =  0.0272390056874 db
lr : 1.00046493718 =  0.00403745453682 db
ur : 1.00265600785 =  0.0230392084558 db

ETMY
ul : 1.00223179107 =  0.0193634913327 db
ll : 0.96755532811 = -0.286483823189 db
sd : 1.00861855271 =  0.0745390477589 db
lr : 1.05718545676 =  0.483023602007 db
ur : 0.99777406174 = -0.0193558045143 db
Attachment 1: botest.py
#!/usr/bin/env python

import sys
import os
import subprocess
import time
import pickle
from numpy import *
import nds
import matplotlib
... 207 more lines ...
  696   Fri Jul 18 17:12:35 2008 JenneUpdateIOOChecking out the MC Servo Board
[Jenne, Max]

One of the things that Rana thinks that might be causing my MC_F calibration to be off is that the MC Servo Board's filters don't match those on the schematics. Max and I pulled the MC servo board today to check resistor and capacitor values. Alberto needed the Mode Cleaner, so we put the board back before finishing checking values. We will probably pull the board again next week to finish checking the values.

I haven't checked to ensure that the MC still locks, because Yoichi is doing stuff on the PSL table, but I didn't change anything on the board, and hooked all the cables back where they were, so hopefully it's all okay.
  697   Fri Jul 18 19:15:15 2008 JenneUpdateIOOChecking out the MC Servo Board

Quote:
[Jenne, Max]

I haven't checked to ensure that the MC still locks, because Yoichi is doing stuff on the PSL table, but I didn't change anything on the board, and hooked all the cables back where they were, so hopefully it's all okay.


I put the PMC back and the MC now locks.
  11603   Tue Sep 15 20:44:13 2015 gautamSummaryLSCChecking the delay line phase shifter DS050339
I checked out the delay line phase shifter D050339, (theory of operation here) this afternoon. I first checked that the power connection was functional, which it was, though the power connector is is not the usual chassis one (see image attached, do we need to change this?).

The box has two modes of operation - you can either change the delay by flipping switches on the front panel or via a 25pin D-sub connector on the back (the pin numberings for this connector on the datasheet are a little misleading, but I determined that pins 1-9 on the D-sub connector correspond to the 9 delays on the front panel in ascending order, pin 10 is the mode selector switch, should be high for remote operation, pins 11 and 13 are NC, pin 12 is VCC of 5V, and pins 14-25 are grounded). I first checked the front-panel mode of operation, using an oscilloscope to measure the delay between the direct signal from the Fluke 6061 and the output from the D050339. This corresponds to the first set of datapoints in the plot attached (signal was 100MHz sine wave).

I then used a 25 pin D sub breakout boards to check the remote operation mode as well, which corresponds to the second set of datapoints in the plot attached. For this measurement, I used the Agilent network analyzer to measure the phase lag between the direct signal (for all delays, I measured the phase lag at 100MHz, having first calibrated the "thru" path by connecting the R and A inputs of the network analyzer using a barrel BNC) and the delayed output from the box, and then converted it to a time delay.

Both sets of data are linear, with a slope nearly equal to 1 as expected. I conclude that the box is functioning as expected. Right now, Koji is checking a board which will be used to remotely control this box. On the hardware side it remains to make a cable going from the DS050339 Dsub input to the driver board output (also 25 pin Dsub).
Attachment 1: IMG_20150915_193100.jpg
IMG_20150915_193100.jpg
Attachment 2: Calibration.pdf
Calibration.pdf
  16442   Mon Nov 1 14:51:34 2021 KojiUpdateGeneralChecking the vent plan

The vent team described a detailed vent plan (and reports where the actions have been performed)

https://wiki-40m.ligo.caltech.edu/vent/Fall2021

- [Sec.4] We should decide the final PR2 mirror through table-top measurements.

- [Sec 6] BS alignment is probably "unknown" now. So it'd be better to use the ITMY spot as the reference, then align BS for ITMX. For temporary alignment, it's OK though.

- [Sec 9-11] RIght now there is no mounts to place LO3/LO4/AS2/AS3/BHDBS. But we probably want to test something before the installation of the BHD? Just place the BHDBS on a optics mount so that we get an interfered beam on ITMY?

At this point we are supposed to have all the electronics all the CDS necessary for the new SOS control. Otherwise, they are just swinging and the alignment work will just be impossible.

- [Sec 15] The OPLEV mirrors can be freely moved as long as it does not block the main IR beams. Moving ITMXOL1 makes the reflection blocked by ITMXOL2. And moving ITMXOL2 would make the IR beams clipped. Consider replacing the mounts with a fixed mount. (The OPLEV mirrors are 1.5" in dia. It is not common vacuum compatible 1.5inch mounts. If 1" Al mirror is sufficient, we can use it.

https://wiki-40m.ligo.caltech.edu/vent/Fall2021/FinalAlignment

- The arms are the most strict alignment requirement. Everything else will follow the arm alignment. So start from the arms and propagate the alignment to Michelson / PRMI / SRMI.

- We reestablish arm alignment using the end green beams.

- Then recover IR arm alignment. Consider using ASS if possible

  2762   Sun Apr 4 00:21:42 2010 rana, kojiSummaryElectronicsCheckout of EG&G (PARC) preamp model #113, s/n 49135

We tested out the functionality of the EG&G 113 preamp that I found in one of the cabinets. This is one of the ancestors of the SR560 preamp that we are all used to.

It turns out that it works just fine (in fact, its better than the SR560). The noise is below 3nV/rHz everywhere above 30 Hz. The filter settings from the front panel all seem to work well. And the red knob on the front panel allows for continuous (i.e. not steps) gain adjustment. In the high-bandwidth mode (low pass filter at 300 kHz), there is ~35 deg of phase lag at 100 kHz. So the box is pretty fast.

IMG_0628.JPG

I would easily recommend this above the SR560 for use in all applications where you don't need to drive a 50 Ohm load. Also the battery is still working after 17 years!

There's several more of the this vintage in one of the last cabinets down the new Y-arm.

  15543   Wed Aug 26 22:49:47 2020 gautamUpdateElectronicsCheckout of Trek Model 603

I unboxed the Trek amplifier today, and performed some basic tests of the functionality. It seems to work as advertised. However, we may have not specified the correct specifications - the model seems to be configured to drive a bipolar output of +/- 125 V DC, whereas for PZT driving applications, we would typically want a unipolar drive signal. From reading the manual, it appears to me that we cannot configure the unit to output 0-250V DC, which is what we'd want for general PZT driving applications. I will contact them to find out more. 

The tests were done using the handheld precision voltage source for now. I drove the input between 0 to +5 V and saw an output voltage (at DC) of 0-250 V. This is consistent with the voltage gain being 50V/V as is stated in the manual, but how am I able to get 250 V DC output even though the bipolar configuration is supposed to be +/- 125 V? On the negative side, I am able to see 50V/V gain from 0 to -1 V DC. At which point making the input voltage more negative does nothing to the output. The unit is supposed to accept a bipolar input of +/- 10 V DC or AC, so I'm pretty sure I'm not doing anything crazy here...

Update:

Okay based on the markings on the rear panel, the unit is in fact configured for unipolar output. What this means is we will have to map the +/- 10 V DC output from the DAC to 0-5 V DC. Probably, I will stick to 0-2.5 V DC for a start, to not exceed 125 V DC to the PI PZT. I'm not sure what the damage spec is for that. The Noliac PZT I think can do 250 V DC no problem. Good thing I have the inverting summing amplifier coming in tomorrow...

Attachment 1: IMG_8951.JPG
IMG_8951.JPG
  11579   Fri Sep 4 20:42:14 2015 gautam, ranaUpdateCDSCheckout of the Wenzel dividers

Some years ago I bought some dividers from Wenzel. For each arm, we have x256 and a x64 divider. Wired in series, that means we can divide each IR beat by 2^14.

The highest frequency we can read in our digital system is ~8100 Hz. This corresponds to an RF frequency of ~132 MHz which as much as the BBPD could go, but less than the fiber PDs.

Today we checked them out:

  1. They run on +15V power.
  2. For low RF frequencies (< 40 MHz) the signal level can be as low as -25 dBm.
  3. For frequencies up to 130 MHz, the signal should be > 0 dBm.
  4. In all cases, we get a square wave going from 0 ~ 2.5 V, so the limiter inside keeps the output amplitude roughly fixed at a high level.
  5. When the RF amplitude goes below the minimum, the output gets shaky and eventually drops to 0 V.

Since this seems promising, we're going to make a box on Monday to package both of these. There will one SMA input and output per channel.

Each channel will have a an amplifier since this need not be a low noise channel. The ZKL-1R5 seems like a good choice to me. G=40 dB and +15 dBm output.

Then Gautam will make a frequency counter module in the RCG which can do counting with square waves and not care about the wiggles in the waveform.

I think this ought to do the trick for our Coarse frequency discriminator. Then our Delay Box ought to be able to have a few MHz range and do all of the Fast ALS Carm that we need.

Attachment 1: TEK00000.PNG
TEK00000.PNG
Attachment 2: TEK00001.PNG
TEK00001.PNG
Attachment 3: TEK00002.PNG
TEK00002.PNG
  11307   Tue May 19 11:15:09 2015 ericqUpdateComputer Scripts / ProgramsChiara Backup Hiccup

Starting on the 14th (five days ago) the local chiara rsync backup of /cvs/cds to an external HDD has been failing:

caltech/c1/scripts/backup/rsync_chiara.backup.log:

2015-05-13 07:00:01,614 INFO       Updating backup image of /cvs/cds
2015-05-13 07:49:46,266 INFO       Backup rsync job ran successfully, transferred 6504 files.
2015-05-14 07:00:01,826 INFO       Updating backup image of /cvs/cds
2015-05-14 07:50:18,709 ERROR      Backup rysnc job failed with exit code 24!
2015-05-15 07:00:01,385 INFO       Updating backup image of /cvs/cds
2015-05-15 08:09:18,527 ERROR      Backup rysnc job failed with exit code 24!
...
 

Code 24 apparently means "Partial transfer due to vanished source files."

Manually running the backup command on chiara worked fine, returning a code of 0 (success), so we are backed up. For completeness, the command is controls@chiara: sudo rsync -av --delete --stats /home/cds/ /media/40mBackup

Are the summary page jobs moving files around at this time of day? If so, one of the two should be rescheduled to not conflict. 

  11327   Wed May 27 15:20:54 2015 ericqUpdateComputer Scripts / ProgramsChiara Backup Hiccup

The local chiara backups are still failing due to vanished source files. I've emailed Max about the summary page jobs, since I think they're running remotely. 

  11336   Fri May 29 11:28:42 2015 ericqUpdateComputer Scripts / ProgramsChiara Backup Hiccup

I've changed the chiara local backup script to read a folder exclusion file, and excluded /users/public_html/detcharsummary, and things are working again. 

This was neccesary because the summary pages are being updated every half hour, which is faster than the time it takes for the backup script to run, so the file index that it builds at the start becomes invalid later on in the process. 


Thinking about chiara's disk, it strikes me that when we went from the linux1 RAID to a single HDD on chiara, we may have tightened a bottleneck on our NFS latency, i.e. we are limited to that single hard drive's IO rates. This of course isn't the culprit for the more recent dramatic slowdowns, but in addition to fixing whatever has happened more recently, we may want to consider some kind of setup with higher IO capability for the NFS filesystem. 

  11337   Fri May 29 12:49:53 2015 KojiUpdateComputer Scripts / ProgramsChiara Backup Hiccup

In fact, the file access is supposed to be WAY faster now than in the RAID case.

As noted in ELOG 9511, it was SCSI-2(or 3?) that had ~6MB/s thruput. Previously the backup took ~2hours.
This was improved to 30min by SATA HDD on llinux1.

I am looking at /opt/rtcds/caltech/c1/scripts/backup/rsync.backup.cumlog

In fact, this "30-min backup" was true until the end of March. After that the backup is taking 1h~1.5h.

This could be related to the recent NFS issue?

  11338   Fri May 29 15:12:39 2015 KojiUpdateComputer Scripts / ProgramsChiara Backup Hiccup

Actual data

Attachment 1: backup_hours.pdf
backup_hours.pdf
  16310   Thu Sep 2 20:44:18 2021 KojiUpdateCDSChiara DHCP restarted

We had the issue of the RT machines rebooting. Once we hooked up the display on c1iscex, it turned out that the IP was not given at it's booting-up.

I went to chiara and confirmed that the DHCP service was not running

~>sudo service isc-dhcp-server status
[sudo] password for controls:
isc-dhcp-server stop/waiting

So the DHCP service was manually restarted

~>sudo service isc-dhcp-server start
isc-dhcp-server start/running, process 24502
~>sudo service isc-dhcp-server status
isc-dhcp-server start/running, process 24502

 

 

  16311   Thu Sep 2 20:47:19 2021 KojiUpdateCDSChiara DHCP restarted

[Paco, Tega, Koji]

Once chiara's DHCP is back, things got much more straight forward.
c1iscex and c1iscey were rebooted and the IOPs were launched without any hesitation.

Paco ran rebootC1LSC.sh and for the first time in this year we had the launch of the processes without any issue.

  13154   Mon Jul 31 20:35:42 2017 KojiSummaryComputersChiara backup situation summary

Summary
- CDS Shared files system: backed up
- Chiara system itself: not backed up


controls@chiara|~> df -m
Filesystem     1M-blocks    Used Available Use% Mounted on
/dev/sda1         450420   11039    416501   3% /
udev               15543       1     15543   1% /dev
tmpfs               3111       1      3110   1% /run
none                   5       0         5   0% /run/lock
none               15554       1     15554   1% /run/shm
/dev/sdb1        2064245 1718929    240459  88% /home/cds
/dev/sdd1        1877792 1426378    356028  81% /media/fb9bba0d-7024-41a6-9d29-b14e631a2628
/dev/sdc1        1877764 1686420     95960  95% /media/40mBackup

/dev/sda1 : System boot disk
/dev/sdb1 : main cds disk file system 2TB partition of 3TB disk (1TB vacant)
/dev/sdc1 : Daily backup of /dev/sdb1 via a cron job (/opt/rtcds/caltech/c1/scripts/backup/localbackup)

/dev/sdd1 : 2014 snap shot of cds. Not actively used. USB

https://nodus.ligo.caltech.edu:8081/40m/11640

 

  13159   Wed Aug 2 14:47:20 2017 KojiSummaryComputersChiara backup situation summary

I further made the burt snapshot directories compressed along with ELOG 11640. This freed up additional ~130GB. This will eventually help to give more space to the local backup (/dev/sdc1)

controls@chiara|~> df -m
Filesystem     1M-blocks    Used Available Use% Mounted on
/dev/sda1         450420   11039    416501   3% /
udev               15543       1     15543   1% /dev
tmpfs               3111       1      3110   1% /run
none                   5       0         5   0% /run/lock
none               15554       1     15554   1% /run/shm
/dev/sdb1        2064245 1581871    377517  81% /home/cds
/dev/sdd1        1877792 1426378    356028  81% /media/fb9bba0d-7024-41a6-9d29-b14e631a2628
/dev/sdc1        1877764 1698489     83891  96% /media/40mBackup

 

 

  14385   Fri Jan 4 15:18:15 2019 KojiUpdateGeneralChiara disk clean up and internally mounted

[Koji Gautam]

Took the opprtunity of the power glitch to take care of the disk situation of chiara.

- Unmounted /cvs/cds from nodus. This did not affect the services on nodus as they don't use /cvs/cds

- Go to chiara, shut it down, and physically checked the labels of the drives.

root = 0.5TB
/cvs/cds = 4TB HGST
backup of /cvs/cds= 6TB HGST

- These three disks are internally mounted and connected with SATA. Previously, 6TB was on USB.

- There were two other drives (2TB and 3TB) but they seemed logically or physically broken. These two disks were removed from chiara. (they came back online after reformatting on mac. So they seem still physically alive).

controls@chiara|~> df
df: `/var/lib/lightdm/.gvfs': Permission denied
Filesystem      1K-blocks       Used  Available Use% Mounted on
/dev/sda1       461229088   10690932  427109088   3% /
udev             15915020          4   15915016   1% /dev
tmpfs             3185412        848    3184564   1% /run
none                 5120          0       5120   0% /run/lock
none             15927044        144   15926900   1% /run/shm
/dev/sdb1      5814346836 1783407788 3737912972  33% /media/40mBackup
/dev/sdc1      3845709644 1884187232 1766171536  52% /home/cds
controls@chiara|~> lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 465.8G  0 disk
├─sda1   8:1    0 446.9G  0 part /
├─sda2   8:2    0     1K  0 part
└─sda5   8:5    0  18.9G  0 part [SWAP]
sdb      8:16   0   5.5T  0 disk
└─sdb1   8:17   0   5.5T  0 part /media/40mBackup
sdc      8:32   0   3.7T  0 disk
└─sdc1   8:33   0   3.7T  0 part /home/cds
sr0     11:0    1  1024M  0 rom

- Rebooted the machine and just came back without any error. This time the control room machines were not shutdown, but they just recovered the NFS once chiara got back.

Attachment 1: P_20190104_143336.jpg
P_20190104_143336.jpg
Attachment 2: P_20190104_143357.jpg
P_20190104_143357.jpg
  10837   Tue Dec 23 14:33:24 2014 SteveUpdateVACChiara gets UPS

Quote:

Quote:

We had an unexpected power shutdown for 5 sec at ~ 9:15 AM.

Chiara had to be powered up and am in the process of getting everything else back up again.

Steve checked the vacuum and everything looks fine with the vacuum system.

PSL Innolight laser and the 3 units of IFO air conditions turned on.

The vacuum system reaction to losing power: V1 closed and Maglev shut down. Maglev is running on 220VAC so it is not connected to VAC-UPS.  V1 interlock was triggered by Maglev "failure" message.

Maglev was reset and started. After Chiara was turned on manually I could bring up the vac control screen through Nodus and opened V1

"Vacuum Normal" valve configuration was recovered instantly.

 

Chiara needs UPS 

It is arriving Thursday

 EricQ and Steve,

Steve preset the vacuum for safe-reboot mode with C1vac1 and C1vac2 running normal: closed valves as shown, stopped Maglev & disconnected valves V1 plus valves with moving labels.

(The position indicator of the valves changes to " moving " when its cable disconnected )

Eric shut down Chiara, installed APC's UPS Pro 1000 and restarted it.

All went well. Nothing unexpected happened. So we can conclude that the vacuum system with running C1vac1 and C1vac2 is not effected by Chiara's losing AC power.

Attachment 1: prepUP.png
prepUP.png
  11481   Thu Aug 6 01:38:19 2015 ericqUpdateComputer Scripts / ProgramsChiara gets new Ethernet card

Since Chiara's onboard ethernet card has a reputation to be flaky in Linux, Koji suggested we could just buy a new ethernet card and throw it in there, since they're cheap. 

I've installed a Intel EXPI9301CT ethernet card in Chiara, which detected it without problems. I changed over the network settings in /etc/networking/interfaces to use eth1 instead of eth0, restarted nfs and bind9, and everything looked fine. 

Sadly, EPICS/network slowdowns are still happening. :(

ELOG V3.1.3-