40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 288 of 330  Not logged in ELOG logo
ID Date Author Type Category Subject
  2151   Tue Oct 27 18:01:49 2009 robUpdatePSLhmmm

A 30-day trend of the PCDRIVE from the FSS.

Attachment 1: pcdrive_trend.png
pcdrive_trend.png
  2150   Tue Oct 27 17:58:25 2009 JenneConfigurationPEMUnknown PEM channels in the PEM-ADCU?

Does anyone know what the channels plugged in to the PEM ADCU, channels 5,6,7,8 are?  They aren't listed in the C1ADCU_PEM.ini file which tells the channel list/dataviewer/everything about all the rest of the signals which are plugged into that ADCU, so I'm not sure if they are used at all, or if they're holdovers from some previous time.  The cables are not labeled in a way that makes clear what they are.  Thanks!

  2149   Tue Oct 27 15:55:04 2009 KojiUpdateGeneralISS injection work / HEPA is on

I was working on the ISS excitation to take TFs.

I used ISS IL excitation, stealing from a small box on the floor for the OMC.

All the configuration was restored except that the HEPA is on.

  2148   Tue Oct 27 01:45:02 2009 robUpdateLockingMZ

Quote:
Tonight we also encountered a large peak in the frequency noise around 485 Hz. Changing the MZ lock point (the spot in the PZT range) solved this.


This again tonight.

It hindered the initial acquisition, and made the DD signal handoff fail repeatedly.
  2147   Mon Oct 26 23:14:08 2009 KojiUpdatePSLlaser power is down

I adjusted the steerings to the PMC and gained 7%. Now the MC_TRANS 7.0 has been recovered.

Actually I need another 7% to get MC_TRANS 7.5.
But I couldn't find how I can recover 126MOPA-AMPMON to 2.8ish.

Quote:

The laser power is down 5-6%

 

Attachment 1: PSL091026.png
PSL091026.png
  2146   Mon Oct 26 19:12:50 2009 kiwamuUpdateLSCdiagnostic script for LSC timing

The diagnostic script I've written is available in the 'caltech/users/kiwamu/work/20091026_OMC-LSC-diag/src'.

To run the script, you can just execute 'run_OMC_LSC.sh' or just call the m-file ' OMC_LSC_timinig.m'  from matlab.

 

NOTES:

The script destructs the lock of DARM and OMC, be careful if you are working with IFO.

  2145   Mon Oct 26 18:49:18 2009 kiwamuUpdateLSCOMC-LSC timing issue

According to my measurements I conclude that LSC-signal is retarded from OMC-signal with the constant retarded time of 92usec.
It means there are no timing jitter between them. Only a constant time-delay exists.

(Timing jitter)
Let's begin with basics.
If you measure the same signal at OMC-side and LSC-side, they can have some time delay between them. It can be described as followers.

exp1.png
where tau_0 is the time delay. If the tau_0 is not constant, it causes a noise of the timing jitter.

(method)
I have injected the sine-wave with 200.03Hz into the OMC-LSC_DRIVE_EXC. Then by using get_data, I measured the signal at 'OMC-LSC_DRIVE_OUT' and 'LSC-DARM_ERR' where the exciting signal comes out.
In the ideal case the two signals are completely identical.
In order to find the delay, I calculated the difference in these signals based on the method described by Waldman. The method uses the following expression.
exp2.png
Here the tau_s is the artificial delay, which can be adjusted in the off line data.
By shifting tau_s we can easily find the minimal point of the RMS, and at this point we can get tau_0=tau_s.
This is the principle of the method to measure the delay.  In my measurement I put T=1sec. and make the calculation every 1sec. in 1 min.


(results)
Attachment is the obtained results. The above shows the minimum RMS sampled every 1sec. and the below shows the delay in terms of number of shifts.
1 shift corresponds to Ts (=1/32kHz).  All of the data are matched with 3 times shift, and all of the minimum RMS are completely zero.
Therefore I can conclude that LSC-signal is retarded from OMC-signal with constant retarded times of 3*Ts exactly, and no timing jitter has been found.
 

Attachment 3: OMC_LSC60sec.png
OMC_LSC60sec.png
  2144   Mon Oct 26 18:15:57 2009 robUpdateIOOMC OLG

I measured the mode cleaner open loop gain.  It's around 60kHz with 29 degs of phase margin.

  2143   Mon Oct 26 17:45:34 2009 JenneUpdateAdaptive FilteringNew changes to the OAF fe code

[Alex, Jenne, Sanjit]

Alex came to the 40m today, and did several awesome things in OAF-land.

We discovered that there is, in fact, an ADC board connected to the ASS machine.  The tricky bit is that it only has a ribbon cable connector, so before we can use this ADC, we need to figure out how to make a breakout board/cable/something to connect the seismometer/accelerometer/microphone BNCs to this little board.  This is the same little board that connects the timing slave to the ASS machine.  For good or for ill, the timing slave is connected to this board via clip-doodles.  Potentially we can connect an ADC tester board to this board, and go from seismometer BNCs to clipdoodles to the tester board, but I'm not in love with the idea of utilizing clipdoodles as a semi-permanent solution until the upgrade.  I emailed Ben to see if he has a better idea, or (better yet) some spare hardware now that's the same as we'll use after the upgrade.  If we can use this ADC, it may solve our timing problem which is caused by the 110B ADC used by the PEM computer. Alex showed Sanjit and I how to connect the ASS's ADC card to the simulink diagram, when we're ready for that.

We also poked around in the code, and it seems that we can now save and restore OAF coefficients at will.  I added buttons to the OAF (ASS) screen, and Alex made it so the OAF coefficients are saved in RFM shared memory whenever you click the "save coeffs" button, and are restored when you click the "restore coeffs" button.  The buttons are the same as the 'Reset' button which has been there for a long time, so they seem to maybe have a similar problem in that you have to hold the button for a while in order for the code to realize that the button has been depressed.  We couldn't fix this easily, because it looks like our SimuLink cds stuff is a little out of date.  Some day (before/when Joe and Peter make new screens for the new 40m), we need to update these things.  Alex was concerned that it might take a while to do this, if the update broke some of the blocks that we're currently using.  Also, Sanjit and I now need to check that the coefficient-saving is going as planned.  When I have DTT open, and the OAF running, I see a certain shape to the signal which is sent to MC1 to correct for the seismic motion.  This shape includes at least several peaks at resonant frequencies that exist in our stacks/suspensions.  I can then save the coefficients, reset the active filter, and then restore the coefficients.  When I do this while watching DTT, it seems as though the general shape of the filter is restored, but none of the detailed features are.  The reason for this is still under investigation. 

The code-modifications involved a few iterations of 'remaking the ass'.

  2142   Mon Oct 26 15:40:01 2009 steveUpdatePSLlaser power is down

The laser power is down 5-6%

Attachment 1: laserpowerdown.jpg
laserpowerdown.jpg
  2141   Mon Oct 26 03:57:06 2009 robUpdateLockingbad

Lock acquisition has gone bad tonight. 

The initial stage works fine, up through handing off control of CARM to MCL.  However, when increasing the AO path (analog gain), there are large DC shifts in the C1:IOO-MC_F signal.  Eventually this causes the pockels cell in the FSS loop to saturate, and lock is lost. 

  2140   Sun Oct 25 14:29:45 2009 haixing, kiwamuConfigurationGeneralSR785 spectrum analyzer

In this morning, we have disconnected SR785 which was in front of 1X2 rack, to measure a Hall sensor noise.

After a while, we put back SR785 and re-connected as it has been.

But the display setup might have been changed a little bit.

 

  2139   Sat Oct 24 04:57:33 2009 ranaUpdateloremarconi phase

Quote:

So, it appears that one doesn't even have to change the Marconi set frequency to alter the phase of the output signal.  It appears that other front panel actions (turning external modulations on/off, changing the modulation type) can do it as well.  At least that's what I conclude from earlier this morning, when after setting up the f2 Marconi (166MHz) for external AM, the double-demod handoff in the DRMI no longer worked.  Luckily this isn't a real problem now that we have the setDDphases and senseDRM scripts. 

 The real problem is that we are using frequency synthesizers to make the beat signals (133 and 199) instead of mixers. Luckily, the future 40m will not use beat signals (?) or synthesizers.

  2138   Fri Oct 23 15:02:00 2009 robUpdateloremarconi phase

So, it appears that one doesn't even have to change the Marconi set frequency to alter the phase of the output signal.  It appears that other front panel actions (turning external modulations on/off, changing the modulation type) can do it as well.  At least that's what I conclude from earlier this morning, when after setting up the f2 Marconi (166MHz) for external AM, the double-demod handoff in the DRMI no longer worked.  Luckily this isn't a real problem now that we have the setDDphases and senseDRM scripts. 

  2137   Fri Oct 23 09:13:45 2009 steveSummaryVACRGA scan

Pump down #66 is 435 days old. RGA scan is normal. New maglev is fine. New UPS is in place but not hooked up to communicate.

V1 has bare minimum interlock. Pirani vacuum gauges  PTP1 and PRP do not communicate with readout system.

There is no emergency dial out in case of vacuum loss.  Our existing vacuum dedicated desk top computer is dead.

New cold cathodes, Pirani gauges and gauge controller should be added.

In general: vacuum system needs an upgrade !

 

Attachment 1: pd66md435.jpg
pd66md435.jpg
Attachment 2: pd66d435ptt.jpg
pd66d435ptt.jpg
  2136   Thu Oct 22 23:14:54 2009 ZachUpdateWIKI-40M UpdatePSL Table Diagram wiki entry

Quote:

Diagram. I don't want to say PNG is an editable format for this purpose...
You have the PPT, PDF or any drawing format to create this diagram.

Quote:

http://lhocds.ligo-wa.caltech.edu:8000/40m/PSL_Table_Diagram

Thanks. I love this. Could you also put the original file that is editable for future modification by anyone?

 Do you mean the diagram or the inventory? The diagrams are online as attachments (small versions on the main "PSL Table Diagram" page and large versions on the linked pages). The inventory is easily editable on the wiki itself. It's just rendered in table form using the CSV parse utility for "comma-separeted values" (though you actually need to use semicolons, for reasons unknown).

 

 

Good news and bad news. For the MOPA diagram, which I did recently, I have GIMP file with separate layers for the background image, ray traces, and labels. Unfortunately, I didn't realize that this was the best way to do it until I had done most of the ray tracing for the main diagram, so, although I have that file in GIMP as well, only the labels are on a separate layer. If this is a major issue I can do the tracing again. The other thing is that the original files are quite large: 17.3 MB for the MOPA, and 64.1(!) MB for the main diagram. Let me know what you think.

  2135   Thu Oct 22 21:58:26 2009 KojiUpdateWIKI-40M UpdatePSL Table Diagram wiki entry

Diagram. I don't want to say PNG is an editable format for this purpose...
You have the PPT, PDF or any drawing format to create this diagram.

Quote:

http://lhocds.ligo-wa.caltech.edu:8000/40m/PSL_Table_Diagram

Thanks. I love this. Could you also put the original file that is editable for future modification by anyone?

 Do you mean the diagram or the inventory? The diagrams are online as attachments (small versions on the main "PSL Table Diagram" page and large versions on the linked pages). The inventory is easily editable on the wiki itself. It's just rendered in table form using the CSV parse utility for "comma-separeted values" (though you actually need to use semicolons, for reasons unknown).

 

  2134   Thu Oct 22 15:49:29 2009 ZachUpdateWIKI-40M UpdatePSL Table Diagram wiki entry

Quote:

http://lhocds.ligo-wa.caltech.edu:8000/40m/PSL_Table_Diagram

Thanks. I love this. Could you also put the original file that is editable for future modification by anyone?

Quote:

 I made a wiki entry for the PSL table diagram under the PSL directory on the 40mHomePage. I tried to use the ImageLink macro to use a resized (smaller) version of the diagram as a link to the full image, which it is designed to do if there is no target given, but it didn't seem to work. Instead, I had to create a second page that had the full-sized diagram, and I used ImageLink with a smaller version to link to that page.

The inventory that is shown is clearly incomplete. Part of this is due to the fact that many labels were either missing or impossible to read without touching stuff. For those components with labels missing, I tried to infer what they were to the best of my knowledge, but I wasn't able to for all of them. In true wiki spirit, everyone is encouraged to fill in any additional information they might have on these components. 

 

 Do you mean the diagram or the inventory? The diagrams are online as attachments (small versions on the main "PSL Table Diagram" page and large versions on the linked pages). The inventory is easily editable on the wiki itself. It's just rendered in table form using the CSV parse utility for "comma-separeted values" (though you actually need to use semicolons, for reasons unknown).

  2133   Thu Oct 22 15:44:16 2009 ZachUpdateWIKI-40M UpdateMOPA diagram

 I have updated the PSL Diagram wiki page to include MOPA. As with the PSL diagram, clicking the photo on the main page takes you to a larger image. The inventory is pretty meager as I didn't have time to sit and read labels (if indeed there are any). I will look through the documentation at the 40m to see if there is a record of what is there. Again, if you know something, please amend the list!!

http://lhocds.ligo-wa.caltech.edu:8000/40m/PSL_Table_Diagram

  2132   Thu Oct 22 08:45:58 2009 steveUpdateIOOIP ang & pos recentered

Quote:

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

 IP-ANG clipping can be traced back to our last vent of Aug. 18, 2008  See elog entry #845

This was an after earth quake - sus repair vent

Attachment 1: pointing1000.jpg
pointing1000.jpg
  2131   Wed Oct 21 17:12:30 2009 AlbertoUpdateelogBrowser context menu enabled on the Elog under HTM editing mode

On behalf of Steve and of the rest of the not-native-English community at the 40m willing to have their browser's spell checker working while editing the Elog, I fixed the Elog's feature that prevented Firefox' context menu (that one which pops up with a mouse right click) to work when using the HTML editing interface (FCKeditor).

That let also Firefox spell checker to get enabled.

To get the browser context menu just press CTRL right-clicking.

To make sure that the features works properly on your browser, you might have to fully clear the browser's cache.

Basically I modified the FCKeditor config file (/cvs/cds/caltech/elog/elog-2.7.5/scripts/fckeditor/fckconfig.js). I added this also to the elog section on our Wiki.

  2130   Wed Oct 21 16:18:12 2009 SteveSummarySAFETYLIGO Safety Officers visited the 40m

David Nolting, chief LIGO Safety Officer and his lieutenants from LLO and LHO paid homage to the 40m lab this morning.

They give us a few recommendation: update safety documents, move optical table from the front of ETMX-rack and label-identify absorbent plastics on enclosure windows-doors.

We'll correct these short comings ASAP

 

  2129   Wed Oct 21 15:07:45 2009 AlbertoUpdateWIKI-40M UpdatePhotodiodes' configuration for the Upgrade

I uploaded on the Wiki (here) the results of an inventory over our current PDs, a list of the new ones that we're going to need for the new control scheme.

  2128   Wed Oct 21 13:07:54 2009 KojiUpdateWIKI-40M UpdatePSL Table Diagram wiki entry

http://lhocds.ligo-wa.caltech.edu:8000/40m/PSL_Table_Diagram

Thanks. I love this. Could you also put the original file that is editable for future modification by anyone?

Quote:

 I made a wiki entry for the PSL table diagram under the PSL directory on the 40mHomePage. I tried to use the ImageLink macro to use a resized (smaller) version of the diagram as a link to the full image, which it is designed to do if there is no target given, but it didn't seem to work. Instead, I had to create a second page that had the full-sized diagram, and I used ImageLink with a smaller version to link to that page.

The inventory that is shown is clearly incomplete. Part of this is due to the fact that many labels were either missing or impossible to read without touching stuff. For those components with labels missing, I tried to infer what they were to the best of my knowledge, but I wasn't able to for all of them. In true wiki spirit, everyone is encouraged to fill in any additional information they might have on these components. 

 

  2127   Wed Oct 21 11:41:29 2009 ZachUpdateWIKI-40M UpdatePSL Table Diagram wiki entry

 I made a wiki entry for the PSL table diagram under the PSL directory on the 40mHomePage. I tried to use the ImageLink macro to use a resized (smaller) version of the diagram as a link to the full image, which it is designed to do if there is no target given, but it didn't seem to work. Instead, I had to create a second page that had the full-sized diagram, and I used ImageLink with a smaller version to link to that page.

The inventory that is shown is clearly incomplete. Part of this is due to the fact that many labels were either missing or impossible to read without touching stuff. For those components with labels missing, I tried to infer what they were to the best of my knowledge, but I wasn't able to for all of them. In true wiki spirit, everyone is encouraged to fill in any additional information they might have on these components. 

  2126   Tue Oct 20 16:35:24 2009 robConfigurationLSC33MHz Mod depth

The 33MHz mod depth is now controlled by the OMC (C1:OMC-SPARE_DAC_CH_15).  The setting to give us the same modulation depth as before is 14000 (in the offset field).

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

  2124   Tue Oct 20 10:46:18 2009 steveUpdateIOOclipping IP-ANG beam at ETMX chamber

Initial pointing beam is clearly clipping on 2" pick off mirror in  ETMX vacuum chamber.

Atm. 1  The pick off mirror is just north west of the ETMX test mass

Atm. 2 The camera is looking in from the north view port of ETMX chamber. The back side of pick off mirror is visible now with the face view of the "IP-ANG-OUT" mirror.

 

Attachment 1: PA200175.JPG
PA200175.JPG
Attachment 2: PA200177.JPG
PA200177.JPG
  2123   Tue Oct 20 02:14:29 2009 robUpdateIOOMC2 alignment bias changed

the mode cleaner was having trouble locking in a 00 mode, needing several tries.  I changed the MC2 coil biases, and it seems better for now.

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

  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
  2118   Mon Oct 19 14:48:15 2009 rana, robSummaryElectronicspiezo jena measuring box
Attached is the schematic of the Piezo Jena driver measuring box made in a Pomona box:
                2.2 uF
In ----o-------- | | --------o-------- Out
       |                     |
       _                     |
       _  1uF                R  7.5 kOhms
       |                     |
       |                     |
      GND                   GND
The 1 uF cap is there to simulate the piezo and the 2.2 uF and 7.5k resistor ac couple the signal for the spectrum analyzer. They give a ~10 Hz corner frequency.
Attachment 1: PA160153.JPG
PA160153.JPG
Attachment 2: PA160151.JPG
PA160151.JPG
  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
  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
  2115   Mon Oct 19 11:00:52 2009 steveHowToSAFETY40m safety training

Kiwamu, Alex and Zach are practicing mandatory IR-safety scan at the 40m-PSL

40m specific safety indoctrination were completed.

Attachment 1: safety_10_2009.JPG
safety_10_2009.JPG
  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. )

 

 

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

 

  2112   Sun Oct 18 22:06:15 2009 ranaConfigurationElectronicsIP POS is back: ND filter gone, new resistors in

I tried to compare the IP_POS time series with the IPANG and MC_TRANS but was foiled at first:

1) The IPANG scan rate was set to 0.5 second, so it doesn't resolve the pendulum motions well. Fixed in the .db file.

2) Someone had used a Windows/DOS editor to edit the .db file and it was filled with "^M" characters. I have removed them all using this command:   tr -d "\r" <ETMXaux.db > new.db

3) The MC_TRANS P/Y channels were on the MC Lock screen but had never been added to the DAQ. Remember, if there's a useful readback on an EPICS screen. its not necessarily in the frames unless you add it to the C0EDCU file. I have done that now and restarted the fb daqd. Channels now exist.

4) Changed the PREC of the IPPOS channels to 3 from 2.

5) changed the sign for the IBQPD (aka IPANG) so that bigger signal is positive on the EPICS screen.

Attachment 1: Untitled.png
Untitled.png
  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
  2110   Sun Oct 18 19:55:45 2009 ranaConfigurationElectronicsIP POS is back: ND filter gone, new resistors in

Its back in and re-centered. Our next move on IPPOS should be to replace its steering mirror with something bigger and more rigid.

Electronics changes:

20K -> 3.65 K  (R6, R20, R42, R31) (unused)

20K -> 3.65 K  (R7, R21, R32, R43, R11, R24, R35, R46)

If you look in the schematic (D990272), you see that its an AD797 transimpedance stage with a couple of LT1125 stages set to give some switchable gain. It looks like some of these

switches are on and some are not, but I am not sure where it would be controlled from. I've attached a snapshot of one quadrant of the schematic below.

The schematic shows the switches in the so-called 'normally closed' configuration. This is what the switches do with zero volts applied to the control inputs. As the schematic also shows,

just disconnecting the 'switch' inputs cause the switch's control inputs to go high (normally open configuration, i.e. pins 2-3 connected, pin4 open). For the record, the default positions of the IPPOS switches are:

switch1   high

switch2   low

switch3   low

switch4   high

 


** EDIT (Nov 2, 2009): I forgot to attach the before and after images; here they are:

IMG_0068.JPGIMG_0072.JPG

  2109   Sun Oct 18 16:09:34 2009 ranaConfigurationASCloop opened on PZT2 YAW at 3:40 pm

 

I wanted to see how long our IP POS beam has been badly clipped - turns out its since April 1, 2007.

Steve's April Fool's joke is chronicled then. The attached trend shows that the drop in IP POS is coincident with that event.

In trying to align IPPOS, I noticed that someone has placed a ND2.0 filter (factor of 100 attenuation) in front of it. This is kind of a waste - I have removed IPPOS to fix its resistors and avoid this bad optic. Also the beam coming onto the table is too big for the 1" diameter optics being used; we need to replace it with a 2" diamter optic (Y1-2037-45P).

 

IP ANG dropped by a factor of 2 back in early August of '08.

We need this guy on the investigation:

 

Attachment 1: a.png
a.png
  2108   Sun Oct 18 15:46:08 2009 AlbertoConfigurationGeneralAntique, unused QPD removed from the AS table

Inspecting the AS table to make an inventory of the photodiodes in use around the interferometer, I found a mysterious photodetector hiding behind PD1 (AS166).

It turned out the detector was an old type of QPD from the Squeezing Experiment a few years ago.

We removed the box and the cable to which it was connected from the table. We stored it in the optics cabinet along the X arm.

  2107   Fri Oct 16 18:46:36 2009 ranaConfigurationASCloop opened on PZT2 YAW at 3:40 pm

Quote:

I pushed the "closed loop" button on PZT2 YAW around 3:40 pm today, then roughly recentered it using the DC Offset knob on the PiezoJena controller and the IP ANG QPD readbacks.  There was a large DC shift.    We'll watch and see how much it drifts in this state.

 Here's the trend.

The transient at ~22:40 is Rob switching to 'Open Loop' on the Piezo Jena PZTs. I don't see any qualitative change in the drift after this event.

At 05:55 UTC, I removed an iris that was blocking the IP POS beam (the sum goes up from 2 to 6.5) without disturbing the mirrors who's oplev beam are on that table. Steve has conceded one sugar Napoleon after betting against my ninja-like iris skills.

We should recenter the beam on IP POS now that its unclipped - I'll let it sit this way overnight just to get more drift data.

Attachment 1: Untitled.png
Untitled.png
  2106   Fri Oct 16 16:44:39 2009 Alberto, SanjitUpdateComputerselog restarted

This afternoon the elog crashed. We just restarted it.

  2105   Fri Oct 16 16:08:00 2009 robConfigurationASCloop opened on PZT2 YAW at 3:40 pm

I pushed the "closed loop" button on PZT2 YAW around 3:40 pm today, then roughly recentered it using the DC Offset knob on the PiezoJena controller and the IP ANG QPD readbacks.  There was a large DC shift.    We'll watch and see how much it drifts in this state.

  2104   Fri Oct 16 13:25:18 2009 KojiSummaryLSCfunny timing setup on the LSC

Could be this.

http://ilog.ligo-la.caltech.edu/ilog/pub/ilog.cgi?group=detector&task=view&date_to_view=10/02/2009&anchor_to_scroll_to=2009:10:02:13:33:49-waldman

Quote:

We should be able to diagnose timing noise between the OMC and the LSC by putting in a signal in the OMC and looking at the signal on the LSC side. Should be a matlab script that we can run whenever we are suspicious of this. This is an excellent task for a new visiting grad student to help learn how to debug the digital control system.

 

  2103   Fri Oct 16 12:40:59 2009 KojiConfigurationGeneralSome questions

Some questions came arise to me:

A. How the green injection system should be? How the handing off between 532 and 1064 should be?

This is not new, though. It would be worth reminding.

B. Do we still need PMC if we use 2W innolight?

Innolight has low intensity noise at the detection freq. Also the spacial mode is clean.

C. Do we still need frequency prestabilization by RC?

Is the stabilization of the laser freq by the MC not enough?
What is the relationship with the green?

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