40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 213 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  12239   Fri Jul 1 17:51:28 2016 PrafulSummaryElectronicsReplacing DIMM on Optimus

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  15692   Wed Dec 2 12:27:49 2020 JonUpdateVACReplacing pressure gauges

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

In summary:

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

Required hardware:

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

 

Quote:

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

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

 

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

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

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

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

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

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

  1681   Tue Jun 16 20:03:41 2009 AlbertoUpdateElectronicsRequirements on Wenzel Multiplier

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

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

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

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

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

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

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

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

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

 

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

  3274   Fri Jul 23 10:16:44 2010 josephbUpdateCDSRerouted RFM around c1lsc, took RFM card out of c1lsc

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

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

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

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

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

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

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

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

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

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

Quote:

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

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

 

  16340   Thu Sep 16 20:18:13 2021 AnchalUpdateGeneralReset

Fridge brought back inside.

Quote:

Put outside.

Quote:

It happened again. Defrosting required.

 

 

  10743   Mon Dec 1 17:43:22 2014 JenneUpdateLSCReset Yarm trans normalization

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

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

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


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

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

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

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

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

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

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

It remains to be seen whether this phase delay is good enough to lock the laser to the OMC cavity
  8054   Mon Feb 11 12:49:54 2013 JenneSummaryLSCResonant freq change - why? (and passive TT mode freqs)

Quote:

  Is it because of the change in the resonant frequency of the BS-PRM stack? How much the load on BS-PRM changed?
  Or is it because of the change in the resonant frequency of PR2/PR3

I claim that neither of those things is plausible.  We took out 1 PZT, and put in 1 active TT onto the BS table.  There is no way the resonant frequency changed by an appreciable amount due to that switch.

I don't think that it is the resonant frequency of the TTs either.  Here, I collate the data that we have on the resonant frequencies of our tip tilts.  It appears that in elog 3425 I recorded results for TTs 2 and 3, but in elog 3447 I just noted that the measurements had been done, and never put them into the elog.  Ooops.

Resonant frequency and Q of modes of passive tip tilts. 

  Vertical Yaw Pos Side
TT1 f0=20, Q=18 f0=1.89, Q=3.8 f0=1.85, Q=2 f0=1.75, Q=3.2
TT2 f0=24, Q=7.8 f0=1.89, Q=2.2 f0=1.75, no Q meas f0=1.8, Q=4.5
TT3 f0=20, Q=34 f0=1.96, Q="low" f0=1.72, Q=3.3 f0=1.85, Q=6
TT4 f0=21, Q=14 f0=1.88, Q=2.3 f0=1.72, Q=1.4 f0=1.85, Q=1.9
TT5 f0=20, Q=22.7 no measurement f0=1.79, Q=1.8 f0=1.78, Q=3.5

Notes:  "Serial Number" of TTs here is based on the SN of the top suspension point block.  This does not give info about which TT is where.  Pitch modes were all too low of Q to be measured, although we tried.

Tip tilt mode measurements were taken with a HeNe and PD shadow sensor setup - the TT's optic holder ring was partially obscuring the beam.

  16914   Tue Jun 14 19:34:06 2022 yutaUpdateSUSResonant frequency identification from the free swing test

[JC, Anchal, Yuta]

We are working on resonant frequency idendification from the free swing test done last weekend.
Table below is the resonant frequencies identified, and attached are the plots of peak identification for some of our new suspensions.
To identify the resonant frequencies, the kicks were done in each degrees of freedom so that we can assume, for example, SUSPOS will be mostly excited when kicked in POS and the heighest peak is at the POS resonant frequency.
For PR3, AS1 and ETMY, the resonant frequency idendification needs to be done in the order of POS, PIT, YAW, SIDE and identified frequencies need to be removed when finding a peak.
Other than that, the identification was done without any prior assumptions on the suspensions.
For ITMY, ETMY, PR2, PR3, AS1, AS4, yaw has lower resonant frequencies than pitch, as opposed to other suspensions.
For LO1, POS and PIT frequencies might be swapped because LLCOIL is not working (40m/16898) and POS/PIT kicks both might be excited SUSPOS/PIT.
LO1 coil output matrix was temporarily modified so that we use only two coils for POS/PIT/YAW excitation (Attachment #7), as we did for ITMY (40m/16899).

The scripts for the free swinging test and analysis live in /Git/40m/scripts/SUS/InMatCalc

     POS    PIT    YAW    SIDE
BS   0.990  0.748  0.794  0.959 
ITMY 0.987  0.739  0.634  0.948 fPIT > fYAW
ETMY 0.979  0.816  0.649  0.954 fPIT > fYAW
ITMX 0.978  0.586  0.758  0.959 
ETMX 0.962  0.725  0.847  1.000 
PRM  0.939  0.541  0.742  0.990 
PR3  1.019  0.885  0.751  0.989 fPIT > fYAW
PR2  0.996  0.816  0.724  0.999 fPIT > fYAW
SRM  0.969  0.533  0.815  0.985 
SR2  0.978  0.720  0.776  0.997 
LO1  0.926  1.011  0.669  0.993 POS AND PIT MIGHT BE SWAPPED
LO2  0.964  0.998  0.995  0.990 WRONG DUE TO STUCK (40m/16913)
AS1  1.028  0.832  0.668  0.988 fPIT > fYAW
AS4  1.015  0.800  0.659  0.991 fPIT > fYAW
MC1  0.967  0.678  0.797  0.995 
MC2  0.968  0.748  0.815  0.990 
MC3  0.978  0.770  0.841  0.969 
  4495   Wed Apr 6 22:13:24 2011 BryanConfigurationGreen LockingResonating green light!

Every so often things just work out. You do the calculations, you put the lenses on the bench, you manually adjust the pointing and fiddle with the lenses a bit, you get massive chunks of assistance from Kiwamu to get the alignment controls and monitors set up and after quite a bit of fiddling and tweaking the cavity mirror alignment you might get some nice TEM_00 -like shapes showing up on your Y-arm video monitors.

So. We have resonating green light in the Y-arm. The beam is horribly off-axis and the mode-matching, while close enough to give decent looking spots, has in no way been optimised yet. Things to do tomorrow - fix the off-cavity-axis problem and tweak up the mode-matching... then start looking at the locking...

  10278   Sat Jul 26 14:45:33 2014 GabrieleMetaphysicsASCResponse of POP QPD

 Koji asked me to perform a simulation of the response of POP QPD DC signal to mirror motions, as a function of the CARM offset. Later than promised, here are the first round of results.

I simulated a double cavity, and the PRC is folded with parameters close to the 40m configuration. POP is extracted in transmission of PR2 (1ppm, forward beam). For the moment I just placed the QPD one meter from PR2, if needed we can adjust the Gouy phase. There are two QPDs in the simulation: one senses all the field coming out in POP, the other one is filtered to sense only the contribution from the carrier field. The difference can be used to compute what a POP_2F_QPD would sense. All mirrors are moved at 1 Hz and the QPD signals are simulated:

pop_qpd_all.png

This shows the signal on the POP QPD when all fields (carrier and 55 MHz sidebands) are sensed. This is what a real DC QPD will see. As expected at low offset ETM is dominant, while at large offset the PRC mirrors are dominant. It's interesting to note that for any mirror, there is one offset where the signal disappears.

pop_qpd_carrier.png

This is the contribution coming only from the carrier. This is what an ideal QPD with an optical low pass will sense. The contribution from the carrier increases with decreasing offset, as expected since there is more power.

pop_qpd_sb.png

Finally, this is what a 2F QPD will sense. The contribution is always dominated by the PRC mirrors, and the ETM is negligible.

The zeros in the real QPD signal is clearly coming from a  cancellation of the contributions from carrier and sidebands.

The code is attached.

  10888   Tue Jan 13 01:11:51 2015 diegoUpdateLSCResponse of error signals to MICH EXC

For several MICH offsets, I measured the response of REFL33Q, ASDC and the ratio ASDC/POPDC to a MICH EXC. It appears that there is no frequency-dependent effect. The plots for MICH_OFFSET = 0.0 and 2.0 are slightly lower in magnitude: the reason is they were the first measurements done, and after that a little realignment of BS was necessary, so probably that is the reason.

 

 

  585   Fri Jun 27 18:21:01 2008 JenneUpdateElectronicsResponse of the LO input on the MC demod board
The alarm handler has been flipping out saying that the LO input of the MC's demod board is too low, so at Rana's suggestion, Eric and I measured the response of the LO input. We used an SR345 function generator at 29.485MHz and several different amplitudes to make a table. The demod board should see an input from the LO between 0-2dBm. When I measured what was going into the LO input from the 29.5MHz delay line phase shifter, the LO input was seeing 4dBm. I'm going to put a 3dB attenuator between the phase shifter and the demod board.

Also, now that we have this table of response values, I'm going to change the settings of the alarm handler to something more reasonable.
Amplitude of 29.485MHz input sine wave [dBm]    |        Value of channel C1:IOO-MC_DEMOD_LO
--------------------------------------------    |        -----------------------------------
-10                                             |        -0.000449867
-8                                              |        -0.000449867
-6                                              |        -0.000449867
-4                                              |        0.000384331
-2                                              |        0.00526733
0                                               |        0.0199163
2                                               |        0.0492143
4                                               |        0.0931613
6                                               |        0.161523
8                                               |        0.229885
10                                              |        0.293364
  275   Sat Jan 26 18:48:43 2008 JohnSummaryComputersRestart iscepics
iscepics died this afternoon. We restarted it and restored settings from yesterday. I've written up instructions in the wiki.
  5396   Tue Sep 13 19:04:58 2011 SureshUpdateComputer Scripts / ProgramsRestarted Frame builder several times while compiling c1ioo, c1mcs and c1rfm

I restarted the frame builder at the following times

 

Tue Sep 13 14:53:49 PDT 2011

 

Tue Sep 13 16:46:32 PDT 2011

 

Tue Sep 13 17:24:16 PDT 2011

  1564   Fri May 8 10:05:40 2009 AlanOmnistructureComputersRestarted backup since fb40m was rebooted

Restarted backup since fb40m was rebooted.

  5828   Mon Nov 7 11:50:42 2011 JenneUpdateelogRestarted elog

Elog restart script killed the elog, but didn't restart it.  Restarted by hand.

  5829   Mon Nov 7 12:51:44 2011 ZachUpdateelogRestarted elog

I've noticed that it always takes running the script twice for it to actually work. I think there's something wrong with how it's doing it. I'll mess with it sometime the elog isn't getting much use.

Quote:

Elog restart script killed the elog, but didn't restart it.  Restarted by hand.

 

  8420   Sun Apr 7 20:49:19 2013 ZachUpdateGeneralRestarted elog

with the script, as it was down.

  8428   Tue Apr 9 01:46:40 2013 ZachUpdateGeneralRestarted elog

Again.

Quote:

with the script, as it was down.

 

  3648   Tue Oct 5 13:46:26 2010 josephb, alexUpdateCDSRestarted fb trending

Fb is now once again actually recording trends.

A section of the daqdrc file (located in /opt/rtcds/caltech/c1/target/fb/ directory) had been commented out by Alex and never uncommented.  This section included the commands which actually make the fb record trends.

The section now reads as:

# comment out this block to stop saving data

#
start frame-saver;
sync frame-saver;
start trender;
start trend-frame-saver;
sync trend-frame-saver;
start minute-trend-frame-saver;
sync minute-trend-frame-saver;
start raw_minute_trend_saver;
#start frame-writer "225.225.225.1" broadcast="131.215.113.0" all;
#sleep 5;

  667   Mon Jul 14 12:43:07 2008 JohnSummaryComputersRestarted fb40m, tpman and c1ass
  2998   Thu May 27 08:22:57 2010 AidanUpdateComputersRestarted the elog this morning
  4365   Tue Mar 1 08:42:18 2011 AidanUpdateelogRestarted the elog this morning

 The elog was dead this morning. I reanimated it. It is now undead.

  4575   Wed Apr 27 20:14:16 2011 AidanSummaryelogRestarted with script ...
  4744   Thu May 19 00:15:20 2011 JenneUpdateelogRestarted, Italian-style

Aka, from a hotel in Pisa.

  4745   Thu May 19 00:22:21 2011 ranaUpdateelogRestarted, Italian-style

Quote:

Aka, from a hotel in Pisa.

 Restarted Thu May 19 00:21:49 2011 to recover from Jenne's Italian terrorism.

  10080   Fri Jun 20 11:43:30 2014 ericqUpdateComputer Scripts / ProgramsRestarting ELOG

Manasa let me know that the ELOG was down, and that she used the normal restart procedure, but then all entries were gone. 

This is because the ELOG has been moved on nodus, so going to the old place and running the restart script starts up the old dysfunctional ELOG installation. 

The proper place to restart the ELOG is now nodus:/export/home/elog/start-elog.csh

I'm updating the relevant 40m wiki page now. 

  15995   Mon Apr 5 08:25:59 2021 Anchal, PacoUpdateGeneralRestore MC from early quakes

[Paco, Anchal]

Came in a little bit after 8 and found the MC unlocked and struggling to lock for the past 3 hours. Looking at the SUS overview, both MC1 and ITMX Watchdogs had tripped so we damped the suspensions and brought them back to a good state. The autolocker was still not able to catch lock, so we cleared the WFS filter history to remove large angular offsets in MC1 and after this the MC caught its lock again.

Looks like two EQs came in at around 4:45 AM (Pacific) suggested by a couple of spikes in the seismic rainbow, and this.

  1464   Thu Apr 9 20:56:12 2009 YoichiHowToGeneralRestore the alignment. Write elog entries.
I often find that the mirrors are left mis-aligned (like in X-arm mode) when I come in for the locking, including tonight.
As Rob stated repeatedly in the past elog, leaving the mirrors mis-aligned for a long time without a reason is an abomination.
It will cause a slow drift of the mirrors and the lock acquisition work is severely slowed down as I have to run the alignment script many times.

I also found that the GPIB-Ethernet box (named teofila) was taken away from the SR785 hooked up to the CM board.
I found it connected to Alberto's setup. Instead, another GPIB box was left on the SR785 but not connected.
I couldn't find any elog entry about this.
This is totally unacceptable.
The SR785 has been used as a very important tool for monitoring the AO path loop gain during the power up.
You can use it if you need, but you have to note it in elog.

The other GPIB box left on the SR785 had a wrong name labeled on it. It had a name "ERMINIA", but the IP address written next to the name was actually assigned to "crocetta" in the DNS server on linux1. I don't know who made the label. I put a new and correct label on it.
Now I'm using crocetta for the SR785 so Alberto can keep using teofila.

Anyway, I think recently people are lazy about elog.
Whatever work you did, please put it in the elog even if you think it is trivial.
I also would like to see more detailed elog entries from people. Many of the recent elog entries are too simple or superficial that it is hard for other people to figure out what was really done.
  16238   Tue Jul 6 10:47:07 2021 Paco, AnchalUpdateIOORestored MC

MC was unlocked and struggling to recover this morning due to misguided WFS offsets. In order to recover from this kind of issue, we

  1. Cleared the bogus WFS offsets
  2. Used the MC alignment sliders to change MC1 YAW from -0.9860 to -0.8750 until we saw the lowest order mode transmission on the video monitor.
  3. With MC Trans sum at around ~ 500 counts, we lowered the C1:IOO-WFS_TRIGGER_THRESH_ON from 5000 to 500, and the C1:IOO-WFS_TRIGGER_MON from 3.0 to 0.0 seconds and let the WFS integrators work out some nonzero angular control offsets.
  4. Then, the MC Trans sum increased to about 2000 counts but started oscillating slowly, so we restored the delayed loop trigger from 0.0 to 3.0 seconds and saw the MC Trans sum reach its nominal value of ~ 14000 counts over a few minutes.

The MC is now restored and the plan is to let it run for a few hours so the offsets converge; then run the WFS relief script.

  16239   Tue Jul 6 16:35:04 2021 Anchal, Paco, GautamUpdateIOORestored MC

We found that megatron is unable to properly run scripts/MC/WFS/mcwfsoff and scripts/MC/WFS/mcwfson scripts. It fails cdsutils commands due to a library conflict. This meant that WFS loops were not turned off when IMC would get unlocked and they would keep integrating noise into offsets. The mcwfsoff script is also supposed to clear up WFS loop offsets, but that wasn't happening either. The mcwfson script was also not bringing back WFS loops on.

Gautam fixed these scripts temprorarily for running on megatron by using ezcawrite and ezcaswitch commands instead of cdsutils commands. Now these scripts are running normally. This could be the reason for wildly fluctuating WFS offsets that we have seen in teh past few months.

gautam: the problem here is that megatron is running Ubuntu18 - I'm not sure if there is any dedicated CDS group packaging for Ubuntu, and so we're using some shared install of the cdsutils (hosted on the shared chiara NFS drive), which is complaining about missing linked lib files. Depending on people's mood, it may be worth biting the bullet and make Megatron run Debian10, for which the CDS group maintains packages.

Quote:

MC was unlocked and struggling to recover this morning due to misguided WFS offsets. In order to recover from this kind of issue, we

  1. Cleared the bogus WFS offsets
  2. Used the MC alignment sliders to change MC1 YAW from -0.9860 to -0.8750 until we saw the lowest order mode transmission on the video monitor.
  3. With MC Trans sum at around ~ 500 counts, we lowered the C1:IOO-WFS_TRIGGER_THRESH_ON from 5000 to 500, and the C1:IOO-WFS_TRIGGER_MON from 3.0 to 0.0 seconds and let the WFS integrators work out some nonzero angular control offsets.
  4. Then, the MC Trans sum increased to about 2000 counts but started oscillating slowly, so we restored the delayed loop trigger from 0.0 to 3.0 seconds and saw the MC Trans sum reach its nominal value of ~ 14000 counts over a few minutes.

The MC is now restored and the plan is to let it run for a few hours so the offsets converge; then run the WFS relief script.

  16816   Thu Apr 28 09:12:18 2022 AnchalUpdateBHDRestoring arm alignment

This would be a daily first task in the morning. We'll need to check the status of arm alignment and optimize it back to maximum every morning for the rest of the day's work.

Today, when I came, on openin gthe PSL shutter, IMC was aligned good, both arms were flashing but YARM maximum transmission count was around 0.7 (as opposed to 1 from yesterday) and XARM maximum transmission count was 0.5 (as opposed to 1 from yesterday). I did not change the input alignment to the interferometer. I only used ITMY-ETMY to regain flashing count of 1 on YARM and used BS and tehn ITMX-ETMX to regain flashing count of 0.9 to 1 in XARM.

Even thought the oplevs were centered yesterday, I found the oplev had drifted from the center and the optimal position also is different for all ooptics except EMTY and BS. It is worth nothign that in optimal position both PIT and YAW of ITMY and ITMX are off by 70-90 uradians and ETMX Pit oplev is off by 55 uradians.

 

  16819   Thu Apr 28 18:07:04 2022 AnchalUpdateBHDRestoring arm alignment at EOD

Restored arm algiment to get 0.8 max flashing on YARM and 1 max flashing on XARM. I had to move input alignment using TT2-PR3 pair and realign YARM cavity axis using ITMY-ETMY pair.

I would like to advertise this useful tool that I've been using for moving cavity axis or input beam direction. It's a simple code that makes your terminal kind of videogame area. It moves two optics together (either in same direction or opposite direction) by arrow key strokes (left, right for YAW, up, down for PIT). Since it moves two optics together, you actually control the cavity axis or input beam angle or position depening on the mode.

 

  12138   Fri May 27 02:52:53 2016 ericqUpdateLSCRestoring high BW single arm control

I've been futzing with the common mode servo, trying to engage the AO path with POY for high bandwidth control of a single arm lock. I'm able to pull in the crossover and get a nice loop shape, but keep getting tripped up by the offset glitches from the CM board gain steps, so can't get much more than a 1kHz UGF.

As yutaro measured, these can be especially nasty at the major carrier transitions (i.e. something like 0111->1000). This happens at the +15->+16dB input gain step; the offset step is ~200x larger than the in-loop error signal RMS, so obviously there is no hope of keeping the loop engaged when recieving this kind of kick. Neither of the CM board inputs are immune from this, as I have empirically discovered. I can turn down the initial input gain to try and avoid this step occuring anywhere in the sequence, but then the SNR at high frequencies get terrible and I inject all kinds of crud into the mode cleaner, making the PC drive furious.

I think we're able to escape this when locking the full IFO because the voltages coming out of REFL11 are so much larger than the puny POY signals so the input-referred glitches aren't as bad. I think in the past, we used AS55 with a misaligned ITMX for this kind of single arm thing, which probably gives better SNR, but the whole point of this is to keep the X arm aligned and lock it to the Y-arm stabilized PSL. 

  209   Thu Dec 20 21:58:28 2007 AndreySummaryComputer Scripts / ProgramsResults for 2 previous XARM measurements have been added

I attached results (plots) of yesterday's daytime and overnight measurements to the initial reports about those measurements.

These are ELOG entries # 201 and # 205.
  199   Tue Dec 18 23:41:00 2007 AndreySummaryComputer Scripts / ProgramsResults of Mon/Tue overnight measurements (entry #194)

Here I inform our community about the results of the measurements of RMS values in XARM during the previous night from Monday to Tuesday (I announced those measurements in ELOG entry #194).

All the plots in today's report seem to agree well with the analogous plots from the night from Saturday to Sunday (those results are given in ELOG entry # 195).

All the intervals in which RMS have been calculated are the same as in yesterday's ELOG entry #195.

I plotted three results for RMS in the abovementioned three intervals in three different ways:

1) view from the top in the axes (Q_{ITMX}+Q_{ETMX})/2 and (Q_{ITMX}-Q_{ETMX}) -> first three graphs (attachments 1 -3);

2) view from the side in the same sum- and difference-axes -> next three graphs (attachments 4-6);

3) view from the side in Q_{ITMX} and Q_{ETMX} axes -> next three graphs (attachments 7-9, also attch. 12), above accelerometer spectra (attachments 10-11).

Also, I compared the ground noise level by comparing spectra of accelerometer signals at different times during that night. As a reminder, before my disease I installed one accelerometer near ITMX and another accelerometer near ETMX (see entries 161 and 172 in ELOG). The plots of ratios of accelerometer signals at different times (pairs of times that were used: 11PM and 2AM, 11PM and 5AM, 11PM and 8AM) are given below, see attachments 10-11. The program was running from 11PM on Monday till 9AM on Tuesday.

As I explained in the previous ELOG entry # 198, tonight I am taking experimental data in the narrowere interval from 1.00 to 4.50 with a smaller step 0.25.
  195   Tue Dec 18 00:51:39 2007 AndreyUpdateComputer Scripts / ProgramsResults of Saturday overnight measurements

As I indicated in the previous e-log entry (#194), I made overnight measurements in XARM in the night from Saturday to Sunday.

Root-mean-square values of the peaks in calibrated spectra were calculated, and I plotted them as functions of suspension gains in ITMX and ETMX "position" degrees of freedom.
More specifically, Q_ITMX means the value in the channel "C1:SUS-ITMX_SUSPOS_GAIN", while Q_ETMX means the value in the channel "C1:SUS-ETMX_SUSPOS_GAIN".

Root-mean-square values (RMS) were calculated during that night in three intervals:

1) around 0.8 HZ in the interval (0.6 Hz <-> 1.0 Hz);

2) around 3.0 Hz in the interval (2.0 Hz <-> 3.6 Hz);

3) in the broad interval from 0.6Hz to 3.6Hz.


I plotted three results for RMS in the abovementioned three intervals in three different ways:

1) view from the top in the axes (Q_{ITMX}+Q_{ETMX})/2 and (Q_{ITMX}-Q_{ETMX}) -> first three graphs (attachments 1 -3);

2) view from the side in the same sum- and difference-axes -> next three graphs (attachments 4-6);

3) view from the side in Q_{ITMX} and Q_{ETMX} axes -> next three graphs (attachments 7-9), above accelerometer spectra (attachments 10-11).


Also, I compared the ground noise level by comparing spectra of accelerometer signals at different times during that night. As a reminder, before my disease I installed one accelerometer near ITMX and another accelerometer near ETMX (see entries 161 and 172 in ELOG). The plots of ratios of accelerometer signals at different times (pairs of times that were used: 12AM and 3AM, 12AM and 6AM, 12AM and 9AM) are given below, see attachments 10-11.

Tomorrow I will try to compare the results with the second measurements that are being taken tonight.
  202   Wed Dec 19 16:07:37 2007 AndreySummaryComputer Scripts / ProgramsResults of overnight measurements Tue/Wed night (entry #198)

As indicated in ELOG entry 198, I was making overnight measurements during last night from Tuesday to Wednesday.

I was changing the suspension damping gain in ETMX and ITMX in "position" degree of freedom between values of 1.00 and 4.50 with the step 0.25.

Results for RMS of peaks (A) at 0.8Hz, (B) at about 3.0Hz and (C) in the range from 0.6Hz to 3.7Hz ("RMS in a broad interval") are given below:

I plotted three results for RMS in the abovementioned three intervals in three different ways:

1) view from the top in the axes (Q_{ITMX}+Q_{ETMX})/2 and (Q_{ITMX}-Q_{ETMX}) -> first three graphs (attachments 1 -3);

2) view from the side in the same sum- and difference-axes -> next three graphs (attachments 4-6);

3) view from the side in Q_{ITMX} and Q_{ETMX} axes -> next three graphs (attachments 7-9)

Attachments 10 and 11 show ratios of accelerometer signals at different times of the night/morning.


A little discussion about these graphs:

1) The areas of minima and of rapid growth are the same for all the measurements during all three nights.

2) Tonight there was a strange spike for the values of Q_{ETMX}=2.5 and Q_{ITMX}=4.0. I interpret that as an error of experiment.

3) On all the plots from all three nights there is a wide area of minimum on the plots for RMS at 0.8Hz and for "RMS in the broad interval",
and the graph for "RMS at 3Hz" indicates a clearer minimum in a localized area for Q_{ITMX}=2+-1, Q_{ETMX}=2+-1. Note that this area 2+-1
is included into the wide region of minimum for "RMS at 0.8Hz" and "RMS in a broad range".

Therefore, my guess at this stage is that we can choose the optimized value of suspension damping gains for both Q_{ITMX} and Q_{ETMX} somewhere
around 2+-1. I would like to make another overnight measurement (tonight) in that narrowed region with a small step to have more certainty.

By the way, I realized that I was a little bit careless and at some plots Q_I stands for {Q_ITMX}, and Q_E stands for Q_{ETMX}.
  15268   Thu Mar 12 01:33:21 2020 gautamUpdateLSCResuming locking activities

It's been a while since I've attempted any locking, so tonight was mostly getting the various subsystems back together.

  • Reconnected SR785 at 1Y3 to CM board for TF measurements.
  • POX/POY locking work fine
  • Locked PRMI (no ETMs) with carrier resonant, fixed PRM and BS alignment.
  • ALS-X noise is still elevated - disconnected it from the switchable delay line and now I'm directly piping the 3dB coupled part of the beat to the LO input of the demod board. But the high freq contribution to the RMS is still ~x2-x3 of what it was in November 2019. But the noise should only depend on the other (delayed) part of the beat (the discriminant is set thus).
  • With arms POX/POY locked, checked that there was no elevated coherence between POX_I/POY_I signals between 800 Hz - 1.2 kHz, which is where I see the excess noise in the laser frequency control signal (see Attachment #1). So this suggests that the IMC locking loop suppresses the noise to a level that the arm cavities don't witness it. It's probably still worth checking this out and fixing it, but it wasn't a show stopper.
  • Transition from POX/POY lock to ALS lock was smooth - I forgot to use the POX/POY photodiodes as OOL sensors to measure the noise in this config to see if it was elevated, but anyway, I was able to push on.
  • PRMI 3f locking worked okay.
  • Main thing I wanted to check today is to try the AO transition with a bit more IN1 gain on the CM board - hypothesis being the high frequency part of the CARM signal is buried in the noise if we run with -32dB of IN1 gain. 
    • Set IN1 gain to -10dB instead.
    • In this config, I checked that with the CARM offset at 0 (CARM still under purely ALS control), the CM_SLOW path was registering ~4000 cts pk-pk, which is healthily within the ADC's range.
    • I was able to engage the CARM_B path and semi-stabilize the arm powers (after compensating for the increased IN1 gain by decreasing the CARM_B gain) and turn on the integrator.
    • However, before I could try any AO path action, the IMC loses lock - too tired to try more tonight, I'll try again tomrrow.
ELOG V3.1.3-