40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 305 of 344  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  14787   Sat Jul 20 14:43:45 2019 MilindUpdateCamerasCNNs for beam tracking || Analysis of results

<Adding details>

See Attachment #2.


Make the MSE a subplot on the same axes as the time series for easier interpretation.

Training dataset:

  1. Peak to peak amplitue in physical units: ?
  2. Dither frequency: 0.2 Hz
  3. Video data: zoomed in video of the beam spot obtained from GigE camera at 500us exposure time. Each frame has a resolution of 640 x 480 which I have cropped to 350 x 350. Attachment #1 is one such frame.
  4. Yes, therefore I am going to obtain video at lower amplitudes. I think that should help me avoid the problem of not-nominal-maximum value?
  5. Other details of the training dataset:
    1. Dataset created from four vides of duration ~ 30, 60, 60, 60 s at 25 FPS.
    2. 4032 training data points
      1. Input (one example/ data point): 10 successive frames stacked to form a 3D volume of shape 350 x 350 x 10
      2. Output (2 dimensional vector): QPD readings (C1:IOO-MC_TRANS_PIT_ERR, C1:IOO-MC_TRANS_YAW_ERR)
    3. Pre-processing: none
    4. Shuffling: Dataset was shuffled before every epoch
    5. No thresholding: Binary images are gonna be of little use if the expectation is that the network will learn to interpret intensity variations of pixels.

Do I need to provide any more details here?


Describe the training dataset - what is the pk-to-pk amplitude of the beam spot motion you are using for training in physical units? What was the frequency of the dither applied? Is this using a zoomed-in view of the spot or a zoomed out one with the OSEMs in it? If the excursion is large, and you are moving the spot by dithering MC2, the WFS servos may not have time to adjust the cavity alignment to the nominal maximum value.



What is the minimum detectable motion given the CCD resolution?

see attachment #4.

  1. Please upload a cartoon of the network architecture for easier visualization. What is the algorithm we are using? Is the approach the same as using the bright point scatterers to signal the beam spot motion that Gabriele demonstrated successfully


I wrote what I think is a handy script to observe if the frames are saturated. I thought this might be handy for if/when I collect data with higher exposure times. I assumed there was no saturation in the images because I'd set the exposure value to something low. I thought it'd be useful to just verify that. Attachment #3 has log scale on the x axis.


What is the significance of Attachment #6? I think the x-axis of that plot should also be log-scaled.


  1. Is the performance of the network still good if you feed it a time-shuffled test dataset? i.e. you have (pictures,Xcoord,Ycoord) tuples, which don't necessarily have to be given to the network in a time-ordered sequence in order to predict the beam spot position (unless the network is somehow using the past beam position to predict the new beam position).
  2. Is the time-sync problem Koji raised limiting this approach?


Attachment 1: frame0.pdf
Attachment 2: subplot_yaw_test.pdf
Attachment 3: intensity_histogram.mp4
Attachment 4: network2.pdf
  14788   Sun Jul 21 02:07:04 2019 KruthiUpdateLoss MeasurementMC2 loss map

I'm running the MC2 loss map scripts on pianosa now. The camera server is throwing an error and is not grabbing snapshots :(

Update: I finished taking the readings for MC2 loss map. I couldn't get the snapshots with the script, so I manually took some 4-5 pictures.

  14789   Sun Jul 21 12:54:18 2019 gautamUpdateLoss MeasurementMC2 loss map

Can you please be more specific about what the error is? Is this the usual instability with the camera server code? Or was it something new?


The camera server is throwing an error and is not grabbing snapshots :(

  14790   Sun Jul 21 12:55:38 2019 gautamUpdateCDSCM board Latch Enable test script

DATED, SEE ELOG14941 for the most up-to-date info on latch.py.

I wrote (/cvs/cds/caltech/target/c1iscaux3/latch.py) and tested the logic illustrated in Attachment #1. Results of a test are shown in Attachment #2, the various channels change as expected. Note that for negative values of the gain channel, the corresponding "BITS" channel will take on values like 65536 - this is because the mbboDirect data type is a 16 bit data type, and presumably the MSB is the sign bit. A bit mask is applied to this channel before the actual BIO unit bits are set - we should verify that the correct behavior happens, but I don't immediately see any problems.

To me, this is a robust logic, but it will benefit from more sets of eyes giving it a look over. The idea is to run this continuously on the Supermicro machine.

Apart from this, I also fixed some errors in the mbboDirect record syntax - so now I am able to start up the EPICS server without it throwing any error messages. It remains to verify that changing an EPICS gain slider results in the appropriate gain bits being flipped in the correct way (on the hardware side, I think the correct behavior is happening on the software end). For this testing, I turned off the old c1iscaux crate at ~10am, and started up the server on c1iscaux3. I am reverting to the nominal config now (~1pm).

Further testing will require the wiring inside the Acromag chassis to be completed. This should be the priority task for next week.

*Update 1130 22 July 2019: I've now installed the required dependencies on c1iscaux3 and setup the latch.py script to run as a systemctl process dependent on modbusIOC.service.

Attachment 1: LatchLogic.pdf
Attachment 2: LatchLogicTest.png
  14791   Sun Jul 21 17:17:03 2019 KruthiUpdateLoss MeasurementMC2 loss map

The camera server keeps throwing the error: failed to grab frames. Milind suggested that it might a problem with the ethernet cable, so I even unplugged it and connected it again; it still had the same issue. One more thing I noticed was, it does take snapshots sometimes with the terminal command caput C1:CAM-ETMX_SNAP 1, but produces a segmentation fault when ezca.Ezca().write(C1:CAM-ETMX_SNAP, 1) ezca.Ezca().write(CAM-ETMX_SNAP, 1) is used via ipython. When the terminal command also fails to take snapshots, I noticed that the SNAP button on the GigE medm screen remains on and doesn't switch back to OFF like it is supposed to.


Can you please be more specific about what the error is? Is this the usual instability with the camera server code? Or was it something new?


The camera server is throwing an error and is not grabbing snapshots :(

  14792   Sun Jul 21 19:27:25 2019 MilindUpdateLoss MeasurementMC2 loss map

I think ezca.Ezca().write() takes the string "CAM-ETMX_SNAP" as an argument and not C1:CAM-ETMX_SNAP. See this, line 47. Are you sure this is not the problem?


The camera server keeps throwing the error: failed to grab frames. Milind suggested that it might a problem with the ethernet cable, so I even unplugged it and connected it again; it still had the same issue. One more thing I noticed was, it does take snapshots sometimes with the terminal command caput C1:CAM-ETMX_SNAP 1, but produces a segmentation fault when ezca.Ezca().write(C1:CAM-ETMX_SNAP, 1) is used via ipython. When the terminal command also fails to take snapshots, I noticed that the SNAP button on the GigE medm screen remains on and doesn't switch back to OFF like it is supposed to.

  14793   Sun Jul 21 20:23:35 2019 ranaUpdateIOOMC locked

I found the MC2 face camera disabled(?) and the MC servo board input turned off. I turned the MC locking back on but I don't see any camera image yet.

  14794   Sun Jul 21 22:16:34 2019 ranaUpdateGeneralrossa Xdisp bricked

"bricked" is to mean that it has the functionality of a brick and can be tossed. But rossa seems to have just gotten some software config corruption. I spent a couple hours reinstalling SL7 today as per my previous elog notes and the X display seems to work as before.

i.e. it was fine with the default setup, except for the ole "X chrashes if the mouse goes to left side of screen". As before, I

  1. blacklisted the nouvaeu driver (which is used by default)
  2. download the NVIDIA driver as per the link
  3. run its installation from the no-X terminal

left side of screen is safe again

This time I installed SL7.6 and followed the K Thorne wiki. But its having trouble installing cds-root because it can't find root.frown


  14795   Mon Jul 22 07:21:13 2019 gautamUpdateCDSpainosa messed with

Somebody changed the settings on painosa without elogging anything about it. Why does this keep happening? I thought the point of the elog was to communicate. I think there are sufficient number of problems in the lab without me having to manually reset the control room workstation settings every week. Please make an elog if you change something.

  14796   Mon Jul 22 12:57:35 2019 KruthiUpdateLoss MeasurementMC2 loss map

In my script I have used "CAM-ETMX_SNAP" only; while entering it in the elog I made a mistake, my bad!


I think ezca.Ezca().write() takes the string "CAM-ETMX_SNAP" as an argument and not C1:CAM-ETMX_SNAP. See this, line 47. Are you sure this is not the problem?


The camera server keeps throwing the error: failed to grab frames. Milind suggested that it might a problem with the ethernet cable, so I even unplugged it and connected it again; it still had the same issue. One more thing I noticed was, it does take snapshots sometimes with the terminal command caput C1:CAM-ETMX_SNAP 1, but produces a segmentation fault when ezca.Ezca().write(C1:CAM-ETMX_SNAP, 1) is used via ipython. When the terminal command also fails to take snapshots, I noticed that the SNAP button on the GigE medm screen remains on and doesn't switch back to OFF like it is supposed to.

  14797   Mon Jul 22 13:26:41 2019 KruthiUpdateIOOMC locked

The MC2 has 2 GigE cameras right now. I'll put back the analog asap.


I found the MC2 face camera disabled(?) and the MC servo board input turned off. I turned the MC locking back on but I don't see any camera image yet.

  14798   Mon Jul 22 13:32:55 2019 KruthiUpdateSUSTest mass pitch adjustment test

[Kruthi, Milind]

On Friday, Milind and I performed the pitch adjustment test Rana had asked us to do. Only 1 blue beam in case of ITMX and two in case of ETMY, ETMX and ITMY were accessible. Milind (of mass 72 kg as of 10 May 2019) stood on each of the accessible blue beams of the test mass chambers for one minute and I recorded the corresponding gps time. Before moving to the next beam, we spared more than a minute for relaxation after the standing end time. Following are the recorded gps times. 







Beam 1

Beam 2

Beam 1

Beam 1

Beam 2

Beam 1

Beam 2

Standing start time (gps)








Standing end time (gps)








PS: For each blue beam relaxation time ~ 1 min after the standing end time

Attachment 1: ETMX.pdf
Attachment 2: itmx.pdf
Attachment 3: ETMY.pdf
Attachment 4: ITMY.pdf
Attachment 5: 3f1a82f2-b86a-469e-8914-9278a216c5f9.jpg
Attachment 6: 1d174307-d940-42e6-812b-83417d0f5f6a.jpg
  14799   Mon Jul 22 21:04:40 2019 ranaUpdateComputersmaking rossa great again
  • copied over /etc/fstab lines from pianosa sothat the NFS mounts work correctly
  • added symlinks so that the NFS dirs mount in the right dirs
  • installed Opera browser
  • symlink libsasl2.so.3 -> libsasl2.so.2 and now DTT runs and can get data now and in the past
  • DTT can natively produce PDF so you don't have to take screen caps of your camera phone and make a chalk drawing of that anymore
  • sitemap/MEDM is working
  • after editing fonts.alias as detailed in Thorne wiki, I ran 'sudo xset fp rehash' to get MEDM to notice new fonts. MEDM Scalable fonts are back!!
  • installed Grace and now dataviewer works
  • ndscope not running: yum install ndscope breaks because it can't find a couple of python34 packagesno
  • tested that AWGGUI also runs and puts in real sine waves
Attachment 1: seis.pdf
  14800   Mon Jul 22 23:53:16 2019 gautamUpdateALSIR ALS locking attempt


My goal tonight was to lock the PSL frequency to be resonant in the XARM cavity, using the PSL+EX beat as the error signal. I was not successful - mainly, I was plagued by huge BR mode coupling in the error signal, and I could not enable the BR notch filter in the control loop without breaking the lock. Need to think about next steps.


  • POX and POY locking was easily restored.
  • EX green alignment was tweaked at the end-table. A large YAW correction was required, which I opted to apply on the mechanical mirror mounts rather than the PZTs. GTRX ~0.4 was recovered.
  • The arm cavity length was first locked using POX as an error signal 
    • Then I looked at the out-of-loop ALS noise, trusting the DFD's V/Hz calibration (red-trace in Attachment #1).
    • I judged it to be close enough to the benchmark reference (green-trace in Attachment #1), and so decided that I could go ahead and try locking.
  • A modified version of the script /opt/rtcds/caltech/c1/scripts/XARM/Lock_ALS_XARM.py was used to transition control from POX to the ALS error signal
    • I found that I had to change the sign of the CARM loop gain for the servo to remain stable (in this config, CARM-->MC2 length, thereby modifying the IMC frequency to keep the PSL resonant in the XARM cavity).
    • I don't know why this sign change was required - we are still sticking to the same convention that the beat frequency increases when the temperature slider for the EX laser is incremented in counts.
    • The script failed multiple times at the BOOST/BR notch filter enabling step.
    • Doing these steps manually, I found that turning the BR notch, FM6, ON destroyed the lock immediately.
    • Motivated by this observation, I looked at the in-loop error signal spectrum, see Attachment #2. Here, the PSL frequency is servoed by the ALS error signal, but the BR notch filter isn't enabled.
    • The Bounce-mode peak is huge - where is this coming from? It is absent in the ALS spectrum when the XARM is locked with POX. So it is somehow connected with actuating on the MC2 suspension? Or is it that the FM6=BounceRoll filter of the XARM loop is squishing the noise when looking at the ALS spectrum in POX lock, i.e. Attachment #1? In which case, why can't I engage FM6 for the CARM loop???

Anyway, now that I have a workable set of settings that gets me close to the ALS lock of the XARM, I expect debugging to proceed faster.

Update 2019 July 23: I looked at the control loop shape today, see Attachment #3. I'm not sure I understand why the "BounceRoll" filter  in this filter bank looks like a resonant gain rather than a notch, as it does for the Oplev or SUSPOS loops for example - don't we want to not actuate at these frequencies because the reason the signal exists is because of the imperfect OSEM/magnet positioning? This does not explain the spectrum shown in Attachment #2 however, as that filter was disabled.

Attachment 1: ALS_X_outOfLoopnoise.pdf
Attachment 2: ALS_X_inLoopnoise.pdf
Attachment 3: CARM_loopShape.pdf
  14801   Tue Jul 23 21:59:08 2019 JonUpdateCamerasPlan for GigE cameras

This afternoon Gautam and I assessed what to do about restoring the GigE camera software. Here's what I propose:

  • Set up one of the new rackmount Supermicros as a dedicated camera feed server
  • All GigE cameras on a local subnet connected to the second network interface (these Supermicros have two)
  • Put the SnapPy, pypylon, and pylon5 binaries on the shared network drive. These all have to be built from source.
  • All other dependencies can be gotten through the package managers, so create requirements files for yum and pip to automatically install these locally.

I've started resolving the many dependencies of this code on rossa. The idea is to get a working environment on one workstation, then generate requirements files that can be used to set up the rest of the machines. I believe the dependencies have all been installed. However, many of the packages are newer versions than before, and this seems to have broken SnapPy. I'll continue debugging this tomorrow.

  14802   Wed Jul 24 00:22:24 2019 gautamUpdateALSPSL frequency locked to XARM length using ALS


I succeeded in locking the PSL frequency to the XARM cavity length, with 9 pm RMS (Attachment #1) motion below 1 kHz, by actuating on MC2 to change the IMC length. The locks were pretty stable (~20 minutes) - the dominant cause of lockloss was the infamous ETMX drifting problem.


  1. I did not need to do anything to fix the anomalosly high BR mode coupling I reported yesterday surprise.
    • To test where this could be coming from - I looked at the ALS spectrum again with the XARM length locked to the PSL frequency using POX.
    • Then I compared the spectra with the BR filter in the XARM servo enabled/disabled, see Attachment #2
    • There bounce/roll peak heights even with the BR filter disabled is ~x100 smaller than what I reported yesterday (it remained the case today, because without enabling the BR filter in the CARM servo bank, the TRX level was fluctuating wildly at ~16 Hz). 
  2. The CARM loop (which is what the PSL frequency was slaved to) had ~150 Hz UGF with ~40 degrees phase margin, see Attachment #3.
  3. The quoted RMS sensing noise is if we trust the old POX calibration - may be off by a factor of a few, but probably not an order of magnitude. I'll recalibrate using the free-swinging Michelson technique in the coming days.
  4. The two broad humps in Attachment #1, centered at ~180 Hz and ~300 Hz, are present in the XARM lock as well - so it is somehow imprinted on the arm cavity length. Fixing that will improve the RMS noise performance significantly.

My main motivation here is to make some measurements and investigate the SoCal idea using a toy system, i.e. a single arm cavity controlled using ALS, so that's what Craig and I will attempt next.

Attachment 1: ALS_X_noise_POX.pdf
Attachment 2: BR_comparison.pdf
Attachment 3: ALS_CARM_OLG.pdf
  14803   Wed Jul 24 02:06:05 2019 KruthiUpdateCamerasHDR images

I have been trying a couple of HDR algorithms, all of them seem to give very different results. I don't know how suitable these algorithms are for our purpose, because they are more concerned with final display. I'm attaching the HDR image I got by modifying Jigyasa's code a bit (this image has been be modified further to make it suitable for displaying). Here, I'm trying compare the plots of images that look similar. The HDR image has a dynamic ratio of 700:1

PS: 300us_image.png file actually looks very similar to HDR image on my laptop (might be an issue with elog editor?). So I'm attaching its .tiff version also to avoid any confusion.

Attachment 1: HDR_8bit.png
Attachment 2: hdrplot.png
Attachment 3: C_MC2_2019-07-19-01-50-09.tiff
Attachment 4: 300us_image.png
Attachment 5: 300us_image.tiff
Attachment 6: actualimageplot.png
  14804   Wed Jul 24 04:20:35 2019 KruthiUpdateCalibration-RepairMC2 pitch and yaw calibration

Summary:  I calibrated MC2 pitch and yaw offsets to spot position in mm. Here's what I did:

  1. Changed the MC2 pitch and yaw offset values using  ezca.Ezca().write('IOO-MC2_TRANS_PIT_OFFSET', <pitch offset value> ) and ezca.Ezca().write('IOO-MC2_TRANS_YAW_OFFSET', <yaw offset value> )
  2. Waited for ~ 700-800 sec for system to adjust to the assigned values
  3. Took snapshots with the 2 GigEs I had installed - zoomed in and zoomed out. (I'll be using these to make a scatter loss map, verify the calibration results, etc)
  4. Ran the mcassDecenter script, which can be found in /scripts/ASS/MC. This enters the spot position in mm in the specified text file.

Results:  In the pitch/yaw vs pitch_offset/yaw_offset graph attached,

  • intercept_pitch = 6.63 (in mm) ,  slope_pitch = -0.6055 (mm/counts) 
  • intercept_yaw = -4.12 (in mm) ,  slope_yaw = 4.958 (mm/counts) 
Attachment 1: Pitchyaw_calibration.png
  14805   Wed Jul 24 12:24:43 2019 MilindUpdateIOOunstick.py and ifotest

Moved the unstick.py code to the ifotest repository here. It now handles signals like those generated by Ctrl-C and so forth. It can still be run as python unstick.py <machine1> <machine2> etc.

  14806   Wed Jul 24 16:45:32 2019 JonUpdateCamerasUpgraded Pylon from 5.0.12 to 5.2.0

I upgraded Pylon, the C/C++ API for the GigE cameras, to the latest release, 5.2.0. It is installed in the same location as before, /opt/rtcds/caltech/c1/scripts/GigE/pylon5, so environment variables do not change. The old version, 5.0.12, still exists at opt/rtcds/caltech/c1/scripts/GigE/backup_pylon5.

The package contains a GUI application (/bin/PylonViewerApp) for streaming video. The old version supports saving still images, but Milind discovered that the new version supports saving video as well. This required installing a supplementary package supporting MPEG-4 output.

Basler's GUI application is launched from the terminal using the alias pylon. I've tested it and confirm it can save both videos and still-image formats. I recommend to also try grabbing images using this program and check the bit resolution. It would be a useful diagnostic to know whether it's a bug in Joe B.'s code or something deeper in the camera settings.

Attachment 1: IMG_3525.jpg
  14807   Wed Jul 24 20:05:47 2019 MilindUpdateCamerasCNNs for beam tracking || Tales of desperation

At the lab meeting today, Rana suggested that I use the Pylon app to collect more data if that's what I need. Following this, Jon helped me out by updating the pylon version and installing additional software to record video. Now I am collecting data at

  1. higher exposure rate - 600 us magically gives me a saturation percentage of around 1%, see attachment #1 (i.e around 1% of the pixels in the region containing the beam spot are over 240 in value). Ths is a consequence of my discussion with Gabriele where we concluded that I was losing information due the low exposure rate I was using.
  2. For much longer: roughly 10 minutes
    1. at an amplitude of 40 cts for 0.2 Hz
    2. at an amplitude of 20 cts for 0.2 Hz
    3. at an amplitude of 10 cts for 0.2 Hz
    4. at an amplitude of 40 cts for 0.4 Hz
    5. at an amplitude of 20 cts for 0.2 Hz
    6. Random motion

Consequently I have dithered the MC2 optic from around 9:00 PM.

Attachment 1: saturation_percentage.pdf
  14808   Wed Jul 24 20:23:52 2019 gautamUpdateCamerasUpgraded Pylon from 5.0.12 to 5.2.0

Since there are multiple SURF projects that rely on the cameras:

  1. I moved the new installs Jon made to "new_pylon5" and "new_pypylon". The old installs were moved back to be the default directories.
  2. The bashrc alias for pylon was updated to allow the recording of videos (i.e. it calls the PylonViewerApp from new_pypylon).
  3. There is a script that can grab images at multiple exposures and save 12-bit data as uint16 numpy arrays to an HDF5 file. Right now, it is located at /users/kruthi/scripts/grabHDR.py. We can move this to a better place later, and also improve the script for auto adjusting the exposure time to avoid saturations.

My changes were necessary because the grabHDR.py script was throwing python exceptions, whereas it was running just fine before Jon's changes. We can move the "new_*" dirs to the default once the SURFs are gone.

Let's freeze the camera software config in this state until next week.

  14809   Thu Jul 25 00:26:47 2019 MilindUpdateCamerasConvolutional neural networks for beam tracking

Somehow I never got around to doing the pixel sum thing for the new real data from the GigE. Since I have to do it for the presentation, I'm putting up the results here anyway. I've normalized this and computed the SNR with the true readings.

SNR = (power in true readings)/ (power in error signal between true and predicted values)

Attachment #2 is SNR of best performing CNN for comparison.

Attachment 1: centroid.pdf
Attachment 2: subplot_yaw_test.pdf
  14810   Thu Jul 25 09:19:32 2019 JonUpdateCamerasUpgraded Pylon from 5.0.12 to 5.2.0

I'll keep developing the camera server on a parallel track using the "new_..." directory naming convention. One thing I forgot to note is that the new pylon/pypylon packages require Python 3, so will not work with any of the 2.7 scripts. All of the environment I need to set up is exclusively Python 3. I won't change anything in the Python 2.7 environment in current use.

Also, I found the source of the bit resolution issue: Joe B's code loads a set of initialization parameters from a config file. One of them is "Frame Type = Mono8" which sets the dynamic range of the stream. I'll look into how this should be changed. 


Since there are multiple SURF projects that rely on the cameras:

  1. I moved the new installs Jon made to "new_pylon5" and "new_pypylon". The old installs were moved back to be the default directories.
  2. The bashrc alias for pylon was updated to allow the recording of videos (i.e. it calls the PylonViewerApp from new_pypylon).
  3. There is a script that can grab images at multiple exposures and save 12-bit data as uint16 numpy arrays to an HDF5 file. Right now, it is located at /users/kruthi/scripts/grabHDR.py. We can move this to a better place later, and also improve the script for auto adjusting the exposure time to avoid saturations.
  14811   Thu Jul 25 12:25:56 2019 gautamUpdateALSIR ALSX noise


  1. There are some broad peaks in the ALS out-of-loop noise, centered at ~145 Hz, ~245 Hz and ~570 Hz which are absent in both the POX in-lock error signal and in the green PDH error signals (see Attachment #1). So I conclude they originate in the IR ALS beat chain somewhere. Needs more investigation, in the general quest to improve the ALS noise.
  2. This measurement also shows that the ALS noise is limited by unsuppressed EX green PDH frequency noise above ~400 Hz (100 Hz if you ignore the unexplained broad humps).

These spectra were taken with the arm cavity length locked to the PSL frequency using POX as an error signal, and the EX laser frequency locked to the XARM cavity length by the analog PDH servo at EX, so there is no feedback control with the ALS beat signal as an error signal.

Other details:

  • The transition of arm resonance control from POX to ALS error signal is more robust now - I am able to do this during daytime, and also maintain the lock for >20 minutes at a time.
  • Rana encouraged me not to spend too much time on this - so my next goal here will be to get the Y arm IR ALS working, and then we can control the two arms using ALS error signals in the CARM/DARM basis instead of the X/Y basis.
  • I still think it's worth getting the ALS good enough that the locking becomes repeatable and reliable.
    • The main task here is going to be re-doing the EY green layout to match the EX layout, get good MM into the cavity etc.
    • The IR light also has to be coupled into the fiber at EY.
Attachment 1: ALS_broadPeaks.pdf
  14813   Thu Jul 25 20:08:36 2019 gautamUpdateComputersSolidworks machine

I brought one CPU (Dell T3500) and one 28" monitor from Mike Pedraza's office in Downs to the 40m. It is on Steve's desk right now, pending setup. The machine already has Solidworks and Altium installed on it, so we can set it up at our leisure. The login credentials are pasted on the CPU with a post-it should anyone wish to set it up.

  14815   Mon Jul 29 13:32:56 2019 gautamUpdateLoss MeasurementLoss measurement PD installed in AS path

[yehonathan, gautam]

  • we placed a PDA520 photodiode in the AS beampath, so AS110 and AS55 no longer see any light.
  • ITMX and ETMX were misaligned (since the plan is to measure the Y arm loss).
  • The PDA520 and MC2 transmission are currently going to the Y arm ALS beat channels in the DAQ system. Unfortunately, we have no control over the whitening gains for these channels because of the c1iscaux2 situation.
  14816   Mon Jul 29 19:08:55 2019 yehonathanUpdateLoss MeasurementReviving loss measurement by reflection

1. X arm is totally misaligned in order to measure the Y arm loss using the reflection method. Each measurement round consists of measuring the reflected power when the Y arm is aligned and when it is misaligned.

2. The measurement script used is /scripts/lossmap_scripts/armLoss/measureArmLoss.py. It generates a log file in the /logs folder specifying the alignment and misalignment times.

3. The data extraction script dlData.py processes the raw data in the log file and creates a hdf5 file in the /Data folder conataining the data of the measurement it self.

4. dlData.py labels the the aligned and misaligned datas incorrectly when the number of measurement is odd. I use only even number of measurements then.

5. In order to clip the chaotic transition between the aligned and misaligned states I use tDur attribute smaller than the actual sleep time used in the measurement script itself.

6. plotData.py (written by Gautam) and AnalyzeLossData.ipynb (written by me) can be used to calculate the loss and to plot some analyses (see https://nodus.ligo.caltech.edu:8081/40m/14568). They give roughly the same answer. The descripancy can be explained by the different modulation and ITM transmissions used.

7. I take a measurement of 8 repeatitions. I plot the measured reflected power alternating between the aligned and misaligned states. 

I find that the reflected power is repeatable to within 1%.

This is consistent with the transmission data plotted here which is also repeatable to within 1%.

8. I take an overnight measurement of 100 repeatitions.

  14817   Tue Jul 30 09:13:31 2019 gautamUpdatePSLc1psl keyed, Agilent setup cleared
  1. IMC would not lock. c1psl EPICS channels were unresponsive. I keyed the crate and went through the usual burtrestore/PMC-relocking dance.
  2. While at 1X2, I decided to take this opportunity to clean up the AG4395 setup that has been setup there unused for several weeks now.
    • Unplugged the active probe connected via BNC-T connector to the mixer IF output.
    • Noticed that the active probe (S/N 2850J01450) did not have it's power connection connected. According to the manual, this is bad. I don't know if the probe is damaged or not.
    • Moved the AG4395 cart out of the way so that there is a little more room around 1X1/1X2.
  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
  14820   Wed Jul 31 14:44:11 2019 gautamUpdateComputersSupermicro inventory

Chub brought the replacement Supermicro we ordered to the 40m today. I stored it at the SW entrance to the VEA, along with the other Supermicro. At the time of writing, we have, in hand, two (unused) Supermicro machines. One is meant for EY and the other is meant for c1psl/c1iool0. DDR3 RAM and 120 GB SSD drives have also been ordered, but have not yet arrived (I think, Chub, please correct me if I'm wrong).

Update 20190802: The DDR3 RAM and 120 GB SSD drives arrived, and are stored in the FE hardware cabinet along the east arm. So at the time of writing, we have 2 sets of (Supermicro + 120GB HD + 4GB RAM).


We should ask Chub to reorder several more SuperMicro rackmount machines, SSD drives, and DRAM cards. Gautam has the list of parts from Johannes' last order.

  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.

  14823   Fri Aug 2 11:37:38 2019 gautamUpdateALSEY IR ALS Assay


I'd like to confirm that the IR ALS scheme will work for locking. The X-arm performance so far has been encouraging. I want to repeat the characterization for the Y arm. So I inspected the layout on the EY table, and made a list of characterization tasks. The current EY beam routing is difficult to work with, and it will definitely benefit from a re-do. However, I don't know how much time I want to spend re-doing it, so for a start, I will just try and couple some amount of light into a fiber and bring it to the PSL table, and see what noise performance I get.


Attachment #1: Photo of the current beam layout. The powers indicated were measured with the Ophir power meter.

  • I measure an SHG conversion efficiency of 0.87 %/W, which is considerably lower than the ~3.7%/W that is theoretically expected, and 1.5%/W that is realized at EX.
  • Of the 0.5 mW of green light that is generated, I measure ~0.375 mW at the viewport into the EY chamber. So there is ~25 % loss in the green beam path on the EY table. Seems high to me.
  • The previous solution of coupling IR light into the fiber realized at EY was to use the SHG leakage IR beam. While there isn't a measurement showing that this dirty beam is noisier than a cleaner pickoff, I'd like to adopt the solution used at EX, which is to use the leakage beam from the first steering mirror in the NPRO beam path. This will allow better mode-matching and polarization control of the beam being coupled into the fiber, which at least in principle, translates to less phase noise.
  • However - the beam layout at the EY table offers much less freedom to work with this idea than EX. A constraint is the clamp that secures the enclosure to the optical table, labelled in the photo. Further behind it, the green steering optics occupy all available space. A more comprehensive photo of the EY table can be found here.
  • Off the top of my head, I don't see any other good open spots on the EY table where we could couple IR light into the fiber. 
  • One other change I'd like to make is to replace the first steering mirror after the NPRO head, which is currently a Y1 HR mirror, with a R=99% BS. This will make it easier to control the amount of power coupled into the fiber, which is something we'd like.

Attachment #2: A candidate mode-matching solution, given the constraints outlined above. It isn't great, with only 85% modematching even theoretically possible. The lenses required are also pretty fast lenses. But I think it's the best possible without a complete overhaul of the EY layout. I'm still waiting for the lens kit to arrive, but as soon as they get here, I will start this work.

Characterization tasks:

  • Characterize SHG at EY [done 7/28]
  • Characterize gPDH at EY (loop TFs, improve MM, PDH discriminant, check the polarization)
  • Couple IR light into fiber with good MM at EY [done with 36% MM 8/9]
  • Clean fiber at EY, and at the PSL table [done 8/9]
  • Make the PSL + Y IR beat [done 8/9]
  • Noise budget
Attachment 1: IMG_7780.JPG
Attachment 2: Ey_MM_20190802.pdf
  14824   Fri Aug 2 16:46:09 2019 KruthiUpdateCamerasClean up

I've put the analog camera back and disconnected the 151 unit GigE. But I ran out of time and wasn't able to replace the beamsplitter. I've put all the equipments back to the place where I took them from. The chopper and beam dump mount, that Koji had got me for the scatterometer, are kept outside, on the table I was working on earlier, in the control room. The camera lenses, additional GigEs, wedge beamsplitter, 1050nm LED and all related equipments are kept in the GigE box. This box was put back into CCD cameras' cabinet near the X arm.

Note: To clean stuff up, I had entered the lab around 9.30pm on Monday. This might have affected Yehonathan's loss measurement readings (until then around 57 readings had been recorded).

Sorry for the late update.

  14825   Fri Aug 2 17:07:33 2019 yehonathan, gautamUpdateLoss Measurement 

We run a loss measurement on the Y arm with 50 repetitions.

  14826   Sun Aug 4 14:39:41 2019 gautamUpdateGeneralsome lab activity
  1. Unresponsive c1psl, c1iool0, c1auxey and c1iscaux VME crates were keyed.
  2. c1psl channels were burt-restored, did a burtrestore, and re-locked the PMC. Tweaked the pointing into the PMC on the PSL table to increase the PMC transmission from ~0.69 to ~0.71.
  3. Re-locked IMC. Ran WFS offset script to relieve the ~100 DAC counts (~10 urad) DC offset from the WFS servos to the IMC suspensions (a serious calibration of this into physical units should be made part of the planned 40m WFS activity). Now that I think about it, since we change the IMC alignment to match the input beam alignment, some post-IMC clipping could modulate the power incident on the ITMs, which is a source of error for the arm cavity loss determination using DC reflection. We need a better normalizing data stream than the IMC transmission.
  4. The IFO_OVEREVIEW medm screen was modified such that the threshold for the PMC transmitted beam to be visible was lowered from 0.7 to 0.6, so that now there is a continuous beam line from the NPRO to the PRM when the IMC is locked even when the PMC transmission degrades by 5% due to thermally driven pointing drifts on the PSL table.
  5. The wmctrl utility on pianosa wasn't working so well, I wasn't able to use my usual locking MEDM autoconfig scripts. Turned out to be due to a zombie MEDM window which I killed with xkill, now it is working okay again.
  6. The misaligned XARM was re-aligned and the loss measuring PDA520 at the AS port was removed from the beam path (mainly to avoid ADC saturations the fringing Michelson will cause).
  7. I noticed that the ETMX Oplev HeNe SUM level has degraded to ~50% of its power level from 200 days ago [Attachment #1], may need a new HeNe here soon. @Chub, do we have spare HeNes in stock?

I want to collect some data with the arms locked to investigate the possibility/usefullness of having seismic feedforward implemented for the arms (it is already known to help the IMC length and PRC angular stability at low frequencies). To facilitate diagnostics I modified the file /users/Templates/Seismic/Seismic_vs_TRXTRYandMC.xml to have the correct channel names in light of Lydia's channel name changes in 2016. Looking at the coherence data, the alignment of the cartesian coordinate system of the Seismometers at the ends and the global interferometer coordinate system can be improved.

I don't know if for the MISO filter design if there is any difference in using TRX/TRY as the target, or the arm length control signal.

Data collection started at 1249018179. I've setup a script running in a tmux shell to turn off the LSC enable in 2 hours.

Attachment 1: ETMX_OL.png
Attachment 2: Seismic_TRXTRYandMC_4Aug2019.pdf
  14827   Mon Aug 5 14:47:36 2019 yehonathanUpdateLoss Measurement 


I analyze the 100 reps loss measurement of the Y arm using the AnalyzeLossData.ipynb notebook.

The mean of the measured loss is ~ 100ppm and the variation between the repititions is ~ 27%.


In Detail

In the real measurement the misaligned and locked states are repeatedly switched between each other. I plot the misaligned and locked PD readings seperately over time.

There seems to be a drift that is correlated between the two readings. This is probably a drift in the power after the MC2. To verify, I plot the ratio between those readings and find no apparent drift:

The variation in the ratio is less than 1%. The loss figure, computed to be 1 minus this ratio times a big number, give a much worse variation. I plot the histogram of the loss figure at each repitition (excluding extremely bad measurements):

The mean is ~ 100ppm. And the variation is ~ 27%.

  Draft   Mon Aug 5 16:28:41 2019 yehonathanUpdateLoss Measurementwhat is going on with the loss measurements ?

We hypothesize that the systematic error in the loss measurement can come from the fact that the requirement on the alignment of the cavity mirrors is not stringent enough.

We repeat the loss measurement with 50 measurements. This time we change the thresholds for the error signals of the dither-align in the measureArmLoss.py file from 0.5 to 0.3.

We repeat the analysis done before:

We plot the reflected power of the two states on top of each other:

This  time it appears there was no drift. The histogram of the loss measurement:

The mean is 104ppm and the variation is 27%.

What I notice this time is that the PD readings in the aligned and misaligned states are anti-correlated. This is also true in the previous run (where there was drift) when looking in the short time scales. I plot several time series to demonstrate:

I wonder what can cause this behaviour.

  14830   Mon Aug 5 17:36:04 2019 yehonathanUpdateLoss Measurement 

We check for unexpected drifts in the PD reading (clipping and such). We put a pickoff mirror where the PD used to be and place the PD at the edge of the table such that the beam is focused on it (see attachment).

The arms are completley misaligned. We note the time of start of measurement to be 1249086917.

Attachment 1: 20190805_171511.jpg
  14831   Tue Aug 6 14:12:02 2019 yehonathanUpdateComputersmaking rossa great again

cdsutils is not working on rossa.

Import cdsutils produces this error:

In [2]: import cdsutils
OSError                                   Traceback (most recent call last)
<ipython-input-2-949babce8459> in <module>()
----> 1 import cdsutils

/ligo/apps/linux-x86_64/cdsutils-480/lib/python2.7/site-packages/cdsutils/__init__.py in <module>()
     54 try:
---> 55     import awg
     56 except ImportError:
     57     pass

/ligo/apps/linux-x86_64/cdsutils-480/lib/python2.7/site-packages/cdsutils/awg.py in <module>()
     30 """
---> 32 import sys, numpy, awgbase
     33 from time import sleep
     34 from threading import Thread, Event, Lock

/ligo/apps/linux-x86_64/cdsutils-480/lib/python2.7/site-packages/cdsutils/awgbase.py in <module>()
     17 libawg = CDLL('libawg.so')
     18 libtestpoint = CDLL('libtestpoint.so')
---> 19 libSIStr = CDLL('libSIStr.so')
     21 ####

/ligo/apps/anaconda/lib/python2.7/ctypes/__init__.pyc in __init__(self, name, mode, handle, use_errno, use_last_error)
    365         if handle is None:
--> 366             self._handle = _dlopen(self._name, mode)
    367         else:
    368             self._handle = handle

OSError: libSIStr.so: cannot open shared object file: No such file or directory

  14832   Tue Aug 6 14:55:23 2019 gautamUpdateCDSMaking Matlab R2015b the default

ML2013 is unable to open Simulink on any of the workstations. We decided to make the default version of Matlab R2015b (the default of the version of RCG we are using).

I commenced the procedure of the migration, starting with making a tagged commit of the current running simulink models. A local backup was also made, plus we have the usual chiara-based backup so I think we're in good hands.

Currently the branch and tag are protected - once we verify that everything works as expected post migration, I will open it up. I changed the directory structure of the models, need to confirm that the rtcds compilers don't have any hardcoded paths which may break due to my change.

The symlink to Matlab R2013 was deleted and a new symlink to R2015b was made. I activated the license using the Caltech campus license. Now running matlab from shell starts up R2015b yes. Simulink even works 😲 .

Attachment 1: ML2015b.png
  14833   Tue Aug 6 15:52:06 2019 gautamUpdateBHDPreliminary BHD calculations


The requirement on the phase noise on the direct backscatter from the OMC back into the SRM is that it be less than 10^{-5} \, \mathrm{rad/\sqrt{Hz}} \approx 10^{-12} \, \mathrm{m/\sqrt{Hz}} @ 100 Hz, for a safety factor (arbitrarily chosen) of 10 (= 20dB below unsqueezed vacuum). Assuming 5 optics between the OMC and SRM which contribute incoherently for a factor of sqrt(5), and assuming a total of 1 ppm of the LO power to be backscattered, we need the suspensions to be moving < 5 \times 10^{-13} \, \mathrm{m/\sqrt{Hz}} @ 100 Hz. This seems possible to realize with single stage suspensions - I assume we get f^4 filtering from the pendulum at 100 Hz, and that there is an additional 80 dB attenuation (from the stack) of the assumed 1 micron/rtHz motion at 100 Hz, for an overall 160 dB attenutaiton, yielding 10^-14 m/rtHz at 100 Hz.


This is the same calculation as I had posted a couple of months ago (see elog that this is a reply to), except that Koji pointed out that the LO power is expected to dominate the (carrier) power incident on the OMC cavity(ies). So the more meaningful comparison to make is to have the x-axes of the plots denote the backscatter fraction, \epsilon_{\mathrm{BS}} rather than the LO power. One subtlety is that because the phase of the scattered field is random, the displacement-noise induced phase noise could show up in the amplitude quadrature. I think that in these quadrature field amplitude units, the RIN and phase noise are directly comparable but I might have missed a factor of 2*pi. But in the worst case, if all the phase noise shows up in the amplitude quadrature, we end up being only ~10dB below unsqueezed vacuum (for 1 ppm backscatter). 

For the requirement on the noise in the intensity quadrature - I think this is automatically satisfied because the RIN requirement on the incident LO field is in the mid 10^-9 1/rtHz regime.

Attachment 1: OMCbackscatter.pdf
  14834   Tue Aug 6 16:44:50 2019 yehonathanUpdateLoss Measurement 

I grab 2 hours of the PD measurements using dlData_simple.ipynb in the misaligned state.

I get pretty much a normally distributed reading without drifts (Attachements 1 and 2).

The error in the reading is ~ 0.5%.


I am pretty sure this amount of noise is enough to explain the big noise in the Loss figure measurement.


The reason is that the loss formula is #(1-P_Locked/P_Misaligned+T1)-T2) where T1 and T2 are the transmissions of the ITM and ETM.

The average of the ratio P_Locked/P_Misaligned is ~ 1.01 for a loss figure of ~ 100ppm.

The standard deviation of the ratio is ~ 1% which is also the standard deviation of the expression in the brackets.

The average of this experssion however is ~ 0.01.

The reduction of the mean amplifies the error in the loss measurments by a factor of a few 10s!

Attachment 1: figure_1.png
Attachment 2: figure_1-1.png
  14835   Tue Aug 6 23:09:20 2019 gautamUpdateALSEY table work
  • Removed power monitoring PD (It was off anyways)
  • Installed Steering mirror and collimator in K6XS mount (fast axis = p-pol to best effort by eye)
  • Installed lens mounts in approx position
  • Cleaned fiber at EY and connected to the collimator
  • Coupled EY--->PSL and spare PSL-->EY fibers together at the PSL table to facilitate coupling.
  • tbc tomorrow...

Couple IR light into fiber with good MM at EY

  14836   Thu Aug 8 12:01:12 2019 gautamUpdateIOOMC1 suspension oddness

At ~1am PDT today, all the MC1 shadow sensor readbacks (fast CDS channels and Slow Acromag channels, latter not shown here) went to negative values. Of course a negative value makes no sense. After ~3 hours, they came back to positive values again. But since then, the shadow sensor RMS noise has been significantly higher in the >20 Hz band, and there are frequent glitches which kick the suspension. The IMC has been having trouble staying locked. I claim that this has to do with the Satellite box.

No action being taken now while I work on the ALS. In the past the problem has fixed itself.

Attachment 1: MC1_suspension.png
Attachment 2: MC1_suspension.pdf
  14837   Fri Aug 9 08:59:04 2019 gautamUpdateCDSPrep for install of c1iscaux

[chub, gautam]

We scoped out the 1Y3 rack this morning to figure out what needs to be done hardware wise. We did not think about how to power the Acromag crate - the LSC rack electronics are all powered by linear supplies and not Sorensens, and the linear supplies are operating at pretty close to their maximum current-drive. The Acromag box draws ~3A of current from the 20 V supply, not sure what the current draw will be from the 15 V supply. Options:

  1. Since there are sorensens in 1Y2 and 1Y1, do we really care about installing another pair of switching supplies (+20 V DC and +15 V DC) in 1Y3?
    • Contingent on us having two spare Sorensens available in the lab. Chub has already located one.
  2. Use the Sorensens installed already in 1Y1. 
    • Probably the easiest and fastest option.
    • +15 V already available, we'd have to install a +20 V one (or if the +/-5 V or +12 V is unused, reconfigure for +20 V DC).
    • Can argue that "this doesn't make the situation any worse than it already is"
    • Will require the running of some long (~3 m) long cabling to bring the DC power to 1Y3 where it is required. 
  3. Get new linear supplies, and hook them up in parallel with the existing.
    • Need to wait for new linear supply to arrive
    • Probably expensive
    • Questionable benefit to electronics noise given the uncharacterized RF pickup situation at 1Y2

I'm going with option #2 unless anyone has strong objections.

  14838   Fri Aug 9 16:37:39 2019 gautamUpdateALSMore EY table work


  1. 220 uW / 600 uW (~36 % mode-matching) of IR light coupled into fiber at EY.
  2. Re-connected the RF chain from the beat mouth output on the PSL table to the DFD setup at 1Y2.
  3. A beat note was found between the PSL and EY beams using the BeatMouth.


We want to know that we can lock the interferometer with the ALS beat note being generated by beating IR pickoffs (rather than the vertex green transmission). The hope is also to make the ALS system good enough that we can transition the CARM offset directly to 0 after the DRMI is locked with arms held off resonance.


Attachment #1: Shows the layout. The realized MM is ~36 %. c.f. the 85% predicted by a la mode. It is difficult to optimize much more given the tight layout, and the fact that these fast lenses require the beam to be well centered on them. They are reasonably well aligned, but I don't want to futz around with the pointing into the doubling crystal. Consequently, I don't have much control over the pointing.

Attachment #2: Shows pictures of the fiber tips at both ends before/after cleaning. The tips are now much cleaner.

The BeatMouth NF1611 DC monitor reports ~580 mV with only the EY light incident on it. This corresponds to ~60 uW of light making it to the photodiode, which is only 25% of what we send in. This is commensurate with the BS loss + mating sleeve losses.

To find the beat between PSL and EY beams, I had to change the temperature control MEDM slider for the EY laser to -8355 cts (it was 225 cts). Need to check where this lies in the mode-hop scan by actually looking at the X-tal temperature on the front panel of the EY NPRO controller - we want to be at ~39.3 C on the EY X-tal, given the PSL X-tal temp of ~30.61 C. Just checked it, front panel reports 39.2C, so I think we're good.

Next steps:

  • Fix the IMC suspension
  • Measure the ALS noise for the Y arm
  • Determine if improvements need to be made to the IR beat setup (e.g. more power? better MM? etc etc).

EY enclosure was closed up and ETMY Oplev was re-enabled after my work. Some cleanup/stray beam dumping remains to be done, I will enlist Chub's help on Monday.

Attachment 1: IMG_7791.JPG
Attachment 2: fiberCleaning.pdf
  14839   Fri Aug 9 20:58:33 2019 JonUpdateElectronicsBorrowed Variac transformer

I borrowed an old-looking Variac variable transformer from the power supplies cabinet along the y-arm. It is currently in the TCS lab.

  14840   Sun Aug 11 11:47:42 2019 gautamUpdateCDSBench test of c1iscaux

I bench tested the functionality of all the c1iscaux Acromag crate channels. Summary: we are not ready for a Monday install, much debugging remains.

  1. DAC channels were tested using 4 ch oscilloscope and stepping the whitening gain sliders through their 15 gain settings
    • Response was satisfactory - the output changes between 0 - 5 V DC in 15 steps.
    • This analog voltage is converted to binary representation by an on-board ADC on the whitening boards. So we may have to tune the offset voltage and range to avoid accidental bit flipping due to the analog voltage of a particualr step falling close to the bit-flipping edge of the on-board ADC. This will require an in-situ test.
    • Test passed
  2. BIO output channels were tested using a DMM, and monitoring the resistance between the BIO pin and the RTN pin. In the "ON" state, the expected resistance is ~5 Mohm, and in the off state, it is ~3 ohms.
    • The AA filter switches on BIO1 unit do not show the expected behavior - @ Chub, please check the wiring.
    • All others (except the mbboDirect bits, see next bullet) were okay, including those for the CM board that are NOT part of the mbboDirect groups.
    • Test failed
  3. ADC channels were tested by driving a ~2Vpp 300mHz sine wave with a function generator, and looking at the corresponding EPICS channel with StripTool.
    • I found that all the ADC channels don't function as expected.
    • Part of the problem is due to incorrect formatting of the EPICS records in the db files, but I think the ADCs also need to be calibrated with the precision voltage source.
    • Why only ADCs require calibration and not the DACs????
    • Test failed
  4. mbboDirect BIO output test - I made a little LED breadboard tester kit to simultaneously monitor the status of these groups of binary outputs.
    • The LSB is toggled as expected when moving the gain slider along.
    • However, the other bits in the group are not toggled correctly.
    • I believe this is a problem with either (i) the way the EPICS record is configured to address the bits or (ii) the incorrect modbus datatype is used to initialize the ioc.
    • It will be helpful if someone can look into this and get the mbboDirect bits working, I don't really want to spend more time on this.
    • Test failed

I am leaving the crate powered (by bench supplies) in the office area so I have the option to work remotely on this.

  14841   Mon Aug 12 17:36:04 2019 gautamUpdateCDSMore bench test of c1iscaux

[chub, gautam]

With Chub's help, most of the problems have been resolved. Summary: I judge that we are good to go ahead with an install tomorrow.

  1. The problem with the BIO channels was a mis-wiring internal to the chassis - Chub fixed this and now all 32 AA enable/disable switches seem to work as advertised. Of course we will need to do the in-situ test to make sure.
  2. The problem with the ADC channels were multiple:
    • On the software end, I had gotten some addressing wrong - this was fixed.
    • On the hardware side - even though the inputs of the Acromag are "differential", I found that the readback was extremely noisy (~0.5 V RMS for a 3 V DC signal from the handheld calibrator unit 😲 ). Looking through the manual, I found a recommendation (pg10) that the "IN-" terminal of the Acromag ADC units be tied to the "RTN" pins on the same units. I don't know if this preserves the differential receiving capability of the Acromag ADCs - anyways, after Chub implemented this change, all the Analog Input channels behave as expected (I tested with a DC voltage and also a 200 mHz sine wave from a function generator).
    • Note that most of the Eurocard electronics we use are single-ended sending anyways.
    • What does this mean for the other Acromag ADCs (e.g. OSEM Shadow Sensor monitors) we have installed????? I saw no documentation in the elog/wiki.
  3. Binary input channel:
    • This is used by the "CM LIMIT" channel.
    • I found that I had to initialize a separate alias for the BIO3 unit, which acquires this signal, to use the modbus function "4" corresponding to "Read Input Registers" - c.f. the binary output modbus function 6, which is to "Write Single Register".
    • The fix for the mbbo channels is also likely to be along this lines - but I don't have the energy for that endavor right now.
  4. Testing of the physical mbboDirect bit channels using the Acromag Window utility
    • I can't get the mbboDirect EPICS record to work as expected, so I decided to use the native Acromag utility to test the functionality
    • First I released control of the acromags from the supermicro (stopped modbus)
    • There were several wiring errors - Chub had left for the day so I just fixed it myself.
    • The LED tester kit was used to check that the correct bits were flipped - they were.
  5. At the time of writing, the non-functional channels (in EPICS) are all related to the CM board:
    • C1:LSC-CM_LIMIT (binary input) tested later in the day, works okay...
    • C1:LSC-CM_REFL1_BITS (mbboDirect)
    • C1:LSC-CM_REFL2_BITS (mbboDirect)
    • C1:LSC-CM_AO_BITS (mbboDirect)
    • C1:LSC-CM_BOOST2_BITS (mbboDirect)

Since we don't immediately need the CM board, I say we push ahead with the install - at least that will restore the ability to lock PRMI / DRMI. Then we can debug these issues in situ - I'm certain the issue is related to the EPICS/Modbus setup and not the hardware because I verified the physical channel map using the Acromag windows utility.

Remaining Tasks:

  1. Install power supply cables at 1Y3
  2. Install supermicro and Acromag crates in 1Y3
  3. Migrate existing P1 connectors to P2 where applicable (Whitening boards)
  4. Connect Dsub-->P1 / P2 adaptors
  5. Run in-situ tests

I bench tested the functionality of all the c1iscaux Acromag crate channels. Summary: we are not ready for a Monday install, much debugging remains.

Attachment 1: iscauxCheclist.pdf
ELOG V3.1.3-