40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 98 of 344  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  2040   Fri Oct 2 02:55:07 2009 robUpdateLockingmore progress

More progress with locking tonight, with initial acquisition and power ramps working.  The final handoff to RF CARM still needs work.

I found the wireless router was unplugged from the network--just plugging in the cable solved the problem.  For some reason that RJ45 connector doesn't actually latch, so the cable is prone to slipping out of the jack.

 

  2041   Fri Oct 2 14:52:55 2009 ranaUpdateComputersc1susvme2 timing problems update

The attached shows the 200 day '10-minute' trend of the CPU meters and also the room temperature.

To my eye there is no correlation between the signals. Its clear that c1susvme2 (SRM LOAD) is going up and no evidence that its temperature.

 

Attachment 1: Untitled.png
Untitled.png
  2042   Fri Oct 2 15:11:44 2009 robUpdateComputersc1susvme2 timing problems update update

It got worse again, starting with locking last night, but it has not recovered.  Attached is a 3-day trend of SRM cpu load showing the good spell.

Attachment 1: srmcpu3.png
srmcpu3.png
  2044   Fri Oct 2 17:00:06 2009 AlbertoUpdateGeneral40m Update - Requirements on the 5x Frequency Multiplier

Here's the gist of the requirements on the 5x frequency multiplier for the upgrade (see attachemnt - despite the preview down here in the elog, they're 3 pages).

An extended version is available on the wiki.

A more complete document is under work and will soon be available on the wiki as well.

Attachment 1: DesignOfTheMultiplier1-14-15.pdf
DesignOfTheMultiplier1-14-15.pdf DesignOfTheMultiplier1-14-15.pdf
  2045   Fri Oct 2 18:04:45 2009 robUpdateCDSDTT no good for OMC channels

I took the output of the OMC DAC and plugged it directly into an OMC ADC channel to see if I could isolate the OMC DAC weirdness I'd been seeing.  It looks like it may have something to do with DTT specifically.

Attachment 1 is a DTT transfer function of a BNC cable and some connectors (plus of course the AI and AA filters in the OMC system).  It looks like this on both linux and solaris.

Attachment 2 is a transfer function using sweepTDS (in mDV), which uses TDS tools as the driver for interfacing with testpoints and DAQ channels. 

Attachment 3 is a triggered time series, taken with DTT, of the same channels as used in the transfer functions, during a transfer function.  I think this shows that the problem lies not with awg or tpman, but with how DTT is computing transfer functions. 

 

I've tried soft reboots of the c1omc, which didn't work.   Since the TDS version appears to work, I suspect the problem may actually be with DTT.

Attachment 1: omc_dac_dtt.png
omc_dac_dtt.png
Attachment 2: omc_dac_sweepTDS.png
omc_dac_sweepTDS.png
Attachment 3: omc_dac_dtt_ts.png
omc_dac_dtt_ts.png
  2047   Sat Oct 3 14:53:24 2009 robUpdateLockingmore progress

Late last night after the ETMY settled down from the quake I made some more progress in locking, with the handoff to RF CARM succeeding once.  The final reduction of the CARM offset to zero didn't work, however.

  2048   Mon Oct 5 02:51:08 2009 robUpdateLockingalmost there

Working well tonight: the handoff of CARM to RF (REFL2I), successful reduction of CARM offset to zero, and transition control of MCL path to the OUT1 from the common mode board.  All that's left in lock acquisition is to try and get the common mode bandwidth up and the boost on.

  2050   Mon Oct 5 10:41:31 2009 KojiUpdatePSLPSL laser accidentally turned off

The PSL output looks smaller than the incident. Try to FSS Slow actuator adj of -5.6 (nominal), instead of -3.5.

Quote:

Alberto, Steve,

While I was moving a cart near by the PSL table I pushed the red emergency button that turns off the PSL laser. We had to unlock the button and then power cycle the laser driver to turn the laser back on.

I relocked MZ, FSS, PMC and I'm now waiting for the power to finish ramping up back to the previous value.

 

  2051   Mon Oct 5 13:43:37 2009 ZachUpdatePSLPSL table photos

I have been commissioned to take pictures of the PSL table so that it can be diagrammed. I am starting now (1:42 pm, 10/5/09).

  2052   Mon Oct 5 14:18:41 2009 ZachUpdatePSLPSL table photos

Quote:

I have been commissioned to take pictures of the PSL table so that it can be diagrammed. I am starting now (1:42 pm, 10/5/09).

All done (for now). That wasn't so bad, was it?

  2053   Mon Oct 5 14:37:29 2009 AlbertoUpdateABSLAbsolute Length Meaasurement NPRO is on

In the revival of the experiement length measurement for the recycling cavities, I turned the auxiliary NPRO back on. The shutter is closed.

I also recollected all the equipment of the experiment after that during the summer it had been scattered around the lab to be used for other purposes (Joe and Zach's cameras and Stephanie and Koji's work with the new EOM).

  2054   Mon Oct 5 18:34:26 2009 JenneUpdateAdaptive FilteringAttempts to take a TF of the OAF system

[Jenne, Sanjit]

As per Matt's instructions in his OAF document (elog 395) in the Tuning section, Sanjit and I took a transfer function measurement from the output of the OAF system, to the input.  i.e. we're trying to measure what happens out in the real world when we push on MC1, and how that is fed back to the input of our filter as MC_L.  The game plan is to measure this transfer function, and read off the phase at the nyquist frequency, and use this value to calculate the appropriate sample-and-hold delay to be used in the OAF.  The downsample rate for the OAF is 32, so that we're running at 64Hz instead of the 2048Hz of the front-end.  Thus, our Nyquist frequency is 32Hz.

                            DownSampleRate

Phase@Nyquist * ------------------------

                                    180

In the attached figure we do a swept sine from CORR_EXC to ERR_EMPH_OUT to determine the transfer function.  Here, we turn off all of the filters in both the CORR and EXC banks, because those are already matched/taken into account in the PEM filter banks. 

Using the cursor on DTT, we find that the phase at 29.85Hz is -228.8deg, and at 37.06Hz is -246.0deg.  Extrapolating, this means that at 32Hz, we expect about -234deg phase.  Using our handy-dandy formula, this means that we should try a delay of 41 or 42 (41.6 is between these two...) 

We'll give this a shot!

Attachment 1: OAF_TF_CORRexc_EMPHout_2.png
OAF_TF_CORRexc_EMPHout_2.png
  2055   Mon Oct 5 19:39:26 2009 KojiUpdatePSLPSL laser accidentally turned off

I set the FSS slow actuator adj to -5.6 at the lunch time. It gave a little help at that time. Now max of the MC Trans is comming back somehow. I hope the MC Trans level is as good as before, if the HEPA is slowed down.

Quote:

The PSL output looks smaller than the incident. Try to FSS Slow actuator adj of -5.6 (nominal), instead of -3.5.

Quote:

Alberto, Steve,

While I was moving a cart near by the PSL table I pushed the red emergency button that turns off the PSL laser. We had to unlock the button and then power cycle the laser driver to turn the laser back on.

I relocked MZ, FSS, PMC and I'm now waiting for the power to finish ramping up back to the previous value.

 

 

  2056   Tue Oct 6 01:41:20 2009 robUpdateLockingDC Readout

Lock acquisition working well tonight.  Was able to engage CM boost (not superboost) with bandwidth of ~10kHz.  Also succeeded once in handing off DARM to DC readout.

  2057   Tue Oct 6 10:09:55 2009 ZachUpdatePSLMore pictures

I'm back to terrorize the PSL table again. The pictures I took yesterday were rubbish--today I'm using a clamp that Steve was nice enough to loan me. I'm starting now, at 10:09 am.

  2058   Tue Oct 6 11:13:53 2009 JenneUpdateAdaptive FilteringAttempts to take a TF of the OAF system

Quote:

[Jenne, Sanjit]

As per Matt's instructions in his OAF document (elog 395) in the Tuning section, Sanjit and I took a transfer function measurement from the output of the OAF system, to the input.  i.e. we're trying to measure what happens out in the real world when we push on MC1, and how that is fed back to the input of our filter as MC_L.  The game plan is to measure this transfer function, and read off the phase at the nyquist frequency, and use this value to calculate the appropriate sample-and-hold delay to be used in the OAF.  The downsample rate for the OAF is 32, so that we're running at 64Hz instead of the 2048Hz of the front-end.  Thus, our Nyquist frequency is 32Hz.

                            DownSampleRate

Phase@Nyquist * ------------------------  =  Delay

                                    180

In the attached figure we do a swept sine from CORR_EXC to ERR_EMPH_OUT to determine the transfer function.  Here, we turn off all of the filters in both the CORR and EXC banks, because those are already matched/taken into account in the PEM filter banks. 

Using the cursor on DTT, we find that the phase at 29.85Hz is -228.8deg, and at 37.06Hz is -246.0deg.  Extrapolating, this means that at 32Hz, we expect about -234deg phase.  Using our handy-dandy formula, this means that we should try a delay of 41 or 42 (41.6 is between these two...) 

We'll give this a shot!

 As Rana pointed out to me last night, I was using continuous phase, which is not good.  When using regular phase, I find: (29.85Hz, 131.216deg), (37.06Hz, 113.963deg), so extrapolating gives (32Hz, 126.07deg).  Plugging this in to our handy-dandy formula, we get a delay of 22.4, so we should try both 22 and 23.

  2061   Wed Oct 7 03:49:49 2009 ranaUpdateAdaptive FilteringAttempts to take a TF of the OAF system

 Here's a plot of the spectra of the seismometers and MCL. The coherence shows which axes are aligned right now: MC1_X is coherent with GUR_NS which means that its mis-oriented.

I've now swapped the "MC1" cables: so the old "NS" now goes into EW and the old EW now goes into NS. VERT is unchanged.

Also fixed the channel names - the Guralp previously named MC1 is now GUR1 and the other one is GUR2. Also no more EW, NS, & VERT. Its all XYZ.

DAQD restarted with the new channel names.

Attachment 1: Untitled.png
Untitled.png
  2063   Wed Oct 7 07:42:55 2009 ranaUpdateAdaptive FilteringAttempts to take a TF of the OAF system

I remeasured the OAF time delay using the OAF-TF template from the Templates/ directory.

Troublingly, I found the MC1 dewhitening switches set OFF - please make sure that the MC1 dewhitening is back ON after each OAF tuning so that the interferometer locking is not hosed.

The OAF-TF template had the excitation amplitude set ~20x too high. I reduced it and the coherence was still > 0.95. The phase at 32 Hz was still ~126 deg as Jenne had measured, but since the phase at DC is 180 deg, the overall phase lag is just 180-126 = 54 deg. So the delay should be 54/180 * 32 = 9.7 => 10. Luckily, Jenne is working on an instructional manual for OAF that will make all of this crystal clear.

  2065   Wed Oct 7 19:23:49 2009 JenneUpdateAdaptive Filtering(Final?) PEM cabling changes

Quote:

 Here's a plot of the spectra of the seismometers and MCL. The coherence shows which axes are aligned right now: MC1_X is coherent with GUR_NS which means that its mis-oriented.

I've now swapped the "MC1" cables: so the old "NS" now goes into EW and the old EW now goes into NS. VERT is unchanged.

Also fixed the channel names - the Guralp previously named MC1 is now GUR1 and the other one is GUR2. Also no more EW, NS, & VERT. Its all XYZ.

DAQD restarted with the new channel names.

 I spiffed up the order of the cables / sensors plugged into the PEM ADCU.  Now all of the seismometers are labeled as Rana left them, and the 2 Guralp's have their sets of 3 channels next to eachother in channel-number-land.  None of the accelerometer names/cabling have changed recently.  In the table, Cable-label refers to the physical tag tied to the end of the cables plugged into the ADCU...they are meant to be descriptive of what seismometer channels they are hooked up to, and then the names change to something useful for us when they come into the DAQ system.  Also, the labels of input channels on the ASS_TOP_PEM screen have been updated accordingly.

 

Channel Name Channel Number on ADCU and OAF PEM list Cable-label .ini channel number
C1:SEIS-GUR2_X 2 Gur2 EW 15001
C1:SEIS-GUR2_Y 3 Gur2 NS 15002
C1:SEIS-GUR2_Z 4 Gur2 Vert 15003
C1:SEIS-GUR1_X 10 Gur1 EW 15009
C1:SEIS-GUR1_Y 11 Gur1 NS 15010
C1:SEIS-GUR1_Z 12 Gur1 Vert 15011
C1:SEIS-RANGER_Y 24 Ranger

15023

 

  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
  2067   Thu Oct 8 11:10:50 2009 josephb, jenneUpdateComputersEPICs Computer troubles

At around 9:45 the RFM/FB network alarm went off, and I found c1asc, c1lsc, and c1iovme not responding. 

I went out to hard restart them, and also c1susvme1 and c1susvme2 after Jenne suggested that.

c1lsc seemed to have a promising come back initially, but not really.  I was able to ssh in and run the start command.  The green light under c1asc on the RFMNETWORK status page lit, but the reset and CPU usage information is still white, as if its not connected.   If I try to load an LSC channel, say like PD5_DC monitor, as a testpoint in DTT it works fine, but the 16 Hz monitor version for EPICs is dead.  The fact that we were able to ssh into it means the network is working at least somewhat.

I had to reboot c1asc multiple times (3 times total), waiting a full minute on the last power cycle, before being able to telnet in.  Once I was able to get in, I restarted the startup.cmd, which did set the DAQ-STATUS to green for c1asc, but its having the same lack of communication as c1lsc with EPICs.

c1iovme was rebooted, was able to telnet in, and started the startup.cmd.  The status light went green, but still no epics updates.

The crate containing c1susvme1 and c1susvme2 was power cycled.  We were able to ssh into c1susvme1 and restart it, and it came back fully.  Status light, cpu load and channels working.  However I c1susvme2 was still having problems, so I power cycled the crate again.  This time c1susvme2 came back, status light lit green, and its channels started updating.

At this point, lacking any better ideas, I'm going to do a full reboot, cycling c1dcuepics and proceeding through the restart procedures.

  2068   Thu Oct 8 11:37:59 2009 josephbUpdateComputersReboot of dcuepics helped, c1susvme1 having problems

Power cycling c1dcuepics seems to have fixed the EPICs channel problems, and c1lsc, c1asc, and c1iovme are talking again.

I burt restored c1iscepics and c1Iosepics from the snapshot at 6 am this morning.

However, c1susvme1 never came back after the last power cycle of its crate that it shared with c1susvme2.  I connected a monitor and keyboard per the reboot instructions.  I hit ctrl-x, and it proceeded to boot, however, it displays that there's a media error, PXE-E61, suggests testing the cable, and only offers an option to reboot.  From a cursory inspection of the front, the cables seem to look okay.  Also, this machine had eventually come back after the first power cycle and I'm pretty sure no cables were moved in between.

 

  2069   Thu Oct 8 14:41:46 2009 jenneUpdateComputersc1susvme1 is back online

Quote:

Power cycling c1dcuepics seems to have fixed the EPICs channel problems, and c1lsc, c1asc, and c1iovme are talking again.

I burt restored c1iscepics and c1Iosepics from the snapshot at 6 am this morning.

However, c1susvme1 never came back after the last power cycle of its crate that it shared with c1susvme2.  I connected a monitor and keyboard per the reboot instructions.  I hit ctrl-x, and it proceeded to boot, however, it displays that there's a media error, PXE-E61, suggests testing the cable, and only offers an option to reboot.  From a cursory inspection of the front, the cables seem to look okay.  Also, this machine had eventually come back after the first power cycle and I'm pretty sure no cables were moved in between.

 

 I had a go at trying to bring c1susvme1 back online.  The first few times I hit the physical reset button, I saw the same error that Joe mentioned, about needing to check some cables.  I tried one round of rebooting c1sosvme, c1susvme2 and c1susvme1, with no success.  After a few iterations of jiggle cables/reset button/ctrl-x on c1susvme1, it came back.  I ran the startup.cmd script, and re-enabled the suspensions, and Mode Cleaner is now locked.  So, all systems are back online, and I'm crossing my fingers and toes that they stay that way, at least for a little while.

  2074   Fri Oct 9 03:53:56 2009 JenneUpdateAdaptive FilteringRemaking the ASS

The c1ass computer, which is now used for the OAF system, has many remnants from the days when it was actually used as an ASS.  These PIT and YAW filter banks and other things were taking up a lot of unnecessary space, so I deleted them in the ass.mdl file.  These files are all backed up, so we can always revert back to an older version when we want some Alignment Stabilization again someday.  I then did a make ass, following the instructions on the 40m Wiki -> Computers and Scripts -> Simulink to Front-End Code page.  Rana moved some things around, most notably all of the things (like the ASS screens) which were only in ...../users/alex/.... are now in ....../caltech/cds/advLigo/..... .  This required a few restarts of the c1ass machine (after a couple different versions of the simulink diagram....one to make sure we knew how to do it, and then again actually deleting the unused portions).

The big lesson of the night was that there are 2 signal paths for the PEM channels.  As is shown in Figure 3 in the mevans document, the PEM channels get the matching filters when they go to the adaptation algorithm, but when they go to the FIR filter, they do not get the matching filters. This is implemented by taking the output of the giant PEM matrix, and having a duplicate of each of the channels "selected for adaptation", one which gets filtered through the PEM_N_ADPT banks, and one which goes straight (in code-land) to the FIR filter.  So, it seems like all the filters which we had been including in the input side of the matrix for matching purposes need to be put in the output side.  One of the AA32 filters needs to stay in the input side, for actual anti imaging of the PEM channels, then we put the AA32 and AI32 which are for matching the ERR_EMPH and CORR filter banks up in the PEM_N_ADAPT banks.  Rana and I made these filters, and they are now turned on appropriately with the OAF down script (so that all the filters are ready and waiting for the OAF to be turned on).

A little success with getting the 3Hz peak reduced, but not a lot beyond that.  Tomorrow I'll put the accelerometers back where they used to be to see if they help out at all.

  2076   Fri Oct 9 16:36:13 2009 rob UpdateIOOfrequency noise problem

I used the XARM as a reference to measure the frequency noise after the MC.  It's huge around 4kHz--hundreds of times larger than the frequency noise the MC servo is actually squashing.  This presents a real problem for our noise performance.

An elog search reveals that this noise has been present (although not calibrated till now) for years.  We're not sure what's causing it, but suspicion falls on the piezojena input PZTs. 

I didn't bother too much about it before because we previously had enough common mode servo oomph to squash it below other DARM noises, and I didn't worry too much about stuff at 4kHz..  Now that we have a weaker FSS and thus much weaker CM servo, we can't squash it, and the most interesting feature of our IFO is at 4kHz. 

I'll measure the actual voltage noise going to the PZTs.  I remember doing this before and concluding it was ok, but can't find an elog entry.  So this time maybe I'll  do it right.

Attachment 1: freqnoiseaftermc.png
freqnoiseaftermc.png
  2077   Fri Oct 9 17:37:21 2009 JenneUpdateIOOMC2 trans beam is dumped

Last night while noise hunting, Rana found that the MC2 trans beam has been left for an unknown length of time just hitting the side of the black enclosure box.  Today I put a brand-spankin'-new razor dump on the MC2 table, to dump the beam.

  2078   Fri Oct 9 17:41:04 2009 JenneUpdatePEMAccelerometers relocated

[Sanjit, Jenne]

The set of 6 accelerometers which were semi-randomly placed underneath the MC2 tank are now back into 2 separate sets of 3 - one set at MC2 and one set at MC1.  The channel names once again reflect reality, i.e. MC1_Y is actually under the MC1 tank, and aligned with the y direction.  Also, the Guralp under MC1 was moved a little bit to the left, because Sanjit wanted to put the accelerometers where the seismometer had been. 

  2079   Sun Oct 11 04:12:44 2009 ranaUpdatePEMAccelerometers relocated

Some of these channels are not like the others.

Attachment 1: Untitled.png
Untitled.png
  2080   Mon Oct 12 14:51:41 2009 robUpdateComputersc1susvme2 timing problems update update update

Quote:

It got worse again, starting with locking last night, but it has not recovered.  Attached is a 3-day trend of SRM cpu load showing the good spell.

 Last week, Alex recompiled the c1susvme2 code without the decimation filters for the OUT16 channels, so these channels are now as aliased as the rest of them.  This appears to have helped with the timing issues: although it's not completely cured it is much better.  Attached is a five day trend.

Attachment 1: srmcpu.png
srmcpu.png
  2081   Mon Oct 12 17:14:39 2009 robUpdateLockingstability

Last night, 2+ hour lock, probably broken by me driving too hard (DARM_EXC).

Attachment 1: transpow.png
transpow.png
  2083   Mon Oct 12 18:37:55 2009 ZachUpdatePSLInventory

--Apologies for the late post--

I was at the PSL table taking an inventory of the components for a while after Koji, Steve, and Kiwamu were there. I set the HEPAs back to 20% when I left (assuming that they were turned up when the compartment was opened).

  2089   Tue Oct 13 10:31:11 2009 ZachUpdatePSLone more time

I am at the PSL table taking what is hopefully the last set of pictures for the diagram. Woohoo.

  2090   Tue Oct 13 10:50:58 2009 ZachUpdatePSLone more time

Quote:

I am at the PSL table taking what is hopefully the last set of pictures for the diagram. Woohoo.

 I'm out, HEPAs are back at 20%.

  2092   Wed Oct 14 16:59:37 2009 robUpdateLockingdaytime locking

The IFO can now be locked during the daytime.  Well, it's locked now.

  2093   Wed Oct 14 23:02:41 2009 ranaUpdateLockingdaytime locking

This is huge.    Five hours of lock only interrupted by intentional break from transfer function abuse.

Attachment 1: a.png
a.png
  2095   Thu Oct 15 02:38:10 2009 rana, robUpdateOMCDark Port Mode Scan using the OMC

Bottom trace is proportional to the OMC PZT voltage - top trace is the transmitted light through the OMC. Interferometer is locked (DARM- RF) with arm powers = 80 / 100. The peaks marked by the cursors are the +(- ?) 166 MHz sidebands.

Attachment 1: OMC-ModeScan_091015.png
OMC-ModeScan_091015.png
  2096   Thu Oct 15 02:41:04 2009 ranaUpdateCOCChoice of folding mirrors in the RC cavities

In addition to the main mirrors (PRM, SRM) we will also have fold mirrors (called PR1, PR2, SR1, SR2). I am curious to see if we can get away with just using commercial optics; I think that the CVI Y1S coatings may do the trick.

Picture_9.png

The above plots show the reflectivities v. wavelength. I've asked the sales rep to give us specs on the reflectivity v. angle. I bet that we can guess what the answer will be from these plots.

  2098   Thu Oct 15 12:35:09 2009 ZachUpdatePSLinventory

I'm at the PSL table taking inventory of the elements I don't have down yet.

  2099   Thu Oct 15 12:57:23 2009 ZachUpdatePSLinventory

Quote:

I'm at the PSL table taking inventory of the elements I don't have down yet.

 OK, I'm out--hopefully for good. HEPAs back at 20%.

  2102   Fri Oct 16 10:15:02 2009 steveUpdateIOOIP ang & pos recentered

Pointing stability of 4 days. Initial pointing does not go through suspended optics. It is launched  right after the Piezo Jena steering mirrors in the BS chamber.

IP-ANG on epics screen is  C1:ASC-IBQPD_X and Y in dataviewer  were recentered. This beam is clipping a bit in ETMX chamber  pick off mirror.

IP-POS pick  off is in the BS chamber and it's qpd on the BS_ISCT This beam is also clipping just a little bit. This is easy to fix. We'll have to remove an iris from the BS optical levers table.

note: arms were not locked when I recentered

Attachment 1: ip4d.jpg
ip4d.jpg
  2106   Fri Oct 16 16:44:39 2009 Alberto, SanjitUpdateComputerselog restarted

This afternoon the elog crashed. We just restarted it.

  2111   Sun Oct 18 22:05:40 2009 kiwamuUpdateLSCLSC timing issue

Today I made a measurement to research the LSC timitng issue as mentioned on Oct.16th.

*method

I put the triangular-wave into the OMC side (OMC-LSC_DRIVER_EXT) by AWG,

then looked at the transferred same signal at the LSC side (LSC_DARM_IN1) by using tdsdata.

I have compared these two signals in time domain to check whether they are the same or not.

In the ideal case it is expected that they are exactly the same.

 

*preliminary result

The measured data are shown in attached fig.1 and 2.

In the fig.1 it looks like they are the same signal.

However in fig.2 which is just magnified plot of fig.1, it shows a time-delay apparently between them.

The delay time is roughly ~50 micro sec.

The surprising is that the LSC signal is going beyond the OMC signal, although the OMC signal drives the LSC !!

We can say it is "negative delay"...

Anyway we can guess that the time stamp or something is wrong.

 

*next plan

Tomorrow I'm going to measure the transfer-function between them to see the delay more clearly.

( And I would like to fix the delay. )

Attachment 1: rough.png
rough.png
Attachment 2: detail.png
detail.png
  2113   Sun Oct 18 23:02:03 2009 KojiUpdateLSCLSC timing issue

You yourself told me that tdsdata uses some downconversion from 32k to 16k!

So, how does the downconversion appears in the measurement?
How does the difference of the sampling rate appears in the measurement?
If you like to understand the delay, you have to dig into the downconversion
issue until you get the EXACT mechanism including the filter coefficients.

AND, is the transfer function the matter now?

As far as the LSC and OMC have some firm relationship, whichever this is phase delay or advance or any kind of filering,
this will not introduce any noise. If so, this is just OK.

In my understanding, the additional noise caused by the clock jitter is the essential problem.
So, did you observe any noise from the data?

Quote:

*preliminary result

The measured data are shown in attached fig.1 and 2.

In the fig.1 it looks like they are the same signal.

However in fig.2 which is just magnified plot of fig.1, it shows a time-delay apparently between them.

The delay time is roughly ~50 micro sec.

The surprising is that the LSC signal is going beyond the OMC signal, although the OMC signal drives the LSC !!

We can say it is "negative delay"...

Anyway we can guess that the time stamp or something is wrong.

 

*next plan

Tomorrow I'm going to measure the transfer-function between them to see the delay more clearly.

( And I would like to fix the delay. )

 

  2114   Mon Oct 19 10:00:52 2009 kiwamuUpdateLSCRE: LSC timing issue

Of course I know there is a downconversion in OMC signal from 32k to 16k.

But I was just wondering if the delay comes from only downconversion.

And I can not find any significant noise in both signals because I use the triangular, which cause the higer harmonics and can hide the timing noise in frequency domain.

So I'm going to make the same measurement by using sinusoidal instead of triangular, then can see the noise in frequency domain.

 

Quote:

You yourself told me that tdsdata uses some downconversion from 32k to 16k!

So, how does the downconversion appears in the measurement?
How does the difference of the sampling rate appears in the measurement?
If you like to understand the delay, you have to dig into the downconversion
issue until you get the EXACT mechanism including the filter coefficients.

AND, is the transfer function the matter now?

As far as the LSC and OMC have some firm relationship, whichever this is phase delay or advance or any kind of filering,
this will not introduce any noise. If so, this is just OK.

In my understanding, the additional noise caused by the clock jitter is the essential problem.
So, did you observe any noise from the data?

Quote:

*preliminary result

The measured data are shown in attached fig.1 and 2.

In the fig.1 it looks like they are the same signal.

However in fig.2 which is just magnified plot of fig.1, it shows a time-delay apparently between them.

The delay time is roughly ~50 micro sec.

The surprising is that the LSC signal is going beyond the OMC signal, although the OMC signal drives the LSC !!

We can say it is "negative delay"...

Anyway we can guess that the time stamp or something is wrong.

 

*next plan

Tomorrow I'm going to measure the transfer-function between them to see the delay more clearly.

( And I would like to fix the delay. )

 

 

  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
  2117   Mon Oct 19 13:00:53 2009 MottUpdateGeneralPhase Noise Measurement

Here is the result for the measurement of the phase noise.  We used the marconi function generator and compared it with an Isomet AOM driver (model 232A-1), so this is really a measure of the relative phase between them.  We used a 5x gain and a frequency response of 13 Hz/V for the modulation.  In all the attached plots, the blue is the data and the red is the measurement limit (as determined by the noise in the SRS785).  Also note that the units on the yaxis of the Phase noise plot are incorrect, they should be dB/Sqrt(Hz), I will fix this and edit as soon as possible.

Attachment 1: PhaseNoiseWithError.jpg
PhaseNoiseWithError.jpg
Attachment 2: G.jpg
G.jpg
Attachment 3: PSD.jpg
PSD.jpg
  2119   Mon Oct 19 17:12:54 2009 jenneUpdatePEMaccelerometers and seismomters are all good.

Quote:

Some of these channels are not like the others.

 All of the PEM channels seem to be okay right now.  The accelerometers didn't turn out to have any differences in the traces when we put both XYZ triplets right next to each other, so we put them back where they belong.  Gur2 seismometer was showing a few problems, especially with Gur2_X, as Rana posted in elog 2079.  This was solved by tightening the cable screws which hold the Dsub end of the Guralp cable to the front panel of the Guralp box.  All is now well.

Attachment 1: SeismometersGoodSpectra_19Oct2009.png
SeismometersGoodSpectra_19Oct2009.png
  2120   Mon Oct 19 18:14:28 2009 robUpdateCamerasvideo switch broken

The Chameleon HB (by Knox) video switch that we use for routing video signals into the control room monitors is broken.  Well, either it's broken, or something is wrong with the mv162 EPICS IOC which communicates with it via RS-232.  Multiple reboots/resets of both machines has not yet worked.  The CHHB has two RS-232 inputs--I switched to the second one, and there is now one signal coming through to a monitor but no switching yet. I've been unable to further debug it because we don't have anything in the lab (other than the omega iserver formerly used for the RGA logger) which can communicate with RS-232 ports.  I've been trying to get this thing (the iserver) working again, but can't communicate with it yet.  For now I'm just going to bypass the video switch entirely and use up all the BNC barrel connectors in the lab, so we can at least have the useful video displays back.

  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
  2122   Mon Oct 19 23:14:32 2009 kiwamuUpdateLSCLSC timing issue

I measured the noise spectrum of LSC_DARM_IN1 and OMC-LSC_DRIVE_EXC by using DTT,

while injecting the sin-wave into the OMC-LSC_DRIVE by AWG.

The attached are the results.

No significant differences appears between OMC and LSC in this measurement.

It means, in this measurement we can not figure out any timing noise which might be in LSC-clock.

In addition there are the noise floor, whose level does not change in each 3-figures. The level is about ~4*10^{-8} count/sqrt[Hz]

(The source of the noise floor is still under research.)

Attachment 1: SPE20Hz.png
SPE20Hz.png
Attachment 2: SPE200Hz.png
SPE200Hz.png
Attachment 3: SPE2kHz.png
SPE2kHz.png
ELOG V3.1.3-