40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 174 of 341  Not logged in ELOG logo
ID Date Author Type Categorydown Subject
  13721   Fri Mar 30 06:14:31 2018 ranaUpdateIOOMCREFL_PD Optical response measurement

the noise eater on/off measurements should be done for 0-100 kHz and from the demod board output monitor

  13724   Fri Mar 30 22:37:36 2018 KevinUpdateIOOMCREFL_PD Optical response measurement

[Gautam, Kevin]

We redid the measurement measuring the voltage noise from the REFL PD demod board output monitor with an SR785 with the noise eater on and off. We used a 100x preamp to amplify the signal above the SR785 noise. The SR785 noise floor was measured with the input to the preamp terminated with 50 ohms. The spectra shown have been corrected for the 100x amplification.

This measurement shows no difference with the noise eater on or off.

Quote:

the noise eater on/off measurements should be done for 0-100 kHz and from the demod board output monitor

 

Attachment 1: REFLPD_DemodBoard.pdf
REFLPD_DemodBoard.pdf
  13728   Thu Apr 5 04:36:56 2018 KevinUpdateIOOCoil driver noise

[Gautam, Kevin]

We measured the MC coil driver noise at the output monitors of the coil driver board with an SR785 in order to further diagnose the excess IMC frequency noise.

Attachments 1 and 2 show the noise for the UL coils of MC3 and MC2 with various combinations of output filters engaged. When the 28 Hz elliptic filter is on, the analog dewhitening filter is off, and vice versa. The effect of the analog low pass filter is visible in MC3, but the effect of the digital low pass filter is swamped by the DAC noise.

We locked the arms and measured the ALS beatnote in each of these filter combinations, but which filters were on did not effect the excess IMC frequency noise. This suggests that the coil drivers are not responsible for the excess noise.

Attachment 2 shows the noise for all five coils on MC1, MC2, and MC3 as well as for ITMY, which is on a different DAC card from the MCs. All filters were on for these measurements.

 

Attachment 1: MC3.pdf
MC3.pdf
Attachment 2: MC2.pdf
MC2.pdf
Attachment 3: CoilDriver.pdf
CoilDriver.pdf
  13730   Thu Apr 5 12:13:18 2018 KojiUpdateIOOCoil driver noise

Why is MC2 LR so different from the others???

  13737   Fri Apr 6 21:39:09 2018 gautamUpdateIOOMC2 suspension health checkup

While Kevin is working on the MC2 electronics chain - we disconnected the output to the optic (DB15 connector on coil driver board). I decided to look at the 'free' freeswinging MC2 OSEM shadow sensor data. Attachment #1 suggests that the suspension eigenmodes are showing up in the shadow sensors, but the 0.8Hz peak seems rather small, especially compared to the result presented in this elog.

Maybe I'll kick all 3 MC optics tonight and let them ringdown overnight, may not be a bad idea to checkup on the health of the MC suspensions/satellite boxes... [MC suspensions were kicked @1207113574]. PSL shutter will remain closed overnight...

Quote:

Why is MC2 LR so different from the others???

 

Attachment 1: MC2_Freeswinging.pdf
MC2_Freeswinging.pdf
  13738   Fri Apr 6 22:23:53 2018 KevinUpdateIOOCoil driver noise

 

Quote:

Why is MC2 LR so different from the others???

The previous measurements were made from the coil driver output monitors. To investigate why the MC2 LR coil has less noise than the other coils, I also measured the noise at the output to the coils.

The circuit diagram for the coil driver board is given in D010001 and a picture of the rack is on the 40m wiki here. The coil driver boards are in the upper left quadrant of the rack. The input to the board is the column of LEMOs which are the "Coil Test In" inputs on the schematic. The output monitors are the row of LEMOs to the right of the input LEMOs and are the "FP Coil Volt Mon" outputs on the schematic. The output to the coils "Coil Out" in the schematic are carried through a DB15 connector.

The attachment shows the voltage noise for the MC2 LR coil as well as the UL coil which is similar to all of the other coils measured in the previous measurement. While the LR coil is less noisy than the UL coil as measured at the output monitor, they have the same noise spectrum as measured at the output to the coils themselves. So there must be something wrong with the buffer circuit for the MC2 LR voltage monitor, but the output to the coils themselves is the same as for the other coils.

Attachment 1: MC2_coil_driver.pdf
MC2_coil_driver.pdf
  13741   Mon Apr 9 18:46:03 2018 gautamUpdateIOOFurther debugging
  1. I analyzed the data from the free swinging MC test conducted over the weekend. Attachment #1 shows the spectra. Color scheme is same for all panels.
    • I am suspicious of MC3: why does the LR coil see almost no Yaw motion?
    • The "equilibrium" values of all the sensor signals (at the IN1 of the coil input filters) are within 20% of each other (for MC3, but also MC1 and MC2).
    • The position resonance is also sensed more by the side coil than by the LR coil.
    • To rule out satellite box shenanigans, I just switched the SRM and MC3 satellite boxes. But coherence between frequency noise as sensed by the arms remain.
  2. I decided to clean up my IMC nosie budget a bit more.
    • Attachment #2 shows the NB as of today. I'll choose a better color palette for the next update.
    • "Seismic" trace is estimated using the 40m gwinc file - the MC2 stack is probably different from the others and so it's contribution is probably more, but I think this will suffice for a first estimate.
    • "RAM" trace is measured at the CM board input, with MC2 misaligned.
    • The unaccounted noise is evident from above ~8 Hz.
    • More noises will be added as they are measured.
    • I am going to spend some time working on modeling the CM board noise and TF in LTspice. I tried getting a measurement of the transfer function fron IN1 to the FAST output of the CM board with the SR785 (motivation being to add the contribution of the input referred CM board noise to the NB plot), but I suspect I screwed up something w.r.t. the excitation amplitude, as I am getting a totally nonsensical shape, which also seems to depend on my input excitation amplitude. I don't think the output is saturated (viewed during measurement on a scope), but perhaps there are some subtle effects going on.
Attachment 1: MC_Freeswinging.pdf
MC_Freeswinging.pdf
Attachment 2: IMC_NB_20180409.pdf
IMC_NB_20180409.pdf
  13744   Tue Apr 10 14:28:44 2018 gautamUpdateIOOFurther debugging

I am working on IMC electronics. IMC is misaligned until further notice.

  13746   Wed Apr 11 01:34:31 2018 gautamUpdateIOOActivities today

[kevin, gautam]

activities done today - details/plots/data/evidence tomorrow.

  1. Checked XARM loop shape. Updated NB code to fetch POX data from NDS and undo loop shape rather than using calibration filter bank.
  2. Checked POX loop calibration (m/ct). Number I was using was 8e-13. Tonight we measured 9e-13. Updated filter bank.
  3. Tried to get Y arm green ALS going.
    • Improved GTRY from ~0.05 to 0.3.
    • Tried to improve mode matching onto BBPD on PSL table to see a green beat.
    • But we were unsuccessful.
    • I think I got the near and far field alignment right, and the EY laser temp is set such that I can see an IR beat @~30MHz (so green beat should be at 60 MHz).
    • But I couldn't see anything with scope or with HP spec analyzer.
    • More tomorrow. Motivation to get green ALS working is to get some more confidence that the excess noise is indeed on the PSL light.
  13762   Wed Apr 18 19:02:15 2018 gautamUpdateIOOMC spot centering scripts

I'm working on fixing these (and the associated MEDM scripts) up so that we can get some reliable readback on how well centered the spots are on the MC mirrors. Seems like a bunch of MEDM display paths were broken, and it looks like the optimal demod phases (to put most of the output in I quadrature) are not what the current iteration of the scripts set them to be. It may well be that the gains that convert demodulated counts to mm of spot offset are also not correct anymore. I ran the script ~4times in ~1 hour time span, and got wildly different answers for the spot centering each time, so I wouldn't trust any of those numbers atm...

As you can see in Attachment #1, I stepped the demod phase of one of the servos from -180 to 180 degrees in 5degree increments. The previously used value of 57degrees is actually close to the worst possible point (if you want the signal in the I quadrature, which is what the scripts assume).

I used Attachment #2 to change up the demod phases to maximize the I signal. I chose the demod phase such that it preserved the sign of the demodulated signal (relative to the old demod phases). I also made some StripTool templates for these, and they are in the MC directory. Doing the spot centering measurement with the updated demod phases yields the following output from the script:

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
[0.72506586251144134, 7.1956908534034403, 0.54754354165324848, -0.94113388241389784, -3.5325883025464959, -2.4934027726657142]

Seems totally unbelievable still that we are so far off center on MC1 yaw. Perhaps the gains and calibration to convert from counts to mm of spot offset need to be rechecked.

Attachment 1: MCass_demodPhase.png
MCass_demodPhase.png
Attachment 2: MCass_demodPhases.png
MCass_demodPhases.png
  13765   Thu Apr 19 00:03:51 2018 gautamUpdateIOOMore IMC NBing

Summary:

As shown in the Attachments, it seems like IMC DAC and coil driver noise is the dominant noise source above 30Hz. If we assume the region around the bounce peak is real motion of the stack (to be confirmed with accelerometer data soon), this NB is starting to add up. Much checking to be done, and I'd also like to get a cleaner measurement of coil driver and DAC noise for all 3 optics, as there seems to be a factor of ~5 disagreement between the MC3 coil driver noise measurement and my previous foray into this subject. The measurement needs to be refined a little, but I think the conclusion holds.

Details:

  1. I had a measurement of the MC3 coil driver noise from ~2weeks ago when I was last working on this that I had not yet added to the NB.
  2. Today I added it. To convert from measured voltage noise to frequency noise, I assumed the usual 0.016N/A per coil number, which is probably a large source of systematic error.
  3. I define the "nominal" IMC operating condition as MC1 and MC3 having the analog de-whitening filters switched on, but MC2 switched off.
  4. So length noise should be dominated by coil driver noise on MC1 and MC3, and DAC noise on MC2.
  5. The measurement I had was made with the input to the coil driver board terminated in 50ohms. Measurement was made in-situ. The measurement has a whole bunch of 60Hz harmonics (despite the Prologix box being powered by a linear power adapter, but perhaps there are other ground loops which are coupling into the measurement). So I'd like to get a cleaner measurement tmrw.
  6. To confirm, Koji suggested some On/Off test by driving some broadband noise in the coils. I figured toggling the analog de-whitening, such that the DAC noise or coil driver electronics dominate is an equally good test.
  7. Attachment #2 shows the effect in arm error and control signal spectra. Note that I engaged analog de-whitening on all 3 optics for the red curves in this plot. But even leaving MC2 de-whitening off, I could see the read curve was below the black reference trace, which was taken with de-whitening off on all 3 optics.

Remarks:

Since I sunk some time into it already, the motivation behind this work is just to try and make the IMC noise budget add up. It is not directly related to lowering the IR ALS noise, but if it is true that we are dominated by coil driver noise, we may want to consider modifying the MC coil driver electronics along with the ITM and ETMs.

Attachment 1: IMC_NB_20180409.pdf
IMC_NB_20180409.pdf
Attachment 2: IMC_coils_20180418.pdf
IMC_coils_20180418.pdf
  13770   Thu Apr 19 17:15:35 2018 gautamUpdateIOOMore IMC NBing

Summary:

Today, I repeated the coil driver noise measurement. Now, the coil driver noise curve in the noise budget plot (Attachment #1) is the actual measurement of all 12 coils (made with G=100 SR560). I am also attaching the raw voltage noise measurement (input terminated in 50ohms, Attachment #2). Note that POX11 spectrum has now been re-measured with analog de-whitening engaged on all 3 optics such that the DAC noise contribution should be negligible compared to coil driver noise in this configuration. The rows in Attachment #2 correspond to 800 Hz span (top) and full span (bottom) on the FFT analyzer.

Details:

The main difference between this measurement, and the one I did middle of last year (which agreed with the expectation from LISO modeling quite well) is that this measurement was done in-situ inside the eurocrate box while last year, I did everything on the electronics benches. So I claim that the whole mess of harmonics seen in the raw measurements are because of some electronics pickup near 1X6. But even disregarding the peaky features, the floor of ~30nV/rtHz is ~6x than what one would expect from LISO modeling (~5nV/rtHz). I confirmed by looking that the series resistance for all 3 MC optics is 430ohms. I also did the measurement with the nominal bias voltages applied to the four channels (these come in via the slow ADCs). But these paths are low-passed by an 8th order low pass with corner @ 1Hz, so at 100 Hz, even 1uV/rtHz should be totally insignificant. I suppose I could measure (with EPICS sine waves) this low-pass filtering, but it's hard to imagine this being the problem. At the very least, I think we should get rid of the x3 gain on the MC2 coil driver de-whitening board (and also on MC1 and MC3 if they also have the x3 factor).

Attachment 1: IMC_NB_20180419.pdf
IMC_NB_20180419.pdf
Attachment 2: IMC_coilDriverNoises_20180419.pdf
IMC_coilDriverNoises_20180419.pdf
  13870   Sun May 20 23:43:50 2018 gautamUpdateIOOCoil driver noise re-measurement

Summary:

In the IMC actuation chain, it looks like the MC1/MC3 de-whitening boards, and also all three MC optics' coil driver boards, are showing higher noise than expected from LISO modeling. One possible candidate is thick film resistors on the coil driver boards. The plan is to debug these further by pulling the board out of the Eurocrate and investigating on the electronics bench.

Why bother? Mainly because I want to see how good the IR ALS noise is, and currently, the PSL frequency noise is causing the measurement to be worse than references taken from previous known good times.

Details:

Sometime ago, rana suggested to me that I should do this measurement more systematically.

  • Attachments #1, #2 and #3 show noise measurements in various conditions for MC1, MC2 and MC3 respectively.
  • In the above three attachments, I stitched together multiple spans from the SR785, and so the bin-width is different. The data is downloaded from the analyzer normalized by the bin-width (PSD units).
  • The roll-off at ~800Hz in the orange trace for MC1 and MC3 is consistent with an 800 Hz LPF that was used for anti-image filtering from the old 2 kHz era.
  • While it may look like the analog de-whitening isn't being switched on in some of these plots, I confirmed by transfer function measurement that it is indeed switching.
  • Data used to make these plots are in Attachment #4. Unfortunately, the code requires some of my personal plotting librariesno and so I'm not uploading it.
  • Sketch of measurement setup is shown in Attachment #5. It is not indicated in the schematic, but the SR560 was operated in battery mode for this measurement.
  • For MC1, I did the additional measurement of terminating the LEMO input to the coil driver and measuring (what should have been) just the coil driver electronics noise. But this measurement doesn't look very clean, and hence, the decision to pull the board out to continue debugging.
  • While at 1X6, Rana tightened the LEMO connectors going to MC1. We should opportunistically do MC2 and MC3 as well.
  • Some changes to be made:
    • Thick film ---> thin film.
    • Reroute HPF-ed back-plane Vmon output to the front panel LEMO.

I've now restored all the wiring at 1X6 to their state before this work.

Attachment 1: MC1_coilDriver.pdf
MC1_coilDriver.pdf
Attachment 2: MC2_coilDriver.pdf
MC2_coilDriver.pdf
Attachment 3: MC3_coilDriver.pdf
MC3_coilDriver.pdf
Attachment 4: MC_coilDriverNoises.tgz
Attachment 5: ActuationChainNoiseMeas.pdf
ActuationChainNoiseMeas.pdf
  13878   Tue May 22 17:26:25 2018 gautamUpdateIOOMC1 Coil Driver pulled out

I have pulled out MC1 coil driver board from its Eurocrate, so IMC is unavailable until further notice. Plans:

  1. Thick film --> Thin Film
  2. AD797 --> Op27
  3. Remove Pots in analog actuation path.
  4. Measure noise
  5. Route HPF signal (UL DAQ Mon) to front panel. I think we should use the SMA connectors. That way, we have DC and AC voltage monitors available for debugging.

If there are no objections, I will execute Step #5 in the next couple of hours. I'm going to start with Steps 1-4.

  13880   Tue May 22 23:28:01 2018 gautamUpdateIOOMC1 Coil Driver pulled out

This work is now complete. MC1 coil driver board has been reinstalled, local damping of MC1 restored, and IMC has been locked. Detailed report + photos to follow, but measurement of the noise (for one channel) on the electronics workbench shows a broadband noise level of 5nV/rtHz (yes) around 100Hz, which is lower than what was measured here and consistent with what we expect from LISO modeling (with fast input terminated with 50ohm, slow input grounded).

Quote:

I have pulled out MC1 coil driver board from its Eurocrate, so IMC is unavailable until further notice.

 

  13883   Wed May 23 17:58:48 2018 gautamUpdateIOOMC1 Coil Driver pulled out
  • Marked up schematic + photo post changes uploaded to DCC page.
  • There was a capacitor in the DAQ monitor path making a 8kHz corner that I now removed (since the main point of this front panel HPF monitor point is to facilitate easy coil driver noise debugging, and I wanted to be able to use the SR785 out to high frequencies without accounting for an additional low pass). Transfer function from front panel LEMO input to front panel LEMO monitor is shown in Attachment #1.
  • Voltage noise measured at DB25 output (with the help of a breakout cable and SR560 G=100) with front panel LEMO input terminated to 50ohm, Bias input grounded, and pin1 of U21A grounded (i.e. watchdog enabled state) is shown in Attachment #2. This measurement was taken on the electronics bench.
  • Inside the lab (i.e. coil driver board plugged into eurocrate), the noise measured in the same way looks identical to what was measured in elog13870.
  • I tried repeating the measurement by powering the board using an bench power supply and grounding the bias input voltage near 1X6, and the strange noise profile persists. So this supports the hypothesis that some kind of environmental pickup is causing this noise profile. Needs more investigation. 

In any case, if it is indeed true that the optic sees this current noise, the place to make the measurement is probably the Sat. Box. Who knows what the pickup is over the ~15m of cable from 1X6 to the optic.

Quote:

Detailed report + photos to follow

 

Attachment 1: MC1_monitorTF.png
MC1_monitorTF.png
Attachment 2: MC1_ULnoise.pdf
MC1_ULnoise.pdf
  13896   Wed May 30 10:17:46 2018 gautamUpdateIOOMC1 Coil Driver pulled out

[rana,gautam]

Summary:

Last night, Rana fact-checked my story about the coil driver noise measurement. Conclusions:

  1. There is definitely pickup of strong lines (see Attachment #1. These are hypothesized to come from switching power supplies). Moreover, they breathe. Checkout Rana's twitter page for the video.
  2. The lines are almost (but not quite) at integer multiples of 19.5 kHz. The cause of this anharmonicity is to be puzzled out.
  3. When the coil driver board is located ~1m away from the SR785 and the bench supply powering it, even though the lines are visible in the spectrum, the low frequency shape does not show the weird broad features I reported here. The measured noise floor level is ~5nV/rtHz, which is consistent with LISO noise + SR560 input noise (see Attachment #2). However, there is still some excess noise at 100 Hz above what the LISO model leads us to expect. 
  4. The location of the coil driver board and SR560 relative to the SR785 and the bench power supply I used to power the coil driver board can increase the line heights by ~x50. 
  5. The above changes the shape of the low frequency part of the spectrum as well, and it looks more like what is reported in elog13870. The hypothesis is that the high frequency lines are downconverted in the SR560.

Note: All measurements were made with the fast input of the coil driver board terminated with 50ohms and bias input shorted to ground with a crocodile clip cable.

Next steps:

The first goal is to figure out where this pickup is happening, and if it is actually going to the optic. To this end, I will put a passive 100 kHz filter between the coil driver output and the preamp (Busby Box instead of SR560). By getting a clean measurement of the noise floor with the coil driver board in the Eurocrate (with the bias input driven), we can confirm that the optic isn't being buffeted by the excess coil driver noise. If we confirm that the excess noise is not a measurement artefact, we need to think about were the pickup is actually happening and come up with mitigation strategies.

RXA: good section EMI/RFI in Op Amp Applications handbook (2006) by Walt Jung. Also this page: http://www.electronicdesign.com/analog/what-was-noise

Attachment 1: EM_pickup.pdf
EM_pickup.pdf
Attachment 2: coilDriverNoiseComparison.pdf
coilDriverNoiseComparison.pdf
  13936   Sun Jun 10 03:46:38 2018 KojiUpdateIOOWFS HEAD SW confusion

I was checking on the slow machine channels and found something I could not understand.

On the IOO WFS HEAD screen, there are two sets of 4 switches (magenta rectangles in Attachment 1) labeled 2/4/8/16dB.
But as far as I could confirm with the WFS demod (D980233) and WFS head (D980012) drawings, they are the gain (attenuation) switches for the individual segments.
Their epics variable names are "C1:IOO-WFS1_SEG1_ATTEN", "C1:IOO-WFS1_SEG2_ATTEN", etc...

I confirmed the switches are alive (effective), and they are not all ON or OFF. I wonder what is the real situation there...

Attachment 1: C1IOO_WFS_HEADS.png
C1IOO_WFS_HEADS.png
  13946   Mon Jun 11 22:46:24 2018 KojiUpdateIOOWFS HEAD SW confusion

The unfortunate discovery today was that the attenuator switches on the IMC WFS heads are actually assigned to individual segments, and they are active. That means that we have been running the WFS with an uneven gain setting. The attached PDFs show that the signals with the attenuators on and off all at the same time, while the WFS servo output was frozen. A more annoying feature is that when some of the attenuators are on, this does not lower the gain completely. I mean that the attenuated channels show some reduction of the gain, but that is not the level of reduction we see when all attenuators are turned on. This RF could come from some internal RF coupling or some similar effect.

Moreover, the demodulation phases are quite off for most of the segments.

So far, the WFS is running with this uneven attenuation. We take time to characterize the gain and retune the demod phases and input matrices.

Attachment 1: 180611_IMC_WFS1.pdf
180611_IMC_WFS1.pdf
Attachment 2: 180611_IMC_WFS2.pdf
180611_IMC_WFS2.pdf
  13960   Thu Jun 14 00:46:09 2018 ranaUpdateIOOWFS HEAD SW confusion

its painful, but you and I should probably take these out, bypass the switches and use them with fixed gain; the 'Reed Relay' attenuators are not a good part for this app.

The historical problem is that they tend to self oscillate with full gain because they had 2 MAX4106 in series which couple to each other in the bad way --- need to remove one of them and set the gain of the other one to 10.

Quote:

The unfortunate discovery today was that the attenuator switches on the IMC WFS heads are actually assigned to individual segments, and they are active. That means that we have been running the WFS with an uneven gain setting.

 

  14092   Fri Jul 20 22:51:28 2018 KojiUpdateIOOIMC WFS path alignment

IMC WFS tuning

- IMC was aligned manually to have maximum output and also spot at the center of the end QPD.
- The IMC WFS spots were aligned to be the center of the WFS QPDs.
- With the good alignment, WFS RF offset and MC2 QPD offsets were tuned via the scripts.

  14198   Mon Sep 17 12:28:19 2018 gautamUpdateIOOPMC and IMC relocked, WFS inputs turned off

The PMC and IMC were unlocked. Both were re-locked, and alignment of both cavities were adjusted so as to maximize MC2 trans (by hand, input alignment to PMC tweaked on PSL table, IMC alignment tweaked using slow bias voltages). I disabled the inputs to the WFS loops, as it looks like they are not able to deal with the glitching IMC suspensions. c1lsc models have crashed again but I am not worrying about that for now.

9pm: The alignment is wandering all over the place so I'm just closing the PSL shutter for now.

  14200   Tue Sep 18 17:56:01 2018 not gautamUpdateIOOPMC and IMC relocked, WFS inputs turned off

I restarted the LSC models in the usual way via the c1lsc reboot script. After doing this I was able to lock the YARM configuration for more noise coupling scripting.

Quote:

The PMC and IMC were unlocked. Both were re-locked, and alignment of both cavities were adjusted so as to maximize MC2 trans (by hand, input alignment to PMC tweaked on PSL table, IMC alignment tweaked using slow bias voltages). I disabled the inputs to the WFS loops, as it looks like they are not able to deal with the glitching IMC suspensions. c1lsc models have crashed again but I am not worrying about that for now.

9pm: The alignment is wandering all over the place so I'm just closing the PSL shutter for now.

 

  14275   Tue Nov 6 15:23:48 2018 gautamUpdateIOOIMC problematic

The IMC has been misbehaving for the last 5 hours. Why? I turned the WFS servos off. afaik, aaron was the last person to work on the IFO, so i'm not taking any further debugging steps so as to not disturb his setup.

Attachment 1: MCwonky.png
MCwonky.png
  14277   Tue Nov 6 19:02:35 2018 aaronUpdateIOOIMC problematic

That was likely me. I had recentered the beam on the PD I'm using for the armloss measurements, and I probably moved the wrong steering mirror. The transmission from MC2 is sent to a steering mirror that directs it to the MC2 transmission QPD; the transmission from this steering mirror I direct to the armloss MC QPD (the second is what I was trying to adjust).

Note: The MC2 trans QPD goes out to a cable that is labelled MC2 op lev. This confusion should be fixed.

I realigned the MC and recentered the beam on the QPD. Indeed the beam on MC2 QPD was up and left, and the lock was lost pretty quickly, possibly because the beam wasn't centered. Lock was unstable for a while, and I rebooted C1PSL once during this process because the slow machine was unresponsive.

When tweaking the alignment near MC2, take care not to bump the table, as this also chang es the MC2 alignment.

Once the MC was stably locked, I was able to maximize MC transmission at ~15,400 counts. I then centered the spot on the MC2 trans QPD, and transmission dropped to ~14800 counts. After tweaking the alignment again, it was recovered to ~15,000 counts. Gautam then engaged the WFS servo and the beam was centered on MC2 trans QPD, transmission level dropped to ~14,900.

Attachment 1: 181106_MCTRANS.jpg
181106_MCTRANS.jpg
  14286   Fri Nov 9 15:00:56 2018 gautamUpdateIOONo IFO beam as TT1 UL hijacked for REFL55 check

This problem resurfaced. I'm doing the debugging.

6:30pm - "Solved" using the same procedure of stepping through the whitening gains with a small (10 DAC cts pk) signal applied. Simply stepping through the gains with input grounded doesn't seem to do the trick.

Attachment 1: REFL55_wht_chk.png
REFL55_wht_chk.png
  14289   Sat Nov 10 17:40:00 2018 aaronUpdateIOOIMC problematic

Gautam was doing some DRMI locking, so I replaced the photodiode at the AS port to begin loss measurements again.

I increased the resolution on the scope by selecting Average (512) mode. I was a bit confused by this, since Yuki was correct that I had only 4 digits recorded over ethernet, which made me think this was an i/o setting. However the sample acquisition setting was the only thing I could find on the tektronix scope or in its manual about improving vertical resolution. This didn't change the saved file, but I found the more extensive programming manual for the scope, which confirms that using average mode does increase the resolution... from 9 to 14 bits! I'm not even getting that many.

There's another setting for DATa:WIDth, that is the number of bytes per data point transferred from the scope.

I tried using the *.25 scope instead, no better results. Changing the vertical resolution directly doesn't change this either. I've also tried changing most of the ethernet settings. I don't think it's something on the scripts side, because I'm using the same scripts that apparently generated the most recent of Johannes' and Yuki's files; I did look through for eg tds3014b.py, and didn't see the resolution explicitly set. Indeed, I get 7 bits of resolution as that function specifies, but most of them aren't filled by the scope. This makes me think the problem is on the scope settings.

  14290   Mon Nov 12 13:53:20 2018 ranaUpdateIOOloss measurement: oscope vs CDS DAQ

sstop using the ssscope, and just put the ssssignal into the DAQ with sssssome whitening. You'll get 16 bitsśšß.

Quote:

I increased the resolution on the scope by selecting Average (512) mode. I was a bit confused by this, since Yuki was correct that I had only 4 digits recorded over ethernet, which made me think this was an i/o setting. However the sample acquisition setting was the only thing I could find on the tektronix scope or in its manual about improving vertical resolution. This didn't change the saved file, but I found the more extensive programming manual for the scope, which confirms that using average mode does increase the resolution... from 9 to 14 bits! I'm not even getting that many.

 

  14297   Thu Nov 15 10:21:07 2018 aaronUpdateIOOIMC problematic

I ran a BNC from the PD on the AS table along the cable rack to a free ADC channel on the LSC whitening board. I lay the BNC on top of the other cables in the rack, so as not to disturb anything. I also was careful not to touch the other cables on the LSC whitening board when I plugged in my BNC. The PD now reads out to... a mystery channel. The mystery channel goes then to c1lsc ADC0 channels 9-16 (since the BNC goes to input 8, it should be #16). To find the channel, I opened the c1lsc model and found that adc0 channel 15 (0-indexed in the model) goes to a terminator.

Rather than mess with the LSC model, Gautam freed up C1:ALS-BEATY_FINE_I, and I'm reading out the AS signal there.

I misaligned the x-arm then re-installed the AS PO PD, using the scope to center the beam then connecting it to the BNC to (first the mystery channel, then BEATY). I turned off all the lights.

I went to misalign the x-arms, but the some of the control channels are white boxed. The only working screen is on pianosa.

The noise on the AS signal is much larger than that on the MC trans signal, and the DC difference for misaligned vs locked states is much less than the RMS (spectrum attached); the coherence between MC trans and AS is low. However, after estimating that for ~30ppm the locked vs misaligned states should only be ~0.3-0.4% different, and double checking that we are well above ADC and dark noise (blocked the beam, took another spectrum) and not saturating the PD, these observations started to make more sense.

To make the measurement in cds, I also made the following changes to a copy opf Johannes' assess_armloss_refl.py that I placed in /opt/rtcds/caltech/c1/scripts/lossmap_scripts/armloss_cds/   :

  • function now takes as argument the number of averages, averaging time, channel of the AS PD, and YARM|XARM|DARK.
  • made the data save to my directory, in /users/aaron/40m/data/armloss/

I started taking a measurement, but quickly realized that the mode cleaner has been locked to a higher order mode for about an hour, so I spend some time moving the MC. It would repeatedly lock on the 00 mode, but the alignment must be bad because the transmission fluctuates between 300 and 1400, and the lock only lasts about 5 minutes.

Attachment 1: 181115_chansDown.png
181115_chansDown.png
Attachment 2: PD_noise.png
PD_noise.png
  14300   Fri Nov 16 10:53:07 2018 aaronUpdateIOOIMC problematic

Back to loss measurements.

I replaced the PD I've been using for the AS beam.

I misaligned the x arm.

I tried to lock the y arm, but PRC was locked so I could was unable. Gautam reminded me where the config scripts are.

The armloss measurement script needed two additional modifications:

  • It was setting the initial offset of the PIT and YAW demod signals to 0, but due to the clipping on the heater we are operating at an offset. I commented out these lines.
  • When the script ran UNFREEZE_DITHER, it was running it using medmrun. The scope script hadn't been using this, and it seemed that when it ran UNFREEZE_DITHER in this way the YARM_ASS servo was passing only '0'. I don't really know why this was, but when I removed the call to medmrun it worked.

I ran successfully the loss measurement script for the x and y arms. I'm getting losses of ~100ppm from the first estimates.

I made the following changes to the lossmap script:

  • make the averaging time an input to the script, so we can exceed 2 second averages
  • remove anything about getting data from the scope, replace it with the correct analogues to save the averages for POX/POY refl, MC trans, op lev P/Y, and ASDC signal.
  • record the GPS time in the file with the cds averages (this way I can grab the full data)
  • Added a step in the lossmap script to misalign the optic, so we can continue getting data for the 'misaligned' state, both for the centered and not-centered measurements (that is, for every position on the lossmap).

When the optic aligns itself not at the ideal position, I'm noticing that it often locks on a 01. When the cavity is then misaligned and restored, it can no longer obtain lock. To fix this, I've moved my 'save' commands to just before the loop begins. This means the script may take longer to run, but as long as the cavity is initially locked and well aligned, this should make it more robust against wandering off and never reacquiring lock.

I left the lossmap script running for the x-arm. Next would be to run it for the y arm, but I see that after stepping to a few positions the lock is again lost. It's still trying to run, but if you want to stop it no data already taken will be lost. To stop it, go to the remaining terminal open on rossa and ctrl+c

the analysis needs:

  • Windowing
  • Filter, don't average
  • detrend to get rid of the linear drifts in lock that we see.
    • Is this the right thing?
Attachment 1: Screenshot_from_2018-11-16_19-22-34.png
Screenshot_from_2018-11-16_19-22-34.png
  14302   Sat Nov 17 18:59:01 2018 aaronUpdateIOOIMC problematic

I made additional measurements on the x and y arms, at 5 offset positions for each arm (along with 6 measurements at the "zeroed" position).

  14329   Sun Dec 2 19:32:35 2018 ranaUpdateIOOfit times

need to vary start/stop times in fit to test for systematics

  14335   Fri Dec 7 17:04:18 2018 gautamUpdateIOOIMC transmission
  • Power just before PSL shutter on PSL table = 97 +/- 1 mW. Systematic error unknown.
  • Power from IFO REFL on AP table = 40 +/- 1 mW. Systematic error unknown.

Both were measured using the FieldMate power meter. I was hesitant to use the Ophir power meter as there is a label on it that warns against exceeding 100 mW. I can't find anything in the elog/wiki about the measured inesrtion loss / isolation of the input faraday, but this seems like a pretty low amount of light to get back from PRM. The IMC visibility using the MC_REFL DC values is ~87%. Assuming perfect transmission of the 87% of the 97mW that's coupled into the IMC, and assuming a further 5% loss between the Faraday rejected port and the AP table, the Faraday insertion loss would be ~30%. Realistically, the IMC transmission is lower. There is also some part of the light picked off for IPPOS. Judging by the shape of the REFL spot on the camera, it doesn't look clipped to me.

Either way, seems like we are only getting ~half of the 1W we send in on the back of PRM. So maybe it's worth it to investigate the situation in the IOO chamber during this vent.


c1pslc1susaux,c1iool0,caux  crates were keyed. Also, the physical shutter on the PSL NPRO, which was closed last Monday for the Sundance crew filming, was opened and the PMC was locked. PMC remains locked, but there is no light going into the IMC.

  14352   Thu Dec 13 18:12:47 2018 gautamUpdateIOOND filter on AS camera changed

In order to see the AS beam a bit more clearly in our low-power config, I swapped out the ND=1.0 filter on the AS camera for ND=0.5.

  14362   Sat Dec 15 20:04:03 2018 gautamUpdateIOOTT1/TT2 stepping

I'm running a script that moves TT1 and TT2 randomly in some restricted P/Y space to try and find an alignment that gets some light onto the TRY PD. Test started at gpstime 1228967990, should be done in a few hours. The IMC has to remain locked for the duration of this test. I will close the PSL shutter once the test is done. Not sure if the light level transmitted through the ITM, which I estimate to be ~30uW, will be enough to show up on the TRY PD, but worth a shot I figure.

Test was completed and PSL shutter was closed at 1228977122.

  14368   Wed Dec 19 15:15:56 2018 gautamUpdateIOOTT1/TT2 stepping

I removed the ND filter from the ETMYT camera to facilitate searching for a TRY beam. This should be replaced before we go back to high power.

  14467   Wed Feb 20 18:26:05 2019 gautamUpdateIOOIPPOS recommissioned

I've suspected that the TTs are drifting significantly over the course of the last couple of days, because despite repeated alignment efforts, the AS beam spot has drifted off the center of the camera view. I tried looking at IPPOS, but found that there was no data. Looking at the table, the QPD was turned backwards, and the DAQ cable wasn't connected (neither at the PD end, nor at 1Y2, where instead, a cable labelled "Spare QPD" was plugged in). Fortunately, the beam was making it out of the vacuum. So as to have a quantitative diagnostic, I reconnected the QPD, turned it the right way round, and adjusted the steering onto it such that with the AS spot on the center of the CCD monitor, the beam is also centered on the QPD. The calibration is uncertain, but at least we will be able to see how much the spot drifts on the QPD over some days. Also, we only have 16 Hz readback of this stuff.

I leave it to Chub to take the high-res photo and update the wiki, which was last done in 2012.


Already, in the last ~1 hour, there has been considerable drift - see Attachment #2. The spot, which started at the center of the CCD monitor, has now nearly drifted off the top end. The ITMX and BS Oplev spots have been pretty constant over the same timescale, so it has to be the TTs?

Attachment 1: IMG_7330.JPG
IMG_7330.JPG
Attachment 2: Screenshot_from_2019-02-20_19-43-27.png
Screenshot_from_2019-02-20_19-43-27.png
  14469   Fri Feb 22 12:19:46 2019 gautamUpdateIOOTT coil driver Vmon

To debug the issue of the suspected drifting TTs further, I temporarily hijacked CH0-CH8 of ADC1 in the c1lsc expansion chassis, and connected the "MON" outputs of the coil drivers (D010001) to them via some DB9 breakouts. The idea is to see if the problem is electrical. We should see some  slow drift in the voltage to the TTs correlated with the spot walking off the IPPOS QPD. From the wiring diagram, it doesn't look like there is any monitoring (slow or fast) of the control voltages to the TT coils, this should be factored into the Acromag upgrade of c1iscaux/c1iscaux2. EPICS monitoring should be sufficient for this purpose so I didn't setup any new DQ channels, I'll just look at the EPICS from the IOP model.

Quote:
Already, in the last ~1 hour, there has been considerable drift - see Attachment #2. The spot, which started at the center of the CCD monitor, has now nearly drifted off the top end. The ITMX and BS Oplev spots have been pretty constant over the same timescale, so it has to be the TTs?
  14473   Sun Mar 3 14:16:31 2019 gautamUpdateIOOMegatron hard-rebooted

IMC was not locked for the past several hours. Turned out MC autolocker was stuck, and I could not ssh into megatron because it was in some unresponsive state. I had to hard-reboot megatron, and once it came back up, I restarted the MCautolocker, FSS slow servo and nds2 processes. IMC re-locked immediately.

I was pulling long stretches of OSEM data from the NDS2 server (megatron) last night, I wonder if this flakiness is connected. Megatron is still running Ubuntu12.

  14530   Wed Apr 10 16:58:54 2019 ranaUpdateIOOfiber MZ for NPRO freq noise measurements

Can we get some panel mount FC/APC connectors and put them on a box?   Then we could have the whole setup inside of a box that is filled with foam and sits outside the PSL hut. cheeky

  14531   Wed Apr 10 22:59:22 2019 gautamUpdateIOOSpooled fiber

Steve had showed me some stock of long fibers a while back - they are from Oz Optics, and are 50m long, and are already spooled - so barring objections, we will try the MZ setup with the spooled fiber and see if there is any improvement in the fringing rate of the MZ. Then we can evaluate what additional stabilization of the fiber length is required. Anjali will upload a photo of the spooled fiber.

  14534   Thu Apr 11 09:05:06 2019 AnjaliUpdateIOOSpooled fiber
  • Attchment #1,2,3 and 4 shows the results with frequency modulation of 32 Hz, 140 Hz , 300 Hz and without frequency modulation. I am trying to understand these results better.
  • A lot of fringing is there even when no modulation is applied. We hope to improve this by spooling the fiber and then encasing it in a box. 
  • As mentioned by Gautam, we have got a 50 m spooled fiber. Attachment #5 shows the photo of the same
Quote:

Steve had showed me some stock of long fibers a while back - they are from Oz Optics, and are 50m long, and are already spooled - so barring objections, we will try the MZ setup with the spooled fiber and see if there is any improvement in the fringing rate of the MZ. Then we can evaluate what additional stabilization of the fiber length is required. Anjali will upload a photo of the spooled fiber.

Attachment 1: Frequecy_modulation_32_Hz.pdf
Frequecy_modulation_32_Hz.pdf
Attachment 2: Frequecy_modulation_140_Hz.pdf
Frequecy_modulation_140_Hz.pdf
Attachment 3: Frequecy_modulation_300_Hz.pdf
Frequecy_modulation_300_Hz.pdf
Attachment 4: Without_modulation.pdf
Without_modulation.pdf
Attachment 5: New_fiber_spool.JPG
New_fiber_spool.JPG
  14637   Fri May 24 17:50:19 2019 gautamUpdateIOOIFO recovery

At ~4pm, the main volume pressure (CC1) was reported to be ~5e-5 torr. So I replaced the HR mirror in the MC REFL path with the usual 10% beamsplitter, and aligned the beam onto MCREFL photodiode. I also replaced the ND filter on the AS port camera, and in front of the IPPOS QPD.

Then I turned up the power by HWP rotation - at the input to the IMC, I now measured 960 mW with the Coherent power meter, so the NPRO power has certainly decayed by ~10% from 2018 July. Normal high-power IMC autolocker script was re-enabled on megatron (and the slow servo enable threshold raised from 1000 cts to 8000cts). IMC was readily locked, after some hand alignment, I got a maximum of 14500 cts transmission. I was then able to lock the Y-arm. The dither alignment servo did not work with the nominal settings, but by hand alignment, I was able to get TRY up to 0.6 (I didn't try too hard to optimize this in any systematic way). X arm was also locked.

AUX drypump valved off and shutdown at ~610pm. I also switched both TP2 and TP3 to their lower rotation "standby" mode. So overall no major mishaps this time around. I am leaving the PSL shutter open over the long weekend. For in-air vs vacuum suspension spectra comparison, I kicked the ETMY optic at Fri May 24 18:26:10 PDT 2019.

  14647   Mon Jun 3 16:46:31 2019 gautamUpdateIOOIMC not locking

Since ~ 2 hours ago, the IMC autolocker has not been able to keep the IMC locked. I don't see any obvious trends in the wall StripTool that may point to what's going on. For the brief periods in which a TEM00 mode is locked, the PC Drive RMS level is ~5x what the nominal level is, and while the autolocker is trying to lock the IMC, the PC drive RMS level is hovering around 4V DC, which is high. The PMC Error and Control signal spectra show huge 60 Hz (and harmonics) peaks, and indeed this is visible in the time domain signals as well (on ndscope or on the oscilloscope on the PSL table), but this is not a new feature in the last two hours. Usually, this kind of problem signals that either/both the c1psl or c1iool0 slow machines need to be power-cycled, but I confirmed that both machines are online and telnet-able. Possibilities: (i) some card in the c1psl / c1ioo crates have failed or (ii) something in the MC/FSS electronics chain has failed or (iii) there is a huge amount of excess high-frequency noise from the NPRO.

I am leaving the PSL shutter closed.

Attachment 1: PCdrive_RMS.png
PCdrive_RMS.png
  14653   Tue Jun 4 10:56:31 2019 gautamUpdateIOOIMC diagnostics

I briefly managed to lock the IMC today - it stayed locked for ~10 minutes. Attachment #1 shows spectra of a few error and control signals for today's lock, and from a stretch yesterday before the problems surfaced*. The 60 Hz lines are much bigger, and MC_F signals broadband excess noise above a few Hz. I suspect a problem somewhere in the electronics.

*I confess the comparison isn't entirely valid because I had to tweak the FSS FAST gain from its nominal value of 22 to 25 in order to get the PC drive RMS down to the ~1.5V level. At the nominal gain setting, with the laser frequency locked to the cavity length, the PC Drive RMS was ~4 V. Still, indicative of something being off in the electronics.

Attachment 1: IMCdiag.pdf
IMCdiag.pdf
  14659   Thu Jun 6 22:11:53 2019 KojiUpdateIOOIMC diagnostics

As per Gautam's request, I looked at the IMC situation.

Locking path

  • Acquisition: IMC IN1 Gain +4 (nominal), Boost 0, VCO Gain (-32), FSS Common +6 (nominal), FSS FAST +20
    This is too low gain. So oscillate VCO Gain between -32 and ~0 until TEM00 lock is acquired
  • Once lock is acquired, bring the VCO gain to +11 (new nominal), and increase the FSS FAST to +23 (new nominal). Change the IMC BOOST to 3 (nominal)

Diagnosis

  • The PMC servo gain was checked. The control signal monitor for the PMC actuation was hooked up to SR785. The nominal gain was +18dB. Increasing the gain to 20dB made the servo oscillating. So the nominal gain of +18dB seems still reasonable.
  • The status of NOISE EATER was checked. Both the PMC REFL and TRANS were looked at by AG4395A. The power spectrum of them did not change much around the kHz~MHz region. It made the PSD slightly (x2~3) improved below 1kHz. I also did not recognize the relaxation oscillation peak. So I could not figure out where to see. NOISE EATSER was on and is still on.
  • IFO Modulation Freq: I took this chance to look at the IMC absolute length using the peak at 3.6MHz. The TP1A output of the IMC servo board was hooked up to AG4395A.
    The new FSR of the IMC (and thus the modulation frequency for the IFO) is 11.066275MHz (instead of the previous 11.066209MHz).
    This corresponds to 0.16mm difference in the roundtrip length.
  • (*Still working) IMC SERVO configuration:
    • FAST 25 (nominal) sometimes invoke the oscilattion. 24 has gain peaking ~30kHz. There is a big line peak at 35kHz so wanted to avoid the servo bump (PZT-EOM cross over). So decided to use 23dB. (This is not optimal for the CM servo as we need as much as bandwidth for CM servo.)
    • IMC VCO GAIN (bad name. this is actually overall output gain for IMC) was increased from the nominal 7 to 11. Increasing this above 11 makes the servo oscillating at ~200kHz.
  • (*Still working) Measured power spectrum of the error signal. Too many line peaks.
  • (*Still working) Single trigger observation: Oscilloscope monitoring started from 35kHz going up and ~20kHz oscillation +/-6V of the IMC servo output was observed. Could not capture good data for this. Try the other day.

I'll complete the entry later.

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

  14673   Thu Jun 13 22:46:41 2019 KojiUpdateIOOLeft IMC at the intermediate gains

SURFS want some locking of IMC for camera adjustment.

So I left the IMC with intermediate gains so that it keeps locking and unlocking.

VCO (overall) iMC gain of -32, FSS common gain 3, and the FAST gain 20. I believe MC2tickle is ON too.

  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. 

 

ELOG V3.1.3-