40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 309 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  10802   Tue Dec 16 00:20:06 2014 diegoUpdateOptical LeversBS & PRM OL realignment

[Rana, Diego]

We manually realigned the BS and PRM optical levers on the optical table.

  16586   Fri Jan 14 12:01:21 2022 AnchalUpdateElectronicsBS & ITMY feedthroughs labeled and connected to Sat Amps

I labeled all the newly installed flanges and connected the in-air cables (40m/16530) to appropriate ports. These cables are connected to the CDS system on 1Y1/1Y0 racks through the satellite amplifiers. So all new optics now can be damped as soon as they are placed. We need to make more DB9 plugs for setting "Acquire" mode on the HAM-A coil drivers since our Binary input system is not ready yet. Right now, we only have 2 such plugs which means only one optic and be damped at a time.

 

  12054   Wed Mar 30 11:35:24 2016 steveUpdatesafetyBS visitor's viewport is protected with lexan

Quote:
The four horizontal viewports of arms are protected
by 3/8" thick, 8.5" OD Lexan disk of MR10 Polycarbonate.

ITMX, ETMX, ITMY and ETMY ccd cameras are not focused now.


BS visitor's viewport glass is now covered with Lexan MR10

Note:
this Lexan cover is in vertical orientation so becomes lose when the black anodized cover is removed.
It needs to be held in place

while it's housing is taken off.
  4858   Wed Jun 22 18:41:23 2011 NicoleSummarySUSBROKEN bread board circuit box and L9337 LED Current Versus Voltage Curve

NOTE: The potentiometers on the bread board circuit box (the one I have been using with the signal generator, DC power, LED displays, and pulse switches) is BROKEN!

The potential across terminals 1 and 2 (also 2&3) fluctuates wildly and there dial does not affect the potential for the second potentiometer (the one with terminals 4, 5, and 6).

This has been confirmed by Koji and Jaimie.  PS I didn't break it! >____<

 

NEVERTHELESS, using individual resistors and the 500 ohm trim resistor, I have managed to get the current versus forward voltage plot for the Hamamatsu L9337 Infared LED

LED_I_vs_V_exp_plot.png

  13118   Sat Jul 15 01:28:53 2017 jigyasaUpdateCamerasBRDF Calibrations

This evening, Gautam helped me with setting up the apparatus for calibrating the GigE for BRDF measurements.
The SP table was chosen to set up the experiment and for this reason a few things including a laser and power meter (presumably set up by Steve) had to be moved around.

We initially started by setting up the Crysta laser with its power source (Crysta #2, 150-190 mW 1064 laser) on the SP table. The Ophir power meter was used to measure the laser power. We discovered that the laser was highly unstable as its output on the power meter fluctuated (kind of periodically) between 40 and 150 mW. The beam spot on the beam card also appeared to validate this change in intensity. So we decided to use another 1064 nm laser instead.
Gautam got the LightWave NPro laser from the PSL table and set it up on the SP table and with this laser the output as measured by the same power meter was quite stable.

We manually adjusted the power to around 150 mW. This was followed by setting up the half wave plate(HWP) with the polarizing beam splitter (PBS), which was very gently and precisely done by Gautam, while explaining how to handle the optics to me.
 On first installing the PBS, we found that the beam was already quite strongly polarized as there seemed to be zero transmission but a strong reflection.
With the HWP in place, we get a control over the transmitted intensity. The reflected beam is directed to a beam dump.
I have taken down the GigE(+mount) at ETMX and wired a spare PoE injector.
We tried to interface with the camera wirelessly through the wireless network extenders but that seems to render an unstable connection to the GigE so while a single shot works okay, a continuous shot on the GigE didn’t succeed.

The GigE was connected to the Martian via Ethernet cable and images were observed using a continuous shot on the Pylon Viewer App on Paola. 

We deliberated over the need of a beam expander, but it has been omitted presently. White printer paper is currently being used to model the Lambertian scatterer. So light scattered off the paper was observed at a distance of about 40 cm from the sample.
While proceeding with the calibrations further tonight, we realized a few challenges.

While the CCD is able to observe the beam spot perfectly well, measuring the actual power with the power meter seems to be tricky. As the scattered power is quite low, we can’t actually see any spot using a beam card and hence can’t really ensure if we are capturing the entire beam spot on the active region of the power meter (placed at a distance of ~40cm from the paper) or if we are losing out on some light, all the while ensuring that the power meter and the CCD are in the same plane.

We tried to think of some ways around that, the description of which will follow. Any ideas would be greatly appreciated.

Thanks a ton for all your patience and help Gautam! :) 

More to follow.. 

  13119   Sat Jul 15 13:40:59 2017 ranaUpdateCamerasBRDF Calibrations

Power meter only needed to measure power going into the paper not out. We use the BRDF of paper to estimate the power going out given the power going in.

  13121   Sun Jul 16 11:58:36 2017 jigyasaUpdateCamerasBRDF Calibrations

 

From what I understood froom my reading, [Large-angle scattered light measurements for quantum-noise filter cavity design studies(Refer https://arxiv.org/abs/1204.2528)], we do the white paper test in order to calibrate for the radiometric response, i.e. the response of the CCD sensor to radiance.‘We convert the image counts measured by the CCD camera into a calibrated measure of scatter. To do this we measure the scattered light from a diffusing sample twice, once with the CCD camera and once with a calibrated power meter. We then compare their readings.’

But thinking about this further, if we assume that the BRDF remains unscaled and estimate the scattered power from the images, we get a calibration factor for the scattered power and the angle dependence of the scattered power!

Quote:

Power meter only needed to measure power going into the paper not out. We use the BRDF of paper to estimate the power going out given the power going in.

 

  13122   Sun Jul 16 12:09:47 2017 jigyasaUpdateCamerasBRDF Calibrations

With this idea in mind, we can now actually take images of the illuminated paper at different scattering angles, assume BRDF is the constant value of (1/pi per steradian), 

then scattered power Ps= BRDF * Pi cosθ * Ω, where Pi is the incident power, Ω is the solid angle of the camera and θ is the scattering angle at which measurement is taken. This must also equal the sum of pixel counts divided by the exposure time multiplied by some calibration factor. 

From these two equations we can obtain the calibration factor of the CCD. And for further BRDF measurements, scale the pixel count/ exposure by this calibration factor.  

Quote:

 

From what I understood froom my reading, [Large-angle scattered light measurements for quantum-noise filter cavity design studies(Refer https://arxiv.org/abs/1204.2528)], we do the white paper test in order to calibrate for the radiometric response, i.e. the response of the CCD sensor to radiance.‘We convert the image counts measured by the CCD camera into a calibrated measure of scatter. To do this we measure the scattered light from a diffusing sample twice, once with the CCD camera and once with a calibrated power meter. We then compare their readings.’

But thinking about this further, if we assume that the BRDF remains unscaled and estimate the scattered power from the images, we get a calibration factor for the scattered power and the angle dependence of the scattered power!

Quote:

Power meter only needed to measure power going into the paper not out. We use the BRDF of paper to estimate the power going out given the power going in.

 

 

  9927   Thu May 8 00:40:39 2014 ericqUpdateLSCBNC vs. 2pin LEMO for AO

 I've checked that the 2pin lemo connector that was run some time ago from the LSC rack to the MC board does indeed transmit signals. To try and evaluate its suitability I did the following:

  • Generated a 5mVpp 1.3kHz signal with an SR785 and fed that into CM board In1, all boosts off, 0dB AO gain. 
  • Both BNC and LEMO connected to CM servo out
  • One of BNC or LEMO connected to IN2 of MC servo, input gain of 30dB but disabled, OUT2 switched to AO and fed to Agilent spectrum analyzer. 
  • Terminated MC IN2 for comparison. 

No real difference was seen between the two cases. The signal peak was the same height, width. 60Hz and harmonics were of the same amplitude. Here are the spectra out to 200k, they are very similar. 

AOcablesWide.pdf

Mode cleaner was locked during this whole thing. This may interfere with the measurement, but is similar to the use case for the AO path. If ground loop / spurious noise issues keep occurring, it will be worthwhile to examine the noise of the CM and MC servo paths, inputs and outputs more carefully. 

  8016   Wed Feb 6 20:00:06 2013 ManasaUpdateElectronicsBNC cables piled up at every corner

 [Yuta, Steve, Manasa]

There are cables piled up around the access connector area which have been victims of stampedes all the time. I have heard these cables were somehow Den's responsibility. 

Now that he is not around here:

I found piled up bnc's open at one end and with no labels lying on the floor near the access connector and PSL area. Yuta, Steve and I tried to trace them and found them connected to data channels. We could not totally get rid of the pile even after almost an hour of struggle, but we tied them together and put them away on the other side of the arm where we rarely walk.

There are more piles around the access connector...we should have a next cleanup session and get rid of these orphaned cables or atleast move them to where they will not be walked on.

109393779.png

 

 

 

  2210   Mon Nov 9 12:09:10 2009 AlbertoOmnistructureEnvironmentBNC Cable Laid Down from South End to East VErtex

I laid down the floor a BNC cable from the Y End table to the BNC Chamber. The cable runs next to the east wall.

I'm leaving the cable because it can turn useful in the future.

I'm tying the end of the cable to a big threaded steel rod on the side of the BS chamber.

I've also labeled as TRY

Attachment 1: DSC_0986.JPG
DSC_0986.JPG
  7016   Tue Jul 24 02:12:14 2012 MashaUpdatePEMBLRMS, MEDM, Triangulation

Today I worked with the BLRMS channels, re-triangulated the seismometers (the STS is now on the very end of the Y-arm, while the GUR2 is on the X-arm - this GUR2 cable will need to be either extended or replaced - Jenne and I will look at parts tomorrow), and added 0.01 - 0.03 Hz and 0.03 - 0.1 Hz RMS channels (However, the MEDM files for these are not yet complete - I will finish these tomorrow) in order to be able to better see earthquakes. I also did some things for the neural network project, including beginning Simulink tutorials so that I can run my code by applying a force on a damped harmonic oscillator + white noise until it stops.

I will explain the methodology behind the new RMS filters tomorrow morning, when the seismometers have settled down and I can make coherence plots.

I'll post a better E-log tomorrow when it's not 2 in the morning.

  5835   Mon Nov 7 16:42:56 2011 JenneUpdateAdaptive FilteringBLRMS's to monitor OAF channels

I copied Mirko's PEM BLRMS block, and made it a library part.  I don't know where such things should live, so I just left it in isc/c1/models.  Probably it should move to cds/common/models.  To make the oaf compile, you have to put a link in /opt/rtcds/caltech/c1/core/branches/branch-2.1/src/epics/simLink , and point to wherever the model is living. 

I then put BLRMSs on the control signals coming into the OAF, and after the Correction filter bank in the Adapt blocks, so we can check out what we're sending to the optics.

  9744   Sun Mar 23 14:20:07 2014 ranaHowToLSCBLRMS screens

 We should make screens like this for the LSC signals, errors, ALS, etc.

Attachment 1: blrms.png
blrms.png
  12064   Tue Apr 5 14:16:34 2016 gautamUpdateCDSBLRMS for optics suspensions - library block UPDATED

As discussed in a Wednesday meeting some time ago, we don't need to be writing channels from BLRMS filter modules to frames at 16k (we suspect this is leading to the frequent daqd crashes which were seen the last time we tried setting BLRMS up for all the suspensions). EricQ pointed out to me that there conveniently exists a library block that is much better suited to our purposes, called BLRMS_2k. I've replaced all the BLRMS library blocks in the sus_single_BLRMS library block that I made with there BLRMS_2k blocks. I need to check that the filters used by the BLRMS_2k block (which reside in /opt/rtcds/userapps/release/cds/common/src/BLRMSFILTER.c) are appropriate, after which we can give setting up BLRMS for all the suspensions a second try...

  11844   Thu Dec 3 18:18:48 2015 gautamUpdateCDSBLRMS for optics suspensions - library block

In order to be consistent with the naming conventions for the new BLRMS filters, I made a library block that takes all the input signals of interest (i.e. for a generic optic, the coil signals, the local damping shadow sensors, and the Oplev Pitch and Yaw signals - so a total of 12 signals, unused ones can be grounded). The block is called "sus_single_BLRMS". Inside the block, I've put in 12 BLRMS library blocks, with each input signal going to one of them. All the 7 outputs of the BLRMS block are terminated (I got a compiling error if I did not do this). The idea is to identify the optic using this block, e.g. MC2_BLRMS. The BLRMS filters inside are called UL_COIL, UR_COIL etc, so the BLRMS channels will end up being called C1:SUS-MC2_BLRMS_UL_COIL_0p01_0p03 and so on. I tried implementing this in C1PEM, but immediately after compiling and restarting the model, I noticed some strange behaviour in the seismic rainbow STS strip in the control room - this was right after the model was restarted, before I attempted to make any changes to the C1PEM.txt file and add filters. I then manually opened up the filter bank screens for the RMS_STS1Z bandpass and lowpass filters, and saw that the filter switches were OFF - I wonder if this has something to do with these settings not being updated in the SDF tables? So I manually turned them on and cleared the filter hitsory for all 7 low pass and band pass filter banks, but the traces on the seismic striptool did not return to their nominal levels. I manually checked the filter shapes with Foton and they seem alright. Anyways, for now, I've reverted to the C1PEM model before I made any changes, and the seismic strip looks to be back at its normal level - when I recompiled and restarted the model with the changes I made removed, the STS1Z BLRMS bandpass and lowpass filters were ON by default again! I'm not sure what I'm doing wrong here, I will investigate this further. 

  11849   Fri Dec 4 18:20:36 2015 gautamUpdateCDSBLRMS for IMC setup

[ericq, gautam]

BLRMS filters have been set up for the coil outputs and shadow sensor signals. The signals are sent to the C1PEM model from C1MCS, where I use the library block mentioned in the previous elog to put the filters in place. Some preliminary observations:

  1. The entire operation seems to be computationally quite expensive - just for the 3 IMC mirrors, the average CPU time for C1PEM increased from ~50 usec (before any changes were made to C1PEM) to ~105 usec just as a result of installing 420 filter modules with no filter coefficients loaded (3 optics x 10 channels x 14 filter banks) to ~120 usec when all the BP and LP filters for the BLRMS blocks have been loaded and turned on (Attachment #1). Eric suggested that it may be computationally more efficient to do this without using the BLRMS library part - i.e. rather than having so many filter modules, do the RMS-ing using a piece of C code that essentially just implements the same SOS filters that FOTON generates, I will work on setting this up and checking if it makes a difference. The fact that just having empty filter modules in the model almost doubled the computation time suggests that this approach may help, but I have to think about how to implement some of the automatic checks that having a filter bank in place gives us, or if these are strictly necessary at all...
  2. While restarting the C1PEM model, we noticed that some of the optics were shaking - looking at the CPU timing signals for all the models on C1SUS revealed that both the C1SUS model and the C1MCS model were geting overclocked when C1PEM was killed (see the sharp spikes in the red and green traces in Attachment #2 - the Y scale in this plot is poor and doesnt put numbers to the overclocking, I will upload a better screenshot that Eric took once I find it). The cause is unknown.
  3. Yesterday, I noticed that when C1PEM was restarted, the states of the filter bank switches were not reverted to their states in the SDF tables. They are showing up as changes, but it is unclear why we have to manually revert them. I have also not yet added the states of the newly installed filters (BPs and LPs for the MC BLRMS blocks) to the SDF tables. 

Unrelated to this work: we cleaned up the correspondence between the accelerometer numbers and channels in the C1PEM model. Also, the 3 unused ADC blocks in C1PEM (ADC0, ADC1 and ADC2) are required and cannot be removed as the ADC blocks have to be numbered sequentially and the signals needed in C1PEM come from ADC3 (as we found out when we tried recompiling the model after deleting these blocks).

Attachment 1: c1pem_timing.png
c1pem_timing.png
Attachment 2: C1SUS_overclocked.png
C1SUS_overclocked.png
  7745   Mon Nov 26 18:36:17 2012 JenneUpdatePEMBLRMS back

Quote:

 I got two seismometers and one microphone back from Tara.

They are now near the Gurlap under the MC.

 I have finally plugged GUR1 back in....it is down at ETMY for now, since that's where the cable was.  BLRMS are back up on the projector.

  8764   Thu Jun 27 15:50:03 2013 JenneUpdatePEMBLRMS are going crazy

The BLRMS are totally crazy today!  I'm not sure what the story is, since it's been this way all day (so it's not an earthquake, because things eventually settle down after EQs).  It doesn't seem like anything is up with the seismometer, since the regular raw seismic time series and spectrum don't look particularly different from normal.  I'm not sure what's going on, but it's only in the mid-frequency BLRMS (30mHz to 1Hz).

Here are some 2 day plots:

 

WeirdBLRMSincrease_27June2013_rawSeis.png

WeirdBLRMSincrease_27June2013_Gur1xBLRMS.png

WeirdBLRMSincrease_27June2013_lowFreqBLRMS.png

  8773   Thu Jun 27 21:45:48 2013 ranaUpdatePEMBLRMS are going crazy

Its an increase in the microseismic peak. Don't know what its due to though.

Attachment 1: useism.pdf
useism.pdf
  6523   Wed Apr 11 22:48:39 2012 ranaUpdateEnvironmentBLRMS

seis_blrms.png

  7183   Tue Aug 14 21:01:51 2012 ranaUpdatePEMBLRMS

Screenshot-Untitled_Window.png

I fixed up the seismic.stp file for the StripTool display:

  1. All BLRMS channels now have a y-axis range of 3 decades. So they all are displaying the same relative changes.
  2. So the 0.01-0.1 Hz band which is all over the place is real, sort of. Masha says that it is due to the seismometer signal being dominated by noise below 0.1 Hz. She is going to fix this somehow.
  3. I changed the samping time from 1 sec. to 10 sec. to make the traces less fuzzy.
  4. We (Masha / Liz) should harmonize the colors of this file with what's on the summary pages.
  5567   Wed Sep 28 18:39:50 2011 MirkoUpdatePEMBLRM seismic channels in c1pem

[Mirko,Jenne]

Created 5-band BLRMS for seismometer data (Gur1, Gur2 and STS1 each in x,y,z respectively) and accelerometer 1 through 6.

Bands are:
0.1Hz-0.3Hz
0.3Hz-1Hz
1Hz-3Hz
3Hz-10Hz
10Hz-30Hz
each with a fitting 4th order butterworth bandpass.

Data is recorded at 256Hz as e.g. C1:PEM-ACC1_RMS_RMS_0p3_1_OUT_DQ. For the 75 channels we have that corresponds to the data rate of just 1.2 16kHz channels.

c1pem execution time increased fom 6-7us to 15-16us out of 480us available.

  15248   Wed Mar 4 12:25:11 2020 gautamUpdateCDSBIO1 on c1psl is dead

There was some work done on the Acro crate this morning. Unclear if this is independent, but I found that the IMC servo board IN1 slider doesn't respond anymore, even though I had tested it and verified it to be working. Patient debugging showed that BIO1 (and only that acromag unit with the static IP 192.168.114.61) doesn't show up on the subnet in c1psl. Hopefully it's just a loose network cable, if not we will switch out the unit in the afternoon. 

Jon is going to make a python script which iteratively pings all devices on the subnet and we will put this info on an MEDM screen to catch this kind of silent failure.

  16188   Sun Jun 6 16:33:47 2021 JonUpdateCDSBI channels on c1auxey

There is still an open issue with the BI channels not read by EPICS. They can still be read by the Windows machine though.

I looked into the issue that Yehonathan reported with the BI channels. I found the problem was with the .cmd file which sets up the Modbus interfacing of the Acromags to EPICS (/cvs/cds/caltech/target/c1auxey1/ETMYaux.cmd).

The problem is that all the channels on the XT1111 unit are being configured in Modbus as output channels. While it is possible to break up the address space of a single unit, so that some subset of channels are configured as inputs and another as outputs, I think this is likely to lead to mass confusion if the setup ever has to be modified. A simpler solution (and the convention we adopted for previous systems) is just to use separate Acromag units for BI and BO signals.

Accordingly, I updated the wiring plan to include the following changes:

  • The five EnableMon BI channels are moved to a new Acromag XT1111 unit (BIO01), whose channels are configured in Modbus as inputs.
  • One new DB37M connector is added for the 11 spare BI channels on BIO01.
  • The five channels freed up on the existing XT1111 (BIO00) are wired to the existing connector for spare BO channels.

So, one more Acromag XT1111 needs to be added to the c1auxey chassis, with the wiring changes as noted above. I have already updated the .cmd and EPICS database files in /cvs/cds/caltech/target/c1auxey1 to reflect these changes.

  16189   Mon Jun 7 13:14:20 2021 YehonathanUpdateCDSBI channels on c1auxey

I added a new XT1111 Acromag module to the c1auxey chassis. I sanitized and configured it according to the slow machines wiki instructions.

Since all the spare BIOs fit one DB37 connector I didn't add another feedthrough and combined them all on one and the same DB37 connector. This was possible because all the RTNs of the BIOs are tied to the chassis ground and therefore need only one connection. I changed the wiring spreadsheet accordingly.

I did a lot of rewirings and also cut short several long wires that were protruding from the chassis. I tested all the wires from the feedthroughs to the Acromag channels and fixed some wiring mistakes.

Tomorrow I will test the BIs using EPICs.

  16193   Tue Jun 8 11:54:39 2021 YehonathanUpdateCDSBI channels on c1auxey

I tested the digital inputs the following way: I connected a DB9 breakout to DB9M-5 and DB9M-6 where digital inputs are hosted. I shorted the channel under test to GND to turn it on.

I observed the channels turn from Disabled to Enabled using caget when I shorted the channel to GND and from Enabled to Disabled when I disconnected them.

I did this for all the digital inputs and they all passed the test.

I am still waiting for the other isolator to wire the rest of the digital outputs.

Next, I believe we should take some noise spectra of the Y end before we do the installation.

Quote:

Tomorrow I will test the BIs using EPICs.

 

  16849   Thu May 12 20:11:18 2022 AnchalUpdateBHDBHDBS Output beams steered out to ITMY table

I successfully steered out the two output beams from BHD BS to ITMY table today. This required significant changes on the table, but I was able to bring back the table to balance coarsely and then recover YARM flashing with fine tuning of ITMY.

  • The counterweights were kept at the North end of the table which was in way of one of the output beams of BHD.
  • So I saved the level meter positions in my head and removed those counterweights.
  • I also needed to remove the cable post for ITMY and SRM that was in the center of the table.
  • I installed a new cable post which is just for SRM and is behind AS2. ITMY's cable post is next to it on the other edge of the table. This is to ensure that BHD board can come in later without disturbing existing layout.
  • I got 3 Y1-45P and 1 Y1-0 mirror. The Y1-0 mirror was not installed on a mount, so I removed an older optic which was unlabeled and put this on it's mount.
  • Note that I noticed that some light (significant enough to be visible on my card) is leaking out of the 45P mirrors. We need to make sure we aren't loosing too much power due to this.
  • Both beams are steered through the center of the window, they are separating outside and not clipping on any of the existing optics outside. (See attachment 1, the red beam in the center is the ITMY oplev input beam and the two IR beams are the outputs from BHD BS).
  • Also note that I didn't find any LO beam while doing this work. I only used AS beam to align the path.
  • I centered the ITMY oplev at the end.

Next steps:

  • LO path needs to be tuned up and cleared off again. We need to match the beams on BHD BS as well.
  • Setup steering mirrors and photodiodes on the outside table on ITMY.
Attachment 1: signal-2022-05-12-201844.jpeg
signal-2022-05-12-201844.jpeg
  15334   Fri May 15 09:18:04 2020 JonUpdateBHDBHD telescope designs accounting for ASC

Hang and I have reanalyzed the BHD telescope designs, with the goal of identifying sufficiently non-degenerate locations for ASC actuation. Given the limited room to reposition optics and the requirement to remain insensitive to small positioning errors, we conclude it is not possible put sufficient Gouy phase separation between the AS1/AS2 and LO1/LO2 locations. However, we can make the current layout work if we instead actuate AS1/AS4 and LO1/LO4. This would require actuating one optic on the breadboard for each relay path. If possible, we believe this offers the simplest solution (i.e., least modification to the current layout).

LO Telescope Design (Attachment 1)

Radius of curvatures:

  • LO1: +10 m
  • LO2: flat
  • LO3: +15 m
  • LO4: flat

AS Telescope Design (Attachment 2)

Radius of curvatures:

  • AS1: +3 m
  • AS2: flat
  • AS3: -1 m
  • AS4: flat
Attachment 1: LOpath.pdf
LOpath.pdf
Attachment 2: ASpath.pdf
ASpath.pdf
  15151   Fri Jan 24 13:56:21 2020 JonUpdateBHDBHD optics specifications

I've started a spreadsheet for the BHD optics specifications and populated it with my best initial guesses. There are a few open questions we still need to resolve, mostly related to mode-matching:

  • PR2 replacement: What transmission do we need for a ~100 mW pickoff? Also, do we want to keep the current curvature of -700 m?
  • LO mode-matching telescope: What are the curvatures of the two mirrors?
  • Lenses: We have six of them in the current layout. What FLs do we need?

The spreadsheet is editable by anyone. If you can contribute any information, please do!

  15305   Thu Apr 16 21:13:20 2020 JonUpdateBHDBHD optics specifications

Summary

I've generated specifications for the new BHD optics. This includes the suspended relay mirrors as well as the breadboard optics (but not the OMCs).

To design the mode-matching telescopes, I updated the BHD mode-matching scripts to reflect Koji's draft layout (Dec. 2019) and used A La Mode to optimize ROCs and positions. Of the relay optics, only a few have an AOI small enough for curvature (astigmatism) and most of those do not have much room to move. This reduced the optimization considerably.

These ROCs should be viewed as a first approximation. Many of the distances I had to eyeball from Koji's drawings. I also used the Gaussian PRC/SRC modes from the current IFO, even though the recycling cavities will both slightly change. I set up a running list of items like these that we still need to resolve in the BHD README.

Optics Specifications

At a glance, all the specifications can be seen in the optics summary spreadsheet.

LO Telescope Design

The LO beam originates from the PR2 transmission (POP), near ITMX. It is relayed to the BHD beamsplitter (and mode-matched to the OMCs) via the following optical sequence:

  • LM1 (ROC = +10 m, AOI 3°)
  • LM2 (Flat, AOI  45°)
  • MMT1 (Flat, AOI  5°)
  • MMT2 (ROC = +3.5 m, AOI  5°)

The resulting beam profile is shown in Attachment 1.

AS Telescope Design

The AS beam is relayed from the SRM to the BHD beamsplitter (and mode-matched to the OMCs) via the following sequence:

  • AS1 (ROC = +1.5 m, AOI  3°)
  • AS2 (Flat, AOI  45°)
  • Lens (FL = -125 mm)

A lens is used because there is not enough room on the BHD breadboard for a pair of (low-AOI) telescope mirrors, like there is in the LO path. The resulting beam profile is shown in Attachment 2.

Attachment 1: LO_Beam_Calc-v1.pdf
LO_Beam_Calc-v1.pdf
Attachment 2: AS_Beam_Calc-v1.pdf
AS_Beam_Calc-v1.pdf
  15339   Wed May 20 18:45:22 2020 HangUpdateBHDBHD mode-matching study--corner plot & adjustment requirement

As Rana suggested, we present the scattering plot of the AS path mode matching for various variables. The plot is for the AS path, Plan 2 (whose params we summarize at the end of this entry).

In the corner plot, we color-coded each realization according to the mode matching. We use (purple, olive, grey) for (MM>0.99, 0.98<MM<=0.99, MM<=0.98), respectively. From the plot, we can see that it is most sensitive to the RoC of AS1. The plot also shows that we can compensate for some of the MM errors if we adjust the distance between AS1-AS3 (note that AS2 is a flat mirror). The telescope is quite robust to other errors.

The compensation requirement is further shown in the second plot. To correct for the 1% RoC error of AS1, we typically need to adjust AS1-AS3 distance by ~ 1 cm (if we want to go back to MM=1; the window for >0.99 MM spans also about 1 cm). This should be doable because the nominal distance between AS1-AS3 is 115 cm. 

The story for plan1 is similar and thus not shown here. 

==============================================================

AS path plan2 nominal params:

label     z (m)     type             parameters  
-----     -----     ----             ----------  
SRMAR          0    flat mirror      none:     
AS1       0.7192    curved mirror    ROC: 2.5000 
AS2       1.2597    flat mirror      none:     
AS3       1.8658    curved mirror    ROC: -0.5000
AS4       2.5822    curved mirror    ROC: 0.6000  
OMCBS1    3.3271    flat mirror      none:   
Attachment 1: AS_MM_scat2.pdf
AS_MM_scat2.pdf
Attachment 2: AS_MM_adj2.pdf
AS_MM_adj2.pdf
  15336   Mon May 18 18:00:16 2020 HangUpdateBHDBHD mode-matching study

[Jon, Tega, Hang]

We proposed a few BHD mode-matching telescope designs and then preformed a few monte-carlo experiments to see how the imperfections would change the story. We assumed a 2 mm (1-sigma) error on the location of the components and 1% (1-sigma) fractional error on the RoC of the curved mirrors. The angle of incidence has not yet been taken into account (no astigmatism at the moment but will be included in the follow-up study.)

For the LO path things are mostly fine. We can use LO1 and LO2 as the actuators (Sec. 2.2 of the note), and when errors are taken into account more than 90% of times we can still achieve 98% mode matching. The gouy phase separation between LO1 and LO2 > 34 deg for 90% of the time, which corresponds to a condition number of the sensing matrix of ~ 3. 

The situation is more tricky for the AS path. While the telescopes are usually robust against 2 or 3 mm of positional error, the 1% RoC does affect the performance quite significantly. In the note we choose two best-performing ones but still only 50% of the time they can maintain a power-overlap of > 99%. In fact, the 1% RoC error assumed should be quite optimistic... Not sure if we could achieve this in reality. 

One potential way out is to ignore the MM for the first round of BHD. Here anyway we only need to test the ISC schemes. Then in the second round when we have the whole BHD board suspended, we can then use AS1 and the BHD board as the actuators. This might be able to make things more forgiving if we don't need to shrink the AS beam very fast so that it could be separated from AS4 in gouy phase.

Attachment 1: MM.pdf
MM.pdf MM.pdf MM.pdf MM.pdf MM.pdf MM.pdf MM.pdf MM.pdf
  15337   Tue May 19 15:24:06 2020 ranaUpdateBHDBHD mode-matching study

It would be good to have a corner plot with all the distances/ RoCs. Also perhaps a Jacobian like done in this breathtaking and seminal work.

  16475   Thu Nov 18 14:29:01 2021 KojiSummaryBHDBHD invac optics / opto-mechanics

I went through the optics list (in the BHD procurement google spreadsheet) and summarized how to build them.

The red ones are what we need to purchase. Because of the strange height of the LMR mounts, the post needs to have none half-integer inch heights.

They need to be designed as the usual SS posts are not designed to be vac compatible (not because of the material but the design like screw hole venting).

We also need to check how many clean forks we have.
-> The components were ordered except for the custom posts.
 

ssome partssss
Name Optic Mount Mount OH Post Post OH Fork / Base Base OH Total Height Notes
POP_SM5  Previous POYM1 / 2" Y1-2037-0 LMR2V Thorlabs 1.36 Custom Post 4.14 SS Fork 0 5.5  
POP_SM4 New CM254-750-E03 Thorlabs LMR1V Thorlabs 0.87 Newport 9953+PLS-T238 3.88 BA1V / BA2V 0.75 5.5  
BSOL1 New 2" VIS BB2-E02 LMR2V Thorlabs 1.36 Custom Post 4.14 SS Fork 0 5.5  
ITMYOL1 New 2" VIS BB2-E02 LMR2V Thorlabs 1.36 Custom Post 4.14 SS Fork 0 5.5  
ITMYOL2 New 2" VIS BB2-E02 LMR2V Thorlabs 1.36 Custom Post 4.14 SS Fork 0 5.5  
SRMOL1 New 2" VIS BB2-E02 LMR2V Thorlabs 1.36 Custom Post 4.14 SS Fork 0 5.5  
ASL LA1779-C Thorlabs or KPX217AR.33 Newport LMR2V Thorlabs 1.36 Custom Post 4.14 SS Fork 0 5.5  
GRY_SM1 Y2-2037-0 (in hand) DLC   DLC Post   DLC Fork   5.5  
BHDBS CVI (In hand) DLC 2 DLC Post   DLC Fork   5.5 (3" post for BHD)
LO3 Lambda (in hand) POLARIS-K1-2AH Thorlabs 1 Custom Post 4.5 SS Fork 0 5.5 (3" post for BHD)
LO4 Lambda (in hand) POLARIS-K1-2AH Thorlabs 1 Custom Post 4.5 SS Fork 0 5.5 (3" post for BHD)
AS3 Lambda (in hand) POLARIS-K1-2AH Thorlabs 1 Custom Post 4.5 SS Fork 0 5.5 (3" post for BHD)
OMC1R3 Y1-1025-45P (in hand) POLARIS-K1-2AH Thorlabs 1 Custom Post 4.5 SS Fork 0 5.5 (3" post for BHD)
OMC1R4 Y1-1025-45P (in hand) POLARIS-K1-2AH Thorlabs 1 Custom Post 4.5 SS Fork 0 5.5 (3" post for BHD)
OMC2R3 Y1-1025-45P (in hand) POLARIS-K1-2AH Thorlabs 1 Custom Post 4.5 SS Fork 0 5.5 (3" post for BHD)
OMC2R4 Y1-1025-45P (in hand) POLARIS-K1-2AH Thorlabs 1 Custom Post 4.5 SS Fork 0 5.5 (3" post for BHD)
                   
OMC1R1 Y1-1025-45P (in hand) LMR1V Thorlabs 0.87 Custom Post 4.63 SS Fork 0 5.5 (3.13" post for BHD)
OMC2R1 NB1-K14 Thorlabs LMR1V Thorlabs 0.87 Custom Post 4.63 SS Fork 0 5.5 (3.13" post for BHD)

 

  15295   Fri Apr 3 13:40:07 2020 JonUpdateBHDBHD front-end complication

I wanted to pass along a complication pointed out by K. Thorne re: our plan to use Gen1 (old) Dolphin IPC cards in the new real-time machines: c1bhd, c1sus2. The implication is that we may be forced to install a very old OS (e.g., Debian 8) for compatibility with the IPC card driver, which could lead to other complications like an incompatibility with the modern network interface.

Hardware is easy - you will also need a DX switch and the cables

As for the driver - the last update (version 4.4.5) was in 2016.  The notes on it say valid for Linux kernel 2.6 to 3.x.  This implies that it will not work with Linux kernel 4.x and greater

So - Gentoo with 3.0 kernel OK, SL7 (kernel 3.10)  - OK,   Debian 8 (kernel 3.16) - OK   

But Debian 9 (kernel 4.9),Debian 10 (kernel 4.19) - NOT OK

We have Gentoo with kernel 3.0  boot server, etc. [used in L1,H1 production right now, but not much longer] The hard part here will be making sure we have network drivers for the SuperMicro 5018-MR.

CDS was never able to get real-time builds to work well on Linux kernels from 3.2 on up until we got to Debian 9. This is not to say that the tricks and stripped-down RCG we found worked for real-time on Debian 9 and 10 won’t work on, say, Debian 8.  But we have not tried.

I have a query out to Dolphin asking:

  1. Have they done any testing of these old drivers on Linux kernel 4.x (e.g., Debian 9/10)?
  2. Is there any way to buy modern IPC cards for the two new machines and interface them with our existing Gen1 network?

I'll add more info if I hear back from them.

  15299   Tue Apr 7 10:56:39 2020 JonUpdateBHDBHD front-end complication
Quote:

I have a query out to Dolphin asking:

  1. Have they done any testing of these old drivers on Linux kernel 4.x (e.g., Debian 9/10)?
  2. Is there any way to buy modern IPC cards for the two new machines and interface them with our existing Gen1 network?

Answers from Dolphin:

  1. No, and kernel 4.x (modern Linux) definitely will not work with the Gen1 cards.
  2. No, cards using different PCIe chipsets cannot be mixed.

Since upgrading every front end is out of the question, our only option is to install an old OS (Linux kernel < 3.x) on the two new machines. Based on Keith's advice, I think we should go with Debian 8. (Link to Keith's Debian 8 instructions.)

  17067   Tue Aug 9 15:33:12 2022 yutaUpdateBHDBHD fringe contrast improved from 43% to 74%

[Anchal, Yehonathan, Yuta]

We did the constrast measurement with the method same as 40m/17020.
Contrast between ITM single bounce and LO beam increased to 74% (we had 43% before unclipping LO beam in 40m/17056).
From equations in 40m/17041 and measured ITM sigle bounce power (93 or 138 counts @ BHD DCPD) and LO power (130 or 124 counts @ BHD DCPD) from 40m/17056,  expected visibility for perfectly mode-matched case is 99%.
Measured constrast of 74% indicate mode-matching of 56%.

Both arms locked, MICH fringe (20% percentile)
Contrast measured by C1:LSC-ASDC_OUT is 80.66 +/- 0.20 %
Contrast measured by C1:LSC-POPDC_OUT is 92.27 +/- 0.66 %
Contrast measured by C1:LSC-REFLDC_OUT is 89.59 +/- 0.84 %
Contrast measured by all is 87.51 +/- 1.69 %

Both arms misaligned, MICH fringe (20% percentile)
Contrast measured by C1:LSC-ASDC_OUT is 82.50 +/- 0.61 %
Contrast measured by C1:LSC-POPDC_OUT is 94.18 +/- 0.26 %
Contrast measured by C1:LSC-REFLDC_OUT is 92.78 +/- 0.19 %
Contrast measured by all is 89.82 +/- 1.75 %

ITMX-LO fringe (40% percentile)
Contrast measured by C1:HPC-DCPD_A_OUT is 73.93 +/- 1.52 %
Contrast measured by C1:HPC-DCPD_B_OUT is 73.56 +/- 1.22 %
Contrast measured by all is 73.74 +/- 0.98 %

ITMY-LO fringe (40% percentile)
Contrast measured by C1:HPC-DCPD_A_OUT is 73.45 +/- 0.61 %
Contrast measured by C1:HPC-DCPD_B_OUT is 75.27 +/- 0.50 %
Contrast measured by all is 74.36 +/- 0.54 %

Attachment 1: HPC-DCPD_B_OUT_1344118517_ITMY-LO.png
HPC-DCPD_B_OUT_1344118517_ITMY-LO.png
Attachment 2: HPC-DCPD_A_OUT_1344118517_ITMY-LO.png
HPC-DCPD_A_OUT_1344118517_ITMY-LO.png
Attachment 3: HPC-DCPD_B_OUT_1344118318_ITMX-LO.png
HPC-DCPD_B_OUT_1344118318_ITMX-LO.png
Attachment 4: HPC-DCPD_A_OUT_1344118318_ITMX-LO.png
HPC-DCPD_A_OUT_1344118318_ITMX-LO.png
  17068   Tue Aug 9 15:50:22 2022 KojiUpdateBHDBHD fringe contrast improved from 43% to 74%

For both 40m/17020 and 40m/17024, what does the contrast mean if the numbers are leaking out to ~-100cnt?
Also how much is it if you convert this contrast into the mode matching?

  17056   Wed Aug 3 16:00:51 2022 yutaUpdateBHDBHD fringe aligned with reduced LO and AS beam clipping

Last week, we could find an alignment which realizes LO beam and AS beam both unclipped, but it was not consistent with an alignment which realize BHD fringe (40m/17046).
Today, we tweaked the alignment of SR2, AS1, AS4 to have BHD fringe with reduced LO and AS beam clipping.
AS beams on AP table and BHD both still look clipped, but much better now.
Ideally, SR2 and AS1 will unclip AS beam, and LO1, LO2, AS4 would make BHD fringe, but it is hard right now since LO beam seem to have little room and LO2 have little actuation range.
BHD optics on ITMY table, including camera, and AS55/ASDC were realigned after the aglinment work (Note that DCPD_A path have a pick-off for camera path, and this pick-off mirror have quite significant incident angle dependence of R/T ratio).

Current alignment scheme:
Current alignment scheme I figured out is the following.
 - Check Y green. If it is transmitted at good spot on GTRY camera, Yarm is OK. If not, tweak ITMY/ETMY. alignment.
 - Mis-align AS4, align TT1, TT2, LO1 to have DCPD_A_OUT of ~130 and DCPD_B_OUT of ~125.
 - Align PR3, PR2 to maximize TRY_OUT to ~1.05.
 - Tweak ITMY/ETMY if the beam spot on them are not good.
 - Align BS, ITMX to have good MICH fringe and TRX_OUT to ~1.1.
 - Tweak ITMX/ETMX if the beam spot on them are not good.
 - Misalign ETMY, ETMX, ITMY to have LO-ITMX fringe in BHD DCPDs, and align AS beam with SR2 and AS4 differentially, with ratio of AS4/SR2=3.6.

DC PD values in various configurations:
Both arms locked with POX/POY, MICH free, PRM/SRM misaligned

                          Mean     Max      Min
C1:IOO-MC_TRANS_SUM :     14088.57 13947.52 14167.04
C1:LSC-ASDC_OUT16 :           0.16    -0.02     0.34
C1:LSC-POPDC_OUT16 :        369.34   -74.88   854.34
C1:LSC-REFLDC_OUT16 :         0.03    -0.00     0.06
C1:LSC-TRY_OUT16 :            1.00     0.95     1.04
C1:LSC-TRX_OUT16 :            1.07     1.04     1.08

Only LO beam to BHD DCPDs
                          Mean     Max      Min
C1:IOO-MC_TRANS_SUM :     14121.32 14057.71 14159.38
C1:HPC-DCPD_A_OUT16 :       129.80   128.37   130.68 (Consistent with, 40m/17046. Power as expected within 20%. Squashed shape)
C1:HPC-DCPD_B_OUT16 :       123.42   121.92   124.48

ITMX single bounce (ITMY, ETMX, ETMY, PRM, SRM, LO misalgined)
                          Mean     Max      Min
C1:IOO-MC_TRANS_SUM :     14105.13 14000.89 14171.91
C1:HPC-DCPD_A_OUT16 :        92.54    91.45    93.30 (Consistent with 40m/17040, Power as expected within 40%. Clipped to the left in camera)
C1:HPC-DCPD_B_OUT16 :       137.70   136.55   138.53 (Note that DCPD_A/B ratio is different from LO, due to BHD BS R/T unbalance; 40m/17044)
C1:LSC-ASDC_OUT16 :           0.10     0.09     0.10 (Power as expected 40m/16952. Clipped to the right in camera)
C1:LSC-POPDC_OUT16 :        309.19   288.93   327.10 (Power as expected within 30% 40m/17042.)
C1:LSC-REFLDC_OUT16 :         0.02     0.01     0.02

ITMY single bounce (ITMX, ETMX, ETMY, PRM, SRM, LO misalgined)
                          Mean     Max      Min
C1:IOO-MC_TRANS_SUM :     14112.09 14025.37 14154.51
C1:HPC-DCPD_A_OUT16 :        92.58    92.01    93.26
C1:HPC-DCPD_B_OUT16 :       137.68   136.81   138.27
C1:LSC-ASDC_OUT16 :           0.10     0.09     0.10
C1:LSC-POPDC_OUT16 :        308.48   290.49   319.73
C1:LSC-REFLDC_OUT16 :         0.02     0.01     0.02

MICH fringe only (ETMX, ETMY, PRM, SRM, LO misalgined)
                          Mean     Max      Min
C1:IOO-MC_TRANS_SUM :     14090.34 13979.15 14143.86
C1:HPC-DCPD_A_OUT16 :       325.60    91.92   714.57
C1:HPC-DCPD_B_OUT16 :       400.27    18.37   762.57
C1:LSC-ASDC_OUT16 :           0.19    -0.05     0.41
C1:LSC-POPDC_OUT16 :        595.66  -119.21  1334.11
C1:LSC-REFLDC_OUT16 :         0.03    -0.01     0.07

LO-ITMX fringe only (ITMY, ETMX, ETMY, PRM, SRM misalgined)
                          Mean     Max      Min
C1:IOO-MC_TRANS_SUM :     14062.58 13968.05 14113.67
C1:HPC-DCPD_A_OUT16 :       224.31    89.57   371.66
C1:HPC-DCPD_B_OUT16 :       259.74    85.37   421.86


Next:
 - Measure contrast (40m/17020) and estimate mode-matching of LO-AS again (40m/17041)
 - Now that we have better LO-AS fringe, lock LO phase in MICH (40m/17037)
 - Now that Dolphin issue was fixed, try double-demodulation to lock LO phase

Attachment 1: Screenshot_2022-08-03_15-46-36_BHDfringeAlmostUnclipped.png
Screenshot_2022-08-03_15-46-36_BHDfringeAlmostUnclipped.png
  15284   Thu Mar 26 17:41:18 2020 JonOmnistructureBHDBHD docs compilation

Since there has been a proliferation of BHD Google docs recently, I've linked them all from the BHD wiki page. Let's continue adding any new docs to this central list.

  16880   Fri May 27 17:45:53 2022 yutaConfigurationBHDBHD camera installed, GRY aligned

[JC, Paco, Yuta]

After the IFO recovery (elog 40m/16881), we installed an analog camera for BHD fringe using a BNC cable for old SRMF camera so that we can see it from the control room.
We also aligned AS-LO using LO1,LO2 and AS4.
We then aligned GRY injection to get maximum GTRY.

Maximum TEM00s right now are
 C1:SUS-ETMX_TRX_OUT_DQ ~0.1
 C1:SUS-ETMY_TRY_OUT_DQ ~0.05
 C1:ALS-TRX_OUT_DQ ~0.20
 C1:ALS-TRY_OUT_DQ ~0.18

  15540   Wed Aug 26 00:52:55 2020 gautamUpdateBHDBHD activities

Listing some talking points from the last week of activity here.

  1. LO delivery fiber cable may be damaged.
    • The throughput itself doesn't suggest any problems, I get almost all the light I put in out the other end.
    • However, even when I slightly move the fiber, I see huge amplitude fluctuations in the DCPD readouts. This shouldn't be the case, particularly if the light is well matched to one of the special axes of the PM fiber. I checked with a PBS at the output that this is indeed the case, so something else must be funky?
    • In any case, I don't think it's a great idea to use this 70m long fiber for bringing the light from the PSL table to the adjacent AP table. Chub has ordered a 10m patch cable.
    • I was a bit too hasty this morning, thinking we had a patch cable in hand, and so I removed the fiber from the AP table. So right now, the LO beam doesn't make it to the BHD setup. Depending on the lead time for the new patch cable, I may or may not resurrect this old setup.
    • I have also located some foam and rigid plastic tubing which I think will help in isolating the fiber from environmental length(phase) modulation due to acoustic pickup.
  2. BHD commissioning activities
    • Basically, I've been trying to use the Single Bounce ITM reflection/ Michelson / PRMI with carrier locked to get some intuition about the BHD setup. These states are easily prepared, and much easier to understand than the full IFO for these first attempts.
    • One concern I have is the angular stability (or lack thereof). When the PRMI is locked, the DC light level on each DCPD fluctuates between ~0 (which is what it should be), up to ~30 cts (~85uW).
    • Using the empirically determined attenuation factor between the DCPDs and the dark port of the beamsplitter, I estimate the power can be as high as 20mW. This is a huge number, considering the input to the interferometer is ~800mW. I assume that all the light is at the carrier frequency, since the PRC should reject all the sideband light in this configuration. In any case, the total amount of sideband light is ~20mW, and the carrier stays resonant in the PRC even when there are these large ASDC excursions, so I think it's a reasonable assumption that the light is at the carrier frequency. Moreover, looking at the camera, one can see a clear TEM10/01 profile, indicative of imperfect destructive interference at the beamsplitter due to beam axis misalignment.
    • The effect of such excursions on the BHD readout hasn't yet been quantified (by me at least), but I think it may be hampering my attempts to dither the homodyne phase to estimate the LO phase noise.
  3. High voltage coil driver project - see thread for updates.
  4. Trek HV driver has arrived.
    • I haven't opened the box yet, but basically, what this means is that I can dither the mirror intended for homodyne phase control in a reasonable way.
    • Previously, I was using the OMC HV driver to drive the PZTs - but this dither signal path has a 2kHz high pass filter (since the OMC length dither is a kHz dither). I didn't want to futz around with the electronics, particularly since the unit was verified to be working.
    • So the plan now would be to drive the input of the Trek with a DAC output (an appropriate AI chassis has been prepared to interface with the CDS system).
    • Hopefully, there's enough DAC dynamic range to dither the PZT and also do the homodyne phase locking using a single channel. Else, we'd need to use two channels and install a summing amplifier.
    • We definitely need more high-voltage amplifiers/supplies in the lab:
      • Any Thorlabs HV drivers we can recover? 
      • Eventually, we will need HV for coil drivers, OMC PZTs, steering PZTs, homodyne phase control PZT. 
  5. PMC bases have arrived.
    • Joe Benson from the machine shop informed me today afternoon that the bases were ready for pickup.
    • We have 3 bases in hand now. The finish isn't the greatest in the world, but I think it'll work. You can see some photos here.
    • I will hold off on putting this together while I work on the basic airBHD commissioning tests. We can install the PMCs later.
  6. AS port WFS project
    • We now have in hand almost all the components for stuffing the ISC whitening and LSC demod boards.
    • Rich, Chub, Luis and I had a call on Monday. The advise from Rich/Luis was:
      • Choose an inductance that has Z~100 ohms at the frequency of interest, for the resonant transimpedance part.
      • Choose a capacitance that gives the appropriate resonant frequency.
      • Don't stuff more notches than you need - start with just a 2f notch (so 110 MHz for us), and make sure to place the highest frequency notch closest to the photodiode.
      • Rich also suggested looking at the optical signal with a non-optimized head, get an idea of what the field content is, and then tune the circuit as necessary. There are obviously going to be many issues that only become apparent once we do such a test.
    • The aLIGO modulation frequencies are only 20% different from the 40m modulation frequencies. So I thought it is best if for our first pass, we stick to the inductance values used in the aLIGO circuits (same footprint, known part etc etc). Then, we will change the capacitance so that we have a tuning range that is centered our modulation frequencies.
    • The parts have been ordered.
  7. ISS project
    • Half of the LO light on the BHD breadboard is diverted for the purpose of sensing the LO intensity noise, for eventual stabilization. Right now, it is just getting dumped.
    • A PD head has been located. It has a minimalist 1kohm transimpedance amplifier circuit integrated into the head.
    • Our AOM driver has an input range of 0-1V DC. We want to map the servo output of +/-10V DC (or +/-4V DC if we use an SR560 based servo for a first pass) to this range.
    • I wanted to do this for once in a non-hacky way so I drew up a circuit that I think will serve the purpose. It has been fabricated and will be tested on the bench in a couple of days.
    • Once I get a feel for what the signal content is, I will also draw up a interface board to the PD head that (i) supplies the reverse bias voltage and +/-15 V DC to the PD head and (ii) applies some appropriate HPF action and provides a DC monitor as well.
  8. Summary pages are dead.
  9. General lab cleanup
    • I moved all the PPE from the foyer area into the designated cabinets along the east arm.
    • Did some basic cleanup of the lab in preparation for crane inspection. Walkways are clear.
    • I de-cluttered the office area a bit, but today I received ~10 packages from Digikey/FrontPanelExpress etc. So, in fact, it got even more cluttered. Entropy will go down once we ship these off to screaming circuits for stuffing the PCBs.
  16815   Wed Apr 27 16:28:57 2022 AnchalSummaryBHDBHD Upgrade - Retreiving arm cavity alignment

[Anchal, Paco, JC]

We had to open ITMY, ETMY chamber doors to get the cavity aligned again. Once we did that, we regained cavity flashing and were able to align the input injection and cavity alignment to get transmission flashing to 1.0 (C1:LSC-TRY_OUT_DQ). JC later centered both ITMY and ETMY oplevs. The ITMY oplev had become completely out of range.

We also opened ITMX, ETMX chamber doors to get Xarm alignment. Again, it seems that ITMX had moved a lot due to cable post installation.

To be continued

  16785   Mon Apr 18 16:09:07 2022 YehonathanUpdateBHDBHD Readout simulation

I'm planning on simulating the BHD readout noise in a manner very similar to the ALS noise model using Simulink. I've made a sketch of the model for the longitudinal DOFs (attached). A model for ASC will be similar but with more measurement devices (OpLevs, QPDs, WFSs).

I'm not pretending to simulate everything in this diagram on the first go, it is just a sketch of the big picture.

Attachment 1: BHD_Simulink_Sketch.drawio.pdf
BHD_Simulink_Sketch.drawio.pdf
  16828   Tue May 3 21:07:17 2022 YehonathanUpdateBHDBHD Readout simulation

I feel like there is an instability in my thought process on this. Before my tendency to try to scale and generalize this problem brings me to a full stop I will make small but quick progress.

First thing is to calculate the noise budget for a simple Michelson. The involved optics are:

  • ITMX
  • ITMY
  • BS
  • LO1
  • LO2
  • AS1
  • AS4

all sensed with OSEMs and OpLevs only.

Things to fetch:

1. OSEM sensing noise. Where do I get the null stream (AKA butterfly mode)?

2. Oplev noise, look at the SUM channel (or this elog)

3. Actuation TF. Latest elog.

4. Coil driver noise. Going to take the HP supply curve from this elog.

5. Seismic noise + Seismic stack TF. Or maybe just take displacement noise from gwinc.

6. Laser noise. Still need to search.

7. DAC noise. Still need to search.

 

 

Quote:

I'm planning on simulating the BHD readout noise in a manner very similar to the ALS noise model using Simulink. I've made a sketch of the model for the longitudinal DOFs (attached). A model for ASC will be similar but with more measurement devices (OpLevs, QPDs, WFSs).

I'm not pretending to simulate everything in this diagram on the first go, it is just a sketch of the big picture.

 

  16834   Thu May 5 17:50:48 2022 YehonathanUpdateBHDBHD Readout simulation

I have made a Simulink diagram to use in the MICH modeling (attachment) for the homodyne angle detection scheme. The model will be used for each optic separately and the noises will be combined in quadrature.

I gathered some more bits of info to fill the Simulink boxes. This is what I have so far:

Noise sources

# Displacement noises from gwinc
# OSEM sensing noise from the null stream
# OpLev noise from SUM channel + Seismic motion

freq = np.logspace(1, 4, 100)
coil_driver_noise = 1*freq/freq # pA/sqrt(Hz), elog 15846 
RIN = 1e-2*freq/freq #1/sqrt(Hz), elog 16082  
freq_noise = (1e6/freq**2) #Hz/sqrt(Hz), elog 15431
dark_noise = 1e-8 #V/sqrt(Hz) https://wiki-40m.ligo.caltech.edu/Electronics/RFPD/AS55
ADC_noise = 1e-6 #V/sqrt(Hz)
DAC_noise = 1e-6 #V/sqrt(Hz), elog 13003
 

TFs and gains

#POS->BHD from Finesse
#RIN->BHD from Finesse
#Frequency noise->BHD from finesse
#Control filters from MEDM
#Whitening filters from https://wiki-40m.ligo.caltech.edu/Electronics/WhiteningFilters
#Dewhitening filters from elog 12983  

DAC_gain = 6.285e-4 #V/cts, elog 16161

coil_driver_gain = 31 # elog 15534

coil_driver_TF = 0.016 #N/A per coil, elog 15846 
coil_R = 20e3 #Ohm,, elog 15846 
SUS_TF = 1/(0.25*freq**2) #m/N, single pendulum
OSEM_TF = 2*16384*1e3 #cts/m, https://wiki-40m.ligo.caltech.edu/Calibration
ADC_TF = 1638.4 #cts/V 
DCPD_responsivity = 0.8 #A/W
DCPD_transimpedance = 1e3 #V/A

Attachment 1: BHD_controls_40m_MICH.pdf
BHD_controls_40m_MICH.pdf
  15901   Thu Mar 11 02:10:06 2021 KojiSummaryBHDBHD Platform vertical dimentions

Stephen and I discussed the nominal heights of the BHD platform components.

  • The beam height from the stack is 5.5"
  • The platform height is 1.5" and the thickness of 0.4", according to the VOPO suspension, which we want to be compatible with.
  • Thus the beam height on the BHD platform is 4".
  • The VOPO platform has a minimum 0.1" gap from the installation surface when it is suspended.
  • When the BHD platform is fixed on the table, we'll use positioners that are fixed on the stack table. Then the BHD platform is fixed on the positioner rather than fixing the entire platform on the stack. This leaves us the option to suspend the platform in the future. The number of the positioners is TBD.
  • Looking at the head size for 1/4-20 socket head screws, It'd be nice to have the thickness of 0.5" for the positioners. This makes the thin part of the stiffener to be 0.6" in thickness.
     
  • The numbers are nominal for the initial design and subject to the change along with FEA simulations to determine the resonant frequency of the body modes.
Attachment 1: BHD_Platform_Vertical_Dimentions.pdf
BHD_Platform_Vertical_Dimentions.pdf
  16839   Mon May 9 22:19:06 2022 KojiUpdateBHDBHD Platform Progress status

[Don, Koji]

Don is working on finalizing the BHD Platform design. All the components on the BHD platform are almost populated and aligned.

Don is still working on the table legs so that we can detach the legs when we need to float the table in the future.
The BHD BS mount will have a third picomotor so that we can steer 3 dof with the mount while the remaining dof needs to be provided by the OMC.
The BHD BS position is going to be adjusted so that the incident and trans beams have sufficient clearance.
The OMC legs (kinematic mounts) need more work so that we can adjust their positions for initial setup while they can be the reference for the reproducible placement of the OMCs.
The OMCs are rigidly held with the legs. For the damping of the 1-kHz body bode, which has a relatively high Q, there will be a dissipative element touching the glass breadboard.

Attachment 1: Screenshot_2022-05-09_220220.png
Screenshot_2022-05-09_220220.png
Attachment 2: Screenshot_2022-05-09_222405.png
Screenshot_2022-05-09_222405.png
  16840   Mon May 9 23:18:44 2022 KojiUpdateBHDBHD Platform Progress status

I quickly ran the FEA model to check the resonant freqs of the BHD platform.
The boundary conditions were:

  • The platform was not loaded
  • FIxed constraints were given to the five legs

Don has optimized the cut-out size for the OMCs to increase the rigidity of the plate. Also, the ribbed grid is made at the bottom side.

The lowest mode is at 168Hz. Because there is no leg around, it seems reasonable to have this kind of mode as the fundamental mode.
The other mode lined up at 291Hz, 394Hz, 402Hz, ...
The mode freqs will be lower once the platform is loaded. But as the unloaded platform mode, these mode freqs sound pretty good numbers.

Attachment 1: Screenshot_2022-05-09_224145.png
Screenshot_2022-05-09_224145.png
Attachment 2: Screenshot_2022-05-09_224137.png
Screenshot_2022-05-09_224137.png
Attachment 3: bhd_platform_168.png
bhd_platform_168.png
Attachment 4: bhd_platform_291.png
bhd_platform_291.png
Attachment 5: bhd_platform_394.png
bhd_platform_394.png
Attachment 6: bhd_platform_402.png
bhd_platform_402.png
ELOG V3.1.3-