40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 43 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  14941   Fri Oct 4 22:22:03 2019 gautamUpdateCDSFinal incarnation of latch.py

[KA, GV]

This elog is meant to be a summary of some of the many subtleties on the CM board. The latest schematic of the version used at the 40m can be found at D1500308 .

Latch logic:

  • There are several Binary Outputs and one Binary Input to the CM board.
  • The outputs control ENABLE/DISABLE switches and gains of amplifier stages, while the input reports whenever the limiter has been reached.
  • The variable gain feature is implemented by enabling/bypassing several cascaded fixed gain stages. So in order to change the gain of a single composite amplifier stage, multiple individual amplifier stages have to be switched.
  • This is implemented by the user interacting with the hardware via a "control word", consisting of a number of bits depending on the number of cascaded stages that have to be switched. 
  • This control word is sent to the device via modbus EPICS, which is an asynchronous communication protocol. Hence, it may be that the individual bits composing the control word get switched asynchronously. This would be disastrous, as there can be transient glitches in the gain of the stage being controlled. 
  • To protect against such problems, there is a latch IC in the hardware between the Binary Inputs to the board (= Binary Outputs from Acromags), and the actual switches (= MAX333) that enable/bypass the cascaded gain stages. The latch IC used is a SN74ALS573. This device acts as a bus, which transmits/blocks changes for multiple bits (= our control word) from propagating, depending on the state of a single bit (= the LATCH ENABLE bit). Thus, by controlling a single bit, we can guarantee that multiple bits get switched synchronously
  • In order to use this latch capability, we need some software logic that sets/disables the LATCH ENABLE bit. For our system, this logic is implemented in the form of a continuously running python 🐍 script, located at /cvs/cds/caltech/target/c1iscaux/latch.py. It is implemented as a systemctl service on the c1iscaux Supermicro. The logic implemented in this script is shown in Attachment #1. While the channels referred to in that attachment are for REFL1_GAIN, the same logic is implemented for REFL2_GAIN, AO_GAIN, and the SuperBoosts.
  • Some FAQ:
    1. Q: Why do we need the soft channels C1:LSC-REFL1_SET_LSB and C1:LSC-REFL1_SET_MSB?
      A: These soft channels are what is physically linked to the Acromag Binary Outputs. In order for our latch logic to be effective, we need to detect when the user asks for a change, and then disable the LATCH ENABLE bit (which is on by default, see FAQ #3) before changing the physical acromag channels. The soft channels form the protective layer between the user and the hardware, allowing latch.py to function.
    2. Q: Why is there an "_MSB" and "_LSB" soft channel? 
      A: This has to do with the mbboDirect EPICS channel type, which is used to control the multiple bits in our control word using a single input (= an MEDM gain slider). The mbboDirect data-type requires the bits it controls to have consecutive hardware addresses. However, the Acromag hardware addressing scheme is not always compatible with this requirement (see pg 33 of the manual for why this is the case). Hence, we have to artifically break up the control word into two separate control words compatible with the Acromag addressing scheme. This functionality is implemented in latch.py.
    3. Q: Why is the default state of LATCH ENABLE set to ON? 
      A: This has to do with the fact that all Binary Inputs, not just the multi-bit ones, to the CM board are propagated to the control hardware via a latch IC. For the single-bit channels, there is no requirement that the switching be synchronous. Hence, rather than setting up ~10 more single-bit soft channels and detecting changes before propagating them, we decided to leave the LATCH ENABLE ON by default, and only disable it when changing the multi-bit gain channels. This is the same way the logic was implemented in the VME state code, and we think that there are no logic reasons why it would fail. But if someone comes up with something, we can change the logic.

Acromag BIO testing:

During my bench testing of the Acromag chassis, I had not yet figured out mbboDirect and the latch logic, so I did not fully verify the channel mapping (= wiring inside the Acromag box), and whether the sitching behavior was consistent with what we expect. Koji and I verified (using the LED tester breakout board) that all the channels have the expected behavior 👏. Note that this is only a certification at the front-panel DB37 connectors of the Acromag chassis  testing of the integrated electronics chain including the CM board is in progress...

Attachment 1: LatchLogic.pdf
  14940   Fri Oct 4 14:25:59 2019 aaronUpdateGeneralMake the Jenne-laser setup fiber-coupled


The fiber-coupled PD seems to have a factor of ~1.5 difference in responsivity compared to the free-space PD. There are some differences in the two ways I made the measurement that I don't yet understand.


I measured relative responsivities of the fiber and free coupled NewFocus 1611 PDs (scaled by the Jenne AM transfer function).

I made the measurement in two ways, see attachment threeIn attachment oneI show the response for separately measuring the two PDs relative to a pickoff of the source (two-port thru calibration). In attachment two I measure the relative responses directly, without picking off a reference (three-port calibration). I scaled the transfer functions by their DC voltages; both PDs have transimpedances of 700 V/A.

However, there are some clear differences in the response (overall factor of 0.5dB offset that may be explained by a miscalibrated DC level; apparent periodicity in attachment 1) that I don't yet understand.The free path of the non-fiber PD is ~5-6 inches, which accounts for the ~45 degrees of phase advance of the fiber relative to free coupled PD signal. (12.7cm / (c / 300 MHz) * 360 degrees ~ 45 degrees)

I didn't find Agilent's manual very helpful for learning about the available calibration schemes, and didn't find a resource online that I liked -- is there a good one?
I think I want to characterize the WFS heads treating the DUT as a three-port device (AM in, ref PD, WFS segment PD).
Attachment 1: PD_norm.pdf
Attachment 2: PD_AB.pdf
Attachment 3: JenneAM_fiberPD_cals.pdf
  14939   Fri Oct 4 01:57:09 2019 KojiUpdateCDSc1iscaux testing

The AA filter for ASDC was fixed.

== Test Status ==

[done] Whitening gain switching test
[done] AA enable/disable switching
[0th order] LO Det Mon channel check
[none] PD I/F board check
[done] QPD I/F board check
[none] CM Board
[none] ALS I/F board

The AA filter for the 4th section of the LSC analog electronics bank (D000076) was pulled out for the test. On the workbench, questionable CH8 was checked. It tuned out that the filter amplifier module for the 8th-order elliptic filter at 7.5kHz was not properly working and exhibited unusual attenuation. This filter module (Frequency Devices Inc D68L8E-7.50kHz) was desoldered and replaced with a module from a spare board. Note that Gautam and I had tried to use this spare board instead of the current one, but it didn't give us any signal for an unknown reason. Since the desoldering required a lot of force and had a risk of damaging the PCB, a socket was made from an IC socket (see Attached 1). This change made CH8 functioning equally to the other channels do.

I took this opportunity to ckech the performance of the AA filters. For each channel, the input signal was injected from J3 using a pomona clip. The output was taken from pin 1, 5, 9, ... of J2. This is the + side of the differential output. The - side just has the equivalent performance but the signal polarity. The digital signals for the AA bypass switches were not connected. Fortunately, this was just fine as it made the anti-aliasing filters engaged.

Attachment 2 shows the transfer functions of all the channels. All the channels showed an identical response (at least visually). The transfer function for CH1 was fitted by LISO. The ZPK values are listed here:

pole 5.2860544577k 503.1473053928m
pole 5.9752193716k 1.0543411596
pole 8.9271953580k 3.5384364788
pole 8.2181747850k 3.4220607928
pole 182.1403534923k 1.1187869426 # This has almost no effect
zero 13.5305051680k 423.6130434049M
zero 15.5318357741k 747.6895990654k
zero 23.1746351749k 1.5412966100M

factor 989.1003181564m
delay 24.4846075283n

Attachment 3 shows the ASD of the output voltage noise measurement. Note the input was shorted for this measurement. The nominal output voltage was found to be 0.1 uV/rtHz and the 1/f noise corner freq was about 100Hz. Only CH3 showed a deviation from the typical values. It looks like this is neither an artifact nor transient noise. Fortunately, nothing is connected to this channel right now.

Attachment 1: P_20191003_172956_vHDR_On.jpg
Attachment 2: TF.pdf
Attachment 3: PSD.pdf
Attachment 4: 191003_AA_Filter.zip
  14938   Fri Oct 4 00:32:24 2019 gautamUpdateALSMore locking updates


I managed to achieve a few transitions of control of the XARM length using the ALS error signal. The lock is sort of stable, but there are frequent "glitches" in the TRX level. Needs more noise hunting, but if the YARM ALS is also "good enough", I think we'd be well placed to try PRMI/DRMI locking with the arms held off resonance (while variable finesse remains an alternative).


Attachment #1One example of a lock stretch. 

Attachment #2ASD of the frequency noise witnessed by POX with the arm controlled by ALS. The observed RMS of ~30pm is ~3-4 times higher than the best performance I have seen, which makes me question if the calibration is off. To be checked...

Attachment 1: ALS_singleArm.png
Attachment 2: ALS_OOL_20191003.pdf
  14937   Fri Oct 4 00:30:31 2019 gautamUpdateGeneralMake the Jenne-laser setup fiber-coupled

I think the metric of interest here is the consistency of the AC transimpedance of the proposed new "Reference PD" (= fiber coupled NF1611) vs the old reference (free space NF1611), since everything will be calibrated against that.


Something still looks very wrong -- the PD is supposed to be flat out to 1GHz, and physical units pending, need food.

  14936   Thu Oct 3 23:15:39 2019 KojiUpdateGeneralMake the Jenne-laser setup fiber-coupled

The 1GHz PD has a bit more flat response, but the laser and the driving network have more frequency dependence as you saw.

  14935   Thu Oct 3 21:50:22 2019 ranaUpdateComputersrossa revival

Got the network to work again just by unplugging the power cord and letting it sit for awhile. But corrupted OS by trying to install Nvidia drivers.


  14934   Thu Oct 3 21:05:04 2019 aaronUpdateGeneralMake the Jenne-laser setup fiber-coupled

I measured the RF response of the fiber-coupled NewFocus 1611, calibrating out the cable delay. The laser current was set to 20.0 mA, and the RF power going into the splitter was -10 dBm. The DC voltage was 1.87 V, and Gautam and I measured the power from the fiber at 344uW.

Something still looks very wrong -- the PD is supposed to be flat out to 1GHz, and physical units pending, need food.

Attachment 1: PD_response.pdf
  14933   Thu Oct 3 19:40:18 2019 gautamUpdateLSCPOX/POY imbalance


There is an imbalance between the POX and POY detector outputs reported in the CDS system. Possibilities are (i) the POX PD has a uncoated glass window whereas POY does not or (ii) there is some problem in the elctronics.


  1. Nominally, we run the POX/POY locking with +18dB whitening gain on POY and +30 dB on POX. This is a factor of 4 difference.
  2. The DC levels reported in C1:LSC-POXDC_OUT and C1:LSC-POYDC_OUT differ by a factor of 10 (24 cts for POY vs 2.4 cts for POX with 0dB whitening gain). These channels come from the P2 connector on the back of the PD Interface board into the fast CDS system.
  3. The levels reported by the Acromag system (which come out of the P1 connector) are 60mV for POY  vs 15 mV for POX.
  4. I confirmed that this imbalance is not due to clipping on the POX photodiode - I tweaked the steering mirror and observed the plateau (I did not, however, look at the beam on the PD active area with an IR viewew which would be a more conclusive test).
  5. I measured the power incident on either PD (using Ophir power meter, filter OFF). They were both ~10uW, as expected since the beam extraction for POY and POX are identical - a single HR mirror and the vacuum viewport.

Update 820pm: 

  1. I checked that there is no glass window on the PD.
  2. It is hard to see the beam on a viewer - but with the PRM aligned, I think I convinced myself that the beam is pretty well centered on the PD. 

So increasingly, it looks like the electronics are the source of the problem.

  14932   Thu Oct 3 14:54:33 2019 KojiUpdateGeneralMake the Jenne-laser setup fiber-coupled

I'm afraid that the RF modualtion of the laser is nonlinear and the electrical and optical resoponse is dependent on the LD pumping current and RF input power. So I feel safe if we keep the reference PD. Of course, this is my feeling and it should be quantitatively tested.

  14931   Thu Oct 3 14:32:37 2019 ranaUpdateGeneralMake the Jenne-laser setup fiber-coupled

I'm curious to see if we really need the 1611, or if we can calibrate the diode laser vs. the 1611 one time and then just use that calibration to get the absolute cal for the DUT.

  14930   Thu Oct 3 12:08:47 2019 gautamUpdateGeneralMake the Jenne-laser setup fiber-coupled

I propose the following re-organization of the PDFR measurement breadboard. We have all the parts on hand, just needs ~30mins of setup work and some characterization afterwards. The fiber beamsplitter will not be PM, but for this measurement, I don't think that matters (the patch fiber from the diode laser head isn't PM anyways). We have one spare 1 GHz BW NF1611 that is fiber coupled (used to live on the ITMY in-air table, and is (conveniently) labelled "REF DET", but I'm not sure what the function of this was). In any case, we have at least 1 free-space NF1611 photodiode available as well. I suggest confirming that the FC version works as expected by calibrating against the free space PD first.

Update 245pm: Implemented, see Attachment #2. Aaron is testing it now, and will post the characterization results.

Attachment 1: PDFR_tabletop.pdf
Attachment 2: IMG_8014.JPG
  14929   Thu Oct 3 11:38:35 2019 aaronUpdateIOOWFS measurements

I set up the spectrum analyzer to make the WFS head RF transfer function measurement (V/W) on WFS1. I placed the Jenne laser on the AP table, along with the reference PD power supply, laptop, and laser power supply. The Agilent output AM modulates the laser; the reference PD is again NewFocus 1611, with its AC output sent to Agilent's R channel and DC output sent to an oscilloscope;

At Koji's suggestion, I've started setting up a small breadboard to hold the fiber collimator, BS, and reference PD. I haven't really used fiber optics before, I'd appreciate another set of eyes before I get too deep.
Gautam showed me the collimator and fiber BS.

I closed the PSL shutter while checking for a location to place the breadboard, and opened it while writing this. Headed back to Cryo to pick up the large incandescent bulb we'd borrowed over the summer.

  14928   Thu Oct 3 11:01:18 2019 ranaUpdateLSC(PR)FPMI locking

wonder if its possible to do variable finesse locking

Gabriele mentioned that Virgo used arm trans PDH for this, but I guess we could possibly use POX/POY to start and bring in the PRM with 50% MICH trans

  14927   Wed Oct 2 23:23:02 2019 gautamUpdateCDSc1oaf DC indicator needs to be green

Today, I found out that this type of "0x2bad" DC error is connected to the 1e+20 cts output. The solution was to bite the bullet and stop/start the c1oaf model (at the risk of crashing the vertex FEs). Today, I was lucky and the model came back online with all CDS indicators green. At which point I was able to engage length feedforward to MC2 (with some admittedly old filter). Some subtraction is happening, see Attachment #1. This was just meant to test whether the signal routing is happening - the feedforward signal goes to the "ALTPOS" input of the suspension CDS block, which AFAIK does not have a corresponding MEDM EPICS indicator. So I couldn't figure out whether the feedforward control signal was in fact making it to the suspension. On the evidence of the suppression of MCL in the 1-3 Hz band, I would conclude that it is. Useful to be able to engage these FF filters for better lockability.


Attachment #1 - the vertex seismometer input produces 1e+20 cts at the output of the feedforward filter. Attachment #2 shows the shape of the feedforward filters - doesn't explain the saturation. Since this is a feedforward loop, a runaway loop can't be the explanation either.

Attachment 1: MCL_FF_Test.pdf
  14926   Wed Oct 2 23:15:02 2019 gautamUpdateLSCFPMI locking


I was able to lock the FPMI. The lock was quite stable. However, the fluctuations in the ASDC power suggest that it will be difficult to make a DC measurement of the contrast defect in this configuration. This problem can be circumvented in part by some electronics tuning. However, the alignment jitter couples some HOM light which is an independent effect. Can this be a good testbed for the proposed AS WFS system? 


  • First, the arm cavities were locked and TRX/TRY were maximized using ASS.
  • Next, AS55_Q-->MICH_A (MICH-->BS) matrix element was set to 1 in the LSC input (output) matrix. The trigger was set to always on.
  • AS55 digital demod phase was -37 degrees.
  • I was then able to increase the gain on the MICH servo and turn on some integrators without any problem.
  • Some guesswork had to be done to get the correct sign. Final servo gain used was -0.8. 

I didn't do any serious budgeting yet - need to think about / do some modeling on how this configuration can be made useful.

Attachment 1: FPMIlocked.png
  14925   Wed Oct 2 20:45:18 2019 ranaUpdateComputersrossa revival

Formatted and re-installing OS on rossa for the 3rd or 4th time this year. I suggest that whoever is installing software and adjusting video settings please stop.

If you feel you need to tinker deeply, use ottavia or zita and then be prepared to show up and fix it.

While I was moving the UPS around, the network lights went out for Rossa, so I may have damaged the network interface or cable. Debugging continues.

  14924   Wed Oct 2 11:52:16 2019 gautamUpdateLSCPRMI Oplev loop checkout

I measured the OLTF of both the PRM Oplev loops. Nothing odd sticks out as odd to me in this measurement - there seems to be ~40 degrees of phase margin and >10 dB gain margin for both loops, see Attachment #1. I didn't measure down to the second UGF at ~0.2 Hz (the Oplev loops are AC coupled), so there could be something funky going on there. The problem still persists - if I misalign and realign the PRM using the ifoalign scripts, the automatic engagement of Oplev loops causes the loop to oscillate. Could be that the script doesn't wait for long enough for the alignment transient to die out.

Update 1230pm: Indeed, this was due to the integrator transient. It dies away after a couple of seconds.


The PRMI Oplev servo needs some tuning, it is currently susceptible to oscillations in Pitch.

Attachment 1: PRM_OLTF.pdf
  14923   Wed Oct 2 10:50:20 2019 gautamUpdateCDSAnaconda updated

The anaconda distribution used by the control room workstations is actually installed on the shared drive (/cvs/cds/ligo/apps/anaconda/) for consistency reasons. The version was 4.5.11. I ran the following commands to update it today. Now it is version 4.7.12.

conda update conda
conda update anaconda

The second command takes a while to resolve conflicts, so I've left it running inside a tmux session for now.

Recall that the bash alias for using the anaconda managed python is "apython". I recommend everyone set up a virtual environment when trying out new package installs, to avoid destroying the locking scripts.

  14922   Wed Oct 2 10:40:07 2019 gautamUpdateCDSc1oaf model restarted

This morning, I restarted the c1oaf model on the c1lsc machine, so as to have the option of enabling some feedforward action. Unsurprisingly, the "DC" indicator is red, citing a "0x2bad". In the past, I've been able to correct this by simply restarting the model. But given the fragility of the c1lsc machine, I think I'll live with not having the OAF model signals in frames. Medium-term, I'd like to pare down the c1oaf model a bit - I think it has way too many options/matrices right now, and is an un-necessarily bloated and heavy model. Unless there are serious objections, I will do this work when I next feel like it.

Attachment 1: c1oafRestart.png
  14921   Wed Oct 2 01:11:40 2019 KojiUpdateCDSc1iscaux testing

I worked on more troubleshooting of the whitening filters Tuesday afternoon

== Test Status ==

[done] Whitening gain switching test => Remaining issues ASDC overall behavior
[done] AA enable/disable switching
[0th order] LO Det Mon channel check
[none] PD I/F board check
[done] QPD I/F board check
[none] CM Board
[none] ALS I/F board

Issue 1: POP110Q did not show any gain switching [Resolved]

A DB37 breakout board was connected to the acromag front panel. I found that Ch6 (POP110Q) did not show any differential DC output. I searched around the other pins and found that the corresponding signal showed up on PIn36  instead of Pin35. Opening the front panel revealed that the internal wiring was wrong (Attachment 1). The wire which should have gone to Pin 35 was connected to Pin 36. By correcting the wiring, POP110Q started to show identical behavior to POP110I. (Attachment 2)

Issue 2: LSC reboot [Resolved]

A rough activity around the acromag chassis crashed c1lsc realtime processes (as usual). I ran usual rebooting script /opt/rtcds/caltech/c1/scripts/cds/rebootC1LSC.sh. This successfully restored the status of the vertex RT processes.

Issue 3: REFL33 different behavior between I and Q [Resolved]

REFL33I and Q consistently showed a difference (Attachment 3). The whitening board was pulled out and powered with an extension card. The raw outputs were checked with a function generator and an oscilloscope connected. The outputs for 33I and Q were identical (Attachment 4). So I concluded that the observed difference was an artifact of the checking script.

Issue 4: Whitening 3_8 did not switch at all [Resolved]

To switch the gain stages, each channel of the whitening board takes a DAC output from acromag and convert it into 4bit digital signals. For CH8 of the WF#3, this signal did not reach the instrumentation amplifier AD620. After tracing the signal on the electronics bench, it was found that the CH8 gain input to the DIN96 connector is not conducive to the input of the AD620. As there were no exposed pads between the DIN96 connector and the AD620 input (pin2), a wire was additionally soldered (forgot to take a photo). This solved the gain switching issue as the test result indicates (Attachment 5). The noisiness came from the whitening filter which can not be turned off right now. For this reason, the test of the whitening part is pending too.

The StripTool plot during the overall WF#3 test is shown in Attachment 6.

Issue 5: ASDC behavior [Unresolved]

First of all, at this test, I found that WF#4 was not responding to the gain change at all. This issue was restored by power cycling the acromag chassis (as usual).

The whitening filter #4 was pulled, and the behavior of CH5,6,7,8 (CH8=ASDC) was compared. It was found that the analog outputs were identical and the problem lies further downstream.

Issue 6: Illeagal REFL11 LO cable [Unresolved]

This is a newly found issue. The cable between the LO distributor and the REFL11 demodulator is not the legit solder soaked RG402 coax, but flexible coax (Attachment 7). This cable needs to be replaced in the end. But for today, it was not so that we can have a consistent configuratin as before.

Issue 7: Signature of a damaged POPDC cable [Resolved]

The cable for POPDC cale indicated some damage at the WF#4 side. It was not a complete damage, and therefore the solder coating was added (Attachment 8).

Attachment 1: WF3_wiring.png
Attachment 2: POP110.pdf
Attachment 3: REFL33.pdf
Attachment 4: P_20191001_174548_vHDR_On.jpg
Attachment 5: Whitening3_8.pdf
Attachment 6: Screenshot_WF3_191001.png
Attachment 7: P_20191001_181052_vHDR_On.jpg
Attachment 8: POPDCcable.png
  14920   Tue Oct 1 21:19:51 2019 gautamUpdateLSCPRMI locked on carrier


The PRMI was locked with the carrier field resonant in the PRC 🙌. The lock is pretty stable (I only let it stay locked for ~10mins and then deliberately unlocked to see if I could readily re-lock, but it has stayed locked for the last ~20mins while I typed this up). See Attachment #1 for the DC power monitor StripTool for a short section of lock.


  • This is the opposite of the config we'd want usually for locking the IFO, but it is a useful configuration for setting the alignment of the vertex optics, and also to train angular feedforward filters, so I decided to try it out.
  • Some patient alignment work was required. I started with the single arm locks, maximized TRX/TRY with ASS, and then misaligned the ETMs and brought the PRM into alignment.
  • The PRM Oplev spot was roughly centerd on its QPD once I judged I was getting decent PRMI cavity flashes on the POP camera. The PRMI Oplev servo needs some tuning, it is currently susceptible to oscillations in Pitch.
  • The error signals used were: REFL11_I ---> PRCL and AS55_Q ---> MICH.
  • The whitening gains were: REFL11 --> +18 dB, AS55 ---> +6 dB.
  • Triggering was done using POPDC, this worked better for me than any of the RF signals (e.g. POP22/POP110). Trigger ON --> 200cts, Trigger OFF --> 100 cts.
  • The DCPD whitening gains may not be set correctly - I think I remember POPDC being ~4000 cts in this configuration, but it may also be that we are not well centered on the POP photodiode.
  • The dominant cause of the POP circulating power seems to be the usual angular instability ascribed to the TTs. The OAF model wasn't running tonight (and I didn't want to try starting it and have to do a full vertex FE reboot tonight) so I didn't get a chance to engage the angular FF.

Next (for LSC activities):

  • PRMI locking with the sidebands resonant in the PRC.
  • DRMI locking

I'm leaving the LSC mode off for tonight, but with the PRMI optics aligned and ETMs misaligned.

Attachment 1: PRMIlocked.png
  14919   Tue Oct 1 18:35:12 2019 gautamUpdateGeneralBeam centering campaign
  1. With TRX and TRY maximized using ASS, I centered the Oplev spots on the respective QPDs for the four test masses and the BS. I also centered the spot onto the IPPOS QPD by moving the available steering mirror.
  2. At EX, I tweaked the input pointing of the green beam into the arm by manually twiddling with the PZT mirrors. I was able to get GTRX~0.4.
  3. On the AS table - Koji and I found that there was a steering mirror placed in the AS beam path such that there was no light reaching the AS110 or AS55 PDs. Please - when you are done with your measurement, return the optical configuration to the state it was in before so that the usual locking activity isn't disturbed by a needless few hours troubleshooting electronics.

Once Koji is done with his checkout of the whitening electronics, I will try and lock the PRMI.

  14918   Mon Sep 30 18:20:26 2019 gautamUpdateALSALS OOL noise - a first look

Attachment #1 shows a first look at the IR ALS noise after my re-coupling of the IR light into the fiber at EY. 

Measurement configuration: 

  • Each arm length was individually stabilized to the PSL frequency using POX/POY locking.
  • The respective AUX laser frequencies were locked to the arm cavity length using the AUX PDH loops.
  • GTRX ~0.3 (usually I can get ~0.5) and GTRY ~ 0.2 (the mode-matching to the arm cavities is pretty horrible as suggested by the multitude of bullseye modes seen when toggling the shutter).
  • The control signal to the AUX PZT had the DC part offloaded by the slow temperature control servos to the AUX laser crystal temperature.

CDS model changes:

  • The c1lsc model was modified to route the input signals to the Y phase tracker servo from ADC1_2 and ADC1_3 (originally, they were ADC0_20 and ADC0_21).
  • This change was necessary because the DFD output is sent differentially to the ADC1 card in the c1lsc expansion chassis (bypassing the iLIGO whitening and AA electronics, for now just going through an aLIGO AA board with no whitening available yet).
  • I chose to use the differential receiving (as opposed to using the front-panel single ended BNC connectors) as in principle, it is capable of delivering better noise performance.
  • After making the model changes, I compiled and restarted the model. Apart from the missing path issue, the compile/restart went smoothly.

Next steps:

  • Get the easy fixes done (better GTRX, GTRY).
  • Test the noise with POX and POY as the OOL sensors, and the arms controlled using the ALS error signal - this is the relevant metric for how ALS will be used in locking.
  • Noise budget. Need to double-check the DFD output calibration into Hz.
  • For the general interferometer recovery, I think I will push ahead with trying to lock some other configurations like the PRMI (should be easy to recover), DRMI (potentially more difficult to find the right settings), and the FPMI (I'd like to use this config to get an estimate for how much contrast defect we have in the interferometer, but I think it'll be pretty challenging to lock in this configuration).
Attachment 1: ALS_OOL_20190930.pdf
  14917   Mon Sep 30 17:04:30 2019 gautamUpdateCDSSome path changes

I made some model changes to c1lsc. To propagate the changes, I tried the usual rtcds make sequence. But I got an error about the model file not being in the path. This is down to my re-organization of the paths to cleanly get everything under git version control. So I had to run the following path modification. Where is this variable set and how can I add the new paths to it? The model compilation, installation and restart all went smooth after I made this change. 

For smooth reboot of the models, I used the reboot script. I had to restart the daqd processes on FB, but now all the CDS indicator lights are green.

export RCG_LIB_PATH=/opt/rtcds/userapps/release/isc/c1/models/isc/:/opt/rtcds/userapps/release/isc/c1/models/cds/:/opt/rtcds/userapps/release/isc/c1/models/sus/:$RCG_LIB_PATH

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.

  14916   Mon Sep 30 15:51:59 2019 gautamUpdateCDSc1iscaux - some admin

I did the following:

  1. symlinked /cvs/cds/rtcds to /opt/rtcds.
  2. Added a line to /etc/systemd/system/modbusIOC.service that executes a burt-restore of the latest c1iscaux.snap file so that whitening gains etc are restored to their last saved value in the event of a service restart.
  14915   Mon Sep 30 14:16:43 2019 gautamUpdateLSCPOX PD checkout - solved

I confirmed that there is light incident on the POX photodiode. So the problem must lie downstream in the demod / whitening / AA electronics. With the PRM aligned (i.e. PRFPMI config with all DoFs uncontrolled), I could see the flashing beam on an IR card. I could also see the spikes in DC power incident on the photodiode using the "DC Monitor" port on the photodiode head and an oscilloscope.

Update 245 pm: I confirmed that I could see a 11 MHz sine wave by connecting the POX11 RFPD output cable at the 1Y2 end to an oscilloscope. The amplitude of this signal was also changing, corresponding to the cavity fringing in and out of resonance. I couldn't, however, see any signal on the RFPDmon port, or the I/Q demodulated output ports. So as of now, the culprit seems to be something on the Demod board. Further investigations underway...

Update 315pm: I did the following checks:

  1. Checked the LO signal level into a 50ohm input scope - it was ~720 mVpp, which was compatible with the LO level into the POY Demod board, so the LO signal level couldn't be to blame.
  2. Connected an RF funcgen to the PD input of the demod board. Drove it at 11.066210 MHz, 50 mVpp, and saw a signal 400 cts-pp in the CDS system - so the demod + digitizaiton electronics also seemed fine.
  3. #2, coupled with the fact I could see no signal at the RF-mon port of the demod board (even though there was a signal visible at the cable coming to 1Y2) suggested that the cable routing the POX11 PD output from the Heliax-breakout in 1Y2 to the demod board was busted - indeed this was the case!
  4. Koji replaced the cable without changing its length, and now the XARM locks readily 👏 . I ran ASS and got TRX ~ 0.95. See Attachment #1

Look for the POX beam with an IR viewer.

  14914   Mon Sep 30 13:20:55 2019 aaronUpdateIOOshot noise measurement

I wanted to measure the RF transimpedance of the WFS heads, as outlined above.

Summary: Measurement is not done.


  • closed the PSL shutter
  • taped over the WFS 2 opening with frosted scotch tape
  • illuminated the QPD with an incandescent flashlight.
    • All of the D batteries were close to dead, so it seemed dimmer than usual
  • Observed the WFS2 segment 1 RF spectrum on the Agilent, but saw no difference between the spectrum with and without the flashlight. Must need a brighter light, and possibly also better alignment.
  • Needed to skype someone and pass off the IFO to gautam, so I untaped the QPD, returned the appropriate LEMO connector, and opened the PSL shutter.
  14913   Mon Sep 30 11:42:36 2019 aaronUpdateComputerscontrol rm wkstns shutdown

I booted Rossa in rescue mode; though I see no errors on bootup, I still see the same error ("a problem has occurred") after boot, and a prompt to logout. I powered rossa off/on (single short press of power button), no change.

Booting in debug mode, I see that the error occurs when mounting /cvs/cds, with the error

[FAILED] Failed to mount /cvs/cds.
See `systemctl status cvs-cds.mount` for details.
[DEPEND] Dependency failed for Remote File System

Which is odd, because when I boot in recovery mode, is mounts /cvs/cds successfully. 

I booted in emergency mode by adding to the boot command


but didn't have the appropriate root password to troubleshoot further (the usual two didn't work).

  14912   Mon Sep 30 11:20:43 2019 gautamUpdateCDSc1iscaux testing - CM board code updated

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

I modified /cvs/cds/caltech/target/c1iscaux/latch.py and /cvs/cds/caltech/target/c1iscaux/C1_ISC-AUX_CM.db to set up the mbbo logic for the other three channels on the CM board, namely REFL2 Gain, AO Gain, and the Super boosts. The systemctl processes were restarted on c1iscaux. We are now ready to perform systematic checks on the CM board functionality.


The addressing of the Acromag BIO registers is done in a way that is kind of inconvenient to use the EPICS mbboDirect protocol

  • The control word going to the Acromag is 16 bits in length
  • However, only the 4 least significant bits actually correspond to physical channels - the remaining 12 bits are "unused".
  • Because each Acromag BIO unit has 16 BIO channels, this means that they are grouped into four "banks" of 4 bits each.
  • The mbboDirect EPICS/modbus protocol is used to control multiple physical BIO channels using a single input, which is exactly what we want for the gain sliders on the CM board. However, one caveat is that the bits need to be consecutive.
  • This means that we have to break up the 6 bits used for the gain sliders (and in fact also the 2 bits used for the super boosts) into a least-significant-bits (LSB) group and a most-significant-bits (MSB) group.
  • What's more annoying is that our physical wiring scheme means that we can't uniformly decide on how this division into LSBs and MSBs work for all the channels - e.g. for REFL1 Gain, the LSB is the 4 least significant bits, while the MSB is the 2 most significant ones, while for REFL2 Gain, the roles are reversed.
  • In hindsight, the "clever" way to do the wiring assignment would have been to factor this in - but the problem is (sort of) easily fixed in software, and so I recommend we stick with the existing wiring scheme.

I tested the new latch.py script by toggling the various sliders (one at a time) between two values and monitoring the states of the various soft and "*_BITS" channels, see Attachment #1. The behavior seems consistent to me, but to be sure, we have to use Koji's LED tester board and confirm that the physical bits are being toggled correctly. The StripTool templates live in /cvs/cds/caltech/target/c1iscaux/CMdiag.


I have not yet implemented the fix for the MBBO gain channels for all the gains - only REFL1_GAIN is set up correctly now. Need to look at the hardware for the correct addressing of bits

Attachment 1: CMsoftTest.png
  14911   Sun Sep 29 16:08:25 2019 gautamUpdateOptical LeversETMX Oplev HeNe replaced

To facilitate POX locking investigations, I replaced this HeNe today with one of the spares Chub/Steve had acquired some time ago. Details:

  • Part number: Lumentum 22037130 (1103P)
  • Serial number: PA00836
  • Manufacture date: 01/2019
  • Power output: ~2.64 mW (Measured with Ophir power meter in the 632nm setting)
  • Power received on QPD: ~0.37 mW = ~18700 cts (Measured with Ophir power meter in the 632nm setting)

The RIN of the sum channel with the Oplev servo engaged, along with that for the other core FPMI optics, in shown in Attachment #1. The ETMX HeNe RIN is compatible with the other HeNes in the lab (the high-frequency behaviour of the BS Oplev is different from the other four because the QPD whitening electronics are different).

Not sure what to make of the ETMY RIN profile being so different from the others, seems like some kind of glitchy behaviour, I could see the mean level of the ASD moving up and down as I was taking the averages in DTT. Needs further investigation.

The old / broken HeNe is placed i(nside the packaging of the abovementioned replacement HeNe) on Steve's old desk for disposal in the proper way.

*It looked like Steve had hooked up a thermocouple to be able to monitor the temperature of the HeNe head. I removed this feature as I figured if we don't have this hooked up to the DAQ, it isn't a really useful diagnostic. If we want, we can restore this in a more useful way.


While working on recovering interferometer alignment, I noticed that the ETMX Oplev SUM channel reported 0 counts. Attachment #1 shows the 200 day trend - despite the missing data, the accelerating downward decay is evident. I confirmed that there is no light coming out of the HeNe by walking down to EX. The label on the HeNe says it was installed in March 2017, so the lifetime was ~30 months. Seems a little short? I may replace this later today.

Attachment 1: OLRIN_20190929.pdf
  14910   Sun Sep 29 15:58:19 2019 gautamUpdateLSCPOX locking attempt


There is no visible PDH error signal on the POX11 channels. As a result, I am unable to lock the XARM length to the laser frequency. See Attachment #1 - the Y arm length is locked to the PSL frequency, and control is disabled for the XARM servo.


Now that several of the c1iscaux functionality tests have been completed, I wanted to push ahead with some locking. However, I was foiled at this early stage, for reasons as yet unknown. One possibility is that the

  • I am able to see TRX cavity flashes >0.8, which suggest to me that the cavity is well aligned.
  • Moreover, I am able to lock some (admittedly high TEM order) mode of the green laser, which further supports the above hypothesis.
  • However, there are no visible PDH-like features in the POX11_I or POX11_Q channels.
  • I checked that the cables from the output of the POX11 demod board are in fact going to the correct channels on WF1 (#5 and #6 respectively), and that the whitening gain for this channel is set to the nominal +30 dB.
  • Next, I went to the POX table and looked for the POX IR beam. I couldn't see anything, but this beam is expected to be weak (of the order of 1 W * T_PRM * R_AR_ITM ~ 30 uW), which is probably not so easily visible.

Next steps:

  • Look for the POX beam with an IR viewer.
  • Confirm that everything is order on the LSC Demod board for POX 11 - maybe the LO isn't connected (somehow)?
Attachment 1: POXlockAttempt.png
  14909   Fri Sep 27 15:59:53 2019 gautamUpdateCDSc1iscaux testing

I reset the normalization for both arms on Jul 9 2019.


The transmission reached just 1.00 at the end. Was the transmission recently normalized? (See attachment 5)

  14908   Thu Sep 26 20:09:40 2019 KojiUpdateCDSc1iscaux testing

== Test Status ==

[done] Whitening gain switching test => Some issues found (POP110Q, Whitening3_8 not switching, ASDC overall behavior, REFL33Q needs recheck)
[done] AA enable/disable switching
[0th order] LO Det Mon channel check
[none] PD I/F board check
[done] QPD I/F board check
[none] CM Board
[none] ALS I/F board

And, the Y-arm lock was recovered! After some alignment work, the Y-arm was locked. The whitening gain for POY11 was +18dB. The servo gain was 0.015 (nominal).
Once the transmission reached 0.8, I could use ASS to align the cavity and the TTs.
The transmission reached just 1.00 at the end. Was the transmission recently normalized? (See attachment 5)

- Whitening Filter Gain Switching Test

Each whitening filters were tested individually. +50mV DC signal was connected to the 8 inputs using an SMA octopus cable.
The existing script ( /cvs/cds/caltech/target/c1iscaux/testScripts/testWhtGain.py ) did not work because cds.getdata failed to fetch all of the data requested. By giving some sleep before start downloading the data, the problem was avoided. Still some truncated data are seen in the result, but StripTools screenshots compliments the missing part.

Whitening Filters #2~4 were a little tricky because the code needed modification so that the spare channels can be tested.
The modified script is stored as /cvs/cds/caltech/target/c1iscaux/testScripts/testWhtGain_190926.py 

Whitening #1: No issue found.

Whitening #2: No issue found. Some of the step plots showed truncation of the data at the end. But this is an artifact of cds.getdat. The striptool show nothing irregular.

Whitening #3: POP110Q and the spare channel (CH8) did not show the reaction. REFL33Q showed some systematic gain deviation. It could just be the offset problem, but needs to be rechecked.

Whitening #4: The DC channels were found to be OK  except for ASDC. ASDC shows earlier saturation. The input was lowered to 5mVDC to avoid saturation in the second trial. The circuit needs to be checked. The spare channels look noisy, but this is because there is no way to turn off the whitening filters for them.

- AA Filter Test

Injected 11kHz 1Vpp sine wave to the whitening filters. The whiter gains were kept at 0dB. If the AA is disabled, the alias of the 11kHz signal appears in the time series.
-> Whitening #1, #3 and #4: the enable/disable worked correctly.
-> Whitening #2 AA
Bbypass no effect. this is an expected behavior.

Attachment 1: Wht1.pdf
Wht1.pdf Wht1.pdf Wht1.pdf Wht1.pdf Wht1.pdf
Attachment 2: Wht2.pdf
Wht2.pdf Wht2.pdf Wht2.pdf Wht2.pdf Wht2.pdf Wht2.pdf
Attachment 3: Wht3.pdf
Wht3.pdf Wht3.pdf Wht3.pdf Wht3.pdf Wht3.pdf Wht3.pdf Wht3.pdf
Attachment 4: Wht4.pdf
Wht4.pdf Wht4.pdf Wht4.pdf Wht4.pdf Wht4.pdf Wht4.pdf Wht4.pdf Wht4.pdf
Attachment 5: lock.png
  14907   Thu Sep 26 17:56:28 2019 KojiUpdateCDSsome rebooting

Yesterday (Sep 25) evening: I had to reboot c1psl, c1iool0, and c1aux to recover nominal IMC locking

Today megatron had no response and I had to reboot it with the reset button. MCautolocker and FSSSlow were recovered and the IMC is locking as usual.

  14906   Wed Sep 25 20:10:13 2019 KojiUpdateCDSc1iscaux testing

== Test Status ==
Whitening gain switching test
[none] AA enable/disable switching
[0th order] LO Det Mon channel check
[none] PD I/F board check
[done] QPD I/F board check
[none] CM Board
[none] ALS I/F board

- LO Det Mon channel check

The StripTool template for the test was made:
Then, the RF output of the main Marconi was toggled a few times. -> Confirmed the channels are respopnding. (Attachment 1)

- IPPOS channel check

(0th order check) The StripTool template for the test was made:
Then, the IPPOS QPD was shined with a phone LED. Initially I saw no response of the QPD. It turned out that the IPPOS IF module had no input cable connected. After the connection, all the 4 segments are responding to the phone LED and also the IFO beam.

(more careful check)
I decided to do more careful check of IPPOS. As there was a f~30mm lens on the oplev table, beam was focused such that only one element reacted to the incident beam. The beam power (a few mW) was too strong for a single QPD element, which saturates at ~6, an ND filter of OD0.6 was used to reduce the incident power.

Here are the results:
SEG1 (UPPER LEFT seen from the beam) | C1:ASC-IP_POS_QPD_Seg1_Mon 3.651+/-0.003 (N=10) | Incident Power 2.35+/-0.01 mW, QPD X_Calc (+) Y_Calc (+)

Segment Arrangement
(Seen from the beam)
Epics Channel CH output

Incident Power

Polarity for the
X/Y_Calc channels
SEG1 UPPER LEFT C1:ASC-IP_POS_QPD_Seg1_Mon 3.651+/-0.003
2.35+/-0.01 X(+) / Y(+)
SEG2 LOWER LEFT C1:ASC-IP_POS_QPD_Seg2_Mon 3.607+/-0.002
2.35+/-0.01 X(+) / Y(-)
SEG3 LOWER RIGHT C1:ASC-IP_POS_QPD_Seg3_Mon 3.658+/-0.002
2.37+/-0.01 X(-) / Y(-)
SEG4 UPPER RIGHT C1:ASC-IP_POS_QPD_Seg4_Mon 3.529+/-0.004
2.30+/-0.01 X(-) / Y(+)

After the measurement, the lens and the filter were removed and the beam was adjusted to the center of the QPD.

Attachment 1: testDetectMons_190925.png
Attachment 2: testIPPOS_190925.png
  14905   Mon Sep 23 10:49:34 2019 ranaUpdateCDSc1iscaux testing
  • I'd say permanently enable AA and AI. There's no reason to turn these off for usual channels. We can always undo one switch later if we want to use aliasing to sample a high frequency signal (ala SoCal).
  • The PD output should ~20 nV/rHz into the mixer, so that's ~7 nV into the whitening filter. We need 60 dB to be above the ADC noise.
  • I've forgotten what the current config is, but in iLIGO we hacked in a fixed whtiening on the Lt1128 input amp to the WF board so that the lock acquisition could be a little easier (better SNR). On Ch1, that's replacing R60 with a RC network. We want to make sure that the lock acq transients are not saturating the ADC, but can maybe put in a 40:200 stage.
  14904   Fri Sep 20 18:28:34 2019 gautamUpdateLSCY arm locking attempt

I tried to lock the Y arm cavity length to the PSL frequency using POY11_I as an error signal. Even though I think the cavity alignment is good (I see TRY flashes ~0.8), I am unable to achieve a lock. I checked the signal conditioning, and as far as I can tell, all the settings are correct, but there may be some settings that have not been re-assigned correct values. The other possibility is that something is not quite right with the new c1iscaux. The PDH error signal and arm cavity flashes all seem good though (see Attachment #1), so I'm not sure what obvious thing I'm missing.

To be continued...

Attachment 1: POYlocking.png
  14903   Fri Sep 20 12:55:02 2019 gautamUpdateCDSc1iscaux testing

I was hoping that the dark / electronics noise level on the LSC photodiodes would be sufficient for me to test the whitening gain switching on the iLIGO Pentek whitening boards. However, this does not seem to be the case. I guess to be thorough, we have to do this kind of test. It's a bit annoying to have to undo and redo the SMA connections, but I can't think of any obvious easier way to test this functionality. More annoyingly, the sensing matrix infrastructure necessary to do the kind of test described in the linked elog is only available for some PDs. I don't really want to modify the c1cal model and go through another mass reboot cycle.

While I was at it, I was also thinking about the tests we want to do. Here is a quick first pass - if you can think of other tests we ought to do, please add them to the list!

  1. Whitening gain switching on the D990694 boards.
    • Need to inject some signal to do this in a clean way. 
    • With some signal injected, we need to switch the whitening gain through the 15 available levels and confirm that we see a +3dB gain for each step.
    • An example script to do this operation and make a diagnostic plot is at /cvs/cds/caltech/target/c1iscaux/testScripts/testWhtGain.py.
  2. AA enable/disable on the D000076 boards. Do we really need this functionality? Can't we permanently enable the AA, as was done for WF2?
    • Need to measure the TF with an SR785 or drive a high-freq line and confirm that the aliased peak height is attenuated as expected in DTT.
  3. LO Det Mon channel check
    • Zeroth level test can be done by turning Marconi OFF/ON, and confirming we see a change in the corresponding monitor channel, like I did here.
    • A more rigorous diagnostic would require these channels to be calibrated to dBm of LO power.
  4. PD INTF board check
    • Zeroth level check can be done by shining light onto PDs one at a time and confirming that the correct channel shows a response.
    • A more rigorous diagnostic would require these channels to be calibrated to mW of optical power incident on the PDs.
  5. QPD INTF board check
    • This is the IP-POS QPD readback.
    • Need to confirm the quadrant mapping, and that Pitch is really Pitch, Yaw is really Yaw.
    • A more rigorous diagnostic would require these channels to be calibrated to mm of position shift.
  6. CM Board
    • Need to determine what tests need to be done.
    • I have not yet implemented the fix for the MBBO gain channels for all the gains - only REFL1_GAIN is set up correctly now. Need to look at the hardware for the correct addressing of bits.
  7. ALS INTF board
    • This board isn't actually connected yet, pending strain relief of cabling at 1Y2.
    • The calibration of the board output volts to dBm is known, so we can easily check this functionality.
  14902   Fri Sep 20 11:39:04 2019 gautamUpdateOptical LeversETMX Oplev HeNe Dead

While working on recovering interferometer alignment, I noticed that the ETMX Oplev SUM channel reported 0 counts. Attachment #1 shows the 200 day trend - despite the missing data, the accelerating downward decay is evident. I confirmed that there is no light coming out of the HeNe by walking down to EX. The label on the HeNe says it was installed in March 2017, so the lifetime was ~30 months. Seems a little short? I may replace this later today.

Attachment 1: ETMX_OLdead.png
  14901   Thu Sep 19 21:23:51 2019 gautamUpdateCDSFast BIO splicing re-implemented at 1Y2

[KA, GV]


  1. New cross connect system for splicing the fast BIO signals for whitening switching to the P2 connectors was installed and tested at 1Y2.
  2. It passed a first round of tests. 😁 
  3. As of now, I believe all the necessary electrical connections have been made at 1Y2/1Y3, and we are ready for testing the c1iscaux system.


  1. We did some testing in the office area, and found several wiring mistakes. These were all rectified. Attachment #1 is an accurate reflection of the implemented wiring scheme (softcopy in the 40m google sheets area). Be aware that the IDC 50 pin connector pin-out is tricky, and you have to be aware of the difference between male/female connector when looking for this pin-out on the internet.
  2. In order to facilitate further testing, we re-routed the ADC0 SCSI cable that was unplugged on the overhead cable tray, and plugged it back into the c1lsc expansion chassis. This action necessitated a reboot of the vertex FEs, but everything came back alright.
  3. Did some general neatenign and strain relieving. Removed a few existing cross-connects to make space for our new terminal blocks.
  4. Attachment #2 shows the layout of the terminal blocks. Note the unusual (vertical) order of the orange terminal blocks.
  5. The final integrated CDS test done was the following:
    • Set whitening gain for channel under test to 45dB, so that the dark noise level is boosted to a measurable level such that a change can be seen with the whitening enabled/disabled.
    • Compare the ASD of the signal between 30-100 Hz with the whitening engaged/disengaged.
    • Example result shown in Attachment #3.I believe the whitening is 15:150 (z:p) 


  1. Recover POX/POY locking,.
  2. ...

Update 2019 Sep 19 1730: The pin numbers of the IDC 50 connector are all off by 1. i.e. 3-->4 and so on. I will fix this shortly. The problem was because of me looking at the pinout for the wrong gender of IDC50 connectors.

Attachment 1: 1Y2_FAST_BIO_WIRING_MAP.pdf
Attachment 2: IMG_7949.JPG
Attachment 3: REFL165.pdf
  14900   Thu Sep 19 15:59:29 2019 aaronHowToCDSHow to save c1ioo

New DIMM cards have arrived. I stored them in the digital cabinet along y arm.

  14899   Thu Sep 19 11:26:18 2019 gautamUpdateIOOTT cables DON'T need to be remade

False alarm - the mistake was mine. Looking at the schematic diagram, the AI/Dewhite board, D000316, accepts the inputs from the DAC on the P2 connector. While restoring the connections at 1Y2, I had plugged the outputs of the DAC interface board into the P1 connectors of the AI boards. Having rectified this problem, I am now able to move the beam on the AS camera in both PIT and YAW using TT1 or TT2. So to zero-th order, this subsystem appears to work. A more in-depth analysis of the angular stability of the TTs can only be done once we re-align the arms and lock some cavities.

  14898   Thu Sep 19 09:39:30 2019 gautamUpdateIOOTT cables need to be remade

While debugging this problem, c1lsc models crashed. I ran the reboot script this morning to bring the models back. There was a 0x4000 error on the DC indicators for the c1lsc models (mx_stream error which couldn't be fixed by restarting the mx service) the first time I ran the script so I did it again, now the indicator lights are in their nominal state.

Attachment 1: CDSoverview.png
  14897   Wed Sep 18 15:27:45 2019 gautamUpdateIOOTT cables need to be remade


The custom ribbon cables piping the coil driver board outputs to the eLIGO (?) TTs (a.k.a. TT1 and TT2) are damaged. They need to be re-made. I can't find any pin-mapping for them.


While waiting for the LSC photodiode whitening switching cross-connect work to be done, I thought I'd re-align the IFO a bit. However, I was unable to find any beam making it to the REFL/AS ports despite some TT steering. I remembered that Chub had undone the TT connections at 1Y2 as well, and thought I'd check the cabling to make sure all was in order. On going to the rack, however, I found that these connections were damaged at the coil-driver end (see Attachment #1), presumably during the cable extraction. These need to be re-made...😔 

Attachment 1: IMG_7945.JPG
  14896   Wed Sep 18 14:45:52 2019 rikaUpdateIOOWFS loop measurements

[aaron, rika]

Gettng TFs

In the data we got yesterday, we can see some filter's effect. 

But it is not good coherence above 10Hz, so we mesured again. And this time we save the data as xml file.

And also we chaned the frequency regions broader to watch corner frequency of suspension.


 Diagnotics test tools

 range: 0.1 Hz to 100 Hz

 points: 120 

 Amplitude: 1000


but at low frequency, the mode maching cavity was unloked cause of too much shaking.

So, we saw single frequency TF, and searched the good amplitude.


First, I tried to get TF @0.1~1 Hz .


0.1 to 1 Hz

points: 61 (I think it's too much becous it takes about an hour)

amplitude: 5


The TFs and coherence of MC1/PIT to each QPD is below. [above window: coherence, below: TF]

During the mesurement, something happened @0.2-0.3Hz so I stopped it.

We found the coherence of WFS1P and WFS2Y is not good, but others are good.

we guess that it could come from alignment which made Q chainging to small.


Finaly, I also got the  .xml data of MC1P 1 Hz to 10 Hz. In this time,


1 to 10 Hz

points: 41 

amplitude: 90



Making matrics

Now we took single frequency 6 TFs (MC1/2/3 PIT/YAW) @7Hz (Because this frequency has good coherence in all channel).

Aaron wrote the script using dtt to making matrics. 




[aaron, rika]

Once stop the auto-locker and realigned to make beam to get into QPD again.

After we lock MC, we took TFs from suspension MC1/2/3 PIT/YAW to WFS1/2 PIT/YAW. 


Diagnotics test tools

range: 7 Hz to 50 Hz


Column 0: WFS2_PIT   1: WFS2_YAW   2:WFS1_PIT   3: WFS1_YAW   4: TRANCE_PIT   5:TRANCE_YAW 


I'm wondering weather the MC1data I saved is correct, becouse I found the channel was changed when I exported MC2 data. So I took MC1 data again.


We got all data for TFs already.  Each data is devided to real part and imaginary part. Then we are arranging the datas to obtain TFs. 

TF of MC2 is attachiment 1. So tomorrow, I make other TF.


[rika, aaron]

We aligned optics of WFS as it was. Now auto-locker is working to lock MC.

But it still doesn't lock. We notice that the c1lsc machine doesn't work. So we run rebootCILSC.sh.


Now we reset the hardware!



After reset, auto locking didn't work well. Gautum and Aaron reboot slow c1ioo. Then it works, and Gautam returned the MC to a good alignment.

We found the beam is not in the center of the QPD, we (turned off the MC autolocker and MC loop, then) realigned to make beam to get in to the QPD center. Afterwards we start auto locking.

With the WFS on, the maximum MC transmission we observe is 14,700 counts; after the transmission level stabilizes (MC_TRANS pit and yaw brought to 0), the MC transmission is only 14,200 counts. Perhaps the MC_TRANS QPD offsets need adjustment. We relieve the WFS servo of its DC offsets. This is the configuration we'll use for WFS loop measurements this week.



Attachment 1: Screenshot_from_2019-09-18_18-15-34.png
  14895   Wed Sep 18 12:40:09 2019 gautamUpdateCDSFast BIO Mapping at 1Y2



With the help of a tester board, I verified the mapping between fast BIO DB37 pins, and pins on the IDC50 connectors that are to be broken out to the whitening boards. I will enlist Chub to implement this mapping in hardware later today.


  1. The LSC PD demodulated signals are optionally whitened before acquisition by our RTCDS ADCs.
  2. The switching of each channel's whitening (enable/disable) is done by a single bit from the fast (a.k.a. RTCDS) system's BIO cards.
  3. The whitening boards live inside Eurocrates.
  4. The aforementioned switching signal needs to be sent to the whitening boards via the backplane of the Eurocrate.
  5. This requires some cross-connect based cable splicing between the BIO card outputs and the P2 connectors of the whitening boards in the Eurocrates.
  6. This connection was accidentally destroyed during the war on cross-connects at 1Y2. I couldn't find a wiring diagram anywhere.
  7. Today, with the help of a tester board, I verified the mapping by toggling the appropriate channels on the MEDM screen, and verifying the correct LEDs on the tester board were toggled.
  8. Map will be posted here after the meeting... Also now on the wiki.

Update 2019 Sep 19 1730: The pin numbers of the IDC 50 connector are all off by 1. i.e. 3-->4 and so on. I will fix this shortly. The problem was because of me looking at the pinout for the wrong gender of IDC50 connectors.

  14893   Tue Sep 17 23:46:21 2019 KojiUpdateCDSLatch Enable Logic

[Koji Gautam]

We continued to check the latch logic. Today we found that latch.py didn't catch the change of LSB but did for MSB. We determined that this happens when the slider value is chaged between the polling for LSB and MSB.
SInce these two should always be related to a single gain value, latch.py was modified so.

Now we don't observe any logic error for ~100 gain transisitions (see attached).

Attachment 1: Screenshot_from_2019-09-17_23-39-35.png
  14892   Tue Sep 17 23:43:34 2019 KojiSummaryCDSAcromag logic checker

For the investigation of the latch logic issue for the CARM CM board, I have made the LED logic checkers with DB breakout boards. They require the pull up voltage supply of +15V because the acromag digital out is a open corrector (well... open "source") output.

The logic from Pin1 to Pin16 of DB37 can be monitored. The DB15 connector is only for monitoring the latch enable logic.

What Gautam and I found with the logic outputs was that the latch logic works fine but occasionally we found that the top 2 bits and the bottom 4bit were processed independently.

Attachment 1: digital_checker.pdf
Attachment 2: IMG_8914.JPG
  14891   Tue Sep 17 21:34:07 2019 gautamUpdateCDSdaqd fw dead no more


  1. Frames seem to be written again.yesSlowly but surely, we are converging to an operable state...
  2. No frames are available for the period 23 Aug to 17 September 2019
  3. Don't edit the C0EDCU.ini file unless you know what you're doing.
  4. If you make some changes to the RT system/channel list or reboot FEs, please make sure all the dependent systems are back up and running. There shouldn't be a need to willy-nilly reboot things.
  5. Tomorrow I will prepare the map of BIO channels for Chub to restore the whitening switching capability. Then we can try locking some cavities.


  1. First, I checked to make sure the /frames partition wasn't full. It wasn't. yes
  2. Next, I looked into the C0EDCU.ini file.
    • The last date for which frames are available, 23 Aug, coincided with the date when this file was modified.
    • It is a known problem that the daqd_fw service can crash if one of the channels in this file is reporting an unusually large number.
    • Several channels were added to this file - in the end, only 9 new ones were required, 5x "DetectMon" channels for each of the RF demodulation frequencies, and 4 for the new ALS LO and RF signal power monitor channels.
    • It is highly likely that one of the other channels was what caused the daqd_fw service to crash - though I can't say for sure, because I did not exhaustively search through the ~100 un-necessary channels that were in this file to see what values they were reporting.
  3. For good measure, I ran the reboot script, and brought the c1lsc models back online.
    • I want to do the mapping of the BIO channels to the pin-out of the BIO adaptor unit, which requires c1lsc to run.
    • Reboot script ran smoothly.
  4. Then I went into fb and restarted all the daqd services. This time, they all seem to run without crashing, at least in the ~10min window it took me to type out this elog.

controls@fb1:~ 127$ sudo systemctl status  daqd_fw.service
● daqd_fw.service - Advanced LIGO RTS daqd frame writer
   Loaded: loaded (/etc/systemd/system/daqd_fw.service; enabled)
   Active: active (running) since Tue 2019-09-17 21:32:25 PDT; 17min ago
 Main PID: 22040 (daqd_fw)
   CGroup: /daqd.slice/daqd_fw.service
           └─22040 /usr/bin/daqd_fw -c /opt/rtcds/caltech/c1/target/daqd/daqdrc.fw

Sep 17 21:32:31 fb1 daqd_fw[22040]: [Tue Sep 17 21:32:31 2019] Producer crc thread - label dqprodcrc pid=22108
Sep 17 21:32:31 fb1 daqd_fw[22040]: [Tue Sep 17 21:32:31 2019] [Tue Sep 17 21:32:31 2019] Producer thread - label dqproddbg pid=22109Producer crc... permitted
Sep 17 21:32:31 fb1 daqd_fw[22040]: [Tue Sep 17 21:32:31 2019] Producer crc thread put on CPU 0
Sep 17 21:32:31 fb1 daqd_fw[22040]: [Tue Sep 17 21:32:31 2019] Producer thread priority error Operation not permitted
Sep 17 21:32:31 fb1 daqd_fw[22040]: [Tue Sep 17 21:32:31 2019] Producer thread put on CPU 0
Sep 17 21:32:31 fb1 daqd_fw[22040]: [Tue Sep 17 21:32:31 2019] Producer thread - label dqprod pid=22103
Sep 17 21:32:31 fb1 daqd_fw[22040]: [Tue Sep 17 21:32:31 2019] Producer thread priority error Operation not permitted
Sep 17 21:32:31 fb1 daqd_fw[22040]: [Tue Sep 17 21:32:31 2019] Producer thread put on CPU 0
Sep 17 21:32:35 fb1 daqd_fw[22040]: [Tue Sep 17 21:32:35 2019] Minute trender made GPS time correction; gps=1252816371; gps%60=51
Sep 17 21:33:31 fb1 daqd_fw[22040]: [Tue Sep 17 21:33:31 2019] ->3: clear crc

drwxr-xr-x 2 controls controls 569344 Aug 23 05:17 12465
drwxr-xr-x 2 controls controls 565248 Aug 23 05:41 12466
drwxr-xr-x 2 controls controls 557056 Aug 23 05:53 12505
drwxr-xr-x 2 controls controls 262144 Aug 23 18:40 12506
drwxr-xr-x 2 controls controls  12288 Sep 17 21:54 12528

Unrelated to this work: c1auxey was keyed.


This meant that no frames were being written since Aug 23, which probably coincides with when the c1lsc frontend crashed. Sad 😢 😭 🙁 .

Attachment 1: RTFEstatus.png
ELOG V3.1.3-