40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m elog, Page 168 of 357  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
  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
Attachment 2: C1SUS_SRM_XYCOM1.png
Attachment 3: 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


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.


  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.

  17720   Thu Jul 27 00:29:13 2023 ReubenUpdateALSOLTFS of digital controller

The OLTFS of AUX locking system when locked with the PDH box, and Moku:Go and Moku:Pro running a similar filter as that of the PDH box. The Moku:Go for some reason seems to have a very low UGF (~10.8kHz) compared to the Moku:Pro  (~21.4kHz), which is a bit lower than than the original UGF of the PDH box (~24.2kHz). With a better, optimal digital controller, it could be possible to get higher low frequency gain and bandwidth. Unfortunately due to time constraints and the interferometer not being available to work on for enough time, I was not able to start testing optimal controllers. 

Today, I managed to completely substitute the analog PDH box with the Moku:Pro. Earlier, I was just taking the error signal demodulated by the PDH box only. Now i can show that the Moku can source the oscillator, and using the mixer and low pass filter retrieve the error signal using the lock in amplifier instrument, and oass it onto the digitial filter instrument to lock the box. This could mean the entire PDH box can be replaced with a Moku:Pro/Moku:Go, which allows for easy modification and upgrades, with optimal controller design. Still, the lock was brief, lasted 10-15 secs, and the transmission was noisier. I could not get a noise reading yet because getting it to maintain lock  out of the box was a bit finicky,  might have to tweak some paramters of the lock in amplifier and pdh box... 
(I also tried the same with a Moku:Go, but the transmission was even more noisier.)

(Moku Pro transmission and setup)

(Moku:Go transmission)

Attachment 1: OLTF_Comparison.pdf
Attachment 5: 1.pdf
Attachment 6: 2.pdf
Attachment 7: 3.pdf
  17723   Thu Jul 27 10:43:58 2023 KojiUpdateALSOLTFS of digital controller

Wow, this is awesome. Can you plot the comparison between the measured and expected OLTFs for both (or either) Moku cases?
At low freq, the measurement of OLTFs gets difficult due to high loop suppression and the estimation will give us an idea of how the loop can be improved.

  17728   Thu Jul 27 18:21:33 2023 KojiUpdateALSOLTFS of digital controller

Here is the OLTF from the model of the system I made in Python. https://github.com/CaltechExperimentalGravity/LaserStabilization/blob/main/code/PlantSim/plant_model.py

With this model, I should be able to plug in potential optimal controllers and see how the OLTF might improve. The green line shows the OLTF of the model with the PDH box zpk values inputted into the Mokus, which in turn was eyeball fitted to the analog uPDH box frequuncy response. 

In hindsight I realise I have made a mistake that could explain the discrepancy in data between the Mokus. I forgot to account for the difference in sampling rate of either Mokus while making the SOS filter file. I used the same file, one that had the Moku:Gos sampling rate for both devices. Using the correct sampling rate could solve the large delta in phase, and minor changes made to the model for better estimation of the Mokus response.


Wow, this is awesome. Can you plot the comparison between the measured and expected OLTFs for both (or either) Moku cases?
At low freq, the measurement of OLTFs gets difficult due to high loop suppression and the estimation will give us an idea of how the loop can be improved.


Attachment 1: OLTF_Comparison2.pdf
  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
Attachment 2: greenGhosts.JPG
Attachment 3: IMG_3322.JPG
Attachment 4: IMG_3326.JPG
  17923   Thu Oct 26 18:34:58 2023 KojiSummaryGeneralOMC #1 / DCPDs / Glass Breadboard are in

[Begüm, Koji]

We brought the OMC #1 / DCPDs / a glass breadboard from the OMC lab to the 40m. They are placed on the wagon next to the staging table.

Attachment 1: PXL_20231027_011853566.MP.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.

Attachment 1: 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:


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


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


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.

  17811   Fri Aug 25 20:27:33 2023 KojiUpdateBHDOMC Interface Aligner

A bit improved the design of OMC Interface Aligner

The idea is...The OMC I/F aligner covers the OMC for aligning the kinematic mounts (3 pairs of a V-groove and a ball) on the OMC. This makes the kinematic mount of two OMCs identical.

However, the OMC kinematic mount can't be adjusted because all the fasteners of the kinematic mounts are hidden by their counterparts.
We can copy the alignment of the OMC to the aligner, but the opposite is not possible.

Attachment 1: Screenshot_2023-08-25_at_20.26.46.png
  17807   Thu Aug 24 02:54:19 2023 KojiUpdateBHDOMC Interface Aligner / BHD OFI arrangement

OMC Interface Aligner - (It's upside down...)

BHD OFI arrangement

Attachment 1: Screenshot_2023-08-24_at_02.50.23.png
Attachment 2: Screenshot_2023-08-24_at_02.51.53.png
Attachment 3: Screenshot_2023-08-24_at_02.52.32.png
  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
  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
  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
Attachment 2: 071103DitherZoom.png
Attachment 3: 071103LSCShape.png
Attachment 4: 071103DitherShape.pdf
Attachment 5: 071103DitherZoom.pdf
Attachment 6: 071103LSCShape.pdf
Attachment 7: 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
Attachment 2: 4.5to10.jpg
Attachment 3: 4.5to10.pdf
Attachment 4: 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.
  17935   Mon Oct 30 15:47:16 2023 KojiUpdateBHDOMC bond rework

[JC Koji]

We successfully applied EP30-2 on the OMC #1.

  • We brought a scale with 0.01g resolution from Yuta's desk.
  • The Black and Decker toaster oven was brought from the bake lab (it was already returned)
  • Made two AL cups for epoxy mixing
  • Brought an SS spatula from the bake lab.
  • Checked which bracket has the 50% delamination by lifting the OMC --> it was the one close to the QPDs (Attachment 1)
  • Used one of the EP30-2 tubes with an expiration date of Nov 1, 2023 (in 2 days!) (Attachment 6).
  • Disposed one push from the glue applicator tube into one of the Al cups. Then, poured 7g into the other Al cup.
  • Added 0.35g of silica bead powder.
  • Mixed -> painted a few drops on a shell of Al foil -> Bake in the oven at 200F for 15min.
  • JC and I confirmed the baked test piece was nicely cured. No stickiness. Very crisp.
  • Applied the bond on the side of the 50% delaminated bracket. (Attachments 2/3).
  • I could confirm that the glue was sucked into the gap somewhat. The action was still going. (Attachment 4).
  • Now, we proceeded to the cable bracket. JC applied the layer of glue to the two brackets.
  • Then, the cable bracket was placed -> We checked how the upper part was wet. It was very nicely done! (Attachment 5)
  • We've placed some weight on the cable bracket so it does not move. In reality, the bracket was well constrained by the four screws and had almost no play to slide. (Attachment 7)
  • Decided to resume tomorrow at 2:30PM
  • The exist particle counting: 0 count for 0.5um particle.
Attachment 1: F71528AC-6985-411F-8463-D5C0CB56D033.jpg
Attachment 2: pxl_20231030_215836571.jpg
Attachment 3: pxl_20231030_215844819.jpg
Attachment 4: pxl_20231030_220137914.jpg
Attachment 5: 9733B2DC-E88D-4B54-AE8F-108196C568C6.jpg
Attachment 6: pxl_20231030_221427003.mp.jpg
Attachment 7: pxl_20231030_220504732.jpg
Attachment 8: pxl_20231030_221410803.jpg
  17943   Tue Oct 31 21:09:15 2023 KojiUpdateBHDOMC bond rework

We came back to the OMC 24 hours later and found the bonding work yesterday went well.

We cleaned up the OMC further and then placed it on the BHD platform. Now it's ready for the optical action.

Entrance particle count 2 / Exit particle count 4 for 0.5um

(Bond inspection photos will be posted here by JC)

Attachment 1: PXL_20231031_223632753.jpg
Attachment 2: PXL_20231031_223705466.jpg
  17932   Sun Oct 29 21:09:23 2023 KojiUpdateBHDOMC cable bracket delamination

[JC, Koji]

While adjusting the kinematic mount, we noticed that the OMC cable bracket was sagging from the OMC breadboard. This happened with no specific impact given.

This was the delamination of the epoxy (EP30-2) between the glass brackets and the rectangular metal shims. (Attachments)
There was no real damage to the components.

Also, a small delamination area was found on one of the mass mounting brackets (not pictured).

# This OMC was the first manufactured OMC in 2013, installed at LLO, and taken out last year. This is not the unit to be (possibly) used at Hanford.

The EP30-2 of this era had no established procedure for proper mixing yet. We've experienced frequent delamination in the OMCs and suspension assemblies.

Now that procedures for testing epoxy mixtures in a toaster oven have been established, the frequency of such delamination has decreased.

My assessment for the repair procedure:
- Remove the remaining epoxy layer on the glass side by scrubbing with a cotton swab using acetone.
- Apply EP30-2 on the cable bracket.
- Inject EP30-2 mixture to the mass mounting bracket via capillary action.

Strictly speaking, this OMC is a loan from aLIGO, so I will contact the aLIGO team to see if they have no objections to the repair before we start the work.
In the meantime, we can prepare optics for locking the OMC.

Ed (Oct 30, 2023 8AM): The rework was approved by GariLynn and Gabriele.

Attachment 1: PXL_20231027_182848934.jpg
Attachment 2: 296D06E4-B935-4462-84E4-7FE1CCDA8204_1_105_c.jpeg
  14819   Wed Jul 31 09:41:12 2019 gautamUpdateBHDOMC cavity geometry


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.


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


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


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.


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
Attachment 2: 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
Attachment 2: 545E5512-D003-408B-9F00-55F985966A16.jpeg
Attachment 3: 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...

  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


D050368 Anti-Imaging Chassis


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)


RBS Interface Chassis Power Board D050512-00



  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.


  17972   Mon Nov 13 00:34:56 2023 KojiUpdateBHDOMC input beam alignment

The polarization and alignment of the fiber for the OMC setup were adjusted. The polarization ratio before the PBS was 50:1. Then, the P-pol was sent to the OMC via two steering mirrors.
As a result of the beam alignment, the OMC cavity is flashing with a good amount of occasional TEM00.

Fiber alignment and polarization refinement

- NPRO power ADJ was "-29". The initial fiber output was 6mW.
- The input fiber collimator and an input steering mirror were adjusted to maximize the fiber output. The output power increased to 12mW.

- Adjusted the output fiber mount to minimize the PBS reflection.
- The initial ratio of the P/S was checked. 3mW was reflected by a PBS out of 12W. (i.e. 3:1).
- Went to the PSL table and repeated 1) rotate the fiber coupler 2) maximize the input beam/coupler alignment.
- Again, adjusted the output fiber mount to minimize the PBS reflection.
- Went back to the PSL to repeat the input side adjustment.
- Determined that I could not do it better.

- Increased the NPRO power ADJ to -20, just to have more power.
  Polarization ratio was ~50:1 (Trans 43mW, Refl 0.82mW).

The beam alignment into the OMC
- Set up the steering mirrors.
- Align the input beam so that I can see the input spot on the center of the second curved mirror (CM2).
- If the alignment is perfect, the input beam should hit the center of the first cavity mirror (FM1)
- The deviation can be adjusted by the mirror/spot position on the last steering mirror.
- So: Adjust CM2 spot by the last steering mirror, Adjust FM1 spot by the penultimate steering mirror.
- This made the cavity flashing. After a bit of alignment, the TEM00 mode was visible.
- A CCD was set at the transmission of CM2

Attachment 1: IMG_2596.JPG
Attachment 2: IMG_2595.JPG
  17974   Mon Nov 13 03:14:43 2023 KojiUpdateBHDOMC input beam alignment

To Do:

  • Set up the OMC refl optical path and the refl PD
  • Set up a trans monitor PD at CM1
  • Set up a platform position marker to ensure the reproducibility
  • Moku setup:
    • Temperature sweep
    • Laser PZT sweep
    • Moku RF modulation demodulation setup for PDH locking

What we need more to make the work better/easier in/around the HEPA table:

  • Proper fiber protection
  • Proper stray beam blocks (anodized Al plates)
  • Electronics rack or shelves at the north side of the booth
  • Parts table at the south side of the booth
  • Rotate the table 180 deg and put a storage shelf beneath the table (Wire rack?)
  17991   Tue Nov 28 02:01:38 2023 KojiUpdateBHDOMC locked

The OMC was locked with Moku Pro.

Attachment 1: Electrical setup. The RF part of the REFL PD signal was fed into Moku pro, while the DC part was monitored on a scope.
Attachment 2: Servo setup. The modulation amplitude is 100mV.
Attachment 3: Image rejection LPF setup
Attachment 4: Laser PZT servo during lock acquisition
Attachment 5: Laser PZT servo for stational operation
Attachment 6: Laser Temp servo setting
Attachment 7: CCD Images during lock. The REFL is still limited by the mode mismatching component.
Attachments 8/9: The REFL locked / unlocked = 340mV/5.4V = 0.06 --> Mode Matching 94%


Attachment 1: PXL_20231128_074405281.MP.jpg
Attachment 2: Screenshot_2023-11-27_at_23.39.29.jpeg
Attachment 3: Screenshot_2023-11-27_at_23.39.37.jpeg
Attachment 4: Screenshot_2023-11-27_at_23.39.57.jpeg
Attachment 5: Screenshot_2023-11-27_at_23.39.42.jpeg
Attachment 6: Screenshot_2023-11-27_at_23.39.47.jpeg
Attachment 7: PXL_20231128_074332868.jpg
Attachment 8: PXL_20231128_074435791.MP.jpg
Attachment 9: PXL_20231128_074259495.jpg
  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
Attachment 2: Fig2.png
Attachment 3: Fig4.png
Attachment 4: Fig2.pdf
Attachment 5: Fig1.pdf
Attachment 6: Fig4.pdf
Attachment 7: ResonanceData.zip
ELOG V3.1.3-