40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 156 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  15755   Thu Jan 7 23:25:19 2021 KojiUpdateALSNoisy ALS

If the sensing noise level of the end PDH degraded for some reason, it'd make the out of loop stability worse without making the end pdh error level degraded.
It's just speculation.


  15756   Fri Jan 8 20:01:11 2021 gautamUpdateALSNoisy ALS

I did this test today. The excess noise around 100 Hz doesn't show up in the green beat.

See Attachment #1. The setup was as usual:

  • X-Arm cavity length stabilized to PSL frequency using the POX locking loop.
  • EX laser frequency locked to the X-Arm cavity length using the AUX PDH loop.
  • The "BEATX" channel records frequency fluctuations in the beat sensed on the IR beat photodiode, while the "BEATY" channel records frequency fluctuations in the beat sensed on the Green beat photodiode.
  • Since the green beat frequency fluctuations are twice that of the IR beat frequency fluctuations, I scaled the former ASD by a factor of 0.5 so as to compare apples to apples.
  • At low frequencies, the green beat is noisier, but that channel doesn't show the excess noise at mid frequencies you see in the IR beat. So the AUX PDH sensing noise is not to blame I think.

So, this excess appears to truly be excess phase noise on the fiber (though I have no idea what the actual mechanicsm could be or what changed between Aug and Oct 2020 that could explain it. Maybe the HEPA?

For this work, I had to spend some time aligning the two green beams onto the beat photodiode. During this time, I shuttered the PSL, disabled feedback via the FSS servo, turned the HEPA high, and kept the EX green locked to the arm so as to have a somewhat stable beat signal I could maximize. Everything has been returned to nominal settings now (obviously, since I locked the arms to get the data).

You may ask, why do we care. In terms of RMS frequency noise, it would appear that this excess shouldn't matter. But in all my trials so far, I've been unable to transition control of the arm cavity lengths from POX/POY to ALS. I suppose we could try using the green beat, but that has excess low frequency noise (which was the whole point of the fiber coupled setup). 


How about resurrecting the PSL table green beat for the X arm to see if the non-fiber setup shows the same level of the freq noise (e.g. the PDH locking became super noisy due to misalignment etc).

Attachment 1: ALSX_IR_green.pdf
  13688   Mon Mar 19 15:02:29 2018 gautamUpdateALSNoisy MC sensing

The working hypothesis, since the excess noise in single arm locks is coherent between both arms, the excess sensing noise is frequency noise in the IMC locking loop (sensing because it doesn't show up in MC_F). I've started investigating the IMC sensing chain, starting with the power levels of the RF modulation source. Recall that we had changed the way the 29.5MHz signal was sent to the EOM and demod electronics in 2017. With the handheld RF power meter, I measured 13.2dBm coming out of the RF distribution box (this is routed straight from the Wenzel oscillator). This is amplified to 26dBm by an RF amplifier (ZHL-2-S) and sent to the EOM, with a coupled 16dBm part sent to a splitter that supplies the LO signal to the demod board and also the WFS boards. Lydia made a summary of expected RF power levels here, and I too seem to have labelled the "nominal" LO level to the MC_REFL demod board as +5dBm. But I measured 2.7dBm with the RF power meter. But looking closely at the schematic of the splitting circuitry, I think for a (measured) 16.7dBm input to it, we should in fact expect around 3dBm of output signal. So I don't know why I labelled the "nominal" signal level as 5dBm.

Bottom line: we are driving a level 17 mixer with more like +14dBm (a number inferred from this marked up schematic) of LO, which while isn't great, is unlikely to explain the excess noise I think (the conversion loss just degrades by ~1dB). So I will proceed to check further downstream in the signal chain.

  13679   Mon Mar 12 22:08:31 2018 gautamUpdateALSNoisy POX

[kevin, gautam]

we tested my noisy POX hypothesis tonight. By locking the single arm with POX, the arm length is forced to follow PSL frequency, which is itself slaved to IMC length. From Attachment #1, there is no coherence between the arm control signal and MC_F. This suggests to me that the excess noise I am seeing in the arm control signal above 30 Hz is not originating from the PSL. It also seems unlikely that at >30Hz, anything mechanical is to blame. So I am sticking with the hypothesis that something is wonky with POX. For reference, a known "normal" arm control signal spectrum looks like the red curve in this elog.


Attachment 1: NoisyPOX_20180312.pdf
  13680   Mon Mar 12 23:57:31 2018 gautamUpdateALSNoisy POX

[kevin, gautam]

Kevin suggested I shouldn't be so lazy and test the POY spectrum as well. So we moved the timing card back to c1iscey, went through the usual dance of vertex machine reboots, and then got both single arm locks going. Attached spectrum shows that both POX and POY are noisy. I'm not sure what has changed that could cause this effect. The fact that both POX and POY appear uniformly bad, but that there is no coherence with MC_F, suggests to me that perhaps this has something to do with the work I did with Koji w.r.t. the power situation at the LSC rack. But we just checked that

  1. All the demod board front panel LED indicators are green.
  2. Marconi and all RF amplifier boxes are on (but we didn't actually measure any RF power levels yet tonight).
  3. We checked the KEPCO power supplies in the little cabinet along the Yarm, and all of them are reporting the correct voltages/currents as per Steve's (recently updated) labels.
  4. Checked the expansion chassis at the LSC rack for any red lights, there were none.

Another observation we made: note the huge bump around 70Hz in both arm control signals. We don't know what the cause of this is. But we occassionally noticed harmonics of this (i.e. 140, 210 Hz etc) appear in the control signal spectra, and they would grow with time - eventually, the X arm would lose lock (though the Y arm stayed locked).

I'm short on ideas for now so we will continue debugging tomorrow.

Unrelated to this work: Kevin reminded me that the high-pitched whine from the CRT TVs in the control room (which is apparently due to the flyback transformer) is DEAFENING. It's curious that the "chirp" to the eventual 15kHz whine is in opposite directions for the QUAD CRTs and the single display ones. Should be a Ph6 experiment maybe.

Update 2:30pm Mar 13: The furthest back I seem to be able to go in time with Frames is ~Jan 20 2018. Looking for a time when the arms were locked from back then, it seems like whatever is responsible for a noisy POX and POY was already a problem back in January. See Attachment #2. So it appears that the recent work at 1Y2 is not to blame...

Attachment 1: NoisyPOXandPOY_20180312.pdf
Attachment 2: noisyPOX_Jan2018.pdf
  15728   Thu Dec 10 16:24:13 2020 gautamUpdateEquipment loanNoliac PZT --> Paco

I gave one Noliac PZT from the two spare in the metal PMC kit to Paco. There is one spare left in the kit.

  11689   Wed Oct 14 16:53:22 2015 KojiUpdateGeneralNon inverting buffer for SR560

Eric needed a buffer to drive low input impedance (~130Ohm) of his pomona box, I quickly made a non-iverting buffer with G=+10. The DC power is obtained from the back of SR560. It uses 1.02K and 9.09K
to have the gain of ~10. The chip is OP27. In fact this limits the output swing to be +/-5V for the load resistance of 130Ohm. Eric thinks this is enough. If we need more, we need to swap the chip.

As SR560s tend to saturate too quickly, it would be very useful to have this kind of kit in all the labs
once it is packed in a box.

Attachment 1: IMG_20151014_145608547.jpg
Attachment 2: IMG_20151014_145548751.jpg
  1871   Mon Aug 10 11:33:58 2009 JenneUpdatePSLNon-Elogged Beam dump on the PSL table - BadBadBad

Big thumbs down to whoever put a beam dump on the PSL table in front of the PMC yesterday afternoon without noting it in the elog

The offending beam dump has been removed, and the PMC relocked.

Attachment 1: commodusthumbsdown.jpg
  1873   Mon Aug 10 15:21:15 2009 JenneUpdatePSLNon-Elogged Beam dump on the PSL table - BadBadBad


Big thumbs down to whoever put a beam dump on the PSL table in front of the PMC yesterday afternoon without noting it in the elog

The offending beam dump has been removed, and the PMC relocked.

 Maybe it was Russell Crowe

  15934   Wed Mar 17 16:30:46 2021 AnchalUpdateSUSNormalized Input Matrices plotted better than SURF students

Here, I present the same input matrices now normalized row by row to have same norm as current matrices rows. These now I plotted better than last time. Other comments same as 15902. Please let us know what you think.

Thu Mar 18 09:11:10 2021 :

Note: The comparison of butterfly dof in the two cases is bit bogus. The reason is that we know what the butterfly vector is in sensing matrix (N_osems x (N_dof +1)) and that is the last column being (1, -1, 1, -1, 0) corresponding to (UL, UR, LR, LL, Side). However, the matrix we multiply with the OSEM data is the inverse of this matrix (which becomes the input matrix) which has dimensions ((N_dof + 1) x N_osem) and has the last row corresponding to the butterfly dof. This row was not stored for old calculation of the input matrix (which is currently in use) and can not be recovered (mathematically not possible) with the existing 5x4 part of that input matrix. We just added (1, -1, 1, -1, 0) row in the bottom of this matrix (as was done in the matlab codes) but that is wrong and hence the butterfly vector looks so bad for the existing input matrix.

Proposal: We should store the last row of generated input matrix somewhere for such calculations. Ideally, another row in the epics channels for the input matrix would be the best place to store them but I guess that would be too destructive to implement. Other options are to store this 5 number information in wiki or just elogs. For this post, the buttefly row for the generated input matrix is present in the attached files (for future references).

Attachment 1: IMC_InputMatrixDiagonalization.pdf
IMC_InputMatrixDiagonalization.pdf IMC_InputMatrixDiagonalization.pdf IMC_InputMatrixDiagonalization.pdf
Attachment 2: NewAndOldMatrices.zip
  8417   Fri Apr 5 01:18:34 2013 ManasaUpdate40m UpgradingNot a fan of the new plastic box yet



 Enclosure is at the east end. It has it's bottom o-ring in place. It will be ready for optics tomorrow around 5pm

I have to shim out the enclosure, finish leveling the table and cut surgical tubing O-ring for the top.


 Glued surgical latex tubing with super glue into O-ring shape. The existing in place tubing K-100, OD 0.125" (actual size 0.140"), wall 0.031", ID 0.062".

I have just found out that tolerances on tubing OD are + - 0.026" by the manufacturer. I'm getting larger tubing for better fit.

The table is ready for optics.

Things left to do:

1, finalize o-ring size  2, finish cable feedthrough  3, finalize window connection 4, IR-Thermashield strips for bridge sides


While I did think that the plastic boxes were cool; I am not happy with the new enclosure on several aspects as I am setting up the TRY PDs/camera.

1. I strongly feel the o-rings should be glued/fixed to the plastic box atleast at some points. Even if we replace the current thin one with a thicker tubing, it takes forever to get the o-ring into the groove when it slips out. Also if it slips from the groove, it falls through the optical path and there are chances of burning the tubing when the NPRO is ON.

2. With the transparent tables, the cameras are sensitive to the room lights. I had to switch off the room lights/use ND filters to see a nice beam at the TRY camera.

3. The lids are heavy...might be a good way to train....but removing and putting them back will definitely increase the pain in getting the green aligned to the arms atleast until we have the PZTs set up.

  8419   Sat Apr 6 09:21:36 2013 ranaUpdate40m UpgradingNot a fan of the new plastic box yet


 1) We still need to drill and install the thumbscrew latches which secure the lids to the table. We cannot use the tables as an acoustic enclosure with loose lids.

2) For the camera issue, the idea is to put the longpass filters on the front of the cameras: then they are only sensitive to light with wavelength > 800 nm.

3) Whenever any interferometer work is happening the light switches must be in the positions which have been marked on them (and which most everyone ignores foolishly). We have never been insensitive to the room lights; the black table enclosures just give us a false sense of security. Room lights impact the interferometer noise.

  10962   Sat Jan 31 01:34:12 2015 JenneUpdateLSCNot able to engage AO path

Nothing earth-shattering today.

A few things of note:

  • I checked the coherence (no lock present, just noise) between REFL11_I_IN1 and CM_SLOW_OUT, which are meant to be the same thing when only the REFL1 path is allowed through the CM board.
    • However, at first, there was very little coherence - small band, and only about 0.7 or so.
    • I went inside and jiggled the cables, and also toggled the whitening switches for REFL11 and the CM_SLOW, and after that I had excellent coherence. 
      • I didn't take a coherence spectrum in between those activities, but since the cable connections were all solid, I believe that it may have been a sticky slider -esque problem, and the CM whitening wasn't matched between the analog and digital.
    • I tried two or three times to engage the AO path, but I always lost lock before I was getting any meaningful gain through.
      • I took some TFs remotely with the SR785, but they're totally noise.  I don't even know which sign of the CM board is correct, so no real knkowledge added there, from today.
  • The ~400Hz ringing that we have been seeing, we have been blaming on the PRCL loop.  However, just before my last lockloss I saw gain peaking around 400Hz in the CARM input spectrum. I didn't see if it was also there in the PRCL spectrum.  So, either it is coupling from PRCL to CARM, or CARM itself.  But I think we need to see if we can eek out a little more phase at higher frequencies for both of those loops.  I  just looked, and about 16 seconds before the last lockloss, I see the PRCL loop coupling into the CARM loop.
    • Since yesterday, we have been lowering the PRCL UGF using the servos to be about 70Hz, to give us more gain margin at the high end of the phase bubble, but we still see this ringing. 
  • Two or three times my arm power buildup at 0 CARM offset, 25% MICH offset was at 20 or 21.  Then, a few other times I was only getting about 10 (which is what we have been seeing the last few days.)
    • I'm running the ASS between each lock, although I'm not running it for a full ~2 minutes or so usually. 
    • I think that the reason I was able to get to such high arm powers was excellent alignment, so maybe it's worth sitting and waiting for the ASS to have a full 2 or 3 minutes between locks, even if the ASS error signals look zero-ed out.
    • This is still a factor of 2 lower than we expect for 25% MICH offset, but the whole factor of 5 isn't explained by some mysterious loss.  At least half of it is alignment.
  • The PRCL ASC feedforward still isn't working, but I'd like to try Q's trans qpd ASC soon, with the full lock.  I think the system is ready, but scripts are not, so Q has to be here to run it.

See first plot below for the PRCL->CARM coupling just before lockloss.  The second plot is the corresponding lockloss, where the PRCL loop is starting to see that oscillation again, and it's just barely starting to get into CARM. 

  10715   Fri Nov 14 11:07:59 2014 manasaUpdateCDSNot able to run models on FE machines


PRM, SRM and the ENDs are kicking up.  Computers are down.  PMC slider is stuck at low voltage.

Still not able to resolve the issue.

Except for c1lsc, the models are not running on any of the FE machines . I can ssh into all the machines but could not restart the models on the FE using the usual rtcds restart <modelname>

Something happened around 4AM (inferring from the Striptool on the wall) and the models have not been running since then.


Attachment 1: CDSissue.png
  6014   Sat Nov 26 02:15:42 2011 MirkoUpdateSUSNot adaptive, still cool

[Rana, Mirko]

I tried out the virtual pendulum idea today. The idea is to compensate the physical pendulum via the control system, and then add a virtual pendulum formed in the control system. We know the actuator TF from p. 5900 and apply its inverse to the C1:SUS-MC?_SUSPOS filters. Also we add an pendulum Q=3 with a resonance frequency of 0.1Hz to the POS control loops.

The result is pretty awesome!

1. Black: Standard config. Wfs on. New Cheby filter in place ( p. 6031 )
2. Red: With virtual pendulum. Extra eliptic LP filter @ 2.5Hz


Filter shape:


This is stable for 5-10minutes, at which point it falls out of lock, swinging in yaw.



Attachment 3: SetupVirtualPendulumV2.png
  6057   Thu Dec 1 03:27:39 2011 MirkoUpdateSUSNot adaptive, still cool


[Rana, Mirko]

I tried out the virtual pendulum idea today. The idea is to compensate the physical pendulum via the control system, and then add a virtual pendulum formed in the control system. We know the actuator TF from p. 5900 and apply its inverse to the C1:SUS-MC?_SUSPOS filters. Also we add an pendulum Q=3 with a resonance frequency of 0.1Hz to the POS control loops.

The result is pretty awesome!

1. Black: Standard config. Wfs on. New Cheby filter in place ( p. 6031 )
2. Red: With virtual pendulum. Extra eliptic LP filter @ 2.5Hz


Filter shape:


This is stable for 5-10minutes, at which point it falls out of lock, swinging in yaw.



In the above entry MC_f  signal is improved off of resonance by the implementation of the pendulum compensation. It should be checked if this is actually due to the implementation of the virtual pendulum at 0.1Hz. A way to check that might be to implement a simple double LP at 0.1Hz instead and look at the resulting MC_f signal. A projection of the OSEM FB noises with the compensation active might be interesting.
The physical resonance at 1Hz is clearly not compensated correctly, which is probably the reason for the lock losses after a few minutes. It might be a good start to measure the residual resonance with the compensation in place. The filters in bank 7 of C1:SUS-MC?_SUSPOS have both the compensation of the 1Hz resonance( really the inverse actuator TF ) and the virtual pendulum in them. The ‘pure’ compensation can be found in the InvTF module in the C1:OAF-ADAPT_MCL_CORR filter.
The fact that the beam swings in yaw at lock loss indicates that the separation of the DOFs might not be perfect. One should have a look into the yaw and pitch DOFs with the compensation active.

  3512   Thu Sep 2 01:48:23 2010 JenneFrogsTreasureNot cool....

This totally creeped me out when I found it wandering around on the floor not so far from my desk:


  3273   Fri Jul 23 08:18:03 2010 josephbUpdateCDSNot enough room in IO chassis for RFM card - need to swap PMC to PCIe adapters

The End IO chassis have small trenton boards, which apparently only have 5 usuable PCI slots, even though there are 6 on the board.  This is because of the way the the host interface board is setup and its closeness to the 2nd to last PCI slot

The PMC to PCIe adapters I was handed by Jay for use with the RFM cards require a 4 pin power connection at the top, which are not available inside the thin 1U computers.

The only solution I can come up with is swap the PMC to PCIe adapters for the RFM cards with adapters for some of the already installed ADCs and DACs which do not require power directly from the power supply.  This should make it possible to mount the RFM card in the computer, at least for the ends.  Since the SUS and IOO chassis will have more slots available than needed, the RFM cards can be slotted into those.  The SUS has to fit in the chassis since the computer will have the Infiband host adapter and a dolphin connector for talking to the LSC machine.

There is still the problem of actually getting the RFM card into the computer, but that should be possible with a little bit of bending of the left side of the computer frame.

  1369   Sat Mar 7 16:50:25 2009 YoichiUpdateComputersNot even data retrieval working
Now our digital system is really in trouble.
We can't even get data from tp channels.

I did another round of computer reboots, this time including the RFM bypass switch, c0daqctrl, c0dcu1 and fb40m itself.
But the problem still persists.

I guess there is nothing I can do until Alex comes in.
  1370   Sun Mar 8 23:09:26 2009 ranaUpdateComputersNot even data retrieval working
Although getting the regular DAQ data works, we can't get any testpoints.

I tried restarting tpman several times; there's no inittab on fb40m for this so we should get Alex to set one up when he comes.
I also tried various power cycles and reboots: daqawg, daqctrl, etc. I also notice that Osamu's setup of new stuff is connected to
the same rack and power strips as all of our sensitive DAQ machines. We should find out if there was any hardware installed in the
last couple days; it would be easy to accidentally unplug or damage on of our fibers.

I moved the old tpman.log over to tpman.log.090308. It starts out with a header and then just lists when each TP is requested.

When restarting tpman it puts the following into the terminal:
fb:controls>./tpman &
[1] 1037
fb:controls>VMIC RFM 5565 (0) found, mapped at 0x2868c90
VMIC RFM 5579 (1) found, mapped at 0x2868c90
Could not open 5565 reflective memory in /dev/daqd-rfm1
16 kHz system
Spawn testpoint manager
Channel list length for node 0 is 4168
Test point manager (31001001 / 1): node 0
which is OK?; its the same startup outputs that are in the old log file. It would be nice if there was not and error message about the RFM.
Requesting new testpoints via tdsdata, dtt, or the diag command line doesn't seem to work. tpman doesn't spit anything out although 'tp show 0'
does show that the TP is selected.

Once Alex fixes the 'tpman' issue, we should make sure to put an inittab or startup script in there so that tpman writes a log
file and also archives its old log files upon a restart.
  11194   Thu Apr 2 04:11:20 2015 ericqUpdateLSCNot much locking, Xover measurement

A paltry two locks tonight, but not entirely useless. I had some issues keeping the PRMI locked, which some additional boosts helped with. But, my feeling was that our crossover process is not tuned well. 

At full lock, both sub-loops have high gain around the crossover region, so the usual DTT loop transfer function measurement produces a meausrement of Gdigital/G_aopath (or minus that. I.e. I'm not currently 100% which is the bad phase in this plot, though it intuitive looks like 0 ). Thus, we can directly look at the crossover frequency and the effect of the different filters there. (I've also been working on an up-to-date CARM loop model today, so this will help inform that). 

Below, the black traces are the crossover at the end of the script when using the 120:500 "helper," and purple is without it. As we turn up the AO path gain, the trace "falls" from above, which explains why we can see instabilities around the violin filter. 

Having the helper on definitely made the probability of surviving the first overall CARM gain ramp higher, but it's not currently intuitively clear to me why that is the case. Afterwards, we can turn the helper off, to keep the shallower crossover shape. This is what I've put in to the up script for now. I also added a few seconds delay for when the script wants to switch DARM to RF only; I found it was maybe speeding too fast through this point.

DTT xml attached

Attachment 1: CARMxOver_Apr3.png
Attachment 2: Apr2_Xover.xml.zip
  11195   Thu Apr 2 15:34:34 2015 ericqUpdateLSCNot much locking, Xover measurement

Here's the comparison of last night's crossover measurement to my loop model. Not stellar, but not totally off base. All of the digital filters are read directly from the foton filter file, and translated from their SOS coefficients, so they should be accurate. I may have tallied together the wrong arrangement of FMs, though. I will recheck. 

Although I don't have a measurement to compare it with yet (as I don't know where the crossover was, the filter statesolder, etc. for the older loop measurements), here's what my current CARM loop model looks like, just for kicks. Here, only the first CM board boost is on. If we turn on some super boosting, we can probably ease up on some of the digital boosts, lower the crossover frequency, and put some lowpass that suppress the violin filters' effect on the crossover and reduces digital sensing noise injection. 

Lastly, I'll just note that my current MIST model predicts that the CARM cavity pole should be at ~170Hz, and a peak arm transmission of 180 times single arm power. I saw powers of ~120 last night. 

Attachment 1: xOverModel.png
Attachment 2: loopModel.png
  11196   Thu Apr 2 17:11:28 2015 ericqUpdateLSCNot much locking, Xover measurement

Whoops, I implemented the IOP downsampling filters wrong. Once I did that, it looked like just delay mismatch, so I added two more computation cycles for a total of four 16k cycles, which is maybe not so justified... Nevertheless, model and measurement now agree much better. Here are the corrected plots. 


Attachment 1: xOverModel.png
Attachment 2: loopModel.png
  10695   Tue Nov 11 01:38:23 2014 KojiUpdateLSCNotch at 110MHz

To further reduce the RF power at 110MHz in the REFL165 chain, I made a twin-t notch in a pomona box.

It is tuned at 110.66MHz.

The inductor is Coil Craft 5mm tunable (164-09A06SL 100-134nH).
Without the 10Ohm resister (like a usual notch), the dip was ~20dB. With this configuration, the notch of -42dB was realized.

Q >> Please measure the RF spectrum again with the notch.


Attachment 1: twin_t_notch.pdf
Attachment 2: notch_tf.pdf
  10699   Wed Nov 12 00:55:56 2014 ericqUpdateLSCNotch at 110MHz


Q >> Please measure the RF spectrum again with the notch. 

The notch filter has been installed directly attached to the output of the SHP-150 at the PD output. Structurally, there is a right angle SMA elbow between the two filters; I set up a post holder under the notch pomona box to prevent torque on the PD. Via directional coupler and AG4395, we measured the output of the REFL165 RF amplifier with the PRMI locked on REFL33. 

Note, the plot below is not referred to the amplifier output, as in my previous plots; it is directly representative of the amplifier output spectrum. 


There are no RF signals being output above -28dBm, thus I am confident that we are not subject to compression distortion. 

Given the last measurements we made (ELOG 10692), I estimate that the notch has reduced the power at 110MHz by ~33dB, which is 9dB higher than the notch performance Koji measured when he made it. Maybe this could be due to the non-50Ohm impedance of the HPF distorting the tuning, or I physically detuned it when mounting it on the PD. Still, 33dB is pretty good, and may even give us room to amplify further. (ZRL-700+ instead of the ZFL-1000LN+?)


  14510   Wed Apr 3 09:04:01 2019 gautamUpdateALSNote about new fiber couplers

The new fiber beam splitters we are ordering, PFC-64-2-50-L-P-7-2-FB-0.3W, have the slow axis working and fast axis blocked. The way the light is coupled into the fibers right now is done to maximize the amount of light into the fast axis. So we will have to do a 90deg rotation if we use that part. Probably the easiest thing to do is to put a HWP immediately before the free-space-to-fiber collimator.

Update 6pm: They have an "SB" version of the part with the slow axis blocked and fast axis enabled, same price, so I'll ask Chub to get it.

  14513   Wed Apr 3 12:32:33 2019 KojiUpdateALSNote about new fiber couplers

Andrew seems to have an integrated solution of PBS+HWP in a singe mount. Or, I wonder if we should use HWP/QWP before the coupler. I am interested in a general solution for this problem in my OMC setup too.

  713   Tue Jul 22 11:55:22 2008 ranaUpdatePSLNote from R. Abbott re: the PMC
an email from Rich:
Your PZT is broken.

  714   Tue Jul 22 13:15:14 2008 robUpdatePSLNote from R. Abbott re: the PMC

an email from Rich:
Your PZT is broken.


Quelle surprise

  10027   Wed Jun 11 15:57:18 2014 JenneUpdateCDSNote on cables for talking to slow computers

We have (now) in the lab 2 cables that are RJ45-DB9.  The gray one is LIGO-made, while the blue one is store-bought.  

The gray LIGO-made one works, but the blue store-bought one does not.  I checked their pinouts, and they are completely different.  On the sketch below, the pictures of the connectors is me looking at them face-on, with the cables going out the back of the page.  The DB9 is female. 


  10033   Thu Jun 12 15:31:47 2014 JamieUpdateCDSNote on cables for talking to slow computers


We have (now) in the lab 2 cables that are RJ45-DB9.  The gray one is LIGO-made, while the blue one is store-bought.  

The gray LIGO-made one works, but the blue store-bought one does not.  I checked their pinouts, and they are completely different.  On the sketch below, the pictures of the connectors is me looking at them face-on, with the cables going out the back of the page.  The DB9 is female. 

 There are RJ45-DB9 adapters in the big spinny rack next to the linux1 rack that are for this exact purpose.  Just use a stanard ethernet cable with them.

  7237   Mon Aug 20 23:31:49 2012 JenneUpdateCDSNote to self - fast PSL chans

Rana points out that we haven't had fast channels for PMC (trans, refl, pzt), input laser things, more FSS things since the upgrade.  Bad.

  15958   Wed Mar 24 15:24:13 2021 gautamUpdateLSCNotes on tests

For my note-taking:

  1. Lock PRMI with ITMs as the MICH actuator. Confirm that the MICH-->PRCL contribution cannot be nulled. ✅  [15960]
  2. Lock PRMI on REFL165 I/Q. Check if transition can be made smoothly to (and from?) REFL55 I/Q.
  3. Lock PRMI. Turn sensing lines on. Change alignment of PRM / BS and see if we can change the orthogonality of the sensing.
  4. Lock PRMI. Put a razor blade in front of an out-of-loop photodiode, e.g. REFL11 or REFL33. Try a few different masks (vertical half / horizontal half and L/R permutations) and see if the orthogonality (or lack thereof) is mask-dependent.
  5. Double check the resistance/inductance of the PRM OSEMs by measuring at 1X4 instead of flange. ✅  [15966]
  6. Check MC spot centering.

If I missed any of the tests we discussed, please add them here.

  14410   Sun Jan 20 23:41:00 2019 JonOmnistructureVACNotes on vac serial comm, adapter wiring

I've attached my handwritten notes covering all the serial communications in the vac system, and the relevant wiring for all the adapters, etc. I'll work with Chub to produce a final documentation, but in the meantime this may be a useful reference.

Attachment 1: Jon_wiring_notes.tar.gz
  11308   Tue May 19 11:24:44 2015 ericqUpdateComputer Scripts / ProgramsNotification Scheme

Given some of the things we've facing lately, it occurs to me that we could be better served by having some sort of unified human-alerting scheme in place, for things like:

  • Local/offsite backup failures
  • Vaccumm system problems
  • HDD status for things like /frames/ and /cvs/cds/, whether the disks are full, or their SMART status indicates imminent mechanical failure

Currently, many of these things are just checked sporadically when it occurs to someone to do so, or when debugging random issues. Smoother IFO operation and peace of mind could be gained if we're confident that the relevant people are notified in a timely manner. 

Thoughts? Suggestions on other things to monitor, like maybe frontend/model crashes?

  5032   Mon Jul 25 17:16:02 2011 JamieUpdateSUSNow acquiring SUSXXX_IN1_DQ channels

> And.....we have also lost the DAQ channels that used to be associated with the _IN1 of the SUSPOS/PIT/YAW filter modules. Please put them back; our templates don't work without them.

I have (re?)added the SUS{POS,PIT,YAW,SIDE}_IN1_DQ channels.  I did this by modifying the activateDQ.py script to always turn them on [0].  They should now always be activated after the activateDQ script is run.

[0] This script now lives in the cds_user_apps repo at cds/c1/scripts/activateDQ.py


  14288   Sat Nov 10 17:32:33 2018 gautamUpdateLSCNulling MICH->PRCL and MICH->SRCL

With the DRMI locked, I drove a line in MICH using the sensing matrix infrastructure. Then I looked at the error points of MICH, PRCL and SRCL. Initially, the sensing line oscillator output matrix for MICH was set to drive only the BS. Subsequently, I changed the --> PRM and --> SRM matrix elements until the line height in the PRCL and SRCL error signals was minimized (i.e. the change to PRCL and SRCL due to the BS moving, which is a geometric effect, is cancelled by applying the opposite actuation to the PRM/SRM respectively. Then I transferred these to the LSC output matrix (old numbers in brackets).

MICH--> PRM = -0.335 (-0.2655)

MICH--> SRM = -0.35 (+0.25)

I then measured the loop TFs - all 3 loops had UGFs around 100 Hz, coinciding with the peaks of the phase bubbles. I also ran some sensing lines and did a sensing matrix measurement, Attachment #1 - looks similar to what I have obtained in the past, although the relative angles between the DoFs makes no sense to me. I guess the AS55 demod phase can be tuned up a bit.

The demodulation was done offline - I mixed the time series of the actuator and sensor signals with a "local oscillator" cosine wave - but instead of using the entire 5 minute time series and low-passing the mixer output, I divvied up the data into 5 second chunks, windowed with a Tukey window, and have plotted the mean value of the resulting mixer output.

Unrelated to this work: I re-aligned the PMC on the PSL table, mostly in Pitch.

Attachment 1: sensMat_2018-11-10.pdf
  15517   Wed Aug 12 18:08:54 2020 gautamUpdateElectronicsNumber of the beast

The "source" output of the SR785 has a DC offset of -6.66 V. I couldn't make this up.

Upshot is, this SR785 is basically not usable for TF measurements. I was using the unit to characterize the newly stuffed ISC whitening board. The initial set of measurements were sensible, and at some point, I started getting garbage data. Unclear what the cause of this is. AFAIK, we don't have any knob to tune the offset - adjusting the "offset" in the source menu, I can change the level of the offset, but only by ~1 V even if I apply an offset of 10 V. I also tried connecting the ground connection on the rear of the SR785 to the bench power supply ground, no change.

Do we have to send this in for repair?

Attachment 1: IMG_8710.JPG
  15519   Wed Aug 12 20:15:42 2020 KojiUpdateElectronicsNumber of the beast

Grrr. Let's repair the unit. Let's get a help from Chub & Jordan.

Do you have a second unit in the lab to survive for a while?

  3515   Thu Sep 2 16:45:48 2010 josephbUpdateCDSNumbering scheme of the PCI bus

Rolf has recently written a document describing how one should fill out an IO chassis and how the numbering works out.  This can be found in the DCC at Rolf's PCIe numbering guide (T1000523).

Basically it works out that slot 1 corresponds to PCIe number 1, but slot 2 corresponds to PCIe number 6.  And so forth.  The following table gives a quick summary.

Slot 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
PCIe Number 1 6 5 4 9 8 7 3 2 14 13 12 17 16 15 11 10


  874   Mon Aug 25 10:07:35 2008 JenneUpdatePSLNumbers for the PMC servo board (Re: entry # 873)
Jenne, Rana

These are the numbers that go along with Rana's entry #873:

The existing notch in the PMC servo is at 31.41kHz.

The power spectrum of the PMC has a peak at 14.683kHz when it is just sitting on the PSL table (no extra mass). When we put a pile of steel and aluminum (~20lbs) on top of the PMC, the body resonance moves to 14.622kHz, but is decreased by about 40 dB!

Rana has ordered a lead brick + foil that should arrive sometime this week. To complete the mechanical part of this installation, we need to extend the earthquake mounts around the PMC so that the lead brick can't fall off of the PMC onto the rest of the table.
  2442   Tue Dec 22 02:50:09 2009 rana, kiwamu, jenneUpdateASSOAF Feedaround ON and doing something good

Kiwamu made the OAF screen functional today - screenshot attached.

After this, I used the measured TF of the MC1 to MCL to filter the signals from the Wilcoxon accelerometers and feed them into the MC.

The noise at 3 Hz went down by a factor of ~3. There's a little excess created at 100 Hz. Its good to see that our intuition about feed-forward is OK.

I did all of the filter calculations by adapting the scripts that Haixing, Valera, and I got going at LLO. They're all in the mDV/extra/C1 SVN.


The Wiener code predicts much better performance from using more than just 2 horizontal accelerometers, but I was too lazy to do more channels today.

I also added the Rai box to the Ranger readout today - the noise at 0.1 Hz went down by a factor of 10 and the noise at 1 Hz is close to 10^-11 m/rHz.

Attachment 1: oaf.png
Attachment 2: oaf.png
  2449   Wed Dec 23 17:33:14 2009 ranaUpdateASSOAF Feedaround ON and doing something good

The Rai box ran out of batteries a couple of days ago and so the data is no good. I've put the Ranger back on the SR560 for now (but with the damping resistor removed, so the gain is 2x more than before).

  5848   Wed Nov 9 14:23:35 2011 JenneUpdateAdaptive FilteringOAF MC Delay Measurement

As described in elog 2063 and the mevans document, we need to measure the TF of the OAF's plant, to find the delay.

At DC, the phase is 2.5deg, and at 32Hz, the delay is -4.6Hz (extrapolated from the points at ~30deg and ~38deg).  The DTT file is in /users/Templates/OAF/OAF-MCL-Delay-9Nov2011.xml . 

This gives a phase lag of 7.1deg at the Nyquist freq.

7.1 / 180 * 32 = 1.26, so ~1 cycle delay.  Not so much.  The new ADCs are waaaay faster than the old 110Bs.  Yay!

Attachment 1: OAF-MCL-Delay-9Nov2011.pdf
  2434   Sun Dec 20 21:39:40 2009 rana, jenne, kiwamuUpdateASSOAF Model update and build instructions

After a lot of headache, I got the OAF working again - read on for details.....................

Sometime last week, Jenne, Kiwamu, and I tried to update the OAF model to include the IIR "feed-around" path.

This path is in parallel to the existing FIR-based adaptive FXLMS stuff that Matt put in earlier. The reason for the

new path is that we want to try emulating the same FF technology which has been successful lately at LLO.


However, we were unable to make the ASS work after this work. Mostly, the build stuff worked fine, but we couldn't get DTT

to make a transfer function. The excitation channels could be selected and the excitation would actually start and get all the

way into MC1, but DTT would just hang on the first swep-sine measurement with no time-out error. Clearly our ASS building

documentation is no good. We tried using the instructions that Koji gave us for AAA, but that didn't completely work.


In particular, the 'make-uninstall-daq-ass' command gave this command:

[controls@c1ass advLigo]$ make uninstall-daq-ass
grep: target/assepics/assepics*.cmd: No such file or directory
Please make ass first
make: *** [uninstall-daq-ass] Error 1

re-arranging the order to do 'make-ass' first fixes this issue and so I have fixed this in the OAF Wiki.


The there's the whole issue with the tpchn_C3.par file. This contains all the test point definitions for the ASS/OAF machine. The main

IFO numbers are all in tpchn_C1.par and the OMC is all in tpchn_C2.par. When we do the usual build, in the 'make install-daq-ass' part:

[controls@c1ass advLigo]$ make install-daq-ass
Installing GDS node 3 configuration file
Updating DAQ configuration file

we get this .par file installed in the target area. The ACTUAL param file seems to actually be in /cvs/cds/caltech/gds/param  !!


Of course, it still doesn't work. That's because the standard build likes to point to /cvs/cds/caltech/gds/bin/awgtpman and the one that runs on

linux is actually /opt/gds/awgtpman. So I've now made a file called startup_ass.cmd.good which runs the correct one. However, the default build

will try to start the wrong one and we have to fix the 'startass' script to point to the correct one on each build. Running the correct awgtpman

allows us to get the TP data using tools like tdsdata, so far no luck with DTT.\


UPDATE (23:33): It turns out that it was my old nemesis, NTPD. c1ass had a /etc/ntp.conf file that was pointing at an ntp server called rana113. I

am not an NTP server; I don't even know what time it is. I have fixed the ntp.conf file by making it the same ass c1omc (it now points to nodus). After

this I set the date and time manually (sudo date -s "20 DEC 2009 23:27:45") and then restarted NTPD. It should now be fine even when

we reboot c1ass.


After all of this nonsense, I am able to get TP data from c1ass and take transfer functions between it and the rest of the world !

  2437   Mon Dec 21 02:22:31 2009 rana, jenne, kiwamuUpdateASSOAF Model update and build instructions

This allowed measuring the MC1 -> MCL TF finally. Its mostly flat. Data saved as Templates/OAF/OAF-MCLTF.xml

Attachment 1: Untitled.png
  2438   Mon Dec 21 07:30:58 2009 ???UpdateASSOAF Model update and build instructions

 What does OAF stand for? The entry doesn't say that. Also the acronym is not in the abbreviation page of the wiki.

Can anyone please explain that?

  2440   Mon Dec 21 10:09:06 2009 jenneUpdateASSOAF Model update and build instructions
OAF stands for Online Adaptive Filtering. We use the same computer which was once the ASS. One of these days, we'd like to completely be rid of all things which refer to ASS, and make even the computer's name OAF.
  2441   Mon Dec 21 19:24:29 2009 ranaUpdateASSOAF Model update and build instructions

I fit the MC1 -> MCL TF using vectfit4.m (from mDV). The wrapper file is mDV/extra/C1/ fitMC12MCL.m.

Plotted here are the data (RED), the fit (BLUE), and the residual x10 (GREEN).

For the magnitude plot, residual is defined as ------   res = 1 - fit / data

For the phase plot the residual is defined as -------    res =  phase(data)-phase(fit)

You can see that the agreement is very good. The phase match is better than 5 deg everywhere below 10 Hz.

This TF is so smooth that we could have probably done without using this, but its good to excercise the method anyway.

Attachment 1: mc12mcl.png
  2571   Fri Feb 5 00:52:55 2010 SanjitUpdateAdaptive FilteringOAF at 0.1-1.0 Hz


At 0.1-1.0Hz, there is some coherence between MC_L and RANGER_Y & GUR_Y, see the first figure. Also GUR_Z has low noise there. So I used all five of them, increased the gains of GUR_Z from 0.1 to 0.5. Some improvement near 0.5Hz. We possibly can not do any better with these PEM measurement, as the coherence of the adapted error signal and the PEM channels is almost zero, see the second figure. May be we need to think about placing the seismometers at different places/orientations.

However, there is lot more scope at higher frequencies, lot of coherence at 5-100Hz.


Attachment 1: OAF_04FEB2010_noOAF.png
Attachment 2: OAF_04FEB2010.png
ELOG V3.1.3-