40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 186 of 341  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  14358   Fri Dec 14 13:06:12 2018 aaronUpdateOMCAligning the OMC

I replaced the 2'' AUX-AS combining BS with a freshly mounted 2'' HR mirror for 1064. The mirror is labelled 'Y1-2037-45-P', and had a comment on its case: 'V'. I aligned the AUX beam from the new HR mirror into the next iris, so AUX passes through irises both before and after the new optic. Now, AS does not go out to the AS PDs.

I mounted the old BS on the SP table in a random orientation.

I also dumped the beam transmitted through one of the AUX steering mirrors before the new HR mirror.

  14363   Mon Dec 17 20:45:40 2018 aaronUpdateOMCAligning the OMC

[gautam, aaron]

We did work in the OMC chamber today to get the OMC aligned. Aaron was in the clean suit while Gautam steered in-air optics. We modified the aux input steering optics and the final two OMC steering optics (between OMMT and OMC), but did not modify any of the AS path optics.

I had already aligned AUX approximately into the AS port from the AP table. With the OMC N door open, we aligned the aux beam first to OM6, then to OMPO, then OM5. OM5 was the last optic in the OMC chamber that we could align to.

From there, Gautam found the aux beam clipping on a few optics on its way to SR4 using the IR viewer. Once we were approximately hitting SR4, we got a return beam in the OMC chamber, which we were able to coalign with the input aux beam.

We had already done the alignment of SR5 into the OMC during the last vent, so we immediately had a refl off of the OMC, which we aligned onto a PD520 from the PSL table (larger aperture than the previous PD, which anyway needed a macroscopic adjustment to catch the refl beam).

Next, we removed the OMC cover, wrapped it in foil, and placed it in the makeshift clean room near the Y end. The screws remain in a foil bucket in the OMC chamber. With the cover off, Aaron moved the OMC input steering mirrors to align the beam in the OMC. We measured ~2.4mW in the OMC refl beam, which means about 240uW is transmitted into the OMC. Aaron thinks the beam overlaps itself after one round trip in the cavity, but that the entire plane may be too low in pitch, so more alignment may be needed here.

With the beam approximately aligned into the OMC, we energized the OMC-L piezo driver with 200V, and applied a ~0.03Hz triangle wave on the OMC diff input (pins 2-7). We monitor the REFL PD, piezo mon, function generator signal, and one of the trans PDs. We noticed that the PZT mon shows the driver saturating before the function generator reaches its full +-10V, which is something to investigate.

We saw what could have been regular dips in the REFL PD signal, but realized that with an unkown level of mode matching, it will be hard to tell whether the light becomes resonant with the DC signal. Gautam has suggested coaligning the aux and PSL beams, then observing the PDH signal from the PSL beam as the OMC sweeps through resonance, while turning aux back on anytime we try to make adjustments to the alignment of the OMC (so I can see the beam in the cavity).

I'll think through the plan in some more detail and we will try to have the OMC locked tomorrow.


gautam:

  1. All references to SR4 etc actually refer to OM4 etc.
  2. For this experiment, we are using the prompt reflection of the AUX beam from the HR surface of the SRM, so as to get maximum light into the cavity.
  3. For 2.4 mW incident on OMC1 (actually we measured the REFL beam on the AS table), we expect ~24 uW inside the cavity, which isn't a lot but still was visible on the card.
  4. After this work, I checked the IMC alignment - it was still easily able to lock to a TEM00 mode, but the transmission was ~half (i.e. ~600cts) of what I am used to it being in low power mode (~1300 cts). I didn't align the cavity to the input beam, as I think in this case, the right thing to do is to align the input beam to the IMC cavity axis.
  14365   Tue Dec 18 18:13:32 2018 aaronUpdateOMCOMC L HV Piezo driver tests (again)

I tested the OMC-L HV driver box again, and made the following observations:

  • Drove the HV diff pins (2,7) with a 5V triangle wave
    • Observed that with a ~0.4V offset on the drive, the HV output (measured directly with a 10x probe) has a 0-(almost)200V triangle wave (for 200V HV in), saturating near 200V and near 0V somewhat before reaching the full range of the triangle
    • The HV mon gives the same answer as measuring the HV output directly, and is reduced 100x compared to the HV output.
    • At 1Hz and above, the rolloff of the low pass still attenuates the drive a bit, and we don't reach the full range.
  • Drove the HV dither pins (1,6) with a 100mV to 10V triangle wave, around 15kHz
    • Even at 10V, the dithering is near the noise of the mon channel, so while I could see a slight peak changing on the FFT near the dither frequency, I couldn't directly observe this on a scope using the mon channel
    • However, measuring the HV directly I do see the dither applied on top of the HV signal. The amplitude of the dither is the same on the HV output as on the dither drive.

[gautam, aaron]

We searched for blips while nominally scanning the OMC length.

We sent a 0.1Hz, 10Vpp triangle wave to the OMC piezo drive diff channels, so the piezo length is seeing a slow triangle wave from 0-200V.

Then, we applied a ~15kHz dither to the OMC length. This dither is added directly onto the HV signal, so the amplitude of the dither at the OMC is the same as the amplitude of the dither into the HV driver.

We monitored the OMC REFL signal (where we saw no blips yesterday) and mixed this with the 15kHz dither signal to get an error signal. Gautam found a pomona box with a low pass filter, so we also low passsed to get rid of some unidentified high frequency noise we were seeing (possibly a ground loop at the function generator? it was present with the box off, but gone with the AC line unplugged). [So we made our own lock-in amplifier.] Photo attached.

We tested the transfer function of the LP, and finding it at 100kHz rather than the advertised 10kHz, we opened the box, removed a resistor to change the 3dB back to 10kHz, and confirmed this by measuring the TF.

We didn't see flashes of error signal in the mixed reflection either, so we suspect that either the PZT is not actuating on the OMC or the alignment is bad. Based on what appears to be the shimmering of far-misaligned fringes on the AS camera, Aaron's suspicion from aligning the cavity with the card, and the lack of flashes, we suspect the alignment. To avoid being stymied by a malfunctioning PZT, we can scan the laser frequency next time rather than the PZT length.

  14664   Tue Jun 11 19:25:58 2019 aaronConfigurationBHDReviving the single OMC BHD design?

I drew out some idea of how we might use a single OMC to clean both paths of the BHD after mixing, without being susceptible to polarization-dependent effects within the OMC. Basically, can we send the two legs of the BHD into the OMC counterpropagating. I've attached a diagram.

I think one issue would be scattered light, since any backscatter directly couples into the counterpropagating mode, and thus directly to the PD. However, unless the polarization of the scattered light rotates it would not scatter back to the IFO. And, since the LO and signal mix before the OMC, this scattered light would not directly add phase noise.

Maybe more problematic would be that if the rejection at the PBS (or the polarization rotation) isn't perfect, light from the LO directly couples into the dark port. Can we get away with a Faraday isolator before the OMC? 

Diagram attached.

  14670   Thu Jun 13 18:01:18 2019 aaronUpdateIOOIMC diagnostics

Continuing this investigation of the IMC, today I am getting familiar with the PMC and FSS. I'd like to measure the frequency noise of the PSL referenced to the PMC.

I checked that the PSL shutter is off, so no light reaches the IMC.

I'm not really sure what I'm looking for on the FSS boxes. I found a few documents to guide:

I ran the FSS autolock script from C1PSL_FSS, nothing obvious changes when I do so. The FSS error signal (which I think is PSL-FSS_MIXERM) is flatlined, and the RC-RF_PD has no LO (PSL-FSS_LOCALC is nan).

  14675   Fri Jun 14 13:10:00 2019 aaronUpdateIOOIMC diagnostics

The circuit diagram for the PMC servo card is D980352. From this diagram, I see that I can send an excitation from the network analyzer to FP2TEST (9.09 kOhm input impedance) where it is added to the PMC error signal before going to the loop filters.

I hook up the following

  • Agilent 4395A output to SR560 (300 Hz HP, gain of 1)
  • SR560 to FP2TEST and to Agilent's channel R
  • PMC error signal IF (mixer box mounted to rack, I noticed the IF BNC->SMA were a bit loose/stressed by a hanging LP RF filter) to SR560 (also 300 Hz HP, gain of 2)
  • SR560 to Agilent channel A

I 'Enable' Test 2 on the PSL screen, so FP2TEST gets added to the error signal.

PDH signal

  • TDS 3034B with four channels
    • 1. PMC servo box external drive (split off from the function generator)
    • 2. PMC servo box output monitor (mirrors the drive, shows when drive is saturating)
    • 3. IF signal (split off after the mixer)
    • 4. PMC Trans (long BNC from the PSL table)
  • SRS DS345 function generator (into the PMC servo box' external drive)
    • 100 Hz signal (there's a 10 Hz pole on the PZT drive, so any faster than this and I can't see both sidebands without the HV output mon clipping)
    • 3.19 Vpp amplitude (smallest amplitude at 100 Hz such that both sidebands are well resolved)
    • 1.52 V offset (center the carrier's PDH error signal at pi/2 out of phase with the drive)

I was able to see the carrier and both sidebands.

I tried to grab this data from the scope via ethernet, but was unsuccessful (timeout errors, I'm using the scripts from scripts/tektronix/tek-dump, and the GPIB box that Kruthi had been using for the GigE cam; I also tried plugging in directly scope->ethernet. Never got anything but timeout errors, so maybe I'm not specifying the port correctly. Anyway the trace is frozen on the scope for later use, or I can easily repeat this now that I know how).

Spectrum

Next, I locked the PMC (Test1 is off, tune DC output adjust until I get some transmission, turn on the loop at Test1, increase the gain to before the loop goes unstable). I'm sending the following channels to SR560 (gain = 2, no filtering, high dynamic reserve, 50 Ohm outputs), and reading spectra from the Agilent 4395A:

  • R-- PMC TRANS PD
  • A-- PDH IF
  • B-- PMC PZT HV MON

The HV mon was always saturating the preamp, so I disconnected it; I added a 50 Hz (6db) high pass to the Trans PD signal, since it has a DC component.

I got to take a look at the traces on the spectrum analyzer front panel, but too tired to do the GPIB for now. There are peaks, things look reasonable.

  14677   Mon Jun 17 12:37:16 2019 aaronUpdateIOOIMC diagnostics

Grabbed the PMC data

I went to set up the spectrum analyzer measurements through GPIB, but inadvertently deleted the contents of ~/Agilent/netgpibdata/ (made a soft link in my folder, decided I wanted it gone but rm'ed instead of unlink). I copied what I think was in that folder back (from /opt/rtcds/caltech/c1/scripts/general/labutils/netgpibdata).

Again, the spectra are:

  • R-- PMC TRANS PD into SR560 with G=2 DC coupled, no filtering
  • A-- PDH IF into SR560 with G=2, DC coupled, no filtering
  • B-- PMC PZT HV MON into SR560 with G=2, AC coupled, no filtering

I recorded the three spectra with the following parameters:

  • Three separate spans:
    • 10 Hz to 150 kHz
    • 100 to 550 kHz
    • 500 kHz to 2.5 MHz
  • bwSpanRatio = 0.1 %
  • averages: 10
  • number of points: 801
  • spec type: noise (PSD units)

I then ran AGmeasure with the above parameters in the yaml, with the rest following the defaults in AgilentTemplate.yaml. I saved the data in /users/aaron/40m/data/PMC/190617/

Looks like the header contains all of the parameters, so I shouldn't have trouble distinguishing the spectra. I didn't get the instant plotting working, but the data seem to be there.

I'm still having trouble getting the data from the oscilloscope. I'm not sure why the tektronix scrips I've used before aren't working, I'm checking it now.

update: Grabbed the data, the issue was just using the wrong IP address. 

 

  14679   Mon Jun 17 16:02:17 2019 aaronUpdateComputerskeyed PSL crate

Milind pointed out that all boxes on the medm screens were white. I didn't have diagnostics from the medm screens, so I started following the troubleshooting steps on the restart procedures page.

It seemed like maybe a frontend problem. I tried telnet-ing into several of the fe, and wasn't able to access c1psl. The section on c1psl mentions that if this machine crashes, the screens will go white and the crate needs to be turned off and on. Millind did this.

Now, most of the status lights are restored (screenshot).

 


Milind: I did a burtrestore following this and locked the PMC following the steps described in this elog.

  14681   Tue Jun 18 20:35:07 2019 aaronUpdateIOOIMC diagnostics

I made a script (/users/aaron/40m/GPIB/tds_dump.py) that grabs data from a Tektronix scope and packages into a pickled dict with the following structure:

  1. ch1
    1. times ("ts")
    2. values ("vals")
    3. channel info ("info")
  2. ch2
    1. ""
  3. etc

I made a python notebook that does the following:

  1. Grab the data from the pickle above
  2. Fit a triangle wave to the drive signal
  3. Determine the (change in Volts) / second from the triangle wave, as well as define the times of a single sweep of the PDH error signal
  4. Trim the error signal data to contain the PDH signal from the carrier and two sidebands only (the original trace was for three periods).
  5. Fit the functional form of the PDH signal to the trimmed error signal. 
    1. The sideband frequency is fixed at 35.5 MHz, and the scaling of Volts-to-Hz is left free, so this fit gives the calibration of IF volts to Hz.
  6. Grab the spectra (already saved from the Agilent with the netgpib scripts) and apply this V-to-Hz scaling
  7. Plot the spectra

The fit in step (5) is still looking quite bad, despite the fitted values being close to the expected. Since we really just want a calibrated spectrum, I'll instead fit a line to the linear portion of the PDH error signal for the carrier and both sidebands, then determine the scaling from that.

  14683   Wed Jun 19 19:12:51 2019 aaronUpdateIOOIMC diagnostics

Here are the results from the fit. Data can be found on nodus in /users/aaron/40m/data/PMC/190617/. I've put a jupyter notebook with the analysis in /users/aaron/40m/analysis/PDH_calibrate.ipynb (might be some filename issues due to different directory structure on my laptop).

Here's a summary of the current measurement. I'll be referencing the diagram for the PMC servo card.

  1. With the PMC servo loop open, sweep the PMC PZT by sending a triangle wave in to J5 (external drive on the servo card).
    1. I used a 100Hz drive, but should use something slower so my drive isn't filtered out by the 100Hz pole on the servo card and the 10Hz pole on the PZT.
  2. Monitor the voltage at the HV drive, as well as at "mixer out" (J8 on the servo board)
    1. Note that I took this PDH error signal from FP2TEST rather than "mixer out", which means my error signal was not low pass filtered.
  3. Calibrate the HV mon in units of Hz by fitting the PDH signal. The sidebands should be 35.5Mhz away from the carrier peak.
    1. This part needs to be done differently to account for thermal locking in the PMC.
  4. You now have the PDH error signal as a function of PMC resonance in Hz, and can use that to calibrate the PDH error spectrum.
    1. The spectrum is taken when the PMC is locked, so the Hz/V scaling is the slope of the PDH error signal.

In the figures below, I obesrved that for fast (100Hz) drives, the PDH error signal had a pi/2 phase shift relative to the triangle wave, which means even though the resonance appears near the turnaround of the triangle, it is actually occuring near the center of the range.

There are several problems with this data:

  • PMC error signal spectrum is not properly calibrated, even according to the process described above
  • The drive was faster than the response of the PZT.
  • I was driving with a ~1V excitation, so I've lost a factor of 10 somewhere on the way to the external drive curve. Probably just a problem with how I've read the data dump from the scope.
  14693   Mon Jun 24 15:49:05 2019 aaronUpdateIOOIMC diagnostics

aI went to repeat these measurements using the mixer out channel from the servo box, and with a slower sweep for the PDH calibration.

I had trouble getting the PDH signal, here are some notes:

  • I added a 50 Ohm terminator to BNC T on the mixer box. This had been terminated before I started, but I noticed no terminator today.
  • Noticed some distortion of my driving triangle wave if I measured it on ch3 and 4 of the tektronix scope, not present on ch 1/2
  • Initially wasn't finding a signal because I was opening the loop by turning off the Test 1 switch, but this meant the mixer mon on the servo box also did not receive the PDH signal. Instead, I cut the loop with the "BLANK" switch on the PMC screen, which instead blanks out the op amp between the mixer mon and the PMC drive conditioning (so the external drive still reaches the PZT).

attachment 1 is the configuration of the PMC screen when I was trying to get some PDH signal; I did move the DC output adjust to 0V, but found that this led to the output being railed; this makes sense, the op amp at U9 has a negative bias at GND.

Rana came by and gave me some tips.

  • I'd been using the wrong servo board diagram, it should be in D1400221
  • We removed the LP filter from the mixer output (before going to FP1TEST on the servo board), since the board itself already is filtering the IF.
  • We might have observed the thermal locking? See for yourself, the trans and refl signals while sweeping the PZT drive at 5 Hz and 30 Hz respectively are in attachments 2 and 3.
  • Rather than using an SR560, I should use an RF coupler between the mixer and FP1TEST to measure the error signal spectrum. I found a ZFDC-20-5-S+ (0.1-2000 MHz) and sent an SMA cable from the coupled port to channel R of the Agilent 4395.

We finally got the PDH signal again, and I recorded the PDH signal while driving with the following settings on the Siglent function generator.

  • 1.1 Hz triangle wave, 6Vpp, -7Vdc offset, high impedance mode

I tried getting a spectrum using the coupler, the mixer mon is seeing a DC offset though and causing the PZT to rail. Will try to understand why, but in the meantime removing the coupler (still no LP filter) lets us lock the PMC again.

RXA: Kruthi thinks all of our subsequent IMC locking problems are Aaron's fault (she was quick to give him up as soon as the thumb screws were tightened...)

  14699   Wed Jun 26 10:55:13 2019 aaronUpdateIOOPMC and IMC locked again, some MEDM maintenance

The PMC was locking again after Gautam's steps above. However, after I added the directional coupler between the mixer I and the servo card (coupled to the Agilent analyzer), the PMC was again not locking, except occasionally with gain of -10 dB.

I removed the coupler (so the mixer I goes directly to the PMC servo card, as Gautam had it), and the PMC was still not locking. While checking connections, I noticed that one of the SMA cables between the LO and the mixer was not even finger tight, so I tightened them to approximately the right torque with a non-torque wrench.

This did not lead to the PMC locking, so Millind helped me key the c1psl VME crate. I burt restored the latest snapshot. Now, the PMC locks up until gain of -5. I try burt restoring the previous snapshot, which was from when the PMC was locking, and now it locks. Adding in the directional coupler again leads to the PMC not locking, though this time removing the coupler restores the normal behavior. I also tried using the coupler with the coupling port connected to a 50 Ohm terminator, and this configuration also did not lock.

I had been using a ZFDC-20-5-S+ (0.1-2000 MHz) with SMA ports and SMA-to-BNC on the input and output ports (since the mixer has BNC connectors). To reduce the number of potentially flaky connections, I am trying the ZFDC-20-4 (1-1000 MHz) that I found with BNC ports. The PMC still doesn't lock.

To get some spectrum, I've connected the PMC servo card's 'mixer out' to the Agilent's A channel, and collected a spectra from [10 Hz, 75 kHz], [75 kHz, 750 kHz], and [750 kHz, 2 MHz].


Wed Jun 26 15:23:37 2019

After the lab cleaning, I added a BNC T on the mixer I port, so now the configuration is:

Mixer I -> BNC T

-> PMC Servo card FP1TEST

-> directional coupler -> coupled to the spectrum analyzer, out port is terminated with 50 Ohms.

I thought maybe the issue was that the TF from in->out on the directional coupler is not what I expect (and Gautam suggested the in-out port might block DC), but the PMC still does not lock in the above configuration, in which the coupler is not between the mixer and the servo board--so only reflections from the coupler should matter, I think.

However, even when I plug the mixer directly into the servo board, the PMC is not locking (again) with gain above -8 dB or so. I did a burt restore again, and this fixed the problem. I wasn't sure why this burt restore is working, because all I am changing is the DC output adjust voltage and the gain, and switching on/off FP1TEST. However, I observed that after running the PMC autolocking script, observing that the autolocker did not achieve lock as it swept through resonance, and cancelling the autolocker, the PMC again cannot be locked for high gains. When I let the autolocker complete, this doesn't happen, so probably I'm just not letting some channel return to its nominal value after being changed by the autolocker.

Now after another burt restore, I'm avoiding using the autolocker and am still having trouble locking with the BNC T + directional coupler configuration above. However, now I'm noticing that the PZT control mon is always railed, as long as FP1TEST is in the loop (and independent of the output adjust voltage). I try returning to the 'baseline' configuration (mixer -> PMC servo card directly), and the PMC locks but with only 0.68 V transmission (was >0.7 V before).


Per Gautam's earlier suggestion, I switched to using the Agilent 41800A probe instead of the directional coupler. I was able to lock the OMC with this probe on a BNC T coming out of the mixer (transmission is 0.71 V). I recorded the spectra of the PMC servo board's "Mixer Out" channel, and the mixer's I as seen by the probe. I recorded spectra from 10 Hz to 100 MHz. The soft linked netgpibdata folder I had in my users directory is no longer soft linked--presumably intentional so I don't tamper with it?

I'm a bit skeptical that I've used the probe correctly, so I'm checking out the manual.

Indeed, I needed to pull back the sheath; I also noticed that the GPIB script I've been using doesn't save the data from both channels when I take a spectrum in dual mode, so I'm taking the spectra again one at a time (lights are on, IMC is locked).

  14721   Tue Jul 2 19:36:18 2019 aaronUpdateIOOIMC diagnostics

The latest in my fling with the PMC. Though PMC trans is back to nominal levels (~0.713 V), we'd still like to understand the PMC noise.

Last time, I took some spectra with the RF probe (Agilent 41800A). I had already measured the PDH error signal by sweeping the PZT at ~1 Hz. The notebook I used for analysis has been updated in /users/aaron/analysis/PDH_calibrate.ipynb. The analysis was the following:

  • fit the PDH error signal, assuming a 35.5MHz modulation frequency. Here are the (approximate) fit parameters:
    • Mapping of PZT mon voltage to Hz: 5.92 Hz/V_{PZT_mon}
    • P_carrier*P_signal: 0.193 W^2
    • HV mon voltage on resonance: 0.910 V
    • Error signal far off resonance: 0.249 V
    • Transmission: 0.00238
      • ​yikes. The nominal transmission is T=0.003. I let this parameter be free as a check, and to avoid overconstraining the data; is this consistent with measurements of the PMC optics' transmission?
    • Length: 0.0210 m
      • This is consistent with the nominal PMC length
  • Using the fit of the full PDH error signal, I am able to plot error signal vs frequency, and fit the linear portion of the carrier PDH signal. The results of this fit are:
    • -9.75e-7 V_PDH per Hz
    • 0.105 V error signal at DC
  • I then divide the power spectra by the squared slope of the linear fit above (V_PDH^2/Hz^2) to get the spectra in Hz^2/rtHz
    • I've plotted both the spectrum I took directly at the mixer I using the agilent probe, as well as the spectrum taken by sending the PMC servo card's mixer mon to an SR560 (G=2) then to the spectrum analyzer

There are a few problems remaining:

  • There should be a gain of 100 between the mixer I and the servo board's mixer out. It's not clear to me that this is reflected in the spectra. Moreover, the header files on the spectra I grabbed from the Agilent say that the R (mixer I) channel has 20dB of input attenuation, which is also not reflected. If I have swapped the two spectra and not accounted for either the gain of the servo card or the attenuation of the spectrum analyzer, these two gains would cancel, but I'm not confident that's what's going on.
  14858   Thu Sep 5 18:42:19 2019 aaronHowToCDSWFS discussion, restarting CDS

[aaron, rana]

While going to take some transfer functions of the MC WFS loop, LSC was down. When we tried to restart the FE using 'rtcds restart --all', c1lsc crashed and froze. We manually reset c1lsc, then laboriously determined the correct order of machines to reboot. Here's what works best:

on c1lsc:

rtcds start c1x04 c1lsc c1ass c1oaf c1cal c1daf

Starting c1dnn crashes the other FE

on c1ioo

rtcds restart --all

on c1sus

rtcds restart c1rfm c1sus c1mcs

restarting c1pem crashes the other FE on c1sus

We're seeing a lot of red IPC indicators--perhaps it's an issue with the order we're restarting?

  14860   Fri Sep 6 09:40:56 2019 aaronHowToCDSWFS discussion, restarting CDS

As suggested, I ran the script cds/rebootC1LSC.sh

I got a timeout error when the script tried closing the PSL shutter ('C1:AUX-PSL_ShutterRqst' not found), but Rana and I closed the shutter before leaving last night. c1sus is down, so the script found no route to host c1sus; I'm thinking I need to reset c1sus for the script to run completely. Nonetheless, c1lsc was rebooted, which crashed c1ioo and left the c1lsc FE all red (probably because c1sus wasn't restarted).

 

  14861   Fri Sep 6 11:56:44 2019 aaronHowToCDSWFS discussion, restarting CDS

Rebooting

I reset c1lsc, c1sus, and c1ioo.

I noticed that the script gives the command 'ssh c1XXX', but we have been getting no route to host using this command. Instead, the machines are currently only reachable as c1XXX.martian. I'm not sure why this is, so I just appended .martian in rebootC1LSC.sh

This time, the script does run. I did get 'no route to host' on c1ioo, so I think I need to reset that machine again. After reset, the script failed to login to c1ioo and c1lsc.

Fri Sep 6 13:09:05 2019

After lunch, I reset the computers again, and try the script again. There is again no route to host for c1ioo. I'm going inside to shutoff the power to c1ioo, since the reset buttom seems to not be working. I still can't login from nodus, so I'm bringing a keyboard and monitor over to plug in directly.

On reset, c1ioo repeatedly reaches the screen in attachment 1, before going black. Holding down shift or ctrl+alt+f1 doesn't get me a command prompt. After waiting/searching the elog for >>3 min, we decided to follow these instructions to cycle the power of c1ioo. The same problem recurred following power up. I found online some instructions that the SunSystems 4600 can hang during reboot if it has become too hot ("reboot during a thermal shutdown"); I did notice that the temperature light was on earlier in this procedure, so perhaps that is the problem. I followed the wiki instructions to shut down the computer again (pressed power button, unplugged 4 power supplies from back of machine), and left it unplugged for 10-30 min (Fri Sep 6 14:46:18 2019 ).

Fri Sep 6 15:03:31 2019

Rana plugged in the power supplies and reset the machine again.

Fri Sep 6 16:30:37 2019

c1ioo is still unreachable! I pressed reset once, and the reset button flashes white. The yellow warning light is still on.

Fri Sep 6 16:54:21 2019

The reset light has stopped flashing, but I still can't access c1ioo. I reset once more, this time watching c1ioo on a monitor directly. I'm still seeing the same boot screen repeatedly. I do see that CPU0 is not clocking, which seems weird.

Troubleshooting CPU module

Following gautam's elog here, I found the Sun Fire X4600 manual for locating faulty CPUs. After the white reset light stopped flashing, I held down the power button to turn off the system. Before shutdown, all of the CPU displayed amber lights; after shutdown, only the leftmost CPU (as viewed from the back, presumably CPU0) displays an amber light. The manual says this is evidence that the CPU or DIMM is faulty. Following the manual, I remove the standby power, then checked out these Instructions for replacing the CPU to remove the CPU; Gautam also has done this before.

Fri Sep 6 20:09:01 2019 Fri Sep 6 20:09:02 2019

I pulled the leftmost CPU module out, following the instructions above. The CPU module matches the physical layout and part number of the Sun Fire X4600 M2 8-DIMM CPU module; pressing the fault reminder light gives amber indicators at the DIMM ejectors, indicating faulty DIMMs (see). The other indicator LEDs did not illuminate.

I located several spare DIMMs in the digital cabinet along Y arm (and a couple with misc computer components in the control room), but didn't find the correct one for this CPU module. The DIMM is Sun PN 371-1764-01; I found it online and ordered eight. Please let me know if this is incorrect.

To protect the CPU module, I've put it in an ESD safe bag with some bubble wrap and a note. It's on the E shop bench.

Conclusion: Need new DIMM, didn't find the correct part but ordered it.

  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.

  14866   Fri Sep 6 22:03:30 2019 aaronHowToCDSHow to save c1ioo

Saw these slightly delayed.

Q1: Not sure--is it a safe operation for me to remove the DIMM on CPU0, replace CPU0 (with no DIMM), and boot up to try this?

Q2: Specifically, it's this DIMM. The CPU core is compatible with DDR2, clock rate up to 333 MHz (DDR2-667) and 1, 2, or 4 GB of memory.

Q3: Hmm checking on that.
I see a message on megatron that it's currently running MC autolocker and the FSS slow servo, with nothing else listed. It's currently running 30-70% of its available memory on all 8 cores, so seems it's got some to spare. I need to relocate the old c1omc RT machine for myself, but becoming inefficient so I'm off.
 
Quote:

Q1 Can we run the machine with the reduced # of cores?

Q2 We might be able to order them quickly. What's the spec and configuration of the DIMMs (like DDR2-667MHz ECC 4GBx4, and even more specs (like Samsung 2GB DDR2 RAM PC2-6400 240-Pin DIMM M378T5663EH3) so that we are to identify the exact spec).

Q3 Can we scavenge the old OMC RT machine or even megatron to extract the memories?

  14867   Mon Sep 9 11:36:48 2019 aaronHowToCDSHow to save c1ioo

One pair of DIMM cards from the Sunstone box had the same Sun part number as those in c1ioo, so I swapped them in and reinstalled c1ioo's CPU0. c1ioo now boots up an seems ready to go, I'm able to log on from nodus. I also reinstalled optimus' CPU0, and optimus boots up with no problems.


  • old C1OMC RT
  • Megatron
    • I also found that megatron will require a CPU filler board if we remove one of its DIMM (it cannot operate with empty CPU module slots)
  • optimus
    • Rana says I can also consider using two of optimus' DIMM cards. Optimus appears to not be running any scripts currently, and I don't find any recent elog entries or wiki pages mentioning optimus with critical use.
    • I shutdown optimus (from the command line Mon Sep 9 13:17:58 2019).

While opening up optimus, I noticed a box labelled 'SUNSTONE' sitting below the rack--it contains two CPU modules a similar type as in c1ioo! I'm going to try swapping in the DIMM cards from this SUNSTONE box; I didn't find any elogs about sunstone--where are these modules from?

I reset c1lsc and c1sus, then ran rebootC1LSC.sh as before. All models started by the script are running with minimal red lights; c1oaf, c1cal, c1dnn, c1daf, and c1omc are not started by the script. I manually started these in the order c1cal->c1oaf->c1daf->c1dnn. Starting c1dnn crashed the other FE on c1ioo, so I reset all three FE again, and ran the script again (this time, including the startup for c1cal, c1oaf, and c1daf, but excluding c1dnn).

Except for c1dnn and c1omc, all models are started. The status lights are attached.

  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.

 

 

  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.

  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.

 

  14881   Mon Sep 16 12:00:16 2019 aaronHowToGeneralMoved some immovable optics

When I put away the lenses we had used for measuring the RF transfer functions of the QPD heads, I saw that I'd removed them from the cabinet containing green endtable optics, but hadn't noticed the sign forbidding their removal. I'll talk with Koji/Gautam about what happened and what should be done.

  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.

  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.

  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.

  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

systemd.unit=emergency.target

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

  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.

Details:

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

  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.

  14940   Fri Oct 4 14:25:59 2019 aaronUpdateGeneralMake the Jenne-laser setup fiber-coupled

Summary:

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.

Details

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).
  14945   Mon Oct 7 14:51:20 2019 aaronUpdateElectronicsWFS head RF measurements

Mon Oct 7 14:51:53 2019. I closed the PSL shutter to measure the WFS head responsivity.

I made a thru calibration as in this elog, treating laser, reference PD, and WFS RF output as a three-port device. The DC current supplied to the laser is 20.0 mA in all cases. The Agilent spectrum analyzer supplies a -10 dBm excitation to Jenne laser's AM port, and A/B is measured with 20dB attenuation on each input port. Results are in /users/aaron/WFS/data/191007/. The calibration had 100 averages, all other measurements 32 averages; other parameters found in the yml file, same folder as the data.

Measurement Reference PD DC (V) WFS Segment DC (V) WFS Segment DC, beam blocked (V) File Notes
WFS 1 Segment 1 1.86 0.79 -0.23
TFAG4395A_07-10-2019_154446.txt
 
WFS 1 Segment 2 1.86 0.72 -0.30 TFAG4395A_07-10-2019_155017.txt  
WFS 1 Segment 3 1.86 0.79 -0.21
TFAG4395A_07-10-2019_155645.txt
 
WFS 1 Segment 4 1.86 0.70 -0.30
TFAG4395A_07-10-2019_160334.txt
TFAG4395A_07-10-2019_160847.txt
I noticed the BS-PRM illuminator was on, and turned it off for the second measurement
WFS 2 Segment 1 1.86 0.56 -0.38 TFAG4395A_07-10-2019_162533.txt  
WFS 2 Segment 2 1.86 0.71 -0.21
TFAG4395A_07-10-2019_163402.txt
 
WFS 2 Segment 3 1.86 0.68 -0.28 TFAG4395A_07-10-2019_164152.txt  
WFS 2 Segment 4 1.86 0.57 -0.42 TFAG4395A_07-10-2019_164745.txt  

 

I normalized the result by the difference between the dark and bright DC levels of each segment.

Mon Oct 7 17:29:58 2019 opened PSL shutter.

  14951   Tue Oct 8 16:00:06 2019 aaronUpdateElectronicsWFS head RF measurements

I simulated this circuit with zero, but haven't gotten the results to match the measurements above.

Removing the DC readout chain from the circuit does not affect the AC response.
Perhaps something to do with the (currently unmodeled) capacitance of the diode? I think this forms a necessary part of the resonant circuit. The gain is also suspiciously low.
Edit: Indeed, simply adding the 'typical' shunt capacitance (9pF) and a small series resistor (10 Ohm) gives the right qualitative response
The python notebook is in /users/aaron/WFS/electronics.
The DC response flattens off at ~20dB by ~mHz, which also seems longer than the timescales I saw while measuring; I'm not sure I have some of the AD827 parameters correct (eg 'delay')
 
I came across this nice note on photodiodes.
 
 
  14957   Tue Oct 8 20:39:42 2019 aaronUpdateIOOWFS loop measurements

I installed nds2 on donatello with yum, but still can't import nds2.

  14958   Wed Oct 9 09:37:28 2019 aaronUpdateIOOWFS loop measurements

I installed nds2 again, this time successfully with

conda install -c conda-forge python-nds2-client

 

  375   Thu Mar 13 12:11:58 2008 aivanovUpdateComputer Scripts / Programsrouting PEM -> ASS -> SUS_MCL

on ASS RFM 1 has PEM signals at

float at 0x100000 has c0dcu1 first ICS110B chan 1
float at 0x100004 has chan 2
etc.

ASS sends to RFM 0

float at 0x100000 goes to PRM MCL
0x100004 to BS MCL
0x100008 to IMTX MCL
0x10000c to ITMY MCL
0x100010 to SRM MCL
0x100018 to MC1 MCL
0x10001c to MC3 MCL
0x100020 to ETMX MCL
0x100024 to ETMY MCL
  376   Thu Mar 13 13:15:09 2008 aivanovUpdateComputer Scripts / Programsnew sfotware intall, backup files
New:
op440m:40m>ls -alt /cvs/cds/caltech/target/c1susvme[12]/*.o
-rw-r--r-- 1 controls staff 57920 2008-03-13 13:11 /cvs/cds/caltech/target/c1susvme2/losLinux2.o
-rw-r--r-- 1 controls staff 57976 2008-03-13 13:11 /cvs/cds/caltech/target/c1susvme1/losLinux1.o
op440m:40m>ls -alt /cvs/cds/caltech/target/c1isce[xy]/*.o
-rw-r--r-- 1 controls staff 246861 2008-03-13 13:12 /cvs/cds/caltech/target/c1iscey/losEtmy.o
-rw-r--r-- 1 controls staff 246861 2008-03-13 13:12 /cvs/cds/caltech/target/c1iscex/losEtmx.o
op440m:40m>ls -alt /cvs/cds/caltech/target/c0dcu1/*.o
-rw-r--r-- 1 controls staff 63547 2008-03-12 14:57 /cvs/cds/caltech/target/c0dcu1/dcuDma.o


Backups:
op440m:40m>ls -alt /cvs/cds/caltech/target/c1susvme[12]/*.o.13mar08
-rw-r--r-- 1 controls staff 55960 2005-06-21 13:30 /cvs/cds/caltech/target/c1susvme2/losLinux2.o.13mar08
-rw-r--r-- 1 controls staff 55960 2005-06-21 13:30 /cvs/cds/caltech/target/c1susvme1/losLinux1.o.13mar08
op440m:40m>ls -alt /cvs/cds/caltech/target/c1isce[xy]/*.o.13mar08
-rw-r--r-- 1 controls staff 229793 2007-03-08 11:09 /cvs/cds/caltech/target/c1iscex/losEtmx.o.13mar08
-rw-r--r-- 1 controls staff 229793 2007-03-08 11:09 /cvs/cds/caltech/target/c1iscey/losEtmy.o.13mar08
op440m:40m>ls -alt /cvs/cds/caltech/target/c0dcu1/*.o.12mar08
-rw-r--r-- 1 controls staff 60810 2004-09-08 08:47 /cvs/cds/caltech/target/c0dcu1/dcuDma.o.12mar08
  3   Thu Oct 18 15:03:14 2007 ajwRoutineGeneralthis is only a test

  7   Mon Oct 22 12:02:59 2007 ajwRoutineGeneralSTACIS as microseismic shaker
In case we ever want to use our Stacis systems as shakers, check this:
link
  30   Tue Oct 30 13:58:07 2007 ajwConfigurationIOOMC Ringdowns
Here's a quick fit-by-eye to the latter part of the data from tek00000.xls.

The prediction (blue) is eqn 41 of
http://www.ligo.caltech.edu/docs/P/P000017-A.pdf

T1 = T2 = 0.002. Loss1 = Loss2 = 150 ppm.
MC3 assumed perfectly reflecting.
Velocity = 320 um/s (assumed constant), 2 usec into the ringdown.

OK, there's one little fudge factor in the prediction:
I multiplied D by 2.
  77   Wed Nov 7 10:55:21 2007 ajwConfigurationComputersbackup script restarted
Following the reboot of computers on 10/31/07, the backup script required restart (which unfortunately "can't" be automated because a password needs to be typed in). I restarted, following the instructions in /cvs/cds/caltech/scripts/backup/000README.txt and verified that it more-or-less worked last night (the rsync sometimes times out; it gets through after a couple of days of trying.)
  144   Fri Nov 30 11:22:22 2007 ajwSummaryCDSGEO DV => LIGO DV

Quote:
Martin Hewitson of GEO600 fame has modified the cool GEO DV
to work with the LIGO NDS system with some NDS advice from Rolf (who's over in Germany this week).

I've moved it onto the 40m CDS system and installed it on the AdhikariLab computer named 'django'. It worked immediately.

I modified the main .m file to include the 40m's NDS server. When you run it you have to include the path to the NDS
client written by Ben Johnson.

The attached is a screenshot of it working on a Mac; it looks as cool on Linux.

Its installed in /cvs/cds/caltech/apps/ligoDV/. In matlab you navigate to that directory and then
type addpath('/cvs/cds/caltech/apps/linux/UNIX_NDS_Client_beta2/') to add the NDS client.
On the Solaris machines, type type addpath('/cvs/cds/caltech/apps/solaris9/UNIX_NDS_Client_beta2/') instead.

Then type ligoDV to start it up. Then click away and have fun.

In the example I've selected
C1:PEM-BS_ACC_EAST_Z
and plotted its specgram.

Big grin


Download and installation instructions, as well as a few examples for use
can be found here (typical lsc username and password):

https://www.gravity.phy.syr.edu/dokuwiki/doku.php?id=ligodv:home
https://www.gravity.phy.syr.edu/dokuwiki/doku.php?id=ligodv:downloading_the_ligodv_software
  453   Sat Apr 26 11:21:15 2008 ajwOmnistructureComputersbackup of /cvs/cds restarted
The backup of /cvs/cds (which runs as a cron job on fb40m; see /cvs/cds/caltech/scripts/backup/000README.txt) 
has been down since fb40m was rebooted on March 3.
I was unable to start it because of conflicting ssh keys in /home/controls/.ssh .
With help from Dan Kozak, we got it to work with both sets of keys
( id_rsa, which allows one to ssh between computers in our 113 network without typing a password,
 and backup2PB which allows the cron job to push the backup files to the archive in Powell-Booth).

It still goes down every time one reboots fb40m, and I don't have a solution.
A simple solution is for the script to send an email whenever it can't connect via ssh keys
(requiring a restart of ssh-agent with a passphrase), but email doesn't seem to work on fb40m.
I'll see if I can get help on how to have sendmail run on fb40m.
  457   Sun Apr 27 22:57:15 2008 ajwDAQComputersbr40m?

Quote:

The testpoint manager (which runs on fb40m) crashed this afternoon. Upon re-starting it, I found there was a rogue dtt process on op440m and also a daqd daemon running on br40m. One or both of these caused the tpman to crash. br40m is the frame broadcaster, which is never used here as we don't run DMT. I killed the daqd process there.

The way to find if there is a rogue process is to watch the output to the console from the tpman when you start it:

Allocate new TP handle 56 by 131.215.113.203
Allocate new TP handle 57 by 131.215.113.203
Allocate new TP handle 58 by 131.215.113.203
Allocate new TP handle 59 by 131.215.113.203
Allocate new TP handle 60 by 131.215.113.203
Allocate new TP handle 61 by 131.215.113.203
Allocate new TP handle 62 by 131.215.113.203
Allocate new TP handle 63 by 131.215.113.203
Allocate new TP handle 64 by 131.215.113.203
Allocate new TP handle 65 by 131.215.113.203
Allocate new TP handle 66 by 131.215.113.203
Allocate new TP handle 67 by 131.215.113.203
Allocate new TP handle 68 by 131.215.113.203


If you see something like this, with a new TP handle being allocated every few seconds, you need to log in to the corresponding host and kill whatever process has run away.


I *think* Alex is responsible for the daqd daemon running on br40m (he set up some new stuff recently, a data concentrator and broadcaster); I'll make sure he sees this post.
  1854   Fri Aug 7 13:42:12 2009 ajwOmnistructureComputersbackup of frames restored

Ever since July 22, the backup script that runs on fb40m has failed to ssh to ldas-cit.ligo.caltech.edu to back up our trend frames and /cvs/cds.

This was a new failure mode which the scripts didn't catch, so I only noticed it when fb40m was rebooted a couple of days ago.

Alex fixed the problem (RAID array was configured with the wrong IP address, conflicting with the outside world), and I modified the script ( /cvs/cds/caltech/scripts/backup/rsync.backup ) to handle the new directory structure Alex made.

Now the backup is current and the automated script should keep it so, at least until the next time fb40m is rebooted...

 

  532   Thu Jun 12 15:09:33 2008 alanUpdateLockingreport
Rob: Awesome figure. As you can imagine, I have lots of questions, and hope that you will consider this figure to be the beginning, leading to ever-more detailed versions. But for now, I just want to ask whether you understand *what* is twitchy, and what the twitchiness does to prevent you from taking this further?
ELOG V3.1.3-