pushd /cvs/cds/caltech/users/tf/build/labca_2_1/bin/linux-x86
setenv PATH ${PATH}:`pwd`
cd /cvs/cds/caltech/users/tf/build/labca_2_1/lib/linux-x86
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:`pwd`
popd

addpath /cvs/cds/caltech/users/tf/build/labca_2_1/bin/linux-x86/labca
help labca
foo = lcaGet('C1:PSL-FSS_RCTRANSPD')

Physical Electronics: Vac-Seal #288-6000 arriving Monday. Our last bag used last week had a p/n 1002003 with expiration date   .....2009 ? and it was stored in the

refrigerator all times. We are getting 68 small bags.

We should have precision gluing notes of epoxies/procedures used on our sus upgrade.

The oplev plots clearly show the alignment effect of this eq.

I've created transmission error monitors in rfm, oaf, sus, lsc, scx, scy and ioo models. I tried to get data from every channel transmitted through PCIE and RFM. I also included some shared memory channels.

The medm screen is in the EF STATUS -> TEM. It shows 16384 for the channels that come from simulation plant. Others are 0, that's fine.

As we now have the loop model, we can characterize the error signals.

We have the following data:

1) Free-running ALS error signals (i.e. phase tracker output) calibrated in Hz (for 532nm) (blue)
2) Controlled ALS error signals calibrated in Hz (for 532nm) (red)
3) ALS error signals measured with X and Y arm locked with the IR PDH. (black)
    This is likely to represent the sensing noise of the beatnote detection

from 2) we can derive the similar quantity as 1)
4) Estimated free-running ALS error signals from the controlled signals (green)

Remarks:

- From 1) and 4) we can see that the phase tracker is not perfectly linear. It seems that fast fringing of the phase tracker is causing upconversion.

- From 2) and 3) the servo loops don't have enough gain between 3Hz and 20Hz. On the other hand they have too much gain bekow 3Hz.

Assuming that PRM is interfering with some other optics, I have estimated the optical distance between PRM and an object that interferes with PRM.

The optical distance is estimated to be 9.5 +/- 0.5 m.

If we believe this number the object is most likely outside of the vacuum chambers.

 (The measurement)

1.  Preparation : calibration of the MC2 actuator as a frequency actuator (for more details, see the next section)
2.  Set the interferometer to the single-bounce configuration such that the beam directly is reflected back from PRM
3.  Take spectra of REFL11_I without driving any optics. This spectra tells us how quiet the noise normally is.
4.  Drive MC2_POS at 10 Hz with an amplitude of 10000 counts so that we can see the high frequency up conversion noise
   • The frequency was chosen such that the excitation is out of the local damping bands
   • The amplitude was chosen to be as big as possible until the MC unlocked
   • With this drive, the laser frequency should change by 20 MHz peak-peak at 10 Hz.
5.  Record the noisy spectrum when the MC2_POS was driven.
6.  Drive PRM instead of MC2 at 10 Hz.
   • Adjust the amplitude of the excitation such that the cut-off frequency of the up conversion noise matches with that of the MC2 driven case.
   • The amplitude was found to be 1700 - 2000 counts, this uncertainty is currently limiting the precision of the optical distance estimation.
   • With this amount of the drive, PRM moves by 0.8 um peak-peak at 10Hz.
7. Estimate the optical length based on the amount of the drives for PRM and MC2.
   • Estimate the FSR using the following relation df/FSR = dx/ (lambda/2). => FSR = 17 MHz
   • Since FSR = c/ (2L),  L = c/(2 FSR) = 9.5 m or so

(Calibration of the MC2 actuator)

I searched for a scattering body in the REFL path.

According to the result the REFL path on the AS table is innocent.

The idea of the search method is given as follows:

•   Put a 1/10 ND attenuator at the origin of the REFL path on the AS table.
•   Of course this reduces the signal level by the same factor of 10 in the REFL11_I demod signal.
•   If the scattering body is in the REFL path the up conversion noise will be smaller by a factor of 100 because the scattered light go across the attenuator twice.

All parts received and assembly near complete, small problem detected because the two DSub connectors are too close together for two cables to fit at the same time. Gautam and I will make some additional slot panels tomorrow using a waterjet cutter, so we can spread the breakout boards out and remedy this.

Fast binary channels need to be spliced into DSub connectors. Aaron is on this. All other, slow connections are already wired from before and have been tested for correct pins on the backplane DIN connectors.

The Acromag modules require only a positive supply voltage between +12 and +30 VDC and draw a maximum of 2.8W at that. This raises the question if we want this supply rail to be regulated or take the raw power from the Sorensens. Consulting with Ben Abbott: The Acromags in LIGO do not operate with regulated power. We could easily accomodate the standard regulator boards D1000217 in the chassis, which is probably a good idea if we want to place any custom electronics inside the chassis in the future, for example for whitening or active lowpass filtering.

This evening I transitioned the slow controls to c1auxex2.

1. Disconnected satellite box
2. Turned off c1auxex
3. Disconnected DIN cables from backplace connectors
4. Attached purple adapter boards
5. Labeled DSub cables for use
6. Connected DSub cables to adapter boards and chassis
7. Initiated modbus IOC on c1auxex2

Gautam and I then proceeded to test basic functionality

1. Pitch bias sliders move pitch, yaw moves yaw.
2. Coil enable and monitoring channels work
3. Watchdog seems to work. We set the treshold for tripping low, excited the optic, watchdog didn't disappoint and triggered.
4. All channels Initialize with "0" upon machine/server script restart. This means the watchdog happens to be OFF, which is good . It would be great if we could also initialize PIT and YAW to retain their value from before to avoid kicking the optic. This is not straightforward with EPICS records but there must be a way.
5. We got the local damping going .
6. There is some problem with the routing of the fast BIO channels through the new chassis - so the ANALOG de-whitening filter seems to be always engaged, despite our toggling the software BIO bits . Something must be wrongly wired, as we confirmed by returning only the FAST BIO wiring to the pre-acromag state (but everything else is now controlled by acromag) and didn't have the problem anymore. Or some electrical connection is not made (I had to use gender changers on these connectors due to lack of proper cabling)
7. The switches for the QPD gain stages did not work. I suspect a wiring problem, since the switching of the coil enables did work.

Arms are locked, have been for ~1hour with no hickups. We will leave it like this overnight to observe, and debug further tomorrow.

Some suggestions of checks to run, based on the rightmost colum in the wiring diagram here - I guess some of these have been done already, just noting them here so that results can be posted.

1. Oplev quadrant slow readouts should match their fast DAQ counterparts.
2. Confirm that EX Transmon QPD whitening/gain switching are working as expected, and that quadrant spectra have the correct shape.
3. Watchdog tripping under different conditions.
4. Coil driver slow readbacks make sense - we should also confirm which of the slow readbacks we are monitoring (there are multiple on the SOS coil driver board) and update the MEDM screen accordingly.
5. Confirm that shadow sensor PD whitening is working by looking at spectra.
6. Confirm de-whitening switching capability - both to engage and disengage - maybe the procedure here can be repeated.
7. Monitor DC alignment of ETMX - we've seen the optic wander around (as judged by the Oplev QPD spot position) while sitting in the control room, would be useful to rule out that this is because of the DC bias voltage stability (it probably isn't).
8. Confirm that burt snapshot recording is working as expected - this is not just for c1auxex, but for all channels, since, as Johannes pointed out, the 2018 directory was totally missing and hence no snapshots were being made.
9. Confirm that systemd restarts IOC processes when the machine currently called c1auxex2 gets restarted for whatever reason.

Both issues were fixed. In both cases it was two separate causes that prevented them from working.

The QPD gain stage switch software channels were assigned to wrong physical pins of the Acromag, and additionally their DSub cable was swapped with a different one.

The BIO switching had its signal and ground wires swapped on ALL connections, and part of it was also suffering from the cable-mixup.

Both issues were fixed. All backplane signals are now routed through the Acromag chassis.

Gautam and I did notice that occasionally ETMX alignment will start drifting as evident from the OpLev. I want to set up a diagnostic channel to see if the DAC voltages coming from the Acromag are responsible for this.

Steve and I removed c1auxex from 1X9 today to make space for the DAQ chassis. Steve installed rails for mounting. To install the box I had to remove all cabling, for which I used the usual precautions (disconnect satellite box etc.)

On reconnect c1auxex2 didn't initialize the physical EPICS channels (the 'actual' acromag channels), apparently it had trouble communicating. A reboot fixed this. It's possible that this is because of the direct cable connection without a network switch that exists
between the Acromags and c1auxex. The EPICS server was started automatically on reboot.

Currently the channel defaults need to be loaded manually after every EPICS server script restart with burt. I'm looking for a good way to automate this, but the only compiled burt binaries for x86 (that we can in principle run on c1auxex2 itself) on the martian network are from EPICS version 3.14.10 and throw a missing shared object error. Could be that simply some path variable is missing.

The burt binaries are not distributed by the lscsoft or cdssoft packages, so alternatively we would need to compile it ourselves for x86 or get it working with the older epics version.

Pete, Rob

After looking at some oplev noise spectra in DTT, we discovered that the ETMY quad (serial number 115)  was noisy.  Particularly, in the XX_OUT and XX_IN1 channels, quadrants 2 (by a bit more than an order of magnitude over the ETMX ref) and 4 (by a bit less than an order of mag).  We went out and looked at the signals coming out of the oplev interface board; again, channels 2 and 4 were noise compared to 1 and 3 by about these same amounts.  I popped in the ETMX quad and everything looked fine.  I put the ETMX quad back at ETMX, and popped in Steve's scatterometer quad (serial number 121 or possibly 151, it's not terribly legible), and it looks fine.  We zeroed via the offsets in the control room, and I went out and centered both the ETMX and ETMY quads. 

Attached is a plot.  The reference curves are with the faulty quad (115).  The others are with the 121.

 I adjusted the ETMY quad gains up by a factor of 10 so that the SUM is similar to what it was before.

It started with fire alarm test yesterday at 14:50 All alarms are  functioning VERY loud and their flashers are bright. Evacuation drill followed. We assembled at north west corner of the 40m building and counted 6 heads.

Nobody was left sleeping inside. Bob carried the success report of the drill to PMA office immediately.

Head count at the evacuation drill today. I checked  alarms and flashers  at room 104,102,101, 103, 105 and 107. They were really loud and bright. 

[Suresh, Jamie]

Suresh and I opened up and checked out the eLIGO tip-tilts assemblies we received from LLO. There are two, TT1 and TT2, which were used for aligning AS beam into the OMC on HAM6. The mirror assemblies hang from steel wires suspended from little, damped, vertical blade springs. The magnets are press fit into the edge of the mirror assemblies. The pointy flags magnetically attach to the magnets. BOSEMS are attached to the frame. The DCC numbers on the parts seem to all be entirely lies, but this document seems to be close to what we have, sans the vertical blade springs: T0900566

We noticed a couple of issues related to the magnets and flags. One of the magnets on each mirror assembly is chipped (see attached photos). Some of the magnets are also a bit loose in their press fits in the mirror assemblies. Some of the flags don't seat very well on the magnets. Some of the flag bases are made of some sort of crappy steel that has rusted (also see pictures). Overall some flags/magnets are too wobbly and mechanically unsound. I wouldn't want to use them without overhauling the magnets and flags on the mirror assemblies.

There are what appear to be DCC/SN numbers etched on some of the parts.  They seem to correspond to what's in the document above, but they appear to be lies since I can't find any DCC documents that correspond to these numbers:

TT1: D070176-00 SN001
  mirror assembly: D070183-00 SN003
TT2: D070176-00 SN002
  mirror assembly: D070183-00 SN006

The punch line is -- the sensing matrix still looks strange in the PRMI configuration.

I have been measuring the sensing matrix of the PRMI configuration because it didn't make sense (#6283).

One strange thing I have noticed before was that all the I-phase signals showed a weird behavior -- they fluctuate too much in time series.

Tonight I measured the sensing matrix again but this time I recorded them as a function of time using the realtime LOCKINs in the LSC front end.

The attached plots are the responses (optical gains) of PRCL and MICH in watts / meter at various sensors in time series.

I will explain some more details about how I measured and calibrated the data in another elog entry.

Next steps:

• Compare the obtained sensing matrix with an Optickle model. Particularly I am interested in the absolute strengths in watts/meter
• Noise estimation of the REFL33_Q as a MICH sensor to see if this sensor is usable for holding MICH.

This is the simulated signals to compare with the original post #6403

Here I describe the measurement of the sensing matrix.

Motivations

  There were two reasons why I have been measuring the sensing matrix :

1.  I wanted to know how much each element in the sensing matrix drifted as a function of time because the sensing matrix didn't agree with what Optickle predicted (#6283).
2.  I needed to estimate the MICH responses in the 3f demodulated signals, so that I can decide which 3f signal I should use for holding MICH.

 I will report #2 later because it needs another careful noise estimation.

Measurement

 In order to measure the sensing matrix, the basic steps are something like this:

1. Excite one of the DOF at a certain frequency, where a notch filter is applied in the LSC servos so that the servos won't suppress the excitation signal.
2. Demodulate the LSC signals (e.g. C1:LSC-REFL11_I_ERR and etc.,) by the realtime LOCKINs (#6152) at the same frequency.
3. Calibrate the obtained LOCKIN outputs to watts/meter.

LOCKIN detection

• The LOCKIN oscillator excites ITMs differentially
  • In order to purely excites the MICH DOF, the actuation coefficients were precisely adjusted (#6398).
  • Currently ITMY has a gain of 1, and ITMX has a gain of -0.992 for the pure MICH excitation. Those numbers were put in the output matrix of the LOCKIN oscillator.
• The demodulation phase of the LOCKIN system was adjusted to be -22 deg at the digital phase rotator.
  • This number maximizes the in-phase signals while the quadrature-phase signals give almost zero.
  • This number was adjusted when the simple MICH configuration was applied.
• In the demodulations, the LO signals have amplitude of 100 counts to just make the demodulated signals readable numbers.

Calibration of the LOCKINs

Calibration of the responses to watts/meter

Settings and parameters

•  LSC RF demodulation phases
  
  •  AS55 = 17.05 deg (minimizing the PRCL sensitivity in the Q-phase)
  •  REFL11 = -41.05 deg (maximizing the PRCL sensitivity in the I-phase)
  • REFL33 = -25.85 deg (maximizing the PRCL sensitivity in the I-phase)
  • REFL55 = 4 deg (maximizing the PRCL sensitivity in the I-phase)
  • REFL165 = 39 deg (random number)
•  Whitening filters
  • AS55 = 30 dB
  • REFL11 = 0 dB
  • REFL33 = 42 dB
  • REFL55 = 30 dB
  • REFL165 = 45 dB
• MICH servo
  • AS55_Q for the sensor
  • G = -5 in the digital gain
  • FM2, FM3, FM5 and FM9 actiavted
  • UGF ~ 100 Hz
  • Feedback to ITMs differentially
• PRCL servo
  • REFL33_I for the sensor
  • G = 1 in the digital gain
  • FM2, FM3, FM4, FM5 and FM9 activated
  • UGF ~ 100 Hz
  • Feedback to PRM

This is not a test. Life can be dangerous in the 40m Control  Room.

 I asked Jamie to read these docs so we can do some troubleshooting while at atmosphere. We have to have the all valve closed DEFAULT condition working-tested.

I'd like to reconnect all valves after this test so the state identification software could work, including interlocks.

Posted the following documents on 40m wiki.

http://www.ligo.caltech.edu/~ajw/40m/40mVaccum_T000054-00.pdf
http://www.ligo.caltech.edu/~ajw/40m/40mProcedures.doc 

https://dcc.ligo.org/DocDB/0015/D000338/000/D000338-00.pdf

Caltech security called me at 1am Sunday. Control room emergency exit door was found unlocked!

It is your responsibility to lock door if you unlocked it !

I unlocked the door on Tuesday in order to move the red cart.
After that I confirmed that the door was locked.

I have estimated how the mode profile of the PRM reflection should be, as shown in the plot blow.

A conclusion here is :

   we should be able to constrain the PRM curvature situation if measurements are precise and accurate enough with a level of less than ~ 100 um

In the calculation two cases are considered :

      (1) PRM has the correct curvature of  +122 m. This is shown as solid curves in the plot.

      (2) PRM has a wrong curvature of - 122 m (mirror is flipped) This is shown as dashed curves in the plot. 

Note:

 I have omitted the effect from the PRM thickness. Therefore PRM is dealt as just a curved reflector with RoC of +/- 122 m in the calculation.

Here shows a plot of the expected open loop transfer function (TF) for the X arm locking.

I assume that the delay time of the digital system associated with the ADC/DAC and the digital filtering process is ~100 usec independently from the RFM delay according to Yuta's measurement (#3961).

Also I assume the MC2 pendulum has a pole at 1Hz with Q of ~5, and the X arm has its cavity pole at ~3kHz.

When the lock acquisition takes place, we used the red curve shown above in order to avoid a big DC feedback onto MC2.

Once the X arm became resonant at TEM00, we manually switched FM3 on, which is a boost filter containing a pole at  1Hz and a zero at 50Hz in order to suppress the residual motion below 1Hz.

The expected curve for the boosted state is drawn by the blue curve in the plot. 

With this open loop TF, the UGF can be realized only around 100-300 Hz due to the phase margin condition.

This expectation of the UGF is consistent with our measurement because we obtained the UGF around 200-300Hz.

In fact above 300Hz we observed that the control became unstable and started oscillating.

[Suresh / Kiwamu]

 We did the 2nd round of the PRM reflection mode scan on Friday.

It seems that the PRM curvature maybe correct if we look at the vertical mode, however but the horizontal mode doesn't seem to agree with any of the expected lines.

In order to increase the reliability of the measurement, we need to confirm the beam profile of the incident beam by looking at the IP-POS beam.

Right now Suresh and Keiko are mode-scanning the IP-POS beam.

The plot below shows both the expected beam profiles (see the detail in #6444) and the actual data. 

(Discussion)

• Clipping at some optics. (Since the beam shape looked very Gaussian, the amount of the clipping could be very slight ?)
• Astigmatism at some optics. (Possibly in the telescope ?)

(Some distances)

(Some notes)

We did the following things prior to the measurement.

• Put a boost filter in the PRM_OLYAW to suppress the beam jitter below 1 Hz.
• Checked the MC WFS servo loop although it looked healthy.

I measured relative motion of 2 seismometers separated by 4, 18 and 38 feet.

Relative motion for difference distances between seismometers is presented below.

Al frequencies f < f_crit relative motion becomes smaller then motion of each point. At these frequencies, the ratio relative / absolute motion can be approximated as ratio = C f^a . The following table summarizes f_{crit, C and a for different length between seismometers.}

_{Using this approximation we can estimate the desired noise floor of the seismometer to subtract seismic noise from MC_F}

Desired seismometer noise should be 100 times less then Guralp's. ADC noise is still less then this level, so this will not be a problem.

Note: for longer cavities condition for seismometer noise becomes more week as f_{crit decreases with length.}

I wondered if linoleum is a reason of high Guralp noise. I measured Guralp noise in 3 cases: they stand on a very soft piece of paper, linulium and stone.

I've calibrated the noise to units m/s/sqrt(Hz). Using soft paper we get the worst noise, stone - the best, but noises do not differ that much and still much worse then declared noise in the manual.

[Rana, Jenne]

There is some craziness going on with the delay in the PEM path for the OAF.  We plot the difference between the C1:PEM-SEIS_GUR1_X and C1:ASS-TOP_PEM_10.  These are physically the same channel, plugged into the PEM ADCU, and then the signal is used as a regular PEM channel, and is also sent to the ASS computer and used there for the OAF system.  As you can see in the blue trace on the bottom plot, there is a huge amount of delay, and it's very noisy.  We also plot the _GUR2_X / ASS-TOP_PEM_2 pair (red), and it has a similar amount of delay, but it is not nearly as fuzzy and noisy.  For comparison, we plot the SUS-MC2_MCL (which is identical to IOO-MC_L) and ASS-TOP_ERR_MCL pair (green), and they don't have any big overall delay problems, so it's not totally a problem with the signals getting to the ASS computer.

This problem was present during/after all of the following attempts to fix it:

* The sample rate on the ASS computer is 2048.  The PEM channels were being acquired the ADCU at 512.  We changed the ADCU sampling rate to 2048 to match.

* We soft rebooted the ASS computer, in case it was a timing problem.

* Doing a "sudo shutdown -r now" while logged in as controls.

We might also try resetting/power cycling c0dcu in the morning.  Alex has been emailed to help us try to figure this out.

In other news, the time delay that we measure from the plot gives us 180degrees in ~210Hz.  This corresponds to a little more than 2msec of delay, with the C1:ASS version lagging behind the C1:PEM version.  (2 samples at 840Hz) Converting to the 2048 sampling rate, we have a delay of 4.8, so 5 front-end cycles.  Since Rana measured this morning that the delay indicated by the transfer function is 10 cycles, and this delay shows that the ASS lags the actual seismometer signal by 5 cycles, we should subtract this 5 from the 10 from the transfer function, giving us a final sample-and-hold delay of 5.  Coincidentally(?), 5 is the delay that was found in the C1:ASS-TOP screen, after it's one year of dormancy.  The point of the delay feature in the code is to help match the delay in the two signal paths: the PEM path and the output path of the filter.  Since the output has a lag of 10, and the PEM path has a lag of 5, to make them match, we artificially put in a delay of 5.

 Alex came in a week ago Friday to help figure this timing problem out, and some progress was made, although there's more to be done. 

Here are the (meager) notes that I took while he was working:

we can rename the tpchn_C1_new back to tpchn_C1, but the _new one works right now, so why change it?

need to find dcuDma.c source code...this is (?) what sends the PEM channels over to ASS.  Found:  source code is dcu.c, th
en the binary is dcuDma.o  Trying to recompile/remake dcuDma to make everything (maybe) good again.

Possibility: maybe having so many channels written to the RFM takes too long? shouldn't be  a problem, but maybe it is.  I
n the startup.cmd (or similar?) change the number of ISC modules to 1, instead of 2, since we only have one physical board
 to plug BNCs into, even though we have 2 isc boards.  c0dcu1 rebooted fine with the one isc board.  now can't get ass tes
tpoints to try the DTT timing measurement again.  rebooting fb40m to see if that helps.  fb40m is back, but we still don't
 have ASS testpoints.  Alex had to leave suddenly, so maybe more later.

Also, next possibility is that c0dcu and c1ass are not synched together properly....we should look at the timing of the AS
S machine.
 

After these adventures, the noisy trace in the timing delay (in the plot in elog 2066) has become quiet, as shown below (The blue trace, which was noisy in 2066 is now hiding behind the red trace).  However, the overall timing delay problem still exists, and we don't quite understand it.  Alex and I are meeting tomorrow morning at the 40m to try and suss this out.  Our first plan of attack is to look at the ASS code, to see if it puts any weird delays in.

Rana pointed out that the delay may be caused by the 110B DAQ, as it integrates over 2ms (5 clock cycles at 2048Hz on the fe computer), to make low noise measurement. However, the C0DCU knows about this delay and corrects it by fudging the time stamp, before sending it to the frame builder, so that the time stamps match the actual measurement time. But, the ASS computer is not aware of such an integration time, so it does not adjust the time. We verified that it is indeed the case. This is what we did (as suggested by Rana):

We split the signal from the MODE cleaner board "OUT" port using a T-splitter to the original PENTEK board (C1:SUS-MC2-MCL-IN) and the PEM ADCU channel #2. Then measured the mutual delays between the signals that are processed by C0DCU and the ASS computer for both the MC_L signal and the corresponding output through the PEM channel. We clearly see the same delay (compare red and brown in the bottom panel) between the signals that are going through 110B and the PENTEK DAQ. This delay is a bit noisy, possibly because the PENTEK is not as low noise as the 110B is.

There is some delay (pink curve in the bottom panel) between the PENTEK DAQ and the frame builder corrected 110B output, much smaller than 2ms, could be ~200-400 u sec. Which should correspond to the 1 or 1/2 cycle delay caused by the PENTEK DAQ.

So, once we have the planned advLIGO DAQ system, there should not be any long delay. Perhaps, to solve the problem and make OAF functional soon, we will upgrade the PEM DAQ asap, rather than waiting for the rest of the upgrades...

An email from Rolf about the delay in the 110Bs:

"...we do take the ~2msec pipeline delay into account when we send the data to DAQ. If I remember correctly, the delay is about 39 samples. On startup, the first 39 samples are 'thrown away', such that, from then on, data lines up with the correct time (just read 2msec later then Penteks)."

#!/bin/csh -f
setenv POSIXLY_CORRECT
while (! { ezcawrite.bin $* })
      echo "Retry $0 $*"
end