40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 308 of 344  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  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.

  17088   Wed Aug 17 11:10:51 2022 ranaUpdateComputersc1teststand rack mounting for CDS upgrade

we want to be able to run SimPlant on the teststand, test our new controls algorithms, test watchdogs, and any other software upgrades. Ideally in the steady state it will run some plants with suspensions and cavities and we will develop our measurement scripts on there also (e.g. IFOtest).


[Tega, Yuta]

I keep getting confused about the purpose of the teststand. The view I am adopting going forward is its use as a platform for testing the compatibility of new hardware upgrade, instead of thinking of it as an independent system that works with old hardware.

  17097   Mon Aug 22 14:36:49 2022 ranaUpdateSUSOpen loop transfer function measurements for local damping loops of Core optics

for damping and OL loops, we typically don't measure the TF like this because it takes forever and we don't need that detailed info for anything. Just use the step responses in the way we discussed at the meeting 2 weeks ago. There's multiple elog entries from me and others illustrating this. The measurement time is then only ~30 sec per optic, and you also get the cross-coupling for free. No need for test-point channels and overloading, just use the existing DQ channels and read back the response from the frames after the excitations are completed.

  17123   Wed Aug 31 12:57:07 2022 ranaSummaryALScontrol of ALS beat freq from command line -easy

The PZT sweeps that we've been making to characterize the ALS-X laser should probably be discarded - the DFD was not setup correctly for this during the past few months.

Since the DFD only had a peak-peak range of ~5 MHz, whenever the beat frequency drifts out of the linear range (~2-3 MHz), the data would have an arbitrary gain. Since the drift was actually more like 50 MHz, it meant that the different parts of a single sweep could have some arbitrary gain and sign !!! This is not a good way to measure things.

I used an ezcaservo to keep the beat frequency fixed. The attacehed screenshot shows the command line. We read back the unwrapped beat frequency from the phase tracker, and feedback on the PSL's NPRO temperature. During this the lasers were not locked to any cavities (shutters closed, but servos not disabled).

For the purposes of this measurement, I reduced the CAL factor in the phase tracker screen so that the reported FINE_PHASE_OUT is actually in kHz, rather than Hz on this plot. So the green plot is moving by 10's of MHz. When the servo is engaged, you can see the SLOWDC doing some action. We think the calibration of that channel is ~1 GHz/V, so 0.1 SLOWDC Volts should be ~100 MHz. I think there's a factor of 2 missing here, but its close.

As you can see in the top plot, even with the frequency stabilized by this slow feedback (-1000 to -600 seconds), the I & Q outputs are going through multiple cycles, and so they are unusable for even a non serious measurement.

The only way forward is to use less of a delay in the DFD: I think Anchal has been busily installing this shorter cable (hopefully, its ~3-5 m long so that the linear range is more. I think a 10 m cable is too long.), and the sweeps taken later today should be more useful.

Attachment 1: Untitled.png
  17156   Fri Sep 23 18:31:46 2022 ranaUpdateBHDBH55 RFPD installed - part I

A design flaw in these initial LIGO RFPDs is that the SMA connector is not strain releieved by mounting to the case. Since it is only mounted to the tin can, when we attach/remove cables, it bends the connector, causing stress on the joint.

To get around this, for this gold box RFPD, connect the SMA connector to the PCB using a S shaped squiggly wire. Don't use multi-strand: this is usually good, since its more flexible, but in this case it affects the TF too much. Really, it would be best to use a coax cable, but a few-turns cork-screw, or pig-tail of single-core wire should be fine to reduce the stress on the solder joint.


Later Anchal noticed that there was no RFPD output (C1:LSC-BH55_I_ERR, C1:LSC-BH55_Q_ERR). I took out the RFPD and opened it up, and the RF OUT SMA to PCB connection wire was broken [Attachment 2]. I re-soldered the wire and closed up the box [Attachment 3]. After placing the RFPD back, we noticed spikes in C1:LSC-BH55_I_ERR and C1:LSC-BH55_Q_ERR channels on ndscope. We suspect there is still a loose connection, so I will revisit the RFPD circuit on Monday. 


  17186   Wed Oct 12 18:18:16 2022 ranaUpdateASSModel Changes

Although we've usually used this empirical way to run the alignment, I'd prefer if we had an analytic / numerical model for it.

Radhika, coud you look into writing down the equations for how the various dithers show up in the various error signals into a Overleaf doc? I'm thinking about this currently for the IMC, so we can zoom about it next week once you've had a chance to think about it for a few days. It would be helpful to have this worked out for the 40m alignment for future debugging. Co-located dither and actuation is not likely the best way to do things from a noise and loop x-coupling point of view.


  17189   Thu Oct 13 23:25:22 2022 ranaUpdateIMCIMC ASC: summary pages and notes

Tega has kindly made a summary page for the IMC WFS. Its in a tab on the usual summary pages.

One thing I notice is that the feedback to MC2 YAW seems to have very little noise. What's up with that?

The output matrix (attached) shows that the WFS have very little feedback to MC2 in YAW, but normal feedback in PIT. Has anyone recalculated this output matrix in the past ~1-2 years?

I'm going to read Prof. Izumi's paper (https://arxiv.org/abs/2002.02703) to get some insight.

The output matrix doesn't seem to have any special thing to make this happen. Any ideas on what this could be?

Attachment 1: Screen_Shot_2022-10-14_at_3.19.43_PM.png
  17196   Mon Oct 17 22:27:25 2022 ranaUpdateBHDBH55 RF output amplified

1) please remember to follow the loading and power up instructions to avoid destroying our low noise RF amplifiers. Its not as easy as powering up any usual device.

2) also, please use the correct decoupling capacitors at the RF amp power pins. Its going to have problems if its powered from a distant supply over a long cable.

  17205   Sat Oct 22 21:36:28 2022 ranaSummaryBHDBH55 phase locking efforts

give us an animated GIF of this cool new tool! - I'm curious what happens if you look at 2 DoF of the same suspension. Also would be cool to apply a bandpass filter before plotting XY, so that you could look for correlations at higher frequencies, not just seismic noise


Using xyplot tool, we tried to see the relationship between C1:HPC-BHDC_DIFF_OUT and C1:HPC-BH55_Q_DEMOD_I_OUT. The two signals, according to our theory, should be 90 degrees out of phase and should form an ellipse on XY plot. But what we saw was basically no correlation between the two.

  17207   Tue Oct 25 05:26:24 2022 ranaSummaryIOOMC SUS tuning

in looking closer at the IMC WFS performance I notice 2 issues:

  1. the watchdog thresholds are set to 200 mV, but this only made sense back when the OSEM calibration was 2 V/mm. Because of the increased analog gain(?) the RMS value of the watchdog sensors is now ~35 mV for MC1, so it will trip its watchdog and unlock the IMC with a 10x smaller seismic impulse than before. I recommend changing the watchdog thresholds appropriately changing the OSEM sensor signals to something so that its the same for all SUS.
  2. For the MC SUS, the F2P or F2A decoupling filters are not on. SO the POS damping loop is injecting a lot of pitch noise into the mirrors. We could perhaps lower the ~1 Hz angular motion by commissioning those filters for the MC optics. Does anyone know why we have several filters in those filter banks? I think we could contain it all in 1, although its fine to make a few different ones with different Q's for testing the performance.
  17213   Tue Oct 25 22:01:53 2022 ranaConfigurationPEMAuto Z on trillium interface board

thanks, this seems to have recentered well.

It looks like it started to act funny at 0400 UTC on 10/24, so thats 9 PM on Sunday in the 40m. What was happening then?


Attachment 1: Screen_Shot_2022-10-26_at_4.45.30_PM.png
  17240   Tue Nov 8 08:57:18 2022 ranaUpdateSUSMC2 OSEMs calibrated using MC_F

this measurement is not valid because of the coil to sensor coupling that I mentioned before. This is why I suggested you make the measurement at low frequencies (like 0.1 Hz).


MC2 OSEM outputs were calibrated today using MC_F to get the output values in microns. This was done using this diaggui file. We drive a sine wave at 13 Hz and 5000 cts at C1:SUS-MC1_BIASPOS_EXC.

  17244   Tue Nov 8 16:56:33 2022 ranaUpdateAUXAUX PZT transfer function fitting + filtering

This looks really good to me. Rather than fully invert the plant, what we would like to do is now design a filter which allow this loop to have a high UGF and a high gain below 1 kHz. Anchal and Paco probably have gain requirements for this loop in the ALS-CAL paper they are writing. The loop would have the cavity transfer function, as well as the demod electronics for the green PDH loop.

In addition to the gain requirements, we would also like to have a phase margin > 30 deg, and a gain margin of > 10 dB.


  17248   Wed Nov 9 07:49:59 2022 ranaUpdateSUSMC2 OSEMs calibrated using MC_F

It would be good if you can post the uncertainties with these measurements (and for generally any measurements). This is so that we can propagate that uncertainty later for other measurements. From your entry, it looks like there are something like 7 digits of precision, which would be astounding.

I suggest that we adopt the convention of reporting Uncertainty properly by number of significant figures and the parantheses notation.

  17254   Thu Nov 10 18:09:28 2022 ranaUpdateSUSMC WFS settings all weird

Today I found the MC WFS settings all weird. Not only was the input slider set to zero, but the filter bank outputs were off, and also the ON/OFF buttons after the output matrix.

I think we may have been hacked, because there was not mention of this settings change in the ELOG, even though we have this scary red sign.

I am now trying to recover things as best as I can, but I'm not sure exactly which settings the hacker changed. Stay tuned...

Attachment 1: Photo_on_11-10-22_at_6.11_PM.jpg
  17255   Thu Nov 10 20:46:32 2022 ranaUpdateASCIMC WFS servo diagnosis

To check out the bandwidths and cross-coupling in the WFS loops, I made a script (attached) to step the offsets around, sleeping between steps. Its also in the scripts/MC/WFS/ dir.

You can see from the steps that there is some serious cross coupling from WFS1-PIT to MC_TRANS PIT. This cross-coupling is not a disaster because we run the MC2 centering loop with such a low gain. This gain hirearchy means that you can effectively consider the IMC with the WFS loops closed to be an "open loop" plant that the MC TRANS loop is trying to control.

I've started another run at 4:40 UTC since my previous one only paused for 30 seconds after turning each offset OFF/ON. This is clearly not long enough to grab the MC_TRANS loop; although you can tell sort of how slow it is from the slope of the error signal after the step is applied.

To make the plot, I used diaggui in the time series mode, with a 3 Hz BW. I applied a 4th order Butterworth filter at 0.3 Hz to low pass the data using the foton string in the time series tool.

Attachment 1: toggleWFSoffsets.py
#!/usr/bin/env python
# toggles the offsets on the WFS loops so that we can estimate the
# loop UGF from the step response
# requires that you have put appropriate size offsets 
# in the WFS1/WFS2/MC_TRANS filter banks.
# the offset should be just enough to see in the error signal, 
# but not so much that the transmitted power drops by more than ~10%
... 30 more lines ...
Attachment 2: imc-wfs-steps.pdf
  17259   Fri Nov 11 19:20:23 2022 ranaUpdateSUSMC1 OSEMs output is weird

I turned on the extra un-whitening filter (not the same as dewhitening) which Anchal has installed in the XXSEN filter banks of MC1. Seems good, so I'm leaving them on.

Anchal determined that the new satellite for MC1 was whitening, and also the old one was whitening, which made the whole thing non-white. So, I turned on the FM3 filter. I then checked that the ADCs were not saturating by looking at the spectrum of the IN1 channels (before the un-whitening). They are very far from saturating, but we should trend the ADC overflows on MC1 to make sure that this is not an issue (someone besides Tega should ask Tega how to add these to the summary pages so that not only Tega can edit summary pages).

In the attached plot, we can see that the reference trace for the unwhitened MC1 (FM1 ON, FM3 OFF) (black) sensor looks noisier than the others at 16 Hz, where we expect the suspensions to be mostly the same. This is because the analog whitening (amplification) was not being compensated properly. With FM1 and FM3 ON (RED) we can see that the spectra line up nicely below 20 Hz. Above 20 Hz the MC1 sensor is quieter than the others because the ADC noise is being reduced more.

Clearly, the other sensors could use some more whitening. If we find a reason to need lower damping noise in the future, let's remember this elog and remember that we ought to do proper signal conditioning on all our OSEMs. For now, probably doesn't matter.

Attachment 1: secretIMCsecrets.png
  17260   Fri Nov 11 19:47:04 2022 ranaUpdateSUSMC SUS were overdamped: damping gains all reduced

After clicking on the extra MC1 unwhitening filter, I was going to retune the damping gains to give a Q ~ 5 for the suspension. I found it was very over damped. I also checked the other MC SUS. They were all overdamped.

A Q ~ 5 means that the amplitude of the oscillation should drop by 1/e after 5 oscillations. Most of the DOFs were damping in 1-2 cycles. This is good for lock acquisition impulses, but because it ties the suspension to the frame, it reduces the seismic isolation that we get from the pendulum. So we normally want the Q to be ~4-7. Someone more clever can figure out a better local damping servo that minimizes the overall MCF and IMC WFS signals, but that is a project that takes some thought.

  17261   Fri Nov 11 20:01:56 2022 ranaFrogsComputer Scripts / ProgramsFSS SLOW servo not running

I was trying to debug why the NPRO PZT is all over the place, and it turns out that the new FSS SLOW script is not actually running.

The BLINKY is blinking, but the script is not running. I wasn't able to figure out how to kill the broken Docker thing, but if the code reports that its running but actually does not, we should probably just put back the old perl or python script that ran before. I don't know how to debug this current issue, but the IMC locks will be limited in length due to this servo being broken. Whoever knows about this, please stop that Docker PID and we can just run the old python script on megatron.

I also tried to post a trend plot, but the minute trends don't yet reach the current date (!!!). They seem to have stopped recording a few days ago, so I guess the Framebuilder still needs some help or its tough to figure out things like when exactly the new SLOW servo stopped working.

  17272   Wed Nov 16 12:53:36 2022 ranaUpdateASCIMC WFS ongoing

In the middle of aportioning gains and signs in the IMC WFS screen, so beware. More updates soon.

  17288   Fri Nov 18 23:21:54 2022 ranaUpdateASCIMC WFS ongoing

On Wednesday, I did some rework of the MC WFS gains. I think it should still work as before as long as the overall input gain is set to 0.1 (not 1.0 as the button on the screen sets it to).

  1. The MC_TRANS P/TY signals were very small because they are normalized by the SUM. I added a '+80 dB' gain filter to the MC2_TRANS_PIT and MC2_TRANS_YAW filter banks which increase the signal gain before the digital signals are sent from the MC2 model to the MC_WFS control screen's Input Matrix. Now if you plot the MC_TRANS and WFS signals on dataviewer, the time series all have roughly the same magnitude.
  2. I put a "-80 dB" gain button into the MC2_TRANS servo filter banks. This should make it have the same overall gain as before, since the (sensor to servo) Input Matrix is diagonal.
  3. The servo gains (WFS1_PIT, WFS2_YAW, etc.) had some negative signs. To make all the servo gains positive, I moved those signs into the Output Matrix.
  4. The Output Matrix had some values with 4-5 significant digits. I think its not necessary to have more than 2 places after the decimal point since out measurements are not that accurate, so I rounded them off. We can/should change that screen to reduce the PREC field on the matrix element display.
  5. Now, if the overall INPUT_GAIN slider is increased beyond 0.1, there is some pitch oscillation. I think that is happening because the Output Matrix is not that great. In principle, if we have diagonalized the system, putting offsets into the various loops' error points won't make offsets in the other loops, but this is not the case. The pitch loops have a lot of cross coupling (my guess is that the off-diagonal elements are of order 0.1); the yaw loops are several times better. I suggest someone redo the Output Matrix diagonalization and then use the error point offset method to check that they are diagonal.

We mainly want these loops to work well at DC, so it is perhaps better if we can measure the matrix at DC. Its less automatic than at 13 Hz, but I think it could be done with a script and some iterative matrix inversion:

  1. IMC locked, IMC ASC loops all open (by setting the overall input gain slider to zero)
  2. apply an offset in the WFS1_P basis (turn off the integrators in all the servo loops, and apply a ~400 count offset in the error point)
  3. tweak the WFS1_P output matrix until the WFS2_P and MC2_TRANS_P signals go to zero.
  4. repeat for all 6 loops.

I haven't tried this procedure before, but I think it should work. You can use something like "cdsutils servo" to slowly adjust the Output Matrix values.


  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.
ELOG V3.1.3-