40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 306 of 344 Not logged in
ID Date Author Type Category Subject
14842   Mon Aug 12 19:58:23 2019 gautamUpdateIOOMC1 suspension oddness

Repair plan:

1. Get "spare" satellite box working --- Chub
• According to elog14441, this box has flaky connectors which probably need to be remade
2. Re-make the 64-pin IDC crimped connection on the cable from the coil driver board to sat. box, at the Satellite box end --- Chub and gautam

Any other ideas? The problem persists and it's annoying that the IMC cannot be locked.

14843   Mon Aug 12 21:25:19 2019 KojiUpdateCDSMore bench test of c1iscaux

1.

> 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

I suppose, we loose the differential capability of an input if the -IN is connected to whatever defined potential. We should check if the channels are still working as a true differential or not.

2. If the multi bit operation is too complicated to solve, we can use EPICS Calc channels to breakout a value to bits and send the individual bits as same as the other individual binary channels.

14844   Tue Aug 13 08:07:09 2019 gautamUpdateCDSP1--->P2

This morning, I wanted to move the existing cables going to the P1 connectors of the iLIGO whitening boards to the P2 connector, to test the modifications made to allow whitening stage switching. Unfortunately, I found that the shrouds werent installed. Where can I find these?

14845   Tue Aug 13 14:36:17 2019 gautamUpdateCDSP1--->P2

As it turns out, only one extra shroud needed to be installed - I did this and migrated the cables for the 4 whitening boards from the P1 to P2 connectors. So until the new Acromag box is installed, we have no control over the whitening gains (slow channels), but do still have control over the whitening filter enable/disable (controlled by fast BIO). I am thinking about the easiest way to test the latter - I think the ambient PD dark noise level is too low to be seen above ADC noise even with the whitening enabled, and setting up drive signals to individual channels is too painful - maybe with +45dB of whitening gain, the (z,p) whitening filter shape can be seen with just PD/demod chain electroncis noise.

 Quote: This morning, I wanted to move the existing cables going to the P1 connectors of the iLIGO whitening boards to the P2 connector, to test the modifications made to allow whitening stage switching. Unfortunately, I found that the shrouds werent installed. Where can I find these?
14846   Thu Aug 15 18:54:54 2019 gautamUpdateALSALS sensing noise due to IMC

Summary:

I came aross an interesting suggestion by Yutaro that KAGRA's low-frequency ALS noise could be limited by the fact that the IMC comes between the point where the frequencies of the PSL and AUX lasers are sensed (i.e. the ALS beat note), and the point where we want them to be equal (i.e. the input of the arm cavity). I wanted to see if the same effect could be at play in the 40m ALS system. A first estimate suggests to me that the numbers are definitely in the ballpark. If this is true, we may benefit from lower noise ALS by picking off the PSL beam for the ALS beat note after the IMC.

Details:

Even though the KAGRA phase lock scheme is different from the 40m scheme, the algebra holds. I needed an estimate of how much the arm cavity moves, I used data from a POX lock to estimate this. The estimate is probably not very accurate (since the arm cavity length is more stable than the IMC length, and the measured ALS noise, e.g. this elog, is actually better than what this calculation would have me believe), but should be the right order of magnitude. From this crude estimate, it does look like for f<10 Hz, this effect could be significant. I assumed an IMC pole of 3.8 kHz for this calculation.

I've indicated a "target" ALS performance where the ALS noise would be less than the CARM linewidth, which would hopefully make the locking much easier. Seems like realizing this target will be touch-and-go. But if we can implement length feedforward control for the arm cavities using seismometers, the low frequency motion of the optics should go down. It would be interesting to see if the ALS noise gets better at low frequencies with length feedforward engaged.

1. Took data from Kiwamu's paper for the seismic noise
2. Overlaid measured ALS noise
14847   Fri Aug 16 04:24:03 2019 ranaUpdateALSALS sensing noise due to IMC

What about just use high gain feedback to MC2 below 20 Hz for the IMC lock? That would reduce the excess if this theory is correct.

14848   Fri Aug 16 16:40:04 2019 gautamUpdateCDS1Y3 work

[chub, gautam]

Installation: The following equipment were installed in 1Y3, see Attachment #1:

1. Supermicro server, which is the new c1iscaux machine, with IP Address 192.168.113.83.
2. 6U Acromag chassis which contains all the ADCs, DACs and BIO units.
3. 2 Sorensen DC power supplies to provide +24 V DC and +15 V DC to the Acromags.
4. Fusable DIN rail power blocks were installed on the North side of the 1Y3 rack - I placed 2 banks of 5 connectors each for +15 V DC and +24 V DC.

Removal: The following equipment was removed from 1Y3:

1. VME crates that were the old c1iscaux and c1iscaux2 machines.
2. Spare VME crate that used to be c1susaux, which Chub and I brought over to 1Y3 in an attempt to revive the broken c1iscaux2.
3. Approximately 30 twisted ribbon cables that were going to the cross connects. For now, we have not done a full cleanup and they are just piled along the east arm (see Attachment #2), beware if you are walking there!

Software:

1. I connected the c1iscaux machine to the martian network.
2. Then I edited the relevant files on chiara to free up the IP addresses previously used by c1iscaux (192.168.113.81) and c1iscaux2 (192.168.113.82), and re-assigned the IP address used for c1iscaux to be 192.168.113.83.
3. I also changed the hostname of the c1iscaux machine (it was temporarily called c1iscaux3 to allow bench testing).
4. I moved the old /cvs/cds/caltech/target/c1iscaux and /cvs/cds/caltech/target/c1iscaux2 directories to /cvs/cds/caltech/target/preAcromag_oldVME/c1iscaux and /cvs/cds/caltech/target/preAcromag_oldVME/c1iscaux2 respectively.
5. I moved the temporarily named /cvs/cds/caltech/target/c1iscaux3 directory, from which I was running all the tests, to /cvs/cds/caltech/target/c1iscaux.
6. I edited all references to c1iscaux3 in the systemd files so that we can run the approriate systemd services.

Next steps:

1. We did not get around to running the DB37 cables between the Acromag chassis and the 1Y2 Eurocrates today - this operation itself took the whole day as we also needed to lay out some support struts etc on the rack to support the Sorensens and the Acromag chassis.
2. Once the Acromags are connected to the Eurocrates, we have to run in-situ tests to make sure the appropriate functionality has been restored.
3. We must have bumped something in the c1lsc expansion chassis - the CDS FE overview screen is reporting some errors (see Attachment #3). I will fix this.
4. General tidiness, strain-relief etc.
 Quote: I judge that we are good to go ahead with an install tomorrow.
14849   Sat Aug 17 16:49:23 2019 gautamUpdateCDSMore 1Y3 work

Work done today:

1. All ribbon cable connections to the backplane of the 1Y2 Eurocrates were removed. The cables themselves were cleared for more space to work with.
2. 20x 15ft DB37 Cables were run between 1Y2 and 1Y3 via overhead cable tray.
3. Backplane interface boards were installed for 1Y2 Eurocrate boards.
4. Connections were made between the Acromag chassis and the eurocrate electronics modules.

Testing of functionality:

1. Fast BIO switching was verified to work for the following photodiodes:
• AS55, AS110, REFL11, REFL33, REFL55, REFL165, POX11, POY11, POP22, POP110.
• No light was incident on the PDs.
• Test was done by increasing the whitening gain to +45 dB, and then looking at the ASD of the electronics noise between 50 Hz and 500 Hz with the whitening enabled/disabled. We expect x10 difference between the two states. This was seen.
2. "DetMon" channels were verified to work - see Attachment #1
• Y-axis units is volts
• Test was done by toggling the output of the 11 MHz Marconi, and looking for a change.
• As seen in the attachment, all 5 monitor channels show a change.
• This needs to be calibrated into some sensible units - I don't know why the different modulation frequencies have such different readbacks from supposedly identical Demod Board monitor points.
• Not sure if the ~10 V reported by the REFL165 monitor point is real or saturated.
• These channels are installed to signal/help debug the infamous ERA-5 decay problem, but maybe already some are decayed?
3. QPD interface channels were verified to work - see Attachment #2
• Test was done by shining a green laser pointer on QPD quadrants.

Much testing remains to be done, but I defer further testing till Monday - the main functionality to be verified in the short run is the whitening gain stepping. The strain-relief of cables and general cleanup will be undertaken by Chub. Current state of affairs is in Attachment #3, leaves much to be desired in terms of cleanliness.

I will also setup the autoburt for the new machine on Monday. We will also need to add some channels to C0EDCU.ini if we want to trend them over some years (e.g. RF signal powers for monitoring ERA-5 health).

* c1lsc FE was rebooted using the usual script, and everything seems to be healthy in CDS-land again, see Attachment #4.

 Quote: Next steps:  We did not get around to running the DB37 cables between the Acromag chassis and the 1Y2 Eurocrates today - this operation itself took the whole day as we also needed to lay out some support struts etc on the rack to support the Sorensens and the Acromag chassis. Once the Acromags are connected to the Eurocrates, we have to run in-situ tests to make sure the appropriate functionality has been restored. We must have bumped something in the c1lsc expansion chassis - the CDS FE overview screen is reporting some errors (see Attachment #3). I will fix this. General tidiness, strain-relief etc.
14850   Mon Aug 19 14:36:21 2019 gautamUpdateCDSc1iscaux remaining work

Here is what is left to do:

1. Strain relief of all cabling. Chub will take care of this in the coming days. I have said he can connect and disconnect cables as he pleases, but after this work, we may require a hard reboot of the Acromag chassis before restoring functionality to the channels, as it is known that the Acromags can sometimes get "stuck" by a sudden connection of voltage.
2. Installation of DB15 cable to the P2 connector of the CM board and a DB9 cable to the ALS demod unit (LO and RF power monitors). These will arrive in the next couple of days and Chub will take care of the install.
3. Design, manufacture and install of a custom version of the backplane P1 adaptor board with only 1 D37 connector - for some of the PD DC signals, a custom adaptor board, part number D010005 for which I can't find any schematics is already installed on the P2 connector, and makes the DC monitor signals available to 4 LEMO connectors. These signals are then digitized by the fast CDS system, presumably for PDH signal normalization. The footprint of this P2--->LEMO adaptor is such that we cannot simply install our P1---> 2xDB37 adaptor boards, because of space constraints. Fortunately, there is a simple fix to reduce the footprint of the board: remove the bottom DB37 connector, which is unused in the c1iscaux system except for the CM board. I recommend getting ~10 pcs of such boards, as it is also useful in a few other places, where the power cabling to the eurocrates are a space constraint. See Attachment #1 for a picture explaining this situation. Anyone want to volunteer to take care of this?
4. In-situ testing. This is easiest done with some light available in the interferometer. Which in turn requires IMC to be locked. Which in turn requires satellite box fixing. Anyone want to volunteer to take care of this?
5. Modify C0EDCU.ini to trend the new slow channels we may want long-term monitoring of (e.g. LO power levels to the Demod boards). Anyone want to volunteer to take care of this?
6. Decide what to do about the CM latch logic. There are some contraints with the way the acromag register addressing works, that I've had to change the way the mbboDirect bits are controlled. Unfortunately, this seems to sometimes and unpredictably cause the bits to flip in a non-robust way, which is the whole point of having the latch in the first place. Either the latch logic needs to be improved, or we need to implement the latch logic in the fast CDS system, not the slow.

Today I set up the autoburt.req file for the c1iscaux channels, and confirmed that the snapshots are getting recorded. There were a lot of channels in the old autoburt.req file which I thought were un-necessary (and several which no longer exist), so now the only channels that are burt-ed are the whitening gains and states of the AA filters. If someone feels we need more channels to be snapshot recorded, you can add them to the file.

In the old target directory, there were also various versions of a "saverestore.req" file - why do we need this in addition to an autoburt? I guess it is possible they are used by the IFOconfigure scripts to setup some whitening gains etc...

14851   Tue Aug 20 19:05:24 2019 KojiUpdateCDSMC1 (and MC3) troubleshoot

Started the troubleshoot from the MC1 issue. Gautam showed me how to use the fake PD/LED pair to diagnose the satellite box without involving the suspension mechanics.

This revealed that the MC1 has frequent light level glitches which are common for five sensors. This feature does not exist in the test with the MC3 satellite box. I will open and check the MC1 satellite box to find the cause of this common glitches tomorrow. MC1 is currently shutdown and undamped.

BTW, at the MC3 test, i found that J2 of the satellite box (male Dsub) has all the pins too low (or too short?). I brought the box outside and found that the housing of this connector was half broken down. The connector was reassembled and the metal parts of the housing was bent again so that the housing can hold the connector body tightly.

The MC3 satellite box was restored and connected to the cables. As I touched this box, it is still under probation.

14852   Thu Aug 22 12:54:06 2019 KojiUpdateCDSMC1 glitch removed (for now) and IMC locking recovered

I have checked the MC1 satellite box and made a bunch of changes. For now, the glitches coming from the satellite box is gone. I quickly tested the MC1 damping and the IMC locking. The IMC was locked as usual. I still have some cleaning up but will work on them today and tomorrow.

Attachment 1: Result

The noise level of the satellite box was tested with the suspension simulator (i.e., five pair of the LED and PD in a plastic box).

Each plot shows the ASD of the sensor outputs 1) before the modification, 2) after the change, and 3) with the satellite box disconnected (i.e., the noise from the PD whitening filter in the SUS rack).

Before the modification, these five signals showed significant (~0.9) correlation each other, indicating that the noise source is common. After the modification, the spectra are lowered down to the noise level of the whitening filters, and there is no correlation observed anymore. EXCEPT FOR the LR sensor: It seems that the LR has additional noise issue somewhere in the downstream. This is a separate issue.

Attachment 2: Photo of the satellite box before the modification

The thermal environment in the box is terrible. They are too hot to touch. You can see that the flat ribbon cable was burned. The amps, buffers, and regulators generate much heat.

Attachment 3: Where the board was modified

- (upper left corner) Every time I touched C51, the diode output went to zero. So C51 was replaced with WIMA 10uF (50V) cap.

- (lower left area) I found a clear indication of the glitch coming from the PD bias path (U3C). So I first replaced another 10uF (C50) with WIMA 10uF (50V). This did not change the glitch. So I replaced U3 (LT1125). This U3 had unused opamp which had railed to the supply voltage. Pins 14 and 15 of U3 were shorted to ground.

- (lower right corner) Similarly to U3, U6 also had two opamps which are railed due to no termination. U6 was replaced, and Pins 11, 12, 14, and 15 were shorted to ground.

- (middle right) During the course of the search, I suspected that the LR glitch comes from U5. So U5 was replaced to the new chip, but this had no effect.

Attachment 4: Thermal degradation of the internal ribbon cable

Because of the heat, the internal ribbon cable lost the flexibility. The cable is cracked and brittle. It now exposes  some wires. This needs to be replaced. I'll work on this later this week.

Attachment 5: Thermal degradation of the board

Because of the excessive heat for those 20years, the bond between the board and the patten were degraded. In conjunction with extremely thin wire pattern, desoldering of the components (particularly LT1125s) was very difficult. I'd want to throw away this board right now if it were possible...

Attachment 6: Shorting the unused opamps

This shows how the pieces of wires were soldered to ground vias to short the unused opamps.

Attachment 7: Comparison of the noise level with the sus simulator and the actual MC1 motion

After the satellite box fix, the sensor outputs were measured with the suspension connected. This shows that the suspension is moving much more than the noise level around 1Hz. However, at the microseismic frequency there is also most no mergin. Considering the use of the adaptive feedforward, we need to lower the noise of the satellite box as well as the noise of the whitening filters.

=> Use better chips (no LT1125, no current buffers), use low noise resistors, better thermal environment.

14853   Thu Aug 22 20:56:51 2019 KojiUpdateCDSMC1 glitch removed (for now) and IMC locking recovered

The internal ribbon cable for the MC1 satellite box was replaced with the one in the spare box. The MC1 box was closed and reinstalled as before. The IMC is locking well.

Now the burnt cable was disassembled and reassembles with a new cable. It is now in the spare box.

The case closed (literally)

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

Summary:

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

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

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

Details:

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

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

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

14855   Fri Aug 23 18:46:17 2019 JonUpdateCDSc1iscaux remaining work

I added the list of new c1iscaux channels to /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini and restarted the framebuilder. Koji had thought some of these channels might have previously existed under slightly different names. However, after looking through C0EDCU.ini and the other _SLOW.ini files, I did not find any candidates for removal. As far as I can tell, all of these channels are being recorded for the first time.

 Quote:Koji Modify C0EDCU.ini to trend the new slow channels we may want long-term monitoring of (e.g. LO power levels to the Demod boards). Anyone want to volunteer to take care of this?
14856   Fri Aug 23 19:10:02 2019 JonUpdateCamerasGigE camera server is online

Following the death of rossa, which was hosting the only working environment for the GigE camera software, I've set up a new dedicated rackmount camera server: c1cam (details here). The Python server script is now configured as a persistent systemd service, which automatically starts on boot and respawns after a crash. The server depends on a set of EPICS channels being available to control the camera settings, so c1cam is also running a softIOC service hosting these channels. At the moment only the ETMX camera is set up, but we can now easily add more cameras.

### Usage

Instructions for connecting to a live video feed are posted here. Any machine on the martian network can stream the feed(s). The only requirement is that the client machine have GStreamer 0.10 installed (all the control room workstations satisfy this).

### Code Locations

As much as possible, the code and dependencies are hosted on the /cvs/cds network drive instead of installed locally. The client/server code and the Pylon5, PyPylon, and PyEpics dependencies are all installed at /cvs/cds/rtcds/caltech/c1/scripts/GigE. The configuration files for the soft IOC are located at /cvs/cds/caltech/target/c1cam.

The 40m GigE camera code is a slightly-updated version of the 10+ year-old camera code in use at the sites. Consequently every one of its dependencies is now deprecated. Ultimately, we'd like to upgrade to the following:

• Python 2.7 --> 3.7
• Basler Pylon 5.0.12 --> 5.2.0
• PyPylon 1.1.1 --> 1.4.0
• GStreamer 0.10 --> 1.2

This is a long-term project, however, as many of these APIs are very different between Python 2 and 3.

14857   Sun Aug 25 14:18:08 2019 gautamUpdateCDSc1iscaux remaining work

There were a bunch of useless / degenerate channels added - e.g. whitening gains which are alreay burt-snapshot. Maybe there are many more useless channels being trended, but no need to add more.

Copy-pasting wasn't done correctly - the first 4 added channels were duplicates. There are in fact 5 LO power mons, one for each of the frequencies 11, 33, 55, 110 and 165 MHz.

I cleaned up. Basically only the detect-mon channels, and the ALS channels, are new in the setup now. I will review if any extra channels are required later. While checking that the daqd is happy, I noticed c1lsc FEs are in their stuck state, see Attachment #1. I guess a cable was bumped when the strain relief operation was underway. I'm not attempting a remote resuscitation.

 Quote: I added the list of new c1iscaux channels to /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini and restarted the framebuilder. Koji had thought some of these channels might have previously existed under slightly different names. However, after looking through C0EDCU.ini and the other _SLOW.ini files, I did not find any candidates for removal. As far as I can tell, all of these channels are being recorded for the first time.
14863   Fri Sep 6 16:38:24 2019 aaronUpdateALARMAlarm noise from smart-ups machine under workstation?

There was an alarm sound from the Smart-UPS 2200 sitting under the workstation. I see that the 'replace battery' light is red, and this elog tells me that these batteries are replaced every ~1-4 years; the last replacement was march 2016. Holding down the 'test' button for 2-3 seconds results in the alarm sound and does not clear the replace battery indicator.

14864   Fri Sep 6 18:08:29 2019 ranaUpdateComputersAlarm noise from smart-ups machine under workstation?

please no one touch the UPS: last time it destroyed ROSSA. Please ask Chub to order the replacement batteries so we can do this in a controlled way (fully shutting down ALL workstations first). Last time we wasted 8 hours on ROSSA rebuilding.

 Quote: There was an alarm sound from the Smart-UPS 2200 sitting under the workstation. I see that the 'replace battery' light is red, and this elog tells me that these batteries are replaced every ~1-4 years; the last replacement was march 2016. Holding down the 'test' button for 2-3 seconds results in the alarm sound and does not clear the replace battery indicator.
14868   Tue Sep 10 15:41:37 2019 aaronUpdateIOOWFS measurements

[rika, aaron, rana]

We are getting the MC locked in anticipation of making some WFS transfer function measurements.

The PSL screen was all white boxes, so I keyed the PSL crate and burt restored the settings from 11:19am Sep 5 (somewhat earlier than we started rebooting computers). Following this, I ran Milind's unstick.py and then the PSL autolocker script; both worked on the first go, great work Milind!

The modecleaner autolocking script is having substantially more trouble. Rana found that pitch and yaw sliders for all MC optics have been swapped--we think it's because the camera at MC2 has been rotated. Note that for now, sliding pitch gives a change in yaw, and sliding yaw changes pitch.

## Improving MC alignment

We noticed that with the WFS servo on, the modecleaner would be well aligned for a while (MC trans ~ 14000), only to lose lock after several minutes. We held the MC2_TRANS_PIT/YAW outputs at 0, so the MC2 QPD does not affect the WFS loop; the beam is well centered on WFS1/2, but not on the MC2 QPD, and with this signal out of the loop MC TRANS recovers to ~15000 counts (consistent with the quiet times over the last 90 days, see attachment 2). Attachment 1 shows the MC lock degrading, followed by some noise where we lost lock, and finally a visible increase in MC trans when we remove the MC2 QPD from the WFS loop.

### mode cleaner alignment setting

MC1 Pich 4.4762     Yow 4.4669

MC2 Pich 3.7652     Yow -1.5482

MC3 Pich -0.4159    Yow 1.1477

After automatic locking MC, we stopped automatical locking and took alignment to the center of QPD.

And then again did the automatic locking MC. Finaly Rana move to best alignment.

### Mode cleaner Alignment Setting

MC1 Pich 4.4942   Yow 4.6956

MC2 Pich 3.7652   Yow -1.5600

MC3 Pich -0.3789   Yow 1.1477

## Measured sine response

We used diaggui to measure the response of WFS1/WFS2/MC2 pitch (yaw) to excitations in MC1/MC2/MC3 pitch (yaw). Seeing fluctuations of amplitude ~1 on the MCX_PIT/YAW_OUT channels, we used an amplitude 0.01 excitation at 20 Hz. We will work on scripting some of this tomorrow.

14869   Tue Sep 10 16:10:40 2019 ChubUpdate Rack Update

Still removing old cable, terminal blocks and hardware.  Once new strain reliefs and cable guides are in place, I will need to disconnect cables and reroute them.  Please let me know dates and times when that is not going to interrupt your work!

14870   Tue Sep 10 17:26:49 2019 KojiUpdateCDSD1900068 SR785 accessory box

I picked up a unit of D1900068 SR785 accessory box from Dean's office at Downs.

14871   Wed Sep 11 10:26:56 2019 aaronUpdateIOOWFS measurements

## Gameplan

We should also have a plan for the next couple weeks so we are organized; heavily adapted from. Here's what I'm thinking this morning:

1. Construct the input/output matrix for the WFS. (basically, what we did yesterday)
1. Measure a transfer function of MC[1, 2, 3]_[PIT, YAW] to [WFS1, WFS2, MC2_TRANS]_[PIT, YAW]. The transfer function above the loop bandwidth (few seconds BW, so we will excite >~ 10 Hz) characterizes the response of the sensor to the excitation.
2. Invert the resulting 3x3 matrix and populate the inverted matrix at WFS_OUTMATRIX. This will map the WFS basis to the MC optics' pit/yaw basis.
3. Script this process. If we make changes (for example, moving the telescoping lenses) to make this matrix more diagonal, we'll want to do these steps many times.
2. Characterizing the loop
1. Optimize the demodulation phase -- we want to minimize the signal in Q. This should also be automated. I found documentation in the white Wave Front Sensing binder
1. Misalign a mirror in pitch or yaw, and rotate the phase to minimize the magnitude of Q (maximize I); this angle is 'R' on the WFSx_SETTINGS screen.
2. We should measure a step response applied to each angular dof of the MC optics.
3. Guoy Phase Calibration
3. Characterizing / Calibrating the WFS heads
1. The DCC has LIGO test procedures for their WFS RFPD, as does the white binder; the following checks are relevant for our WFS, and this is how I think we should carry them out (not identical to the procedure as written in the document). For many of these, we'll want to set up the JenneAM laser with a network analyzer for RF modulation.
1. DC path transimpedance
1. Measure the DC power of JenneAM with a power meter, and direct the beam to each of the QPD quadrants. Make sure the beam fits on a single quadrant.
2. This will give us the product of the PD efficiency and DC transimpedance gain
3. Last time this was measured (white WFS binder)
2. notch tuning -- we are going to measure the TF, but I won't tune it without someone as ancient as the electronics
1. Using the network analyzer, measure a transfer function from the laser AM to the QPD head's RF output
1. Is there a pickoff available? The LIGO testing procedures recommend a FET probe
2. We should do this while measuring the DC transimpedance for each quadrant
3. notch rejection ratios
1. While taking the RF transfer function, use the delta marker to record the difference between the notch and the RF operating frequency.
4. RF transimpedance
1. Illuminate the PD with white light from an incandescent bulb (a shot-noise limited source)
1. 6-10 mA of photocurrent should be generated
2. Use an RF spectrum analyzer and low noise RF pre-amplifier (gain ~20dB) to measure the shot noise limited spectrum
3. A piece of scotch tape can be used to make the light uniformly illuminate the QPD
4. Convert this RF PSD to an rms amplitude (voltage) spectral density, and also note the DC photocurrent. This can be used to calculate the RF transimpedance with
1. $Z_\mathrm{RF} = \sqrt{\frac{V_\mathrm{rms}^2I_\mathrm{DC}}{3.2\times 10^{-19}}}$
5. Shot noise limited input sensitivity
1. Measure the RF PSD with the beam blocked and light off; this is the dark photocurrent, and can be used to calculate the shot noise limited sensitivity.

References:

• Binders of documents about the 40m WFS
• LIGO ISC WFS RFPD test procedure (T1200347 is dual frequency, T1200380 is single frequency)
• The associated datasheet template is in T1200381
• Wavefront Sensor (T960111). This document even has a calibration protocol with forms to fill in during testing, so I've printed an extra copy of that appendix.

## Automation

It would be good to script some of what we did yesterday. I'm checking out some scripts I'd used for Qryo and armloss measurements to remember the best way to do this.

• Existing WFS scripts (I didn't try these)
• WFS_DC_offsets -- sets the WFS QPD dark offsets
• block beam, then run script
• MC2_TRANS_offsets -- sets the MC2 transmission offset (why isn't this in the same script as WFS_DC_offsets?)
• MC should be aligned, beams centered on WFS, WFS servo off
• mcWFSallowOn(Off) -- turns on (off) the ASC filter module outputs
• mcwfshold -- turns off the input to WFS servos, but holds the current values of MC optic biases
• mcwfsoff -- turns off the mc wfs loop
• First, turns off the WFS outputs (eg WFS1_PIT OUTPUT)
• Turns off the MC WFS input gains
• Holds the WFS loop outputs

## Miscellany

I noticed yesterday that the PSL_shutterqst box is white, and I've seen timeout requests when eg the reboot script tries to open/close the PSL shutter. It seems like a shutter that should open, so I should find the aux machine to restart it.

14872   Wed Sep 11 14:37:43 2019 aaronUpdateIOOWFS measurements

[aaron, rika]

We identified the Jenne laser and found a long optical fiber that might be able to transport our beam to the AP table.

Now we're searching for documentation on using this laser. Kevin and John measured a TF last year. Koji advised that we needn't worry too much, the current limit is already set correctly and we need only power on the laser.

We moved the breadboard (including a couple PDs, collimating lenses, laser, steering mirrors, etc) over to the AP table, and set it on top of the panel next to the WFS. We mounted the laser on the AP table, and added one lens with f~68 mm after the laser to fit the beam on a single quadrant; the beam was about 1mm diameter (measured by eye) when it entered the QPD. We turned the laser driver on at ~19.4 mA, and directed it to WFS2 via the last two steering mirrors before WFS2.

We monitored the QPD segments' DC level with ndscope on a laptop, and were able to send the beam to each of the four quadrants in turn. We set up the Agilent network analyzer to drive the laser's amplitude modulation and sent the RF signal from the LEMO output on the QPD head directly to the network analyzer. We will take the measurements tomorrow morning.

14873   Thu Sep 12 09:49:07 2019 gautamUpdateComputerscontrol rm wkstns shutdown

Chub wanted to get the correct part number for the replacement UPS batteries which necessitated opening up the UPS. To be cautious, all the workstations were shutdown at ~9:30am while the unit is pulled out and inspected. While looking at the UPS, we found that the insulation on the main power cord is damaged at both ends. Chub will post photos.

However, despite these precautions, rossa reports some error on boot up (not the same xdisp junk that happened before). pianosa and donatella came back up just fine. It is remotely accessible (ssh-able) though so maybe we can recover it...

 Quote: please no one touch the UPS: last time it destroyed ROSSA. Please ask Chub to order the replacement batteries so we can do this in a controlled way (fully shutting down ALL workstations first). Last time we wasted 8 hours on ROSSA rebuilding
14874   Thu Sep 12 12:42:31 2019 aaronUpdateIOOWFS measurements

[rika, aaron]

At Seiji and Gautam's suggestion, we added an additional RF photodiode (NewFocus 1611) to the system so we can calibrate our transfer functions. The configuration is now laser -> BS --> lenses -> QPD and BS --> lenses -> RFPD. We added lenses to get the beams focused on the RFPD and QPD heads, and are again set up for TF measurement.

We took the following data. These parameters were consistent across all measurements:

• 1kHz IF BW
• log sweep with 801 points
• 32 averages
• auto attenuation
• -10 dBm excitation amplitude
• 19.2 mA DC current to the laser
• The DC level of the reference PD is -, and with the beam blocked (dark current) it is
 Measurement file parameters WFS2_SEG1 / RFPD TFAG4395A_12-09-2019_155901.txt 100 MHz - 500 MHz WFS2_SEG1 / RFPD TFAG4395A_12-09-2019_160811.txt 10 MHz - 100 MHz WFS2_SEG1 / RFPD TFAG4395A_12-09-2019_170234.txt 100 kHz - 10 MHz WFS2_SEG2 / RFPD AG4395A_12-09-2019_183125.txt 100 MHz - 500 MHz WFS2_SEG2 / RFPD TFAG4395A_12-09-2019_183614.txt 10 MHz - 100 MHz WFS2_SEG2 / RFPD TFAG4395A_12-09-2019_183930.txt 100 kHz - 10 MHz WFS2_SEG3 / RFPD TFAG4395A_12-09-2019_225243.txt 100 MHz - 500 MHz WFS2_SEG3 / RFPD TFAG4395A_12-09-2019_225601.txt 10 MHz - 100 MHz WFS2_SEG3 / RFPD TFAG4395A_12-09-2019_225922.txt 100 kHz - 10 MHz WFS2_SEG4 / RFPD TFAG4395A_12-09-2019_230758.txt 100 MHz - 500 MHz WFS2_SEG4 / RFPD TFAG4395A_12-09-2019_232058.txt 10 MHz - 100 MHz WFS2_SEG4 / RFPD TFAG4395A_12-09-2019_234447.txt 100 kHz - 10 MHz

After taking the data for segment 1, I moved the beam to segment 2. The beam didn't fit on segment 2 without partially illuminating segment 1 (tested by maximizing the signal on segment 2, then blocking the beam. If the beam is entirely on one segment, only that segment should be effected; in this case, we found that segment 1's DC signal also changed when the beam was blocked). We readjusted the telescoping lenses to get the beam a bit smaller, and now the beam fits on segment 2. We know it is entirely on segment 2 because small beam movements do not change the signal on segment 2.

We are trying to take the remaining data, but AGmeasure keeps hanging while sending the data (after taking the measurement, over 10 min). We tried restarting the network analyzer to no avail. I was able to grab the data by cancelling the measurement and running

AGmeasure --getdata -i vanna

I've uploaded the spectrum for segment 1 in the meantime. Zero model is on the way.

When I finished up the measurements on WFS2, I removed the cables from the AP table and closed the cover.

EDIT: I forgot to switch the LEMO connector to measure the other segments, so we measured the RF signal from segment 1 even when the beam was on segments 2-4. We'll have to try again tomorrow.

14875   Fri Sep 13 10:36:03 2019 aaronUpdateIOOWFS measurements

[rika, aaron]

We are at it again. Rika is setting up the TF measurement, I'm looking into scripting the WFS sensing matrix measurement we made earlier in the week so we can return to it next week.

 Measurement file parameters WFS2_SEG1 / RFPD 100 MHz - 500 MHz WFS2_SEG1 / RFPD 10 MHz - 100 MHz WFS2_SEG1 / RFPD 100 kHz - 10 MHz WFS2_SEG2 / RFPD TFAG4395A_13-09-2019_181415.txt 100 MHz - 500 MHz WFS2_SEG2 / RFPD TFAG4395A_13-09-2019_180955.txt 10 MHz - 100 MHz WFS2_SEG2 / RFPD TFAG4395A_13-09-2019_182918.txt 100 kHz - 10 MHz WFS2_SEG3 / RFPD TFAG4395A_13-09-2019_121533.txt 100 MHz - 500 MHz WFS2_SEG3 / RFPD TFAG4395A_13-09-2019_123820.txt 10 MHz - 100 MHz WFS2_SEG3 / RFPD TFAG4395A_13-09-2019_123243.txt 100 kHz - 10 MHz WFS2_SEG4 / RFPD TFAG4395A_13-09-2019_161834.txt 100 MHz - 500 MHz WFS2_SEG4 / RFPD TFAG4395A_13-09-2019_170007.txt 10 MHz - 100 MHz WFS2_SEG4 / RFPD TFAG4395A_13-09-2019_172001.txt 100 kHz - 10 MHz

When we mesuring TF of SEG4, the beam leaking to SEG1 about 1%.

We finished mesurement SEG2-4 and get the figure by running PDH_calibrate.ipynb .

edit: We observed during segment 2 measurements that blocking the beam reduced the DC level of segment 1 by less than 1%, but still clearly observable. As you can see in the plots, something is suspicious about the normalization of these TFs. We took segment 1 data a few days before the other segments, so perhaps we weren't getting the full beam on the reference PD during the later measurements? When I make this measurement for WFS1, I will try to fix some of these problems by choosing different telescoping optics, and I will consider whether removing the QPD heads from their table will improve the measurement.

14876   Fri Sep 13 10:53:40 2019 aaronUpdateIOOWFS loop measurements

I'm scripting the WFS sensing matrix measurements. I haven't really scripted DTT before, so I'm trying to find documentation or existing scripts. I came across this elog where Gautam measured a sensing matrix during DRMI lock, and he pointed me to some .xml files used for these measurments.

14878   Mon Sep 16 05:08:04 2019 ranaUpdateIOOWFS loop measurements

not need to use DTT. I'm attaching some half-finished notebooks that give the gist.

2. Downsample the data for ease of use.
4. demodulate the data at the specified frequencies.

That's it! Now you have the complex, single frequency TFs. Next you invert the matrix.

14880   Mon Sep 16 11:55:58 2019 rikaUpdateIOOWFS loop measurements

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

17:11

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.

14882   Mon Sep 16 12:38:59 2019 aaronUpdateIOOWFS measurements

I wanted to make a zero model of this circuit to get a handle on the results. I couldn't import zero on pianosa, and I tried pip installing zero, but was denied due to not finding version 3.0.3 of matplotlib. I finally got it to install using

pip3 install zero --user

Oddly, even though I can now import zero when I open a python3 session from the command line, when I open a jupyter notebook and switch to a python3 kernel, the zero module is still unavailable. I think I recall that conda manages the jupyter environment -- is pip managing an entirely separate environment (annoying)?

edit: Yeah, it was something like that. I reminded myself how this works with this article.

14883   Mon Sep 16 17:53:16 2019 aaronUpdateCamerasMC2 trans camera (?) rotated

We noticed last week that the MC2 trans camera has pitch and yaw swapped; I rotated what I thought is the correct camera by 90 degrees clockwise (as viewed from above, like in the attachment), but I now have doubts. It's the camera on the right in the attachment.

14884   Mon Sep 16 19:29:24 2019 KojiUpdateCamerasMC2 trans camera (?) rotated

The left one is analog and 90deg rotated.

14886   Tue Sep 17 09:41:48 2019 gautamUpdateIOOWFS loop measurements

 But it still doesn't lock. We notice that the c1lsc machine doesn't work. So we run rebootCILSC.sh.
14887   Tue Sep 17 10:34:48 2019 aaronUpdateIOOWFS loop measurements

I'm using the notebooks from rana as a starting point, and making a script to measure and fill the WFS sensing matrix. It lives at /users/aaron/WFS/scripts/WFSsensingMatrix.ipynb for now. Here's what it does; what's been tested is in green, untested is goldenrod, uncoded is fire brick.

1. Sets up an nds connection, listening to the WFS channels and the MC#_PIT/YAW IN1 channels.
2. Loops over the excitation channels. For now, I'm assuming the user is injecting excitations one at a time in awggui; in principle, we could excite the various MC angular dof at several frequencies and take a single measurement, or use the natural frequencies of the suspensions.
1. For each excitation, grab the data
2. Filter the data. I'm using a 30 Hz to 40 Hz cheby filter
3. Take an FFT, hold on to that for future reference
4. Generate an LO at the excitation frequency, and demodulate the signals. Strong low pass.
5. The single-frequency transfer function is now [WFS channel] / [excited MC channel]. Each iteration of this loop generates a column of the sensing matrix.
3. Invert the sensing matrix
4. Populate in the appropriate channels of the WFS_OUTMATRIX

# Grabbing data with nds

To run these on pianosa, I ran (inside the jupyter notebook)

import sys
!{sys.executable} -m pip install astropy --user

I'm getting an error when starting the nds2 connection

conn = nds2.connection('192.168.113.201', 31200)
Failed to establish a connection[INFO: Request SASL authentication protocol]+


I didn't find anything on the elog about this error, but I'm looking at the nds user manual. The problem was, I didn't have a valid Kerberos ticket; I opened one on Pianosa with my albert.einstein (note all caps ligo.org).

kinit aaron.markowitz@LIGO.ORG

I'm now able to run the scripts Rana mentions, but I haven't been able to grab the channels I want (eg C1:SUS-MC1_ASCPIT_IN1_OUT); it says the channel isn't found. When I check how many of the Caltech channels are available (conn.count_channels('C1*')), there are none. I was connecting to nds.ligo.caltech.edu, but this must be the wrong server (it has all the channels for the sites). fb and fb1 (and the IP they point to, 192.168.113.201) cannot be connected to, giving the error 'Error occurred trying to write to socket.'

I recall that in the cryo lab, we need to use port 8088 to get data from cymac1, and indeed substituting 31200 -> 8088 lets me access the C1 channels (I can count the channels), but no matter what time I request, nds tells me there is no data available (gap). Gautam came by and diagnosed that the gaps I'm seeing in the frames' data are real, fb is down (see elog).

# WFS Sensing Matrix Script

## Saving extra channels

Continuing, I'm going to modify the script to grab live data. I'm using the iterate and next methods. I noticed that the MC2_TRANS pit/yaw channels are not saved to frames, even though WFS1/2 pit/yaw are. Since I expect I'll want to lookback at these channels, I followed the instructions for adding a daq channel, uncommenting the following line in /opt/rtcds/caltech/c1/chans/daq/C1IOO.ini:

[C1:IOO-MC2_TRANS_PIT_OUT_DQ]
acquire=1
datarate=512
chnnum=10186
datatype=4
[C1:IOO-MC2_TRANS_YAW_OUT_DQ]
acquire=1
chnnum=10189
datarate=512
datatype=4

I made a backup of the old version of this .ini file, which can be found in /users/aaron/backups/190917_C1IOO.ini. I did not remake the model, as I couldn't find the c1ioo model in /opt/rtcds/caltech/c1/userapps/trunk or from the matlab command prompt. I restarted the fb via telnet, but didn't restart the model or check the svn (got an error?). The _DQ channels are now reachable on dataviewer, so things seem to be working.

## awgpy

I also tried importing cdsutils, so I can control awg in the same script that we read out the sensing matrix, but I'm getting the python3 error when I import cdsutils:

No module name '__version'

I tried pip upgrading cdsutils, but it's already up-to-date. I get the above error even if I switch to a python 2 kernel; cdsutils is installed in the python2.7 directory, so I don't know why pip is finding it when I'm running a python 3 kernel. I can move on from this for now, but it would be useful to be able to script the excitation along with the measurement.

# Changes to the user environment

## jupyter on donatella

Tangentially related, Rika wanted to be running some jupyter notebooks while working on donatella. I ran, on donatella:

conda install jupyter

hm, that didn't work. Also jupyter is installed when you install conda, so I'm not sure how there is a version of conda but not of jupyter. I also see that pip and pip3 are not recognized commands on donatella.

## scipy on pianosa

I noticed that some of the functions in the scipy signal processing toolbox were out of date on pianosa. The cheby and welch filters now accept additional kwargs (for eg, before you needed to give IIR filter methods a cutoff frequency normalized to the Nyquist rate, but now you can give it the frequencies and sampling rate separately).

I want to update this package, but I hesitate to break everyone's existing scripts.

14888   Tue Sep 17 10:47:44 2019 rikaUpdateIOOWFS loop measurements

[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

avarage=61

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.

 Quote: [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!   17:11 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.

14889   Tue Sep 17 14:01:46 2019 gautamUpdateCDSdaqd fw dead

For some reason, the daqd_fw service was dead on FB. This meant that no frames were being written since Aug 23, which probably coincides with when the c1lsc frontend crashed. Sad 😢 😭 🙁 . Simply restarting the fw service does not work, it crashes again after ~20 seconds. The problem may have to do with the indeterminate state of the c1lsc expansion chassis. However, this is not something that can immediately be fixed, as Chub is still working on the wiring there. So in summary, no frame data will be available until we fix this problem (it is still unclear what exactly the problem is). Team WFS can still work by getting online data.

Why were the CDS overview DC indicators not red???

Unrelated to this work: I had to key the c1psl crate to get the IMC autolocker functioning again. However, I found that the key 🔑 turns continuously - as opposed to having two well defined states, ON and OFF. Be careful while handling this.

14891   Tue Sep 17 21:34:07 2019 gautamUpdateCDSdaqd fw dead no more

Summary:

1. Frames seem to be written again.Slowly 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.

Details:

1. First, I checked to make sure the /frames partition wasn't full. It wasn't.
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.

 Quote: This meant that no frames were being written since Aug 23, which probably coincides with when the c1lsc frontend crashed. Sad 😢 😭 🙁 .
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).

14895   Wed Sep 18 12:40:09 2019 gautamUpdateCDSFast BIO Mapping at 1Y2

INCORRECT INFO IN THIS ELOG HAS BEEN REMOVED. SEE THIS ELOG FOR THE UPDATED INFO.

Summary:

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.

Details:

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.

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.

Quote:

[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

avarage=61

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.

 Quote: [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!   17:11 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.

14897   Wed Sep 18 15:27:45 2019 gautamUpdateIOOTT cables need to be remade

Summary:

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.

Details:

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

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.

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.

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

[KA, GV]

Summary:

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.

Details:

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)

Tomorrow:

1. Recover POX/POY locking,.
2. ...
 Quote: 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.
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.

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

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.
14906   Wed Sep 25 20:10:13 2019 KojiUpdateCDSc1iscaux testing

== Test Status ==
[none]
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:
/cvs/cds/caltech/target/c1iscaux/testScripts/testDetectMons.str
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:
/cvs/cds/caltech/target/c1iscaux/testScripts/testIPPOS.str
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 (mW) Polarity for the X/Y_Calc channels SEG1 UPPER LEFT C1:ASC-IP_POS_QPD_Seg1_Mon 3.651+/-0.003 (N=10) 2.35+/-0.01 X(+) / Y(+) SEG2 LOWER LEFT C1:ASC-IP_POS_QPD_Seg2_Mon 3.607+/-0.002 (N=12) 2.35+/-0.01 X(+) / Y(-) SEG3 LOWER RIGHT C1:ASC-IP_POS_QPD_Seg3_Mon 3.658+/-0.002 (N=11) 2.37+/-0.01 X(-) / Y(-) SEG4 UPPER RIGHT C1:ASC-IP_POS_QPD_Seg4_Mon 3.529+/-0.004 (N=11) 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.

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.

ELOG V3.1.3-