40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 157 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  2572   Fri Feb 5 01:04:58 2010 SanjitUpdateAdaptive FilteringOAF at > 5Hz

 

There is lot of coherence between the error signal and PEM channels at 5-100Hz. We had been applying a 1Hz low pass filter to all the GUR and RANGER channels for stability. I turned those off and OAF still works with mu=0.0025, this will give us some more freedom. Kind of annoying for testing though, it takes about 45min to adapt!

In any case, there is no significant improvement at high frequencies as compared to our usual OAF performance. Also, the low frequency improvement (see previous e-log) is lost in this set up. I think, we have to adjust the number of taps and channels to do better at high frequencies. Also, delay can be important at these frequencies, needs some testing.

 

Attachment 1: OAF_04FEB2010_highFreq.png
OAF_04FEB2010_highFreq.png
  2575   Sat Feb 6 00:10:08 2010 SanjitUpdateAdaptive FilteringOAF at > 5Hz

 

Did some more test to get better performance at higher frequencies.

Increased # taps to 4000 and reduced downsampling to 4, without changing the AA32 filters, from CORR, EMPH and the matching ADPT channels. But for testing I turned off AA32 from the input PEM channels. So that high frequency still gets blocked at CORR, but the adaptive filters have access to higher frequencies. Once we fix some reasonable downsampling, we should create corresponding AA filters.

I used only two channels, RANGER/GUR2_Y and GUR1_Z, and basically they had only one filter 0.1:0

This set up gave little better performance (more reduction at more frequencies), at some point even the 16HZ peak was reduced by a factor of 3. The 24Hz peak was a bit unstable, but became stable after I removed the Notch24 filters from PEM channels, to ensure that OAF is aware of those lines. There was some improvement also at the 24Hz peak.

 

  6075   Tue Dec 6 00:58:34 2011 DenUpdateWienerFilteringOAF current goal

After reducing the digital noise I did offline Wiener filtering to see how good should be online filter. I looked at the MC_F and GUR1_X and GUR1_Y signals. Here are the results of the filtering. The coherence is plotted for MC_F and GUR1_X signals.

oaf_goal_psd.png     oaf_goal_coh.png

We can see the psd reduction of the MC_F below 1 Hz and at resonances. Below 0.3 Hz some other noises are present in the MC_F. Probably tilt becomes important here.

OAF is ready to be tested. I added AA and AI filters and also a highpass filter at 0.1 Hz. OAF workes, MC stays at lock. I looked at the psd of MC_F and filter output. They are comparable, filter output adapts for MC_F in ~10 minutes but MC_F does not go down too much. Determing the right gain I unlocked the MC, while Kiwamu was measuring something. Sorry about that. I'll continue tomorrow during the daytime.

  2548   Tue Jan 26 19:51:44 2010 Sanjit, ranaUpdateAdaptive FilteringOAF details

We turned on the OAF again to make sure it works. We got it to work well with the Ranger as well as the Guralp channels. The previous problem with the ACC is that Sanjit and Matt were using the "X" channels which are aligned the "Y" arm. Another casualty of our ridiculous and nonsensical coordinate system. Long live the Right Hand Rule!!

The changes that were made are:

  • use of RANGER channel (with ACC_MC1_X and/or ACC_MC2_X)
  • mu = 0.01, tau = 1.0e-6, ntaps = 2000, nDown = 16
  • nDelay = 5 and nDelay = 7 both work (may not be so sensitive on delay at low frequencies)
  • Main changes: filter bank on the PEM channels - ASS_TOP_PEM_## filters: 0.1:0, 1:, Notch24, AA32, gain 1
  • Added the AI800 filter for upsampling in MC1 (should not matter)

Other parameters which were kept at usual setting:

  • CORR: AI32, gain = 1
  • EMPH: 0.001:0, AA32, gain = 1
  • ERR_MCL: no filters, gain = 1
  • SUS_MC1: no filter, gain = 1
  • PEM Matrix: All zero except: (24,1), (15,2), (18,3)
  • ADAPT path filter: union of CORR and EMPH filters, gain 1
  • XYCOM switches # 16-19 (last four on the right) OFF 

Screenshots are attached.

Burt snapshot is kept as: /cvs/cds/caltech/scripts/OAF/snaps/ass_burt_100126_211330.snap

taken using the script: /cvs/cds/caltech/scripts/OAF/saveOAF

we should put this in ASS screen.


ERROR Detected in filter ASS_TOP_PEM_24 (RANGER): 1: was actually typed as a 1Hz high pass filter!

(Correcting this one seems to spoil the adaptation)

Possibly this makes sense, we may not want to block witness signals in the 0.1-20 Hz range.


  11:40 PM: Leaving the lab with the OAF running on 5 PEM channels (Ranger + Guralp 1&2  Y & Z). There's a terminal open on op440m which will disable the OAF in ~2.8 hours. Feel free to disable sooner if you need the MC/IFO.

Attachment 1: C1ASS_TOP.png
C1ASS_TOP.png
Attachment 2: C1SUS_SRM_XYCOM1.png
C1SUS_SRM_XYCOM1.png
Attachment 3: Untitled.png
Untitled.png
  2555   Mon Feb 1 18:31:00 2010 SanjitUpdateAdaptive FilteringOAF details

  I tried downsampling value 32 (instead of 16), to see if it has any effect on OAF. Last week I encountered some stability issue - adaptation started to work, but the mode cleaner was suddenly unlocked, it could be due to some other effect too.

One point to note is that different downsampling did not have any effect on the CPU meter (I tried clicking the "RESET" button few times, but no change).

  2557   Mon Feb 1 21:51:12 2010 SanjitUpdateAdaptive FilteringOAF details

 I tried some combination of PEM channels and filters to improve OAF performance at other frequencies, where we do not have any improvement so far. There is progress, but still no success.

Here are the main things I tried:

For the ACC channels replaced the 0.1 Hz high pass filters by 3Hz high pass and turned off the 1: filter.

Then I tried to incorporate the Z ACC/GUR channels, with some reasonable combination of the others.

The Z axis Guralp and Accelerometers were making OAF unstable, so I put a 0.1 gain in all four of those.

Following the PEM  noise curves Rana has put up, we should probably use

  • two ACC_Y channels (3:0, Notch24, AA32)
  • two GUR_Z channels (filters: 0.1:0, 1:, AA32, gain 0,1)
  • one RANGER_Y, just because it works (0.1:0, 1:, Notch24, AA32)

In the end I tried this combination, it was stable after I reduced the GUR_Z gain, but looked very similar to what we got before, no improvement at 5Hz or 0.5Hz. But there was a stable hint of better performance at > 40Hz.

Possibly we need to increase the GUR_Z gain (but not 1) and try to use ACC_Z channels also. Since we can not handle many channels, possibly using one GUR_Z and one ACC_Z would be worth checking.

  5572   Wed Sep 28 22:30:01 2011 JenneUpdateAdaptive FilteringOAF is disabled

I am leaving the OAF disabled, so there should be nothing that goes to the suspensions from the OAF. 

Disabled for the OAF means all the outputs are multiplied by 0 just before the signals are sent back over to the LSC system to be summed in and sent to the suspensions.  So 0 times anything should mean that the OAF isn't injecting signals.

In other news, while Mirko was trying to figure out the c-code, I began making a new OAF screen.  It is still in progress, but it's in c1oaf/master/C1OAF_OVERVIEW.adl  If you open it up, you can see for yourself that the OAF is disabled.  (Eventually I'll put an enable/disable button on the LSC screen also, but that hasn't happened yet.)

  6641   Fri May 11 17:21:56 2012 JenneUpdateIOOOAF left enabled - MC unlocked for more than an hour

No leaving the OAF running until you're sure (sure-sure, not kind of sure, not pretty sure, but I've enabled guardians to make sure nothing bad can happen, and I've been sitting here watching it for 24+ hours and it is fine) that it works okay.

OAF (both adaptive and static paths) were left enabled, which was kicking MC2 a lot.  Not quite enough that the watchdog tripped, but close.  The LSCPOS output for MC2 was in the 10's or 100's of thousands of counts.  Not okay.

This brings up the point though, which I hadn't actively thought through before, that we need an OAF watchdog.  An OAF ogre?  But a benevolent ogre.  If the OAF gets out of control, it's output should be shut off.  Eventually we can make it more sophisticated, so that it resets the adaptive filter, and lets things start over, or something. 

But until we have a reliable OAF ogre, no leaving the adaptive path enabled if you're not sitting in the control room.  The static path should be fine, since it can't get out of control on it's own.

Especially no leaving things like this enabled without a "I'm leaving this enabled, I'll be back in a few hours to check on it" elog! 

  5886   Mon Nov 14 12:16:41 2011 JenneUpdateComputersOAF model died for unknown reason

I am meditating on the OAF, and had it running and calculating things.  I had the outputs disabled so I could take reference traces in DTT, but the Adapt block was calculating for MCL.  At some point, all the numbers froze, and the CPU meter had gone up to ~256ms.  Usually it's around ~70 or so for the configuration I had (2 witness sensors and one degree of freedom enabled....no c-code calculations on any other signals).  The "alive" heartbeat was also frozen.

I ssh'ed into c1lsc, ran ./startc1oaf in the scripts directory, and it came back just fine.

Anyhow, I don't know why it got funny, but I wanted to record the event for posterity.  I'm back to OAFing now.

  6626   Tue May 8 17:48:50 2012 JenneUpdateCDSOAF model not seeing MCL correctly

Den noticed this, and will write more later, I just wanted to sum up what Alex said / did while he was here a few minutes ago....

 

Errors are probably really happening.... c1oaf computer status 4-bit thing:  GRGG.  The Red bit is indicating receiving errors.  Probably the oaf model is doing a sample-and-hold thing, sampling every time (~1 or 2 times per sec) it gets a successful receive, and then holding that value until it gets another successful receive. 

Den is adding EPICS channels to record the ERR out of the PCIE dolphin memory CDS_PART, so that we can see what the error is, not just that one happened.

Alex restarted oaf model:  sudo rmmod c1oaf.ko, sudo insmod c1oaf.ko .  Clicked "diag reset" on oaf cds screen several times, nothing changed.  Restarted c1oaf again, same rmmod, insmod commands.

Den, Alex and I went into the IFO room, and looked at the LSC computer, SUS computer, SUS I/O chassis, LSC I/O chassis and the dolphin switch that is on the back of the rack, behind the SUS IO chassis.  All were blinking happily, none showed symptoms of errors.

Alex restarted the IOP process:  sudo rmmod c1x04, sudo insmod c1x04.  Chans on dataviewer still bad, so this didn't help, i.e. it wasn't just a synchronization problem.  oaf status: RRGG. lsc status: RGGG. ass status: RGGG.

sudo insmod c1lsc.ko, sudo insmod c1ass.ko, sudo insmod c1oaf.ko .  oaf status: GRGG. lsc status: GGGG. ass status: GGGG.  This means probably lsc needs to send something to oaf, so that works now that lsc is restarted, although oaf still not receiving happily.

Alex left to go talk to Rolf again, because he's still confused.

Comment, while writing elog later:  c1rfm status is RRRG, c1sus status is RRGG, c1oaf status is GRGG, both c1scy and c1scx are RGRG.  All others are GGGG.

  6632   Wed May 9 10:46:54 2012 DenUpdateCDSOAF model not seeing MCL correctly

Quote:

Den noticed this, and will write more later, I just wanted to sum up what Alex said / did while he was here a few minutes ago....

 From my point of view during rfm -> oaf transmission through Dolphin we loose a significant part of the signal. To check that I've created MEDM screen to monitor the transmission errors in the OAF model. It shows how many errors occurs per second. For MCL channel this number turned out to be 2046 +/- 1. This makes sense to me as the sampling rate is 2048 Hz => then we actually receive only 1-3 data points per second. We can see this in the dataviewer.

C1:OAF-MCL_IN follows C1:IOO-MC_F in the sense that the scale of 2 signals are the same in 2 states: MC locked and unlocked. It seems that we loose 2046 out of 2048 points per second.

oaf_rec.png

  2012   Mon Sep 28 11:52:23 2009 JenneUpdateTreasureOAF screen added to the screenshots webpage

I used Kakeru's instructions in elog 1221 to add the C1OAF screen (still called C1ASS_TOP) to the medm screenshots webpage.  The tricky part of this is figuring out that the file that needs editing is in fact in /cvs/cds/projects/statScreen, not /cvs/cds/caltech/statScreen, as claimed in the entry. 

  1985   Fri Sep 11 17:11:15 2009 SanjitUpdateASSOAF: progress made

[Jenne & Sanjit]

Good news: We could successfully send filtered output to MC1 @ SUS.

We used 7 channels (different combinations of 3 seismometer and six accelerometer)

We tried some values of \mu (0.001-0.005) & gain on SUS_MC1_POSITION:MCL and C1ASS_TOP_SUS_MC1 (0.1-1).

C1:ASS-TOP_SUS_MC1_INMON is huge (soon goes up to few times 10000), so ~0.1 gains at two places bring it down to a reasonable value.

Bad news: no difference between reference and filtered IOO-MC_L power spectra so far.

Plan of action: figure out the right values of the parameters (\mu, \tau, different gains, and may be some delays), to make some improvement to the spectra.

 ** Rana: there's no reason to adjust any of the MCL gains. We are not supposed to be a part of the adaptive algorithm.

  10708   Thu Nov 13 01:03:28 2014 rana, jenneUpdateSUSOL updates on ITMs and ETMs

 We copied the new SRM filters over onto the OL banks for the ITMs and ETMs. We then adjusted the gain to be 3x lower than the gain at which it has a high frequency oscillation. This is the same recipe used for the SRM OL tuning.

Before this tune up, we also set the damping gains of the 4 arm cavity mirrors to give step response Q's of ~5 for all DOF and ~7-10 for SIDE.

  12568   Tue Oct 18 18:56:57 2016 gautamUpdateGeneralOM5 rotated to bypass OMC, green scatter is from window to PSL table

[ericq, lydia, gautam]

  • We started today by checking leveling of ITMY table, all was okay on that front after the adjustment done yesterday. Before closing up, we will have detailed pictures of the current in vacuum layout
  • We then checked centering on OMs 1 and 2 (after having dither aligned the arms), nothing had drifted significantly from yesterday and we are still well centered on both these OMs
  • We then moved to the BS/PRM chamber and checked the leveling, even though nothing was touched on this table. Like in the OMC chamber, it is difficult to check the leveling here because of layout constraints, but I verified that the table was pretty close to being level using the small (clean) spirit level in two perpendicular directions
  • Beam centering was checked on OMs 3 and 4 and verified to be okay. Clearance of beam from OM4 towards the OMC chamber was checked at two potential clipping points - near the green steering mirror and near tip-tilt 2. Clearance at both locations was deemed satisfactory so we moved onto the OMC chamber
  • We decided to go ahead and rotate OM5 to send the beam directly to OM6 and bypass the partially transmissive mirror meant to send part of the AS beam to the OMC
  • In order to accommodate the new path, I had to remove a razor beam dump on the OMC setup, and translate OM5 back a little (see Attachment #1), but we have tried to maintain ~45 degree AOI on both OMs 5 and 6
  • Beam was centered on OM6 by adjusting the position of OM5. We initially fiddled around with the pitch and yaw knobs of OM4 to try and center the beam on OM5, but it was decided that it was better just to move OM5 rather than mess around on the BS/PRM chamber and introduce potential additional scatter/clipping
  • OMC table leveling was checked and verified to not have been significantly affected by todays work
  • It was necessary to loosen the fork and rotate OM6 to extract the AS beam from the vacuum chambers onto the AP table
  • AS beam is now on the camera, and looks nice and round, no evidence of any clipping. Some centering on in air lenses and mirrors on the AP table remains to be done. We are now pretty well centered on all 6 OMs and should have more power at the AS port given that we are now getting light previously routed to the OMC out as well. A quantitative measure of how much more light we have now will have to be done after pumping down and turning the PSL power back up
  • I didn't see any evidence of back-scattered light from the window even though there were hints of this previously (sadly the same can't be said about the green). I will check once again tomorrow, but this doesn't look like a major problem at the moment

Lydia and I investigated the extra green beam situation. Here are our findings.

  1. There appears to be 3 ghost beams in addition to the main beam. These ghosts appeared when we locked the X green and Y green individually, which lead us to conclude that whatever is causing this behaviour is located downstream of the periscope on the BS/PRM chamber
    Link to greenGhosts.JPG
  2. I then went into the BS/PRM chamber and investigated the spot on the lower periscope mirror. It isn't perfectly centered, but it isn't close to clipping on any edge, and the beam leaving the upper mirror on the periscope looks clean as well (only the X-arm green was used for this, and subsequent checks). The periscope mirror looks a bit dusty and scatters rather a lot which isn't ideal...
    Link to IMG_3322.JPG
  3. There are two steering mirrors on the IMC table which we do not have access to this vent. But I looked at the beam coming into the OMC chamber and it looks fine, no ghosts are visible when letting the main beam pass through a hole in one of our large clean IR viewing cards - and the angular separation of these ghosts seen on the PSL table suggests that we would see these ghosts if they exist prior to the OMC chamber on the card...
  4. The beam hits the final steering mirror which sends it out onto the PSL table on the OMC chamber cleanly - the spot leaving the mirror looks clean. However, there are two reflections from the two surfaces of the window that come back into the OMC chamber. Space constraints did not permit me to check what surfaces these scatter off and make it back out to the PSL table as ghosts, but this can be checked again tomorrow.
    Link to IMG_3326.JPG

I can't think of an easy fix for this - the layout on the OMC chamber is pretty crowded, and potential places to install a beam dump are close to the AS and IMC REFL beam paths (see Attachment #1). Perhaps Steve can suggest the best, least invasive way to do this. I will also try and nail down more accurately the origin of these spots tomorrow.


Light doors are back on for the night. I re-ran the dithers, and centered the oplevs for all the test-masses + BS. I am leaving the PSL shutter closed for the night

 

Attachment 1: OMCchamber.pdf
OMCchamber.pdf
Attachment 2: greenGhosts.JPG
greenGhosts.JPG
Attachment 3: IMG_3322.JPG
IMG_3322.JPG
Attachment 4: IMG_3326.JPG
IMG_3326.JPG
  19   Fri Oct 26 17:34:43 2007 waldmanOtherOMCOMC + earthquake stops

[Chub, chris, Pinkesh, Sam]

Last night we hugn the OMC for the first time and came up with a bunch of pictures and some problems. Today we address some of the problems and, of course, make new problems. We replaced the flat slotted disks with the fitted slotted disks that are made to fit into the counterbore of the breadboard. This changed the balance slightly and required a more symmetric distribution of mass. It probably did not change the total mass very much. We did find that the amount of cable hanging down strongly affected the breadboard balance and may also have contributed to the changing balance.

We also attached earthquake stops and ran into a few problems:

  • The bottom plate of the EQ stops is too thick so that it bumps into the tombstones
  • The vertical member on the "waist" EQ stops is too close to the breadboard, possibly interfering with the REFL beam
  • The "waist" EQ stops are made from a thin plate that doesn't have enough thickness to mount helicoils in
  • Helicoil weren't loaded in the correct bottom EQ stops
  • The DCPD cable loops over the end EQ stop looking nasty but not actually making contact

However, with a little bit of jimmying, the EQ stops are arrayed at all points within a few mm of the breadboard. Meanwhile, Chub has cabled up all the satellite modules and DCPD modules and Pinkesh is working on getting data into the digital system so we can start playing games. Tonight, I intend to mount a laser in Rana's lab and fiber couple a beam into the 056 room so we can start testing the suspended OMC.
  99   Wed Nov 14 07:48:38 2007 nornaOmnistructureOMCOMC Cable dressing
[Snipped from an email]

1) Last Friday Pinkesh and I set the OMC up with only the top three OSEMs and took a vertical transfer function. We had removed the other OSEMs due to difficulty of aligning all OSEMs with the weight of the bench etc bringing the top mass lower than the tablecloth can accommodate. See attached TF.Clearly there are extra peaks (we only expect two with a zero in between) and my belief is that at least some of them are coupling of other degrees of freedom caused by the electrical wiring. Pinkesh and I also noticed the difficulty of maintaining alignment if cables got touched and moved around. So.....

2) Yesterday Dennis and I took a look at how much moving a cable bundle around (with the peak shielding) changed the DC alignment. In a not too precise experiment ( using HeNe laser reflecting off the bench onto a surface ~ 1 metre away) we saw that we could reposition the beam one or two mm in yaw and pitch. This corresponds to ~ one or two mrad which is ~ the range of the OSEM DC alignment. We discussed possibility of removing the cabling from the middle mass, removing the peak and taking it from the bench directly to the structure above. I asked Chub if he could make an equivalent bundle of wires as those from the two preamps to see what happens if we repeat the "moving bundle" experiment. So...

3) Today Chub removed the cabling going to the preamps and we replaced it with a mock up of wire bundle going directly from the preamps to the structure above. See attached picture. The wires are only attached to the preamp boxes weighted down with masses but the bundle is clamped at the top. We repeated the "wiggle the bundle" test and couldnt see any apparent movement ( so maybe it is at most sub-mm). The cable bundle feels softer.

The next thing Chub did was to remove the second bundle ( from photodiodes, heater, pzt) from its attachment to the middle mass and strip off the peek. It is now also going to the top of the structure directly. The whole suspension now appears freer. We discussed with Dennis the "dressing " of the wires. There are some minor difficulties about how to take wires from the bright side to the dark side, but in general it looks like that the wires forming the second "bundle" could be brought to the "terminal block" mounted on the dark side and from there looped up to the top of the structure. We would have to try all this of course to see the wiring doesnt get in the way of other things (e.g. the L and R OSEMs). However this might be the way forward. So...

4) Tomorrow Pinkesh and I will check the alignment and then repeat the vertical transfer function measurement with the two bundles as they are going from bench to top of structure. We might even do a horizontal one if the middle mass is now within range of the tablecloth.
We can then remove preamp cables completely and lay the second bundle of cables on the optical bench and repeat the TFs.

The next thing will be to weigh the bench plus cables. This will allow us to
a) work out what counterbalance weights are needed - and then get them manufactured
b) firm up on how to handle the extra mass in terms of getting the masses at the correct height.

And in parallel Chub will work on the revised layout of cabling.

Looking a little further ahead we can also get some stiffness measurements made on the revised bundle design ( using Bob's method which Alejandro also used) and fold into Dennis's model to get some sanity check the isolation.

I think that's it for now. Comments etc are of course welcome.

Norna
Attachment 1: OMC-11-13-07_011.jpg
OMC-11-13-07_011.jpg
Attachment 2: VerticalTrans.pdf
VerticalTrans.pdf VerticalTrans.pdf VerticalTrans.pdf VerticalTrans.pdf
  2220   Mon Nov 9 18:27:30 2009 AlbertoFrogsComputersOMC DCPD Interface Box Disconnected from the power Supply

This afternoon I inadvertently disconnected one of the power cables coming from the power supply on the floor next to the OMC cabinet and going to the DCPD Interface Box.

Rob reconnected the cable as it was before.

  14120   Tue Jul 31 22:50:18 2018 aaronUpdateOMCOMC Expected Refl Signal

I learned a lot about lasers this week from Siegman. Here are some plots that show the expected reflectivity off of the OMC for various mode matching cases.

The main equation to know is 11.29 in Siegman, the total reflection coefficient going into the cavity:

R=r-\frac{t^2}{r}\frac{g(\omega)}{1-g(\omega)}

Where r is the mirror reflectivity (assumed all mirrors have the same reflectivity), t is the transmissivity, and g is the complex round-trip gain, eq 11.18

g(\omega)=r_1r_2(r_3...)e^{-i\phi}e^{-\alpha_0p}

The second exponential is the loss; in Siegman the \alpha_0 is some absorption coecfficient and p is the total round trip length, so the product is just the total loss in a round trip, which I take to be 4*the loss on a single optic (50ppm each). \phi is the total round trip phase accumulation, which is 2\pi*detuning(Hz)/FSR. The parameters for the cavity can be found on the wiki.

I've added the ipynb to my personal git, but I can put it elsewhere if there is somewhere more appropriate. I think this is all OK, but let me know if something is not quite right.

Attachment 1: omcRefl.pdf
omcRefl.pdf
  2221   Mon Nov 9 18:32:38 2009 robUpdateComputersOMC FE hosed

It won't start--it just sits at Waiting for EPICS BURT, even though the EPICS is running and BURTed.

 

[controls@c1omc c1omc]$ sudo ./omcfe.rtl
cpu clock 2388127
Initializing PCI Modules
3 PCI cards found
***************************************************************************
1 ADC cards found
        ADC 0 is a GSC_16AI64SSA module
                Channels = 64
                Firmware Rev = 3

***************************************************************************
1 DAC cards found
        DAC 0 is a GSC_16AO16 module
                Channels = 16
                Filters = None
                Output Type = Differential
                Firmware Rev = 1

***************************************************************************
0 DIO cards found
***************************************************************************
1 RFM cards found
        RFM 160 is a VMIC_5565 module with Node ID 130
***************************************************************************
Initializing space for daqLib buffers
Initializing Network
Waiting for EPICS BURT


  2222   Mon Nov 9 19:04:23 2009 robUpdateComputersOMC FE hosed

Quote:

It won't start--it just sits at Waiting for EPICS BURT, even though the EPICS is running and BURTed.

 

[controls@c1omc c1omc]$ sudo ./omcfe.rtl
cpu clock 2388127
Initializing PCI Modules
3 PCI cards found
***************************************************************************
1 ADC cards found
        ADC 0 is a GSC_16AI64SSA module
                Channels = 64
                Firmware Rev = 3

***************************************************************************
1 DAC cards found
        DAC 0 is a GSC_16AO16 module
                Channels = 16
                Filters = None
                Output Type = Differential
                Firmware Rev = 1

***************************************************************************
0 DIO cards found
***************************************************************************
1 RFM cards found
        RFM 160 is a VMIC_5565 module with Node ID 130
***************************************************************************
Initializing space for daqLib buffers
Initializing Network
Waiting for EPICS BURT


 

From looking at the recorded data, it looks like the c1omc started going funny on the afternoon of Nov 5th, perhaps as a side-effect of the Megatron hijinks last week.

 

It works when megatron is shutdown.

  2224   Mon Nov 9 19:44:38 2009 rob, ranaUpdateComputersOMC FE hosed

 

We found that someone had set the name of megatron to scipe11. This is the same name as the existing c1aux in the op440m /etc/hosts file.

We did a /sbin/shutdown on megatron and the OMC now boots.

Please: check to see that things are working right after playing with megatron or else this will sabotage the DR locking and diagnostics.

  14365   Tue Dec 18 18:13:32 2018 aaronUpdateOMCOMC L HV Piezo driver tests (again)

I tested the OMC-L HV driver box again, and made the following observations:

  • Drove the HV diff pins (2,7) with a 5V triangle wave
    • Observed that with a ~0.4V offset on the drive, the HV output (measured directly with a 10x probe) has a 0-(almost)200V triangle wave (for 200V HV in), saturating near 200V and near 0V somewhat before reaching the full range of the triangle
    • The HV mon gives the same answer as measuring the HV output directly, and is reduced 100x compared to the HV output.
    • At 1Hz and above, the rolloff of the low pass still attenuates the drive a bit, and we don't reach the full range.
  • Drove the HV dither pins (1,6) with a 100mV to 10V triangle wave, around 15kHz
    • Even at 10V, the dithering is near the noise of the mon channel, so while I could see a slight peak changing on the FFT near the dither frequency, I couldn't directly observe this on a scope using the mon channel
    • However, measuring the HV directly I do see the dither applied on top of the HV signal. The amplitude of the dither is the same on the HV output as on the dither drive.

[gautam, aaron]

We searched for blips while nominally scanning the OMC length.

We sent a 0.1Hz, 10Vpp triangle wave to the OMC piezo drive diff channels, so the piezo length is seeing a slow triangle wave from 0-200V.

Then, we applied a ~15kHz dither to the OMC length. This dither is added directly onto the HV signal, so the amplitude of the dither at the OMC is the same as the amplitude of the dither into the HV driver.

We monitored the OMC REFL signal (where we saw no blips yesterday) and mixed this with the 15kHz dither signal to get an error signal. Gautam found a pomona box with a low pass filter, so we also low passsed to get rid of some unidentified high frequency noise we were seeing (possibly a ground loop at the function generator? it was present with the box off, but gone with the AC line unplugged). [So we made our own lock-in amplifier.] Photo attached.

We tested the transfer function of the LP, and finding it at 100kHz rather than the advertised 10kHz, we opened the box, removed a resistor to change the 3dB back to 10kHz, and confirmed this by measuring the TF.

We didn't see flashes of error signal in the mixed reflection either, so we suspect that either the PZT is not actuating on the OMC or the alignment is bad. Based on what appears to be the shimmering of far-misaligned fringes on the AS camera, Aaron's suspicion from aligning the cavity with the card, and the lack of flashes, we suspect the alignment. To avoid being stymied by a malfunctioning PZT, we can scan the laser frequency next time rather than the PZT length.

Attachment 1: IMG_4576_copy.jpg
IMG_4576_copy.jpg
  8849   Mon Jul 15 16:44:46 2013 AlexUpdateOMCOMC North Safety

 [Eric Alex]

We are planning on testing our laser module soon, so we have added aluminum foil and a safety announcement to the door of OMC North. The safety announcement is as pictured in the attachment.

Attachment 1: photo_2_(1).JPG
photo_2_(1).JPG
  60   Sun Nov 4 23:22:50 2007 waldmanUpdateOMCOMC PZT and driver response functions
I wrote a big long elog and then my browser hung up, so you get a less detailed entry. I used Pinkesh's calibration of the PZT (0.9 V/nm) to calibrate the PDH error signal, then took the following data on the PZT and PZT driver response functions.:

  • FIgure 1: PZT dither path. Most of the features in this plot are understood: There is a 2kHz high pass filter in the PZT drive which is otherwise flat. The resonance features above 5 kHz are believed to be the tombstones. I don't understand the extra motion from 1-2 kHz.
  • Figure 2: PZT dither path zoom in. Since I want to dither the PZT to get an error signal, it helps to know where to dither. The ADC Anti-aliasing filter is a 3rd order butterworth at 10 kHz, so I looked for nice flat places below 10 KHz and settled on 8 kHz as relatively harmless.
  • Figure 3: PZT LSC path. This path has got a 1^2:10^2 de-whitening stage in the hardware which hasn't been digitally compensated for. You can see its effect between 10 and 40 Hz. The LSC path also has a 160 Hz low path which is visible causing a 1/f between 200 and 500 Hz. I have no idea what the 1 kHz resonant feature is, though I am inclined to point to the PDH loop since that is pretty close to the UGF and there is much gain peaking at that frequency.
Attachment 1: 071103DitherShape.png
071103DitherShape.png
Attachment 2: 071103DitherZoom.png
071103DitherZoom.png
Attachment 3: 071103LSCShape.png
071103LSCShape.png
Attachment 4: 071103DitherShape.pdf
071103DitherShape.pdf
Attachment 5: 071103DitherZoom.pdf
071103DitherZoom.pdf
Attachment 6: 071103LSCShape.pdf
071103LSCShape.pdf
Attachment 7: 071103LoopShape.pdf
071103LoopShape.pdf
  5   Fri Oct 19 16:11:38 2007 pkpOtherOMCOMC PZT response
Sam and I locked the laser to the OMC cavity and looked at the error signal as a function of the voltage applied to the OMC PZT.
Here are two plots showing the response as a function of frequency from 1 kHz to 100 kHz and another high-res response in the region of 4.5 kHz to 10 kHz.
Attachment 1: fullspec.jpg
fullspec.jpg
Attachment 2: 4.5to10.jpg
4.5to10.jpg
Attachment 3: 4.5to10.pdf
4.5to10.pdf
Attachment 4: fullres.pdf
fullres.pdf
  6   Sat Oct 20 11:54:13 2007 waldmanOtherOMCOMC and OMC-SUS work
[Rich, Chub, Pinkesh, Chris, Sam]

Friday the 18th was a busy day in OMC land. Both DCPDs were mounted to the glass breadboard and the OMC-SUS structure was rebuilt to the point that an aluminum dummy mass is hanging, unbalanced. The OSEMs have not be put on the table cloth yet, but everything is hanging free. As for the DCPDs, if you recall one beam is 3mm off center from the DCPD tombstone. Fortunately, one DCPD is nearly 3mm offcenter from the case in the right direction, so the errors nearly cancel. The DCPD is too high, so the beam isn't quite centered, but they're close. We'll get photos of the beam positions in someday. Also, the DC gain between the two PDs is, at first glance, different by 15%. DCPD1, the one seen in transmission has 315 mV of signal while DCPD2 has 280 mV. Not sure why, could be because of beam alignment or tolerances in the Preamp or the angle incident on the diode or the QE of the diodes. The glass cans have *not* been removed.
  14819   Wed Jul 31 09:41:12 2019 gautamUpdateBHDOMC cavity geometry

Summary:

We need to determine the geometry (= round-trip length and RoC of curved mirrors) of the OMC cavities for the 40m BHD experiment. Sticking to the aLIGO design of a 4 mirror bowite cavity with 2 flat mirrors and 2 curved mirrors, with a ~4deg angle of incidence, we need to modify the parameters for the 40m slightly on account of our different modulation frequencies. I've setup some infrastructure to do this analytically - even if we end up doing this with Finesse, it is useful to have an analytic calculation to validate against (also not sure if Finesse can calculate HOMs up to order 20 in a reasonable time, I've only seen maxtem 8). 

Attachment #1: Heatmap of the OMC transmission for the following fields:

  • Carrier TEM00 is excluded, but HOMs up to m+n=20 included for both the horizontal and vertical modes of the cavity.
  • f1 and f2 upper and lower sidebands, up to m+n=20 HOMs for both the horizontal and vertical modes of the cavity, including TEM00.
  • Power law decay assumed for the HoM content incident on the OMC - this will need to be refined
  • The white region is where the cavity isn't geometrically stable.
  • Green dashed line indicates a possible operating point, white dashed line indicates the aLIGO OMC operating point. On the basis of this modeling, we would benefit from choosing a better operating point than the aLIGO OMC geometric parameters.

Algorithm:

  1. Compute the round-trip Gouy phase, \phi_{\mathrm{gouy}}, for the cavity.
  2. With the carrier TEM00 mode resonant, compute the round-trip propagation phase, \phi_{\mathrm{prop}} = \frac{2 \pi f_{\mathrm{offset}} L_{\mathrm{rt}}}{c}, and the round-trip Gouy phase, \phi_{\mathrm{G}} = (m+n)\phi_{\mathrm{gouy}} for the \mathrm{TEM}_{mn} mode of the field, with f_{\mathrm{offset}} specifying the offset from the carrier frequency (positive for the upper sideband, negative for the lower sideband). For the aLIGO cavity geometry, the 40m modulation sidebands acquire ~20% more propagation phase than the aLIGO modulation sidebands.
  3. Compute the OMC transmission for this round-trip phase (propagation + Gouy).
  4. Multiply the incident mode power (depending on the power law model assumed) by the cavity transmission.
  5. Sum all the fields.

Next steps:

  1. Refine the incident mode content (and power) assumption. Right now, I have not accounted for the fact that the f2 sideband is resonant inside the SRC while the f1 sideband is not. Can we somehow measure this for the 40m? I don't see an easy way as it's probably power dependent?
  2. Make plots for the projection along the slices indicated by the dashed lines - which HOMs are close to resonating? Might give us some insight.
  3. What is the requriement on transmitted power w.r.t. shot noise? i.e. the colorbar needs to be translated to dBVac.
  4. If we were being really fancy, we could simultaneously also optimize for the cavity finesse and angle of incidence as well.
  5. Question for Koji: how is the aLIGO OMC angle of incidence of ~4 degrees chosen? Presumably we want it to be as small as possible to minimize astigmatism, and also, we want the geometric layout on the OMC breadboard to be easy to work with, but was there a quantitative metric? Koji points out that the backscatter is also expected to get worse with smaller angles of incidence.

The code used for the ABCD matrix calcs have been uploaded to the BHD modeling GIT (but not the one for making this plot, yet, I need to clean it up a bit). Some design considerations have also been added to our laundry list on the 40m wiki.

Attachment 1: paramSpaceHeatMap.pdf
paramSpaceHeatMap.pdf
  14821   Wed Jul 31 17:57:35 2019 KojiUpdateBHDOMC cavity geometry

4 deg is not an optimized number optimized for criteria, but to keep the cavity short width to 0.1m. But the justification of 4deg is found in Section 3 and 4 of T1000276 on Page 4.

Quote:

Question for Koji: how is the aLIGO OMC angle of incidence of ~4 degrees chosen? Presumably we want it to be as small as possible to minimize astigmatism, and also, we want the geometric layout on the OMC breadboard to be easy to work with, but was there a quantitative metric? Koji points out that the backscatter is also expected to get worse with smaller angles of incidence.

  14854   Fri Aug 23 10:01:14 2019 gautamUpdateBHDOMC cavity geometry - some more modeling

Summary:

I did some more investigation of what the appropriate cavity geometry would be for the OMC. Unsurprisingly, depending on the incident mode content, the preferred operating point changes. So how do we choose what the "correct" model is? Is it accurate to model the output beam HOM content from NPROs (is this purely determined by the geometry of the lasing cavity?), which we can then propagate through the PMC, IMC, and CARM cavities? This modeling will be written up in the design document shortly.

*Colorbar label errata - instead of 1 W on BS, it should read 1 W on PRM. The heatmaps take a while to generate, so I'll fix that in a bit.

Update 230pm PDT: I realize there are some problems with these plots. The critically coupled f2 sideband getting transmitted through the T=10% SRM should have significantly more power than the transmission through a T=100ppm optic. For similar modulation depth (which we have), I think it is indeed true that there will be x1000 more f2 power than f1 power for both the IFO AS beam and the LO pickoff through the PRC. But if the LO is picked off elsewhere, we have to do the numbers again.

Details:

Attachment #1: Two candidate models. The first follows the power law assumption of G1201111, while in the second, I preserved the same scaling, but for the f1 sideband, I set the DC level by assuming a PRG of 45, modulation depth of 0.18, and 100 ppm pickoff from the PRC such that we get 50 mW of carrier light (to act as a local oscillator) for 10 W incident on the back of PRM. Is this a reasonable assumption?

Attachment #2: Heatmaps of the OMC transmission, assuming (i) 0 contrast defect light in the carrier TEM00 mode, (ii) PRG=45 and (iii) 1 W incident on the back of PRM. The color bar limits are preserved for both plots, so the "dark" areas of the plot, which indicate candidate operating points, are darker in the left-hand plot. Obviously, when there is more f1 power incident on the OMC, more of it is transmitted. But my point is that the "best operating point(s)" in both plots are different.

Why is this model refinement necessary? In the aLIGO OMC design, an assumption was made that the light level of the f1 sideband is 1/1000th that of the f2 sideband in the interferometer AS beam. This is justified as the RC lengths are chosen such that the f2 sideband is critically coupled to the AS port, but the f1 is not (it is not quite anti-resonant either). For the BHD application, this assumption is no longer true, as long as the LO beam is picked off after the RF sidebands are applied. There will be significant f1 content as well, and so the mode content of the f1 field is critical in determining the OMC filtering performance.

Attachment 1: modeContentComparison.pdf
modeContentComparison.pdf
Attachment 2: OMCtransComparison.pdf
OMCtransComparison.pdf
  14350   Thu Dec 13 10:03:07 2018 ChubUpdateGeneralOMC chamber

Bob, Aaron, and I removed the door from the OMC chamber this morning.  Everything went well.

  14332   Thu Dec 6 11:16:28 2018 aaronUpdateOMCOMC channels

I need to hookup +/- 24 V supplies to the OMC whitening/dewhitening boxes that have been added to 1X2.

There are trailing +24V fuse slots, so I will extend that row to leave the same number of slots open.

While removing one +24V wire to add to the daisy chain, I let the wire brush an exposed conductor on the ground side, causing a spark. FSS_PCDRIVE and FSS_FAST are at different levels than before this spark. The 24V sorensens have the same currents as before according to the labels. Gautam advised me to remove the final fuse in the daisy chain before adding additional links.

gautam: we peeled off some outdated labels from the Sorensens in 1X1 such that each unit now has only 1 label visible reflecting the voltage and current. Aaron will post a photo after his work.

  14338   Mon Dec 10 12:29:05 2018 aaronUpdateOMCOMC channels

I kept having trouble keeping the power LEDs on the dewhitening board 'on'. I did the following:

1. I noticed that the dewhitening board was drawing a lot of current (>500mA), so I initially thought that the indicators were just turning on until I blew the fuse. I couldn't find the electronics diagrams for this board, so I was using analagous boards' diagrams and wasn't sure how much current to expect to draw. I swapped out for 1A fuses (only for the electronics I was adding to the system).

2. Now the +24V indicator on the dewhitening board wasn't turning on, and the -24V supply was alternatively drawing ~500mA and 0mA in a ~1Hz square wave. Thinking I could be dropping voltage along the path to the board, I swapped out the cables leading to the whitening/dewhitening boards with 16AWG (was 18AWG). This didn't seem to help.

3. Since the whitening board seemed to be consistently powered on, I removed the dewhitening board to see if there was a problem with it. Indeed, I'd burned out the +24V supply electronics--two resisters were broken entirely, and the breadboard near the voltage regulator had been visibly heated.

  1. I identified that the resistors were 1Ohm, and replaced them (though I couldn't find 1Ohm surface mount resistors). I also replaced the voltage regulator in case it was broken. I couldn't find the exact model, so I replaced the LM2940CT-12 with an LM7812, which I think is the newer 12V regulator.
  2. Though this replacement seemed to work when the power board was disconnected from the dewhitening board, connecting to the dewhitening board again resulted in a lot of current draw.
  3. I depowered the board and decided to take a different approach (see)

I noticed that the +/-15V currents are slightly higher than the labels, but didn't notice whether they were already different before I began this work.

I also noticed one pair of wires in the area of 1X1 I was working that wasn't attached to power (or anything). I didn't know what it was for, so I've attached a picture.

Attachment 1: 52DE723A-02A4-4C62-879B-7B0070AE8A00.jpeg
52DE723A-02A4-4C62-879B-7B0070AE8A00.jpeg
Attachment 2: 545E5512-D003-408B-9F00-55F985966A16.jpeg
545E5512-D003-408B-9F00-55F985966A16.jpeg
Attachment 3: DFF34976-CC49-4E4F-BFD1-A197E2072A32.jpeg
DFF34976-CC49-4E4F-BFD1-A197E2072A32.jpeg
  14340   Mon Dec 10 19:47:06 2018 aaronUpdateOMCOMC channels

Taking another look at the datasheet, I don't think LM7812 is an appropriate replacement and I think the LM2940CT-12 is supposed to supply 1A, so it's possible the problem actually is on the power board, not on the dewhitening board. The board takes +/- 15V, not +/- 24...

Quote:
 
  1. I identified that the resistors were 1Ohm, and replaced them (though I couldn't find 1Ohm surface mount resistors). I also replaced the voltage regulator in case it was broken. I couldn't find the exact model, so I replaced the LM2940CT-12 with an LM7812, which I think is the newer 12V regulator.

 

  14341   Tue Dec 11 13:42:44 2018 KojiUpdateOMCOMC channels

FYI:

D050368 Anti-Imaging Chassis
https://dcc.ligo.org/LIGO-D050368

https://labcit.ligo.caltech.edu/~tetzel/files/equip

D050368 Adl SUS/SEI Anti-Image filter board 
S/N 100-102 Assembled by screaming circuits. Begin testing 4/3/06 
S/N xxx Mohana returned it to the shop. No S/N or traveler. Put in shop inventory 4/24/06 
S/N 103 Rev 01. Returned from Screaming circuits 7/10/06. complete except for C28, C29 
S/N 104-106 Rev 01. Returned from Screaming circuits 7/10/06. complete except for C28, C29 Needs DRV-135’s installed 
S/N 107-111 Rev 02 (32768 Hz) Back from assembly 7/14/06 
S/N 112-113 Rev 03 (65536 Hz) assembled into chassis and waiting for test 1/29/07 
S/N 114 Rev 03 (65536 Hz) assembled and ready for test 020507 


D050512 RBS Interface Chassis Power Supply Board (Just an entry. There is no file)

https://dcc.ligo.org/LIGO-D050512

RBS Interface Chassis Power Board D050512-00

https://labcit.ligo.caltech.edu/~rolf/jayfiles/drawings/D050512-00.pdf
 

 

  14342   Tue Dec 11 13:48:04 2018 aaronUpdateOMCOMC channels

Koji gave me some tips on testing this board that I wanted to write down, notes probably a bit intermingled with my thoughts. Thanks Koji, also for the DCC and equipment logging!

  • Test the power and AI boards separately with an external supply, ramping the voltage up slowly for each.
  • If it seems the AI board is actually drawing too much current, may need to check its TPs for where a problem might be
    • If it's really extensive may use an IR camera to see what elements are getting too hot
    • Testing in segments will prevent breaking more components
  • Check the regulator that I've replaced
  • The 1 Ohm resistors may have been acting as extra 1A fuses. i need to make sure the resistors I've used to replace them are rated for >1W, if this is the case.
  • Can check the resistance between +-12V and Gnd inputs on the AI board, if there is a short drawing too much current it may show up there.
  • The 7812 may be an appropriate regulator, but the input voltage may need to be somewhat higher than with the low drop regulator that was used before.
  • I want to double check the diagram on the DCC
  14354   Thu Dec 13 22:24:21 2018 aaronUpdateOMCOMC channels

I completed testing of the AI board mentioned above. In addition to the blown fuse, there were two problems:

  • A was a large drop of solder splattered on some of the ch 1 ICs, which is why we couldn't maintain any voltage. I removed the solder.
  • The +12V wire from the power board to the AI board was loose, so I removed and replaced that crimp connection

After this, I tested the TF of all channels. For the most part, I found the expected 3rd order ~7500Hz cheby with notches at ~16kHz and 32kHz. However, some of the channels had shallower or deeper notches. By ~32kHz, I was below the resolution on the spectrum analyzer. Perhaps I just have nonideal settings? I'll attach a few representative examples.

I reinstalled the chassis at 1X2, but haven't connected power.

 

  86   Fri Nov 9 00:01:24 2007 waldmanOmnistructureOMCOMC mechanical resonances (Tap tap tappy tap)
[Pinkesh, Aidan, Sam]

We did a tap-tap-tappy-tap test of the OMC to try to find its resonances. We looked at some combination of the PDH error signal and the DCPD signal in a couple of different noise configurations. The data included below shows tapping of the major tombstone objects as well the breadboard. I don't see any strong evidence of resonances below the very sharp resonance at 1300 Hz (which I interpret as the diving board mode of the breadboard). If I get free, I 'll post some plots of the different breadboard resonances you can excite by tapping in different places.

(The "normalized" tapping response is abs(tap - reference)./reference.)
Attachment 1: Fig1.png
Fig1.png
Attachment 2: Fig2.png
Fig2.png
Attachment 3: Fig4.png
Fig4.png
Attachment 4: Fig2.pdf
Fig2.pdf
Attachment 5: Fig1.pdf
Fig1.pdf
Attachment 6: Fig4.pdf
Fig4.pdf
Attachment 7: ResonanceData.zip
  14055   Thu Jul 12 11:13:39 2018 gautamUpdateGeneralOMC revival

Aaron and I are going to do the checkout of the OMC electronics outside vacuum today. At some point, we will also want to run a c1omc model to integrate with rtcds. Barring objections, I will set up this model on one of the spare cores on the physical machine c1ioo tomorrow.

  14056   Thu Jul 12 12:26:39 2018 aaronUpdateGeneralOMC revival

We found a diagram describing the DC Readout wiring scheme on the wiki page for DC readout (THIS DIAGRAM LIED TO US). The wiring scheme is in D060096 on the old DCC.

Following this scheme for the OMC PZT Driver, we measured the capacitance across pins 1 and 14 on the driver end of the cable nominally going to the PZT (so we measured the capacitance of the cable and PZT) at 0.5nF. Gautam thought this seemed a bit low, and indeed a back of the envelope calculation says that the cable capacitance is enough to explain this entire capacitance.

Gautam has gone in to open up the HV driver box and check that the pinout diagram was correct. We could identify the PZT from Gautam's photos from vent 79, but couldn't tell if the wires were connected, so this may be something to check during the vent.

UPDATE:

Turns out the output was pins 13 and 25, we measured the capacitance again and got 209nF, which makes a lot more sense.

  14163   Tue Aug 14 23:14:24 2018 aaronUpdateOMCOMC scanning/aligning script

I made a script to scan the OMC length at each setpoint for the two TTs steering into the OMC. It is currently located on nodus at /users/aaron/OMC/scripts/OMC_lockScan.py.

I haven't tested it and used some ez.write syntax that I hadn't used before, so I'll have to double check it.

My other qualm is that I start with all PZTs set at 0, and step around alternative +/- values on each PZT at the same magnitude (for example, at some value of PZT1_PIT, PZT1_YAW, PZT2_PIT, I'll scan PZT2_YAW=1, then PZT2_YAW=-1, then PZT2_YAW=2). If there's strong hysteresis in the PZTs, this might be a problem.

  14312   Tue Nov 20 20:33:11 2018 aaronUpdateOMCOMC scanning/aligning script

I finished running the cabling for the OMC, which involved running 7x 50ft DB9 cables from the OMC_NORTH rack to the 1X2 rack, laying cables over others on the tray. I tried not to move other cables to the extent I could, and I didn't run the new cables under any old cables. I attach a sketch diagram of where these cables are going, not inclusive of the entire DAC/ADC signal path.

I also had to open up the AA board (D050387, D050374), because it had an IPC connector rather than the DB37 that I needed to connect. The DAC sends signals to a breakout board that is in use (D080302) and had a DB37 output free (though note this carries only 4 DAC channels). I opened up the AA board and it had two IPC 40s connected to an adapter to the final IPC 70 output. I replaced the IPC40 connectors with DB37 breakouts, and made a new slot (I couldn't find a DB37 punch, so this is not great...) on the front panel for one of them, so I can attach it to the breakout board.

I noticed there were many unused wires, so I had to confirm that I had the wiring correct (still haven't confirmed by driving the channels, but will do). There was no DCC for D080302, but I grabbed the diagrams for the whitening boards it was connected to (D020432) and for the AA board I was opening up as well as checked out elog 8814, and I think I got it. I'll confirm this manually and make a diagram if it's not fake news.

Attachment 1: pathwaysketch.pdf
pathwaysketch.pdf
Attachment 2: IMG_0094.JPG
IMG_0094.JPG
Attachment 3: IMG_0097.JPG
IMG_0097.JPG
  14317   Mon Nov 26 15:43:16 2018 aaronUpdateOMCOMC scanning/aligning script

I've started testing the OMC channels I'll use.

I needed to update the model, because I was getting "Unable to setup testpoint" errors for the DAC channels that I had created earlier, and didn't have any ADC channels yet defined. I attach a screenshot of the new model. I ran

rtcds make c1omc
rtcds install c1omc
rtcds start c1omc.
 
without errors.
Attachment 1: c1omc.png
c1omc.png
  2277   Mon Nov 16 17:35:59 2009 kiwamuUpdateLSCOMC-LSC timing get synchronized !

An interesting thing was happened in the OMC-LSC timing clock.

Right now the clock of the OMC and the LSC are completely synchronized.

 The trend data is shown below. At the first two measurements (Oct.27 and Nov.1),  LSC had constant retarded time of 3Ts (~92usec.).

The last measurement, on Nov.15, number of shifts goes to zero, this means there are no retarded time.

Also the variance between the two signal gets zero, so I conclude the OMC and the LSC are now completely synchronized.

The measurement on Nov.8 is somehow meaningless, I guess the measurement did not run correctly by an influence from megatron(?)

 

OMC-LSC.png

 

  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
  14   Thu Oct 25 17:52:45 2007 waldmanOtherOMCOMCs with QPDs
[Rich, Chub, Pinkesh, Sam]

Yesterday we got the QPD, OTAS, and PZT cabling harness integrated with the OMC. We found a few things out, not all of them good. The QPDs went on no problem and could be fairly well aligned by hand. We "aligned" them by looking at all four channels of the QPD on the scope and seeing that there is signal. Since the beam is omega = 0.5 mm, this is a reasonable adjustment. We then connected the OTAS connector to the OTAS and found that the heater on the OTAS was bonded on about 30 degrees rotated from its intended position. This rotated the connector into the beam and caused a visible amount of scattering. This wasn't really a disaster until I removed the connector from the heater and broke the heater off of the aluminum parts of the OTAS. Two steps backwards, one step forward. After the OMC, OMC-SUS integration test we will re-bond the heater to the aluminum using VacSeal. In the meantime, the OMC has been moved to Bridge 056 for integration with the OMC-SUS. More on that as we make progress.
  11731   Wed Nov 4 16:12:07 2015 ericqUpdateCDSOPTIMUS

There is a new machine on the martian network: 32 cores and 128GB of RAM. Probably this is more useful for intensive number crunching in MATLAB or whatever as opposed to IFO control. I've set up some of the LIGO analysis tools on it as well. 

A successor to Megatron, I dub it: OPTIMUS

  294   Sat Feb 2 14:11:27 2008 JohnSummaryComputersOPTLEVmaster screen
I changed the layout of the optlev master screen. The old version is /cvs/cds/caltech/medm/old/C1ASC_OPTLEVmaster080202.adl
  6375   Wed Mar 7 16:32:09 2012 keikoUpdateLSCOSA

 I swap an OSA at PSL and OSA at REFL. It was because the PSL-OSA had a better resolution, so we place this better one at REFL. The ND filter (ND3) which was on the way to REFL OSA was replaced by two BSs, because it was producing dirty multiple spots after transmitting.

  6390   Fri Mar 9 10:44:57 2012 steveUpdateRF SystemOSA

Optical spectrum analyzers like the Attachment made by Coherent , Meles Griot- CVI and Spectral Product are all discontinued.

The 40m have Coherent models C240 analyzer with controller C251 Their Finesse measured in 2004: sn205408  F302,  sn205409  F396,

Jenne borrowed Jan's Meles Griot model 13SAE006, Peter King has the same model. FSR 300 MHZ, finnees 200 minimum

Attachment 1: OSA.pdf
OSA.pdf
ELOG V3.1.3-