40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 289 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  6875   Tue Jun 26 22:37:43 2012 yutaUpdateIOOenergized OMC stages

[Koji, Yuta]

We checked that PZTs between SRM and OMC (called OMC stage 1 and 2) is working.
Now we need them to be EPICS channels because they are not connected to digital world right now.

Background:
  For the IFO alignment, what we have been doing for last 2weeks is,

1. Align Y arm to Y end green and maximize green transmission
2. Use PZT2 to maximize TRY (PZT1 is not functioning well. PZT1 Y do a little, but X totally does nothing.)
3. Align BS and X arm to maximize TRX
4. Tune BS and ITMX so that reflection from both arms overlap at AS
5. Align X end green to that we can see bright(~250 uW) TEM00 at transmission

  However, we found that something (Y arm axis or Y end green?) has drifted horizontally and can't make Y green transmission and TRY high level at same time. Because PZT1 is not functioning well, it is hard to compensate beam translation.
  So, now what we have to do is to align Y arm to IR incident beam. That means, we either have to realign Y end green or forget about maximizing green transmission. I think I will leave green as it is for a while because calibration of the beatbox is going on and I want to proceed to PRC.
  Anyway, if we align IFO to the IR incident beam, we see clipping in the AS port. From the contrast measurement last night, we thought clipping comes from somewhere between BS and AS port. So, we need PZTs between BS and AS port working.

What we did:
  1. Turned on 24P 24N power supplies(Sorensen DCS33-33E) in AUX_OMC_SOUTH rack to supply power to AUX_OMC_NORTH rack. 18P 18N cables to OMC_NORTH was unplugged and used by the beatbox, so we reconnected them.

  2. Turned on KEPCO high voltage power supply to supply 150 V to the PZT driver, but it was not functioning well. So, we currently use Aligent HP 6209B instead. Its on the OMC_NORTH rack.

  3. PZT driver output to OMC stage 1 was unplugged. So, we plugged them.

  4. Opened PZT driver (LIGO-D060287), put some signal from Piezo_Drive_in(J4 in schematic), and checked beamspot at AS port is moving. The gain from Piezo_Drive_in to the output (hv_out) was ~20.

  5. We could avoid clipping by putting some offset to OMC stage 2 (or 1) in yaw. That means, the clipping comes from after OMC stage 2.

Conclusion:
  If we can control OMC stage 1 and 2, we can avoid clipping. So, we want them to be EPICS channels.

  5918   Wed Nov 16 21:01:08 2011 JenneUpdateTreasureeom box

I made a super sweet new foam box for our EOM.  It's awesome, and should be reasonably easy to duplicate.  Check out the PHOTOS!

Notes:

* I didn't think I was going to cover the inside of the box at first, since the foam is non-fuzz-generating, but Koji suggested it would be a good idea anyway.  The foam was cut perfectly to the EOM, so adding the tape inside makes it a tight fit.  Especially height-wise...leave a little space next time.

* To cover the insides of the optical path holes, do it in 2 parts.  One half-cylinder, and then another.  Way easier than trying to do the whole thing at once.  Also, pre-cut the tabs on both sides of the foil before inserting.  Then you just have to grab the tabs with tweezers and flatten them, and they hold the aluminum tape in place. 

* Having 1" wide, 2" wide and 3" wide aluminum tape was handy.  3" to make the top, 2" for the sides, and 1" for the inside of the holes. 

  5944   Fri Nov 18 11:16:08 2011 ranaUpdateIOOeom box

Quote:

I made a super sweet new foam box for our EOM.  It's awesome, and should be reasonably easy to duplicate.  Check out the PHOTOS!

 These are great photos and a nice box, but I fear from the photos that there's too much air getting in. How to pack it so that there's no air flow? How does the temperature sensors wires get in?

  117   Tue Nov 20 11:10:07 2007 tobinUpdateComputersepics access from matlab
I installed "labca", which allows direct access to EPICS channels from within Matlab. It comes with both Linux and Solaris binaries (and source) but I've only tried it on linux.

To set it up, run these shell commands:
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
Then start matlab, and within matlab type:
addpath /cvs/cds/caltech/users/tf/build/labca_2_1/bin/linux-x86/labca
help labca
foo = lcaGet('C1:PSL-FSS_RCTRANSPD')
It seems like reasonably well-written software, and is being actively maintained right now. If we like it, I can build a more recent version, install it in a more permanent location, etc.
  3867   Fri Nov 5 09:08:14 2010 steveUpdateSUSepoxy

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.

Attachment 1: 11081001.PDF
11081001.PDF
  2677   Tue Mar 16 09:37:30 2010 steveUpdateSUSeq 4.4 seen by oplevs and osems

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

Attachment 1: opleveq4.4.jpg
opleveq4.4.jpg
Attachment 2: eq4.4.jpg
eq4.4.jpg
Attachment 3: opleveq4.4d3.jpg
opleveq4.4d3.jpg
  6661   Tue May 22 20:01:26 2012 DenUpdateCDSerror monitor

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.

  9862   Mon Apr 28 10:24:10 2014 KojiUpdateLSCerror signal characterization

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.

Attachment 1: ALSX_SPE.pdf
ALSX_SPE.pdf
Attachment 2: ALSY_SPE.pdf
ALSY_SPE.pdf
  6211   Wed Jan 18 14:28:36 2012 kiwamuUpdateLSCestimation of optical length between PRM and scattering object

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)

  In order to estimate the optical length between PRM and a scattering body, I swept the frequency of the main laser by actuating on the MC length.
With the sweep, the laser frequency go across some fringes and basically it allows us to estimate the FSR of a very low finesse cavity formed by PRM and the scattering body.
Therefore we get the the optical distance based on the resultant FSR.
 
  The measurement goes as follows:
  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
scattering.png

 

 

(Calibration of the MC2 actuator)

 To do the measurement described above, the MC2 actuator must be calibrated in terms of a frequency actuator.
I did the same old technique (#4721): lock a cavity, adjust the UGF as low as possible, and shake an actuator of interest.
This time I used the half-PRM (PRM + ITMY) for this measurement.
The actuator responses are calibrated from that of displacement to frequency by using df/f = dx/L and assumed that L = 6.760 (#4585).
Also the PRM actuator was measured such that we can use this as a reference since we already know the response in displacement (#5637).
 The attached plot below is the actual responses that I measured yesterday. The y-axis is calibrated to Hz/counts.
 

 

calibration.png

 

Quote from #6202

Is PRM making some fringes with some other optics ??

  6212   Wed Jan 18 16:31:10 2012 kiwamuUpdateLSCestimation of optical length between PRM and scattering object

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.

 

 The attached plot below is the spectra of REFL11 with the 1/10 attenuator at the origin of the REFL path when the beam is single-bounced from PRM.
In the measurement PRM_POS was driven at 10 Hz with an amplitude of 1700 all the time. This is exactly the same situation as that explained in the previous elog entry (#6211).
You can see that the up conversion noise level also decreased by the same factor of 10, which suggests there are no scattering object in the REFL path.
Note that the data with the attenuator in place is intentionally scaled by multiplying a factor of 10 for comparison.
ND1atten.png
 

Quote from #6211

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.

 

  228   Wed Jan 9 10:47:15 2008 frickeUpdateComputersethernet wiring in office/control room
The electrical people have been here for three days, installing ethernet cables and drops in the 40m office area, in the old conduits where there was power and 10base2. Soon we will have reliable ethernet connections, instead of relying on switches hanging from the ceiling, etc!
  13517   Tue Jan 9 00:07:03 2018 johannesUpdateDAQetmx slow daq chassis

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.

  13529   Wed Jan 10 22:24:28 2018 johannesUpdateDAQetmx slow daq chassis

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 yawyes.
  2. Coil enable and monitoring channels work yes
  3. Watchdog seems to work. yes 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 yes. 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 yes.
  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 no. 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. no 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.

  13535   Thu Jan 11 20:59:41 2018 gautamUpdateDAQetmx slow daq chassis

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.

 

  13537   Fri Jan 12 10:02:05 2018 johannesUpdateDAQetmx slow daq chassis
Quote:

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 no. 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)

The switches for the QPD gain stages did not work. no I suspect a wiring problem, since the switching of the coil enables did work.

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.

  13543   Fri Jan 12 19:15:34 2018 johannesUpdateDAQetmx slow daq chassis

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.

  232   Thu Jan 10 10:38:02 2008 steveUpdateSUSetmy damping restored
The IST building onstruction has really started yesterday and continuing today with big heavy ground breaking
machinary. The MC is holding lock and the suspentions are hanging on.

ETMY does not like this.

SUS-MC2_LLPD_VAR monitor is a good indicator of seismic activity on this 12 days plot
Attachment 1: etmysus.jpg
etmysus.jpg
Attachment 2: sustrend16d.jpg
sustrend16d.jpg
  938   Wed Sep 10 08:57:03 2008 steveUpdateGeneraletmy illuminator turned off
The ETMY illuminator was left on yesterday.
I just turned it off.
  504   Thu May 29 16:32:09 2008 steveUpdateSUSetmy oplev is back
I relayed the optics for ETMY-oplev as shown in pictures below.
The reflected beam goes directly to the qpd
Attachment 1: P1020417.png
P1020417.png
Attachment 2: P1020420.png
P1020420.png
  507   Fri May 30 12:37:45 2008 robUpdateSUSetmy oplev is back

Quote:
I relayed the optics for ETMY-oplev as shown in pictures below.
The reflected beam goes directly to the qpd


I turned on the servo. UGFs in PIT and YAW are ~3Hz. I had to flip the sign of the YAW.
  487   Mon May 19 11:49:57 2008 steveUpdateSUSetmy oplev laser replaced
The 9 years old Uniphase HeNe was replaced by a new JDSU 1103P
Power output ~3.5 mW, reflected light back on qpd ~140 microW, 12,800 counts
Andrey will get the ~2.5 mm od spot on the qpd smaller by replacing
the f1000 lens
  1578   Tue May 12 17:26:56 2009 peteUpdateoplevsetmy oplev quad was bad

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.

 

Attachment 1: bad_oplev_quad.pdf
bad_oplev_quad.pdf
  1580   Wed May 13 03:05:13 2009 peteUpdateoplevsetmy oplev quad was bad

Quote:

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.

  122   Mon Nov 26 10:17:31 2007 steveOmnistructureSUSetmy sus damping restored
20 days plot is showing etmy loosing damping 4 times.
I zoomed in with each event. Three of them could of been triggered
by garbage loading just outside. However attachment 2 plot demonstrating that small earthquake or seismic event
did not tripped etmy damping.
The fourth event was preceded by a 4-5 hrs of continous rise of the rms motion at C1:SUS-ETMY_LLPD_VAR
Attachment 1: etmyrms20d.jpg
etmyrms20d.jpg
Attachment 2: etmyrmseq.jpg
etmyrmseq.jpg
  222   Thu Jan 3 09:55:11 2008 steveUpdateSUSetmy sus damping restored
ETMY watch dog was lost at midnight
Attachment 1: etmy12h.jpg
etmy12h.jpg
  254   Wed Jan 23 09:27:55 2008 steveUpdate etmy sus damping restored
Seismis event trips etmy
Attachment 1: etmysus.jpg
etmysus.jpg
  237   Mon Jan 14 14:41:09 2008 steveUpdateSUSetmy sus damping restored & mz relocked
Tree days trend of MZ HV drift is typical these days.
So as the etmy sus inability to hold damping for longer then 2-3 days.
Attachment 1: etmysus&mzhvtrend.jpg
etmysus&mzhvtrend.jpg
  225   Fri Jan 4 08:42:03 2008 steveUpdateSUSetmy trips again
ETMY sus damping tripped at 6am this morning
It was reset. We should put an accelerometer to the south end to see
the garbage dumping effect.
Attachment 1: etmy20m.jpg
etmy20m.jpg
Attachment 2: etmy120s.jpg
etmy120s.jpg
Attachment 3: etmysenV.jpg
etmysenV.jpg
  220   Thu Jan 3 08:53:55 2008 steveUpdateSUSetmy vs etmx
Rana have corrected sus gain damping setting of ETMY 8 days ago

gain settings: pos, pit, yaw & sd
etmx: 4,2,2,& -16
etmy: 4,2,2,& 50
Attachment 1: sus.jpg
sus.jpg
  6226   Thu Jan 26 08:36:38 2012 steveUpdateSAFETYevacuation drill

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.

  3311   Wed Jul 28 14:54:56 2010 steveUpdateSAFETYevacuation drill at the 40m

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. 

Attachment 1: P1060520.JPG
P1060520.JPG
  6348   Fri Mar 2 18:11:50 2012 jamieSummarySUSevaluation of eLIGO tip-tilts from LLO

[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
  609   Tue Jul 1 10:15:22 2008 steveUpdatePSLeventfull two days
The laser recovered from a short temp rise. The MZ was aligned and realigned. The suspentions were kicked up accidentally.
Now the computers are down.
Attachment 1: 2d.jpg
2d.jpg
  6403   Tue Mar 13 07:04:55 2012 kiwamuUpdateLSCevolution of the sensing matrix in PRMI as a function of time

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.

 

PRCL.png

 MICH.png

 

  6406   Tue Mar 13 16:56:19 2012 kiwamuUpdateLSCevolution of the sensing matrix in PRMI as a function of time

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.

Quote from #6403

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.

  6419   Wed Mar 14 21:01:36 2012 keikoUpdateLSCevolution of the sensing matrix in PRMI as a function of time

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

 

 

PRMI configuration, PRCL signal

[W/m] Simulation Measured
REFL11 575440

 

~10000

REFL33 4571 ~50
REFL55 288400 ~5000
REFL165 891 NA
AS55 71 70

 

PRMI configuration, MICH signal

[W/m] Simulation Measured
REFL11 2290

 

~600

REFL33 36 ~4
REFL55 5623 ~200
REFL165 17 NA
AS55 6456 ~200
 

Simulated DC REFL power is 9mW (before the attenuator). AS DC is 0.3mW.

They don't agree. I suspect the PR gain for the SBs are somehow different. It is about 40 (or a bit less) in the simulation for 11MHz.

 

 

 

 

  6405   Tue Mar 13 16:40:06 2012 kiwamuUpdateLSCevolution of the sensing matrix in PRMI as a function of time: details

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.
In the actual measurement I choose the frequency of the excitation signal to be at 283.1 Hz,
at which any of the LSC servos don't have gains of more than 1 and there were no particular structures in the spectra.
For the amplitude of the excitation, I usually choose it to be 1000 - 2000 counts.
Because all the actuators have response functions of approximately 10-9 / f^2 meter/counts  (#5637), the actual displacement in the excited DOF should be about 10 pm level.
Therefore the excited displacements must be always in the linear ranges and also the amplitude in counts is reasonably smaller than the DAC range.
 

LOCKIN detection

The attached cartoon below shows how the LOCKIN system works for the MICH response measurement.
In the case of the PRCL response measurement, the setup is the same except that only PRM is shaken.
Here is some notes about the 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.

 

lockins_MICH.png

 

Calibration of the LOCKINs

  The calibration of the LOCKIN detectors is easy because all the processes takes place in the digital land, where we know all the parameters.
In this phase the goal is to calibrate the signals into counts / meter.
To calibrate the LOCKIN output signals, the following equation is used :
 
 [The obtained LOCKIN output in counts ] = H x ADOF x CLO x CEXC x 1/2  ,
 
 where H is the response of a sensor (e.g. AS55_I, AS55_Q and so on) against a particular DOF in unit of counts / m and this the quantity which we want to measure here,
ADOF is the actuator efficiency of the DOF at the excitation frequency in unit of m/counts,
CLO is the amplitude of the local oscillator signal for demodulating the sensor signals in unit of counts,
CEXC is the amplitude of the excitation signal in unit of counts,
the last 1/2 term comes from the fact there is a low pass filter in each demodulation path. 
Therefore once we measure the response of a sensor, dividing the obtained LOCKIN output by ADOF x CLO x CEXC x 1/2 gives the calibrated response in unit of counts/meter.
  ADOF are well known as they have been measured several times (#5637).
For the MICH actuator I assumed that AMICH = 2 x (ITMY response) since they are balanced through the actuation coefficients.
Note that a confirmation of this calibration has been done
when the configuration is in the simple Michelson, where we can easily estimate the response of a sensor by letting the MICH freely swing.
 

Calibration of the responses to watts/meter

  With the calibration process described above, we obtain the sensor responses in unit of counts/m.
 Then we need to do another calibration to make them into unit of W/m.
If we think about how the RFPD signal flows, we get the following gain chain.
 
[raw response in counts/m ] = Hopt x CADC x Ldemod x GWF x Ztrans x RPD
 
Hopt  is the optical gain at a sensor which we want to calibrate. It is in unit of W/m.
CADC  is the conversion factor of the ADCs and the value is CADC = 1638.4 counts/m because their resolution is 16 bit and the range is +/-20 V.
Ldemod is the conversion efficiency of the demodulation boards in unit of V/V. I used the values which Suresh measured yesterday (#6402).
GWF is the gain of the whitening filter in unit of V/V,
Ztrans is the transimpedance gain of an RFPD in unit of V/A and I used the values summarized in (the wiki),
and RPD is the responsivity of the photo diodes and I assumed RPD = 0.75 A/W for all the RFPDs.
 
Therefore the calibration can be done by dividing the raw response value by the entire gain chain of CADC x Ldemod x GWF x Ztrans x RPD.
 

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

Quote from #6403

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.

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

  9489   Wed Dec 18 15:35:48 2013 SteveUpdatePEMexcess seismic noise

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

Attachment 1: seismicCar.jpg
seismicCar.jpg
  7669   Mon Nov 5 10:34:48 2012 SteveUpdateVACexisting vacuum documents

Quote:

Quote:

Quote:

Quote:

Apparently all of the ION pump valves (VIPEE, VIPEV, VIPSV, VIPSE) opened, which vented the main volume up to 62 mTorr.  All of the annulus valves (VAVSE, VAVSV, VAVBS, VAVEV, VAVEE) also appeared to be open.  One of the roughing pumps was also turned on.  Other stuff we didn't notice?  Bad. 

 Several of the suspensions were kicked pretty hard (600+ mV on some sensors) as a result of this quick vent wind.  All of the suspensions are damped now, so it doesn't look like we suffered any damage to suspensions.

CLOSE CALL on the vacuum system:

Jamie and I disabled V1, VM2 and VM3 gate valves by disconnecting their 120V solenoid actuator before the swap of the VME crate.

The vacuum controller unexpectedly lost control over the swap as Jamie described it. We were lucky not to do any damage! The ion pumps were cold and clean. We have not used them for years so their outgassing possibly  accumulated to reach ~10-50 Torr

I disconnected_ immobilized and labelled the following 6 valves:  the 4 large ion pump gate valves and VC1,  VC2  of the cryo pump. Note: the valves on the cryo pump stayed closed. It is crucial that a warm cry pump is kept closed!

This will not allow the same thing to happen again and protect the IFO from warm cryo contamination.

The down side of this that the computer can not identify vacuum states any longer.

This vacuum system badly needs an upgrade. I will make a list.

 While I was doing the oil change of the roughing pumps I accidentally touched the 24 V adjustment knob on the power supply.

All valve closed to default condition. I realized that the current indicator was red at 0.2A  and the voltage fluctuated from 3-13V

Increased current limiter to 0.4A and set voltage to 24V     I think this was the reason for the caos of valve switching during the VME swap.

 

 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
  7154   Sun Aug 12 01:21:26 2012 steveUpdateSAFETYexit door left unlocked

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 !

 

  7155   Sun Aug 12 10:34:45 2012 KojiUpdateSAFETYexit door left unlocked

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

Quote:

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 ! 

 

  6444   Mon Mar 26 15:15:16 2012 kiwamuUpdateIOOexpected beam profile of PRM reflection

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. 

expected_edit.png

The plot above shows beam radii of the PRM reflections for vertical and horizontal profiles in each case.
The x-axis is distance from PRM in meter and the y-axis is the beam radii in mm.
As for the initial beam parameter, I used the measured values (see the wiki), which are that of after the beam exits from the mode matching telescope and before it goes to PRM.
 
(1) If PRM has the correct curvature, the reflection after it passes MMT1 will have ~ 1.6 mm beam radii.
This is intuitively correct because the beam profiles should match to that of the MC exiting beam  (see the wiki), which has waist size of 1.5 - 1.6 mm if everything is perfect.
(2) When PRM is flipped, the beam starts converging at the beginning as PRM act as a convex mirror, resulting in smaller beam sizes after it comes out from the telescope.
Roughly speaking the waist sizes will be different by ~ 5 mm between those two cases, so our measurement should be more precise and accurate than this number.

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.

 

  4154   Fri Jan 14 11:29:00 2011 kiwamuUpdateLSCexpected open loop TF of X arm locking

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

xarm_oltf.png

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.

 

Quote:

 (some notes)

 unWhitening filter           pole:15Hz. pole:15Hz, zero:150Hz, zero:150Hz

 C1LSC_MC_FM1   pole:1kHz, zero:10Hz

 Gain in digital control       G ~ -1

measured UGF  ~  200-300 Hz

 measured RFM delay ~ 125 usec 

 

  6445   Mon Mar 26 16:25:44 2012 kiwamuUpdateIOOexpected v.s. measured beam profile of PRM reflection

[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. 

PRMreflection.png

This plot is the same as one shown in the previous entry (#6444) with newly added actual data.
The errorbar in each data point is the standard deviation obtained by 100 times of averaging.
In this plot I made the error bars 10 times bigger in order to let them visible in the plot, so the actual deviation is much lesser than they appear.
 

(Discussion)

 The vertical profile (shown in red) seems to be close to the curve for the correct PRM case.
However the horizontal profile has a bigger waist size of about  2 mm.
While measuring the waist size Suresh and I have noticed that the rotational angle of the scan head affects the measurement by 10% or so.
Of course in each data point we tried making the incident beam normal to the scan head by rotating the scan head.
But this 10% is not big enough to explain the discrepancy in the horizontal mode.
There are some possible scenario which can distort the beam shape in the horizontal direction:
  • 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)

DSC_4001_small.jpg
 

(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.

Quote from #6444

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 

 

  6692   Sat May 26 20:40:48 2012 DenUpdatePEMexperiments with seismic noise

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

DSC_4307.JPG         DSC_4308.JPG

Relative motion for difference distances between seismometers is presented below.

    psd_distance.png        ratio.png

 

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

 

L, ft fcrit, Hz
C a
4 45 0.0074 1.30
18 30 0.0057 1.52
38 15 0.0208 1.43

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

sim_delta.png

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 fcrit decreases with length.

  6695   Sun May 27 23:15:22 2012 DenUpdatePEMexperiments with seismometers

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.

DSC_4309.JPG               DSC_4310.JPG                  DSC_4311.JPG

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.

loc_noise.png

  2066   Wed Oct 7 20:32:21 2009 ranaUpdateAdaptive Filteringextra delay and noise in PEM -> ASS/OAF system

[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.

Attachment 1: a.gif
a.gif
  2116   Mon Oct 19 11:31:55 2009 JenneUpdateAdaptive Filteringextra delay and noise in PEM -> ASS/OAF system

Quote:

[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.

Attachment 1: PEM-timing_19Oct2009.png
PEM-timing_19Oct2009.png
  2121   Mon Oct 19 19:37:39 2009 Sanjit, JenneUpdateAdaptive Filteringextra delay and noise in PEM -> ASS/OAF system

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...

 

Attachment 1: PEM_timingDealy_19OCT09_MCL2PEM2.png
PEM_timingDealy_19OCT09_MCL2PEM2.png
  2125   Tue Oct 20 11:38:10 2009 rana, rolfUpdateAdaptive Filteringextra delay and noise in PEM -> ASS/OAF system

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)."

ELOG V3.1.3-