40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 304 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  16959   Tue Jun 28 18:53:16 2022 ranaSummaryALSALS beat allan deviation (XARM)

what's the reasoning behind using df/f_beat instead of df/f_laser ?



I took ~ 7 minutes of XALS beatnote data with the XAUX laser locked to the XARM cavity, and the XARM locked to PSL to develop an allan deviation estimator.


  16963   Wed Jun 29 18:53:38 2022 ranaUpdateElectronicsElectronics noise

this is just the CDS error signal, but is not the electronics noise. You have to go into the lab and measure the noise at several points. It can't be done from the control room. You must measure before and afte the whitening.


I measured electronics noise of WFSs and QPD (of the WFS/QPD, whitening, ADC...) by closing PSL and measuring the error signal. It was needed to put the offset in C1:IOO-MC_TRANS_SUMFILT_OFFSET to 14000 cts (without offset the sum of quadrants would give zero, and 14000 cts is the value when the cavity is locked). For WFS that are RF, if there is intensity noise at low frequencies, it is not affecting the measurement.

In the attachment please find the power spectrum of the error signal when the PSL shutter is on and off.


  16966   Thu Jun 30 19:04:55 2022 ranaSummaryPSLPSL HEPA: How what when why

For the PSL HEPA, we wanted it to remain at full speed during the vent, when anyone is working on the PSL, or when there is a lot of dust due to outside conditions or cleaning in the lab.

For NORMAL conditions, the policy is to turn it to 30% for some flow, but low noise.

I think we ought to lock one of the arms on IR PDH and change the HEPA flow settings and plot the arm error signal, and transmitted power for each flow speed to see what's important. Record the times of each setting so that we can make a specgram later

  16967   Thu Jun 30 19:24:24 2022 ranaSummaryPEMeffect of nearby CES construction

For the proposed construction in the NW corner of the CES building (near the 40m BS chamber), they did a simulated construction activity on Wednesday from 12-1.

In the attached image, you can see the effect as seen in our seismometers:

this image is calculated by the 40m summary pages codes that Tega has been shepherding back to life, luckily just in time for this test.

Since our local time PDT = UTC - 7 hours, 1900 UTC = noon local. So most of the disturbance happens from 1130-1200, presumably while they are setting up the heavy equipment. If you look in the summary pages for that day, you can also see the IM lost lock. Unclear if this was due to their work or if it was coincidence. Thoughts?

  16981   Fri Jul 8 16:18:35 2022 ranaUpdateLSCActuator calibration of MC2 using Yarm

although I know that Yuta knows this, I will just put this here to be clear: the NNN/f^2 calibration is only accurate abouve the pendulum POS eiegenfrequency, so when we estimate the DC part (in diaggui, for example), we have to assume that we have a pendulum with f = 1 Hz and Q ~5, to get the value of DC gain to put into the diaggui Gain field in the calibration tab.

  16989   Tue Jul 12 09:14:50 2022 ranaUpdateBHDMICH AS55 noise budget

Looking good:

  • I think the notches you see in he measured noise are a clue as to the excess noise source. You can try turning some notches on/off.
  • Laser noise does matter a bit more subtley: the low freq noise couples to AS55 through the RMS deviation of the MICH loop from the zero crossing, and the noise of the 55 MHz modulation.
  • Jitter in the IMC couples to MICH through the misalignment of the Michelson.
  • As you rightly note, the optical lever feedback on the ITMs and BS also make length noise through the suspension actuator imbalance and the spot mis-centering.
  16990   Tue Jul 12 09:25:09 2022 ranaUpdateIOOIMC WFS

MC WFS Demod board needs some attention.

Tomislav has been measuring a very high noise level in the MC WFS demod output (which he promised to elog today!). I thought this was a bogus measurement, but when he, and Paco and I tried to measure the MC WFS sensing matrix, we noticed that there is no response in any WFS, although there are beams on the WFS heads. There is a large response in MC2 TRANS QPD, so we know that there is real motion.

I suspect that the demod board needs to be reset somehow. Maybe the PLL is unlocked or some cable is wonky. Hopefully not both demod boards are fried.

Please leave the WFS loops off until demod board has been assessed.

  16991   Tue Jul 12 13:59:12 2022 ranaSummaryComputersprocess monitoring: Monit

I've installed Monit on megatron and nodus just now, and will set it up to monitor some of our common processes. I'm hoping that it can give us a nice web view of what's running where in the Martian network.

  16998   Wed Jul 13 13:26:44 2022 ranaSummaryElectronicsElectronics noise measurements

as I said to you yesterday, I don't think image 2a shows the output of the demod board. The output of the demod board is actually the output connector ON the demod board. What you are showing in 2a, is the signal that goes from the whitening board to the ADC I believe. I may be msitaken, so please check with Tega for the signal chain.

  17003   Thu Jul 14 19:09:51 2022 ranaUpdateGeneralEQ recovery

There was a EQ in Ridgecrest (approximately 200 km north of Caltech). It was around 6:20 PM local time.

All the suspensions tripped. I have recovered them (after some struggle with the weird profusion of multiple conflicting scripts/ directories that have appeared in the recent past...)

ETMY is still giving me some trouble. Maybe because of the HUGE bias on that within the fast CDS system, it had some trouble damping. Also the 'reenable watchdog' script in one of the many scripts directories seems to do a bad job. It re-enables optics, btu doesn't make sure that the beams are on the optical lever QPD, and so the OL servo can smash the optic around. This is not good.

Also what's up with the bashrc.d/ in some workstations and not others? Was there something wrong with the .bashrc files we had for the past 15 years? I will revert them unless someone puts in an elog with some justification for this "upgrade".

This new SUS screen is coming along well, but some of the fields are white. Are they omitted or is there something non-functional in the CDS? Also, the PD variances should not be in the line between the servo outputs and the coil. It may mislead people into thinking that the variances are of the coils. Instead, they should be placed elsewhere as we had it in the old screens.

Attachment 1: ETMY-screen.png
  17004   Thu Jul 14 19:56:15 2022 ranaUpdateIOOmc wfs demod

It looks like Tomislav's measurements of the WFS demod board noise were actually of the cable that goes from the whitening to the ADC. So the huge low frequency excess that he saw is not due to wind, but just the inverse whitening of the digital system?

In any case, today, I looked at the connections from the Whitening to the ADC. It goes through an interface chassis to go from ribbon to SCSI. The D-Sub connectors there have the common problem in many of the LIGO D-sub connectors: namely that the strain relief nuts are too tall and so the D connector doesn't seat firmly - its always about to fall out. JC, can you please take a look at this and order a set of low profile nuts so that we can rework this chassis? Its the one between the WFS whitening and the SCSI cables which go to the ADCs.

After pushing them in, I confirmed that the WFS are working, by moving all 6 DoF of the MC mirrors via bias slider, and looking at the step responses (attached). As you can see, all sensors see all mirrors, even if they are noisy.

Next up: get a breakout for the demod output connector and measure the noise there.

For today, I aligned the IMC by hand, then centred the WFS beams by unlocking the IMC and aligning the bright beam. I noticed that the WFS1 beam was being dumped randomly, so I angled the WFS1 by ~3 deg and dumped the specular reflection on a razor blade dump. To handle the sign change in the MC1 actuation (?), I changed the sign in the MC1 ASC filter banks. MCWFS loops still nto closing, but they respond to mirror alignment.

Attachment 1: mcwfs-steps.pdf
  17008   Fri Jul 15 22:36:04 2022 ranaSummaryLSCFPMI with REFL/AS55 demod phase adjust

Very nice!

DARM feedback should go to ETMY - ETMX, not just a single mirror: Differential ARM.

For it to work with 1 mirror the UGF of the CARM loop must be much larger than DARM UGF. But in our case, both have a UGF of ~150 Hz.

In principle, you could run the CARM loop with higher gain by using the CM servo board, but maybe that can wait until the X,Y -> CARM, DARM handoff.


  17065   Mon Aug 8 14:47:10 2022 ranaUpdatePSLFSSSlow/MCAutolocker issue (docker)

can't we just go back to the old python script that was working for many years, and tested? I imagine that as soon as someone besides you tries to debug the docker setup, this is what will happen.


Added C1:IOO-MC_LOCK to ALConfigMC.yml which solved the isse with FSS Slow. We should tune the FSS Slow Servo PID coefficients for a better performance.

the C1PSL_SLOW.adl screen is not obsolete. It can be used to change the PID coefficients, engage/disengage the PID loop, monitor the PID script blinker, and monitor FAST actuator value C1:PSL-FSS_FAST. the functionality of this screen has not changed from before.

I've also added a wiki page for scripts documentation.


  17071   Wed Aug 10 19:24:19 2022 ranaUpdateGeneralWorking Red Pitaya VNA



  17075   Thu Aug 11 16:48:59 2022 ranaUpdateComputer Scripts / ProgramsNDS2 updates

We had several problems with our NDS2 server configuration. It runs on megatron, but I think it may have had issues since perhaps not everyone was aware of it running there.

  1. channel lists were supposed to updated regularly, but the nds2_nightly script did not exist in the specified directory. I have moved it from Joe Areeda's personal directory (/home/nds2mgr/joework/server/src/utils/) to nds2mgr/channel-tracker/.
  2. The channel history files (/home/nds2mgr/channel-tracker/channel_history/) are stored on the local megatron disk. These files had grown up to ~50 GB over tha past several years. I backed these up to /users/rana/, and then wiped them out so that the NDS could regen them. Now that the megatron local disk is not full, it seems to work in giving raw data.
  3. Need to confirm that this serves up trend data (second and minute)
  4. I think there is a nds2-server package for Debian, so we should update megatrons OS to the preferred flavour of DebIan and use that. Who to get to help in this install?

Since Megatron is currently running the "Shanghai" Quad-core Opteron processor from ~2009,  its ~time to replace it with a more up to date thing. I'll check with Neo to see if he has any old LDAS leftovers that are better.

  6081   Wed Dec 7 09:56:14 2011 rana imitation of steveOmnistructureEnvironmentTelephone Map

 This is the fone storree 

we should turn off 3977,3979 and 2351 has no function


Edit, JD:  x8925 is at the Visitor desk, and isn't on the map.

  8531   Mon May 6 21:05:06 2013 rana, Jamie, KOjiUpdateIOOmode cleaner not locking

As it turned out, the setting of +26dB for the FSS Fast gain was making the NPRO PZT / Pockels cell crossover too unstable. This was the cause of the large ~30 kHz peak that Jamie was seeing in his spectra (more to follow in the morning).

After recovering the locking, etc. by fiddling with the gains, we went about systematically setting all of the gains/offsets. Jamie's elog will show all of the various spectra with different FSS gains.

For offset setting, this was the procedure:

  1. We want the MC servo board to have zero voltage on its MCL and MCF outputs (aka MC_SLOW_MON and MC_FAST_MON) with the Boosts ON, so we switched ON the 40:4000 and the 2 Super Boosts and put the VCO gain into its nominal +25 dB setting. This saturates the outputs and makes them impossible to use as readbacks so you have to be careful. Get the outputs close to zero as you turn on each boost. Finally, you will see that +/- 1mV of input offset (aka MC_REFL_OFFSET) will flip the FAST output between +/- 10V. This is the right setting.
  2. With the MC board adjusted to send 0 V into the FSS error point, adjust the FSS input offset (with the Common and Fast gains at the nominal values) so that the FAST output voltage goes to +5.5 V. This is the middle of the range for the high voltage driver which drives the NPRO.
  3. Let the MC lock and go through the UP script. When the MCL comes on with the integrator, the FAST voltage will shift from +5.5 V to something else. Use the following line: ezcaservo -r C1:PSL-FSS_FAST -g -1 -s 5.5 C1:SUS-MC2_MCL_OFFSET, to automatically tune the MCL offset.


    That's all. I have left the FSS common gain at +10.5 and the Fast gain at +23.5. These seem to be close to the optimum. Jamie will have more tuning tomorrow.
    I have also changed the 'mcup' script to set the MCL offset and set the FSS Slow setpoint to shoot for +5.5 V of FSS_FAST.
    MC_REFL_OFFSET = +1.176 V
    MC2_MCL_OFFSET = +47.8 counts
    FSS_INOFFSET   = -0.85 V
  1926   Tue Aug 18 19:57:47 2009 rana, JenneUpdatePSLMZ

- we finished the MZ alignment; the contrast is good.

- we did the RFAM tuning using a new technique: a bubble balanced analyzer cube and the StochMon RFPD. This techniques worked well and there's basically no 33 or 166 RFAM. The 133 and 199 are as expected.

- the MC locked right up and then we used the periscope to align to it; the transmission was ~75% of max before periscope tuning. So the beam pointing after the MC should be fine now.

- the Xarm locked up with TRX = 0.97 (no xarm alignment).


If Rob/Yoichi say the alignment is now good, the we absolutely must center the IOO QPDs and IP POS and IP ANG and MC TRANS  today so that we have good references.



The first photo is of our nifty new setup to get the beam to the StochMon PD.  The MZ transmitted beam enters the photo from the bottom right corner, and hits the PBS (which we leveled using a bubble level).  The P-polarization light is transmitted through the cube, and the S-polarization is reflected to the left.  The pure S-polarized light hits a Beam Splitter, which we are using as a pickoff to reduce the amount of light which gets to the PD.  Most of the light is dumped on an aluminum dump.  The remaining light hits a steering mirror (Y1 45-S), goes through a lens, and then hits the StochMon PD.  While aligning the MZ to maximize visibility, we look at the small amount of P-polarized light which passes through the PBS on an IR card, and minimize it (since we want to be sending purely S-polarized light through the EOMs and into the MC).

The second photo is of a spectrum analyzer which is directly connected to the RF out of the StochMon PD.  To minimize the 33MHz and 166MHz peaks, we adjust the waveplates before each of the EOMs, and also adjusted the tilt of the EOM holders.

The final photo is of the EOMs themselves with the Olympus camera.

Once we finished all of our MZ aligning, we noticed that the beam input to the MC wasn't perfect, so Rana adjusted the lower periscope mirror to get the pointing a little better.  

The MZ refl is now at 0.300 when locked.  When Rana reduced the modulation depth, the MZ refl was about 0.050 .  Awesome!


Attachment 1: MZ_RFAMmon_setup_small.jpg
Attachment 2: MZ_RFAMmon_SpecAnalyzer_small.jpg
Attachment 3: MZ_EOM_IRrefl2_small.jpg
  2665   Tue Mar 9 12:06:53 2010 rana, JenneUpdatePEMStyrofoam Cooler on the Seismos

Looks like the GUR2_X signal is bad. Jenne says that we need to center it mechanically before the signals will become useful again. Maybe Steve will do this - instructions are in the manuel ?

  3609   Sun Sep 26 18:29:23 2010 rana, JohnUpdateCDSModified front end medm screens

Issues I notice on first glance:

  1. The OSEM Sensor Input matrix and the DOF2COIL Output matrix screens should be their own screens and linked from the overview. Right now they are not. Where is the input matrix?
  2. The SIDE GAIN looks like zero on the main screen, but the side OSEM signal seems to be getting through to the SIDE filter bank. . I think the wiring of the SIDE signal through the input matrix is bogus.
  3. The OUTPUT matrix seems to be the transpose of the previous OUTPUT matrix and we have lost the wires that connect the inputs and outputs to the matrix. We ought to think about how best to represent things on the OVERVIEW screen; probably only need to have a minimal representation and allow power users to open up the detailed screen.
  4. The TIME string is whited out. How will this be done? Does each FE display its local time on its EPICS screens?
  5. So far unable to get any channels on DV. How do we look at channels / test points?
  6. As far as we can tell, there is no connection between the output of the SUSPOS, etc. filter banks and the OUTPUT MATRIX. So....nothing actually goes to the coil driver. Its hard to imagine that this new SUS could have ever worked. Is there any evidence that the damping actually worked in the past, or was it something like "well, the watchdog values came down to small numbers eventually..." ???
  7. We are trying to debug the simulink file, but....the wiki entry on how to do this is out of date (yet updated as recently as August!) some path stuff just probably needs to be edited.


Basically the suspensions are not functioning yet and we can't attempt locking of the MC.

  15341   Wed May 20 20:10:34 2020 rana, John ZUpdateComputer Scripts / ProgramsNDS2 server / conf updated - seems OK now

We noticed about a week ago that the NDS2 channel lists were not getting updated on megatron. JZ and I investigated; he was able to fix it all up this afternoon by logging in and snooping around Megatron.

Please try it out and tell me about any problems in getting fresh data.

  1. The NDS2 server is what we connect to through our python NDS2 client software to download some data.
  2. It has been working for years, but it looks like there was a file corruption of the channel lists that it makes back in 2017.
  3. Since the NDS2 server code tries to make incremental changes, it was failing to make a new channel list. Was failing to parse the corrupted file.
  4. there was a controls crontab entry to restart the server every morning, but the file name in that tab had a typo, so that wasn't working. I commented it out, since it shouldn't be necessary (lets see how it goes...)
  5. the nds2mgr account also has a crontab, but that was failing since it didn't have sudo permission. JZ added nds2mgr to the sudoers list so that should work now.
  6. I was able to get new channels as of 4 PM today, so it seems to be working.

* we should remember to rebuild the NDS2 server code for Ubuntu. The thing running on there is for CentOS / SL7, but we moved to Ubuntu recently since the SL7 support is going away.

** the nds2 code & conf files are not backed up anywhere since its not on /cvs/cds. It has 52 GB(!!) of txt channel lists & archives which we don't need to backup

  8555   Thu May 9 00:05:12 2013 rana, Koji, JenneSummaryLSCAA and AI change

We would like to increase the UGF of the PRC loop so as to allow more suppression of the PRC signal and less pollution of the MICH signal (remember that the PRC/MICH optical gain ratio is huge).

We were already losing phase because of delay in the LSC - SUS digital link. In addition to that, a major source of delay is the analog anti-aliasing (on the LSC error signals before they enter the ADC) and the analog anti-imaging (between the SUS DAC and the coil driver).

 IN addition to these, the other major sources of phase lag in the system are the FM5 filter in the LSC-PRC filter bank, the digital upsampling and downsampling filters, and the DAC sample and hold.

In the near term, we want to modify these analog filters to be more appropriate for our 64 kHz ADC/DAC sample rate. Otherwise, we are getting the double phase lag whammy.


Staring at the schematics for the AA (D000076-01) and the AI (D000186-A), we determined a plan of action.

For the AA, we want to remove the multi-pin AA chip filter from Frequency Devices, Inc. and replace it with a passive LC low pass. Hopefully, these chips are socketed. Rana will design an appropriate LC combo and elog; we should make the change on a Wednesday afternoon so that we have enough soldering help.

For the AI, the filter is a dual bi-quad using discrete components and LT1125 opamps. Not so clear what to do with these. The resistors are all the noisy thick film kind and maybe should be replaced. Koji will find some online design tool for these or do it in LISO. Changing the TF is easy; we can just scale the capacitors. But we also want to make sure that the noise of the AI does not destroy the noise reduction action of the dewhitening board which precedes it.

Jenne should figure out how low the noise needs to be at the input to the coil driver.


P.S. the matlab code which defines these filters

>> [z,p,k] = ellip(4,4,60,2*pi*7570,'s');
>> misc.ai = zpk(z,p,k*10^(4/20)) * zpk([],-2*pi*13e3,2*pi*13e3);
>> % Fudged Anti-Imaging Filter
>> [z,p,k] = ellip(8,0.001,80,2*pi*7570,'s');
>> misc.aa = zpk(z,p,k*10^(0.001/20)) * zpk([],-2*pi*32768,2*pi*32768);

Attachment 1: AAAI.pdf
  9898   Fri May 2 02:22:56 2014 rana, QUpdateIOOMC alignments

We were having unstable MC locking so we did some physical alignment touch up. Use MC suspension bias to have good MC alignment. Unlock MC and align DC beams to center on WFS. Re-lock and things are now stable.

Someone had been feeding bad info to Eric about MC alignments; we do not center the MC WFS beams with the MC locked.

However, in any case, today the MC2-TRANS servo was not being good so I turned it off. We need the real matrix measurement to bring it back.

  9932   Thu May 8 17:00:56 2014 rana, QSummaryLSCREFL_DC handoff didn't work last night

Last night after checking cabling and turning on ISS, we tried several times to handoff to REFL_DC but it didn't work at all.

Some issues:

  1. The ISS was injecting a lot of very low frequency power fluctuations because of bad AC coupling.
  2. The SR560 @ LSC rack was saturating a lot with the x10 gain that Jenne and Rana put in; we turned it back to G = 1.
  3. The ISS was also saturating a lot. We turned it off around 4 AM, but still no success.
  4. The ALS sequence for finding the Red Resonance takes too long (~2 minutes), so we're trying a faster scheme tonight.
  1359   Thu Mar 5 01:09:29 2009 rana, albertoUpdateDMFstill not working
We tried to run DMF on mafalda, but it didn't work. I tried to compile it using Rob's elog instructions.
On mafalda, I started matlab and ran the mdv_config.m to set up mDV. I tested that the seisBLRMS.m
script ran and correctly produced changes in the seisBLRMS strip tool. but when I tried to compile it I got:
>> mcc -v -m -R -nojvm seisBLRMS.m
Warning: Duplicate directory name: /cvs/cds/caltech/apps/linux/matlab/toolbox/local.
Compiler version: 4.6 (R2007a)
Processing /cvs/cds/caltech/apps/linux/matlab/toolbox/matlab/mcc.enc
Processing /cvs/cds/caltech/apps/linux/matlab/toolbox/signal/mcc.enc
Processing /cvs/cds/caltech/apps/linux/matlab/toolbox/control/mcc.enc
Processing /cvs/cds/caltech/apps/linux/matlab/toolbox/filterdesign/mcc.enc
Processing /cvs/cds/caltech/apps/linux/matlab/toolbox/shared/controllib/mcc.enc
Processing /cvs/cds/caltech/apps/linux/matlab/toolbox/ident/mcc.enc
Warning: an error occurred while parsing class FilterDesignDialog.AbstractEditor:
Undefined function or variable 'DAStudio.Object'.

> In /cvs/cds/caltech/apps/linux/matlab/toolbox/shared/filterdesignlib/@FilterDesignDialog/@CoeffEditor/schema.p>schema at 9
Warning: an error occurred while parsing class FilterDesignDialog.CoeffEditor:
Invalid superclass handle.

Processing /cvs/cds/caltech/apps/linux/matlab/toolbox/fixedpoint/mcc.enc
terminate called after throwing an instance of 'ApplicationRedefinedException*'
Abort (core dumped)
"/cvs/cds/caltech/apps/linux/matlab/bin/mcc" -E "/tmp/fileRnU5Qj_31324": Aborted
??? Error executing mcc, return status = 134.

In the meantime, I've started up a green terminal on allegra which is ssh'd into megatron.
On megatron there is a regular matlab session which is running seisBLRMS.m as a matlab script
and the seis DMF channels are getting updated.
  1811   Wed Jul 29 19:46:04 2009 rana, albertoUpdatePEMDents = Bad??
It looks like the MC2 chamber and/or stack has been jarred and shifted. Please be careful and use much less force and speed around the MC2 chamber.

My guess is that the work with the accelerometers around there had made the MC2 angle and
position change last night. The reason that we don't see it in the OSEMs so much is that its
a change in the actual stack position and tilt.

To recover, we changed the MC2 alignment bias to get the beam through the Faraday. This did NOT get
the beam back onto the right place on the MC TRANS QPD. For tonight we decided to not recenter that
since Rob might not like this position. We did, however, zero out the MC WFS and the PSL POS/ANG.

If the interferometer locking is OK tonight, then we (Steve and whoever else is here at 7 AM)
should recenter IP POS and IP ANG and also fix up the PSL POS and PSL ANG QPDs. You can see
in the attached picture that there are two problems to fix:
1) The knobs (circled in red and blue) are wrapped in foil. Why???
2) The handedness of the mirror mount with the orange arrow is wrong. This should be unmounted and clocked
by 90 deg. Right now the beam is nearly clipping on the mount. Also, we need to change the channel names
on the PSL POS (or maybe its ANG). It has the horizontal/vertical channels misnamed.
  2469   Wed Dec 30 20:33:36 2009 rana, albertoConfigurationCamerasITMY & MC2 Camera work

We restored the good state of the ITMY camera and neatened both the MC2 and ITMY camera.

The MC2 camera was driving a triple T jungle into some random cables and spoiling the image. We removed all T's and the MC2 camera now drives only The Matrix.

The ITMY camera was completely unmounted and T'd. So it was misaligned just by the force of gravity acting on its BNC cable. We swapped the lens for a reasonable sized one and remounted it in its can. We then used orange cable ties to secure the power and BNC cable for the MC2 and ITMY cameras so that tugging on the cables doesn't misalign the cameras. This is part of the camera's SOP.

No more driving 50 Ohm cables and T's with video cables, Steve! If you need a portable video, just use a spigot of the Matrix and then you can control it with a web browser.


I also wiped out the D40's memory card after uploading all of the semi-useful files to the Picasa page.

  1161   Mon Nov 24 19:15:16 2008 rana, alberto, johnConfigurationEnvironmenttemperature
The PSL Room Temperature was alarming because it had gone above 23 C. This set off an unfortunate chain of events:

We found that the PSL HEPA was set low (20%). This is a fine setting for when no one is working in there but it
does raise the temperature since there are heat sources inside the blue box.

We tried to change the office area temperature to compensate and also the westmost sensor inside the lab area by 2 deg F.

The office area one was problematic - there was so much dust in it that the gas valve nipple was clogged. So we've
now blown it all clean with a compressed air can. We're now tuning the calibration screw to make our new
digital sensor agree with the setpoint on the controller.

Expect wild temperature swings of the office area for a couple days while Alberto and I tune the servo.
  1163   Tue Nov 25 19:29:15 2008 rana, alberto, johnConfigurationEnvironmenttemperature

The PSL Room Temperature was alarming because it had gone above 23 C. This set off an unfortunate chain of events:

We found that the PSL HEPA was set low (20%). This is a fine setting for when no one is working in there but it
does raise the temperature since there are heat sources inside the blue box.

We tried to change the office area temperature to compensate and also the westmost sensor inside the lab area by 2 deg F.

The office area one was problematic - there was so much dust in it that the gas valve nipple was clogged. So we've
now blown it all clean with a compressed air can. We're now tuning the calibration screw to make our new
digital sensor agree with the setpoint on the controller.

Expect wild temperature swings of the office area for a couple days while Alberto and I tune the servo.

This morning Bob found 92F in the office area and in the control room of the lab. He turned down the thermostat and when I got in at about 9 I found 65. After a few hours of adjustment of the thermostat's calibration, I could stabilize the room temperature to about 72F. I also turned down the thermostats inside the lab of a couple of degrees F.
  1151   Fri Nov 21 16:11:26 2008 rana, alberto, robUpdatePSLMach Zender alignment
The Mach Zender's dark port DC voltage had gone up too high (~0.5 V)and was turning yellow
on the screen. I re-aligned by touching the knobs on the 166 MHz path. Doing alignment after the
166 EOM had very little effect. The main improvement came from doing yaw on the turning mirror
just ahead of the 166 MHz EOM; this is the one which as no adjustment knobs (duh).

During this procedure, I had the MC off, the ISS off, and the MC autolocker off. After finishing
the alignment, the power on the ISS PDs had railed and the dark port power was ~0.29 V. So we
put in a ND0.2 on the ISS path and now the voltages are OK (~2 V on each PD). We have to remove the
ND filters and change the first ISS turning mirror into a ~10-20% reflector.

So now the MZ alignment seems good; Alberto is on the MC periscope alignment like a cheap suit.
Attachment 1: PB210051-1.JPG
  1155   Fri Nov 21 20:29:43 2008 rana, alberto, robUpdatePSLMach Zender alignment

So now the MZ alignment seems good; Alberto is on the MC periscope alignment like a cheap suit.

And alignment is now mostly done - MC locks on the TEM00.

Unlocked           4.50  V
Locked noWFS       1.30  V
Locked + WFS       0.42  V
and the 29.5 MHz modulation depth is really small.

We should be able to rerun the Wiener analysis on this weekends MC data.

I don't know what our nominal StochMon numbers now are, but after Alberto tweaks up the alignment he can tell us if the RFAM has gotten any better.
  1973   Tue Sep 8 15:14:26 2009 rana, alexConfigurationDAQRAID update to Framebuilder: directories added + lookback increased

 Alex logged in around 10:30 this morning and, at our request, adjusted the configuration of fb40m to have 20 days of lookback.

I wasn't able to get him to elog, but he did email the procedure to us:

1) create a bunch of new "Data???" directories in /frames/full
2) change the setting in /usr/controls/daqdrc file
       set num_dirs=480;

my guess is that the next step is:

3) telnet fb0 8087

    daqd>  shutdown

I checked and we do, in fact, now have 480 directories in /frames/full and are so far using up 11% of our 13TB capacity. Lets try to remember to check up on this so that it doesn't get overfull and crash the framebuilder.

  4112   Wed Jan 5 16:00:11 2011 rana, alexSummaryDAQFrameBuilder fails in a new way

Email from Alex:

Turned out to be the lack of current year information in the IRIG-B signal
received by the Symmetricom GPS card in the frame builder machine caused
this. I have added a constant in daqdrc to bring the seconds forward:

controls@fb /opt/rtcds/caltech/c1/target/
fb $ grep symm daqdrc
#set symm_gps_offset=-1;
set symm_gps_offset=31536001;

Hopefully we will be upgrading to the newer timing system at the 40M this
year, so this will not happen again next year.


Doing an 'ls -lrt' in /frames/full/ now shows that the names are correct:

drwxr-xr-x 2 controls controls 249856 Dec 30 19:06 9777
drwxr-xr-x 2 controls controls 192512 Dec 31 16:00 9778
drwxr-xr-x 2 controls controls 151552 Jan  1 08:53 9463
drwxr-xr-x 2 controls controls 266240 Jan  2 12:39 9464
drwxr-xr-x 2 controls controls 258048 Jan  3 16:26 9465
drwxr-xr-x 2 controls controls 253952 Jan  4 20:13 9466
drwxr-xr-x 2 controls controls 151552 Jan  5 13:54 9467
drwxr-xr-x 2 controls controls  12288 Jan  5 15:57 9783

  1551   Wed May 6 16:56:35 2009 rana, alex, joeConfigurationComputersdaqd log, cront, etc.
While Alex came over, we investigated the log file problems with DAQD and NDS on FB0. There was a lot of
the standard puzzling and mumbling, but eventually we saw that it doesn't create its log file and so it
doesn't write to it. The log file is /usr/controls/main_daqd.log. The other files called daqd.log.DATE
in the logs/ directory are actually not written to. Its awesome.

We also have put in a fix for the overflowing jobs/ directory. It gets a file written to it every time
you make and NDS request and our seisBLRMS has been overloading it. There's now a cron for it in the fb0
crontab which cleans out week-old files at 6:30 AM every day.

We also changed the time of the daily backup from 3:30 AM (when people are still working) to 5:50 AM
(by which time the seismic has ramped up and interferometerists should be asleep). I didn't like the
idea of a bandwidth hog nailing the framebuilder during the peak of interferometer work.

# Script to backup via rsync the most recent 40m minute trends and
# any changes to the /cvs/cds filesystem.
50 05 * * * /cvs/cds/caltech/scripts/backup/rsync.backup < /dev/null > /cvs/cds/caltech/scripts/\
backup/rsync.backup.log 2>&1

30 06 * * * find /usr/controls/jobs -mtime +7 -exec /bin/rm -f {} \;

seisBLRMS.m restarted on mafalda.
  6049   Wed Nov 30 02:04:26 2011 rana, den, jenne, kiwamu, jzweizigUpdateCDSFiltering Noise issue tracked down ???

 You can read through all of our past tests to see what didn't work in tracking things down. As Den mentions, there was actually a lot of evidence that there was some double->single precision action in the filter calculation causing the noise we saw.

However, it turns out that this is NOT the case.

This afternoon I was so confused that I enlisted JZ to help us out. He came over and I tried to replicate the error. When looking at the time series, we noticed that it wasn't random noise; the signals seem to be getting clipped as they crossed zero. Sort of like a stiction problem. JZ left to go replicate the error on an offline system.

This turned out to be the important clue. As we examine the code we find this inside of fm10Gen.c:

if((new_hist < 1e-20) && (new_hist > -1e-20)) new_hist = new_hist<0 ? -1e-20: 1e-20;

this is line is basically trapping the filter history at 1e-20, to prevent some kind of numerical underflow problem (?). Seems reasonable, except that some filters which have higher order low passing in them actually have an overall scale factor which can be small (even as small as 1e-23, as Den pointed out).

So the reason we saw such weird behavior is that the first filter in SUSPOS is an AC coupling filter. This takes the OSEM signal and remove the large mean value. Then the next filter multiplies it by 1e-23 before doing the filtering and you end up with this noise in the filter history.

I looked and this line is commented out in the new BiQuad code, but as far as I can tell this issue has been around in aLIGO, eLIGO, iLIGO, etc. for a long time and could have been causing many cases of excess noise whenever we ended up a tiny gain factor in an IIR filter. At the 40m, there are easily a hundred such cases.

For now, I suppose we can just change this number to 1e-40 or so. I don't know how to calculate what the right number should be. Not sure why this underflow is not an issue for the BiQuad, however.

  10723   Mon Nov 17 20:40:29 2014 rana, diegoUpdateIOOInvestigating the IMC WFS situation

We've known for years that the IMC WFS sensing chain is pointlessly bad, but until recently, we haven't thought it was worth it to fix.

There are problems in all parts of the chain:

  1. The WFS Photodetectors oscillate ~200 MHz when turned up to full gain. Diego and I confirmed this today by measuring the RF spectrum of the signals going into the WFS demod boards and seeing the oscillation change (not much) with RF gain. I recommend we switch the heads into the full gain mode (turn all of the attenuators OFF). At the moment we are operating with the 2dB and 8dB attenuators ON.
  2. The demod board has some bad gain allocation and noisy opamps.
  3. The whitening board has too much up/down of gain with noise injection along the way. And the range cannot fill up the ADC.
  10803   Tue Dec 16 01:50:27 2014 rana, diegoFrogsLSCMICH filter is nuts

 This is ridiculous.

How many RGs can I fit into one button???

Attachment 1: badMICHrg.pdf
  11905   Mon Jan 4 14:45:41 2016 rana, eq, kojiConfigurationComputer Scripts / Programsnodus pwd change

We changed the password for controls on nodus this afternoon. We also zeroed out the authorized_keys file and then added back in the couple that we want in there for automatic backups / detchar.

Also did the recommended Ubuntu updates on there. Everything seems to be going OK so far. We think nothing on the interferometer side cares about the nodus password.

We also decided to dis-allow personal laptops on the new Martian router (to be installed soon).

  11303   Mon May 18 17:42:14 2015 rana, ericQUpdateGeneralsome status

Today at 5 PM we replaced the east N2 cylinder. The east pressure was 500 and the west cylinder pressure was 1000. Since Steve's elogs say that the consumption can be as high as 800 per day we wanted to be safe.

  1. We closed the black valve before the regulator and closed the valve on the cylinder.
  2. We unscrewed the brass fill line to the cylinder.
  3. We unchained the cylinder and put in the dolly (and attached the chains on there).
  4. We rolled in a fresh cylinder from outside using the red dolly (it should have chains).
  5. We put it in place, hooked up the chains, and screwed on the brass nozzle with the large adjustable wrench (need to put a non-adjustable here).
  6. Opened up the cylinder valve.
  7. Opened up the black valve.
  8. New east pressure reading is 2500 PSI. Regulated N2 pressure is 68 PSI.

1) Checked the N2 pressures: the unregulated cylinder pressures are both around 1500 PSI. How long until they get to 1000?


  11315   Tue May 19 18:55:12 2015 rana, ericQUpdateGeneralsome status

After one day the pressures are east/west = 2200/450 PSI



  1. New east pressure reading is 2500 PSI. Regulated N2 pressure is 68 PSI.


  10418   Thu Aug 21 02:42:17 2014 rana, ericqConfigurationGreen LockingGain changes on Green Y PDH

[rana, ericq]

We spent time trying to relieve the Yend green PDH of it troubles. 

We realized that the mixer in the PDH setup (mini circuits ZAD-8+), wants 7dBm of LO to properly function. However, we use one function generators output, through a splitter, to give signals to the laser PZT and the mixer LO. 

We don't want 7dBm of power hitting the laser PZT, though. The summing node that adds the servo output to the sideband signal was supposedly designed to do some of this attenuation. Rana measured that 10Vpp out of the function generator resulted in 20mVpp on the fast input to the NPRO, after the summing node. Hence, the 0.09V setting was only resulting in something like 0.2mV hitting the PZT. The PZT has something like 30 rad/V PM response, meaning we only had ~0.006 rad of modulation. 

Now, the function generator is set to 2 Vpp, meaning 4 mVpp hitting the PZT, meaning ~0.12 radians of modulation. The mixer is now getting +7dBm on its LO, and the PDH traces look much cleaner. However, the PDH error signal is now something like 100mVpp, which is much bigger than the PDH board is designed for, so there is now a 10dB attenuator between the reflection PD DC block and the RF input to the mixer. 

Here are screenshots of the Inmon channel (which has a gain of ~20) showing a sweep through some PDH signal, and the error signal while in green lock. Huge 60Hz harmonics are still observed. 



Regarding these 60Hz issues, we need to make sure that we remove all situations where long BNCs are chained together with barrel connectors, or Ts are touching other ones. We also should glue or affix the pomona summing box to the shelf, so that its not just laying on the floor.

The concrete next step is to go fiddle with things, and see if we can get the 60Hz noise to go away, then measure the PDH loop and noises again. Hopefully, this should make the ALS much more reliable. 

  9329   Fri Nov 1 19:09:01 2013 rana, evanConfigurationPSLPMC reflected beam nonsense

 While looking at the PMC REFL beam for the AOM diffracted beam, we noticed that although only one beam exists between the PMC and the first steering mirror, there are two afterwards and they both go to the PMC REFL  RFPD!!! This is madness. We only want one beam on our PDH diode.

The reason that we have two beams is that that first steering mirrors is actually a (W1-PW-1025-UV-1064-45P) non-wedged window with an AR coating on only one side. So two beams come out of it. There is a terrible and floppy and illegal anodized aluminum dump close to this beam which *someone* probably intended to use as a "scraper" to get rid of one of the beams.

Black anodized aluminum is a horrible beam dump material at 1064 - its about as grey as Steve's chair. And its so soft that it scatters light back into the PMC and makes more acoustic noise. And it is mounted so poorly (only one screw) that it can easily be bumped and twist and miss the beam. Punchline: only use anodized aluminum dumps for stray light around cameras or for HeNe for OL. Its NOT allowed anywhere where we care about interferometry of NIR beams.

It was also set to dump the dimmer beam. On Monday, we should order ~5 W1 and get them with a wedge of 1-2 deg. Then we use a black glass dump for the dim beam and orient the bright one to hit the REFL camera and the PMC REFL PD.

For the weekend, I have adjusted the crappy grey aluminum flapper to catch the bright beam so that the PMC REFL image no longer shows the interference fringe of two beams. Lets see how the PMC drifts over the next 3 days.

  12646   Tue Nov 29 17:46:18 2016 rana, gautamFrogsComputer Scripts / Programsgateway PWD change

We found that someone had violated all rules of computer security decency and was storing our nodus password as a plain text file in their bash_profile.

After the flogging we have changed the pwd and put the new one in the usual secret place.

  12911   Mon Mar 27 20:41:21 2017 rana, gautamUpdatePSLPMC DAQ assay for feed-forward integration

We are thinking to use the PMC signals to help us in figuring out the feedback / feedforward stuff and making it better.

Today we scoped out the PMC DAQ channels (which were never re-hooked up after the Joe/Jamie CDS upgrade 6 years ago).

There is a 4-pin LEMO connector on the front panel which gives

  1. the error signal (after the 4th order, post-mixer lowpass and a OP27 buffer with a 17 kHz low pass)
  2. the feedback voltage to the PZT, after a resistive divide by 50

Both of these signals are buffered by the AD620 inst amp configured with a gain of 1. In the green scope trace, you can see that there's a ~110 MHz signal strongly evident there. In the spectrum analyzer screen shot there is a instrument noise trace and then a PMC error point trace. You can see that all the peaks are ony there when I connect to the servo board instead of a Terminator. This RF noise is mainly the higher harmonics of the 35.5 MHz modulation getting there. It seems to be in both the error and control DAQ outputs, and a question is whether or not it is also in the servo electronics.

I also attach a close up of the servo board in the region of the post-mixer LC low pass filtering. I think its supposed to be 4th order cutoff at 1 MHz, but maybe the caps are busted or there's a way for the RF from the mixer to bypass the filters and get into the main servo path?

In the medium term, we probably want to use the new PDH servo that Rich is making. Need to buy/make a HV driver to use, but that should be easy.

Attachment 1: TEK00000.PNG
Attachment 2: 20170327_194931.jpg
Attachment 3: 20170327_204554.jpg
  13316   Mon Sep 18 15:00:15 2017 rana, gautamFrogsComputer Scripts / Programsgateway PWD change

We implemented the post-SURF-season nodus password change today.

New password can be found at the usual location.

  15173   Wed Jan 29 03:05:47 2020 rana, gautamUpdateSUSMC misalignments / sat box games

In the last couple days, as the IMC ringdowns have been going on, we have noticed that the MC is behaving bad. Misaligning, drifting, etc.

Gautam told me a horror story about him, Koji, and melted wires inside the sat boxes.

I said, "Its getting too hot in there. So let's take the lids off!"

So then we:

  1. Removed the lid (only 4 screws were still there)
  2. cut off some of the shield - ground wires and insulated them with electrical tape
  3. squished the IDC connectors on tightly
  4. left it this way to see if MC would get better - certainly the painfully hot heatinks inside the box were now just 110 F or so

After some minutes, we saw no drifting. So maybe my theory of "hot heatsink partially shorting a coil current to GND through partially melted ribbon cable" makes sense? IF this seems better after a month, lets de-lid all the optics.

Let's look at some longer trends and be very careful next to MC2 for the next 3 days! I have put a dangerous mousetrap there to catch anyone who walks near the vacuum chamber.

gautam: the grounding situation per my assessment is that the shield of all the IDC cables are connected to a common metal strip at 1X5 - but in my survey, I didn't see any grounding of this strip to a common ground.

Attachment 1: IMG_8366.JPG
  15849   Sun Feb 28 16:59:39 2021 rana, gautamUpdateLSCmore PRMI checks here: what it is ain't exactly clear

On Friday evening we checked out a few more things, somewhat overlapping with previous tests. All tests done with PRMI on carrier lock (REFL11_I -> PRC, AS55_Q-> MICH):

  • check that PRC drive appropriately minimizes in REFL55_Q. I:Q ratio is ~100:1; good enough.
  • put sine waves around 311 and 333 Hz into PRCL and MICH at the LSC output matrix using awggui and LSC osc. not able to adjust LSC/OSC output matrix to minimize the MICH drive in REFL_I.
  • measured the TF from BS & PRM LSC drive to the REFL55_I/Q outputs. very nearly the same audio frequency phase, so the problem is NOT in the electronics || mechanical transfer functions of the suspensions.


Further questions:

  1. is this something pathological in the PRMI carrier lock? we should check by locking on sidebands to REFL55 and REFL165 and repeat tests.
  2. Can it be a severe mode mismatch from IMC output to PRMI mode? the cavity should be stable with the flipped folding mirrors, but maybe something strange happening. How do we measure the mode-matching to the PRC quantitatively?
  3. huge RAM is ruled out by Gautam's test of looking at REFL demod signals: dark offset vs. offset with a single bounce off of PRM (with ITMs mis-aligned)
  4. if there is a large (optical) offset in the AS55_Q lock point, how big would it have to be to mess up the REFL phase so much?
  5. what is going on with the REFL55 whitening/AA electronics?

unrelated note: Donatella the Workstation was ~3 minutes ahead of the FE machines (you can look at the C0:TIM-PACIFIC_STRING on many of the MEDM screens for a rough simulacrum). When the workstation time is so far off, DTT doesn't work right (has errors like test timed out, or other blah blah). I installed NTP on donatella and started the service per SL7 rules. Since we want to migrate all the workstations to Debian (following the party line), lets not futz with this too much.

gautam, 1 Mar 1600: In case I'm being dumb, I attach the screen grab comparing dark offset to the single bounce off PRM, to estimate the RAM contribution. The other signals are there just to show that the ITMs are sufficiently misaligned. The PRCL PDH fringe is usually ~12000 cts in REFL11, ~5000cts in REFL55, and so the RAM offset is <0.1% of the horn-to-horn PDH fringe.

P.S. I know generally PNGs in the elog are frowned upon. But with so many points, the vector PDF export by NDS (i) is several megabytes in size and (ii) excruciatingly slow. I'm proposing a decimation filter for the export function of ndscope - but until then, I claim plotting with "rasterized=True" and saving to PDF and exporting to PNG are equivalent, since both yield a rasterized graphic.

Attachment 1: RAMestimate.png
  9925   Wed May 7 23:09:06 2014 rana, jamieSummaryComputer Scripts / ProgramsOttavia back on network

After Jamie fixed the third party repo issue with Ottavia, he was able to upgrade it to Ubuntu 12.04 Precise Pangolin. But its network stopped working.

I tried to fix its issues by ifconfig and GUI, but what it really wanted was for me to put the network cable back into its eth0 slot. The eth1 network card appears not be working anymore.

All seems fine now. Next I will mount the shared user disk from linux1 and put in a .bashrc.

  553   Mon Jun 23 19:33:01 2008 rana, jenneUpdateIOOMC_F Noise check
We looked at the MC_F spectrum because Rob and Yoichi said that it had gone 'all crazy'. It
seemed fine as we looked at it (even with only one boost stage on) so we looked for things
that might be marginal and make it go nuts.

At the error point (Q mon on the demod board and TEST IN1) of the MC Servo board we saw the
old 3.7 MHz signal (comes from the 33 MHz RFAM getting demodulated by the 29.5 MHz MC LO)
and thought that this might cause some worries. So we installed Jenne's passive elliptic
low pass which has a 3.7 MHz zero.

This wiped out the 3.7 MHz noise but we were not able to re-create the extra frequency noise
so its unlikely to have fixed the main problem. However, we leave it in because its good. If
there is a need to revert it, we have left hanging on the side of the rack the old cable which
was a SMA->TNC making a direct, unfiltered connection between the MC Demod board and the MC
servo board.

More before and after results from Jenne tomorrow, but for now here is a calibrated MC_F spectrum
using the new MC_F-Reference.xml template file.

We also noticed that we could make some small effects on the MCF spec by adjusting the PMC gain so
there's probably more hay to be made there using a lead brick and a gain slider. More in Jenne's
Attachment 1: mcf.png
  873   Sat Aug 23 09:39:51 2008 rana, jenneUpdatePSLPMC Survey
Jenne, Rana

We scoped out the PMC situation yesterday.

Summary: Not broke. UGF ~ 500 Hz. Needs some electronics work (notches, boosts, LPFs)

Ever since we swapped out the PMC because of the broken PZT of the previous one, the UGF has been
limited to a low value. This is because the notches no longer match the mechanical resonant
frequencies of the body. The old one had a resonance at 31.3 kHz which we were notching using
the LC notch on the board as well as a dangling Pomona box in the HV line to the PZT. The one
has a resonance at ~14.5 kHz which we don't yet have a notch for. Jenne has all the real numbers and
will update this entry with them.

  • Implement the 4th order Grote low pass after the mixer.
  • Replace the AD797 with an OP27.
  • Change servo filter to have a boost (need DC gain)
  • Make a 14.5 kHz notch for the bode mode.
  • Put a 20 lb. gold-foil wrapped lead brick on the PMC.

Here's the link about the modified PMC board which we installed at LHO:
LHO PMC elog 2006
ELOG V3.1.3-