I made a page in the ATF Wiki for Delay Line Frequency Discriminators. There is some prior work on these things, but these links are maybe a good starting point to see what the state-of-the-art is and whether our thing is better or not.
I started moving our fiber components to the rack-mounted box. I inspected and cleaned the tip of the fibers for the 50-50 fiber beamsplitter. Will work on some photos through the viewer of the analog microscope.
We need an uncoated APC to uncoated PC fiber patch cable to send a beam to our FC 1611. We have a coated patch cable, but should only use that for launching to free space.
I also searched for an appropriate replacement o-ring for the cantilever cryostat. I found the drawings and manual from IR labs, but they don't mention the size of the o-ring, and I didn't find something suitable in our supply. I'll order a new one, along with the patch cables and some panel mount DB9 adapters.
We cleared out the desk drawers and the middle optics table today. This involved
We still need to clear the following heavier equipment from the desks. To move this equipment, we'll first need to sort through the miscellaneous objects on the workbench so we have somewhere to put everything. It will require at least two people to move the reference cavity safely.
Other than that, we're ready for facilities to move out the desks and optics table. We should place an order for the new desks by tomorrow so they will arrive without too much awkward waiting.
Shruti and I opened up the cantilevers cryostat. Vacuum wasn't fully vented despite the valve being fully open, due to the foil covering the open valve sealing against the flange while venting. The cryostat popped rather than lifted open. The damage is at least:
Overall pretty disastrous. We'll have to investigate the full extent of the damage this afternoon, and first order of business will be cleaning out the broken Si fragments and evaluating the vacuum pressure.
We removed the silicon cantilever from the bottom of the cryostat with teflon-tipped foreceps, and stored them in a wafer casette. We also cleaned and regreased the o-ring with Krytox lubricant (we couldn't find the cryo lab's Apiezon N grease, must have been lent).
We pumped down the cryostat, but the roughing pump wasn't able to reach a low enough pressure to switch on the turbo. We also valved off the cryostat from the rest of the system, and pumped down on the hose + gauge + up-to-air valve (closed). The turbo was able to spin up to 90 krpm, but the pressure leveled out a several 100 uTorr. Pumpdown curves are in attachment 2.
The second pumpdown curve (pumping on just the hose and pressure gauge) suggests the pumping station needs some maintenance. I've seen this behavior before from a faulty KF flange connection, or when some condensation had built up in the roughing pump line. There is a procedure in the HiCube manual for flushing this line, I'll dig it up from my old elogs. However, the pumpdown on the cryostat suggests an even more severe leak in the cryostat itself, since the turbo wasn't even able to spin up and the curve appears leak-limited well above 1 torr. This is consistent with the visible damage to the mating surface in attachment 1. I suspect we need to send the cryostat to be reground and polished.
Attached is the most recent month of temperature trends for the lab, as measured by the particle counter. The lab temperature has been steady at 78 F for a couple weeks. I added a config file for this plot to our scripts repo under ndscope, so we can easily reproduce this plot.
While the particle counter has been logging, the AD590 temperature mon is again not logging. Possibly relatedly, when I try to apt-get install emacs on cominaux, it's complaining that the ligo repos 'couldn't be verified because the public key is not available.' I noticed that it was looking for the buster distribution in http://apt.ligo-wa.caltech.edu/debian, but the code currently lives in */debian/pool. Adding /pool/ (and commenting out the lines referring to stretch, which we are no longer using) let me upgrade cds-workstation and install emacs.
apt-get install emacs
I did find some apparent bugs in the modbusIOC database file (CRYOXT.db), but none restored these ai channels. Haven't quite finished yet.
Update: I identified that only the slow ADC channel 15 was not logging by observing a 1 Hz sine from a function generator on the other channels. Unfortunately we use channel 15 for the AD590 temperature sensor. There was just an extra character in the epics record for that channel, removing it fixed the problem and the AD590 is again logging. I've updated with a new temperature trend that includes both sensors and the particle counts in attachment 2. I used dataviewer because ndscope doesn't support log axes, but also defined some new calc channels to record the log of particle counts... and upvoted the log-axis feature request for ndscope.
We've been using T-junctions to pick off PDH control and error signals, but sometimes we should have a high impedance, floating buffer between our current control loop and noisy or grounded devices like the ADC or oscilloscopes. I've added an SR560 between the PDH error signal and control signal pickoff points, and also used the 'aux out' connector on the back of the LB servo box as the control signal monitor point. I terminated aux out into 50 Ohm, with a T to the SR560 high impedance input.
Changes to the previous configuration are highlighted in attachment 1.
We should note that the LB box driving into 50 Ohm is current limited at its output (assuming we don't narrow the voltage window using the trim pots on the back panel). It can supply up to +- 20 mA, so if we see control voltages approaching 1 V we are nearing saturation of the servo controller.
I also added a 50 ohm terminator in parallel to the 20 dB attenuator at the analog input modulation port of the ITC 502 current driver. This is to ensure a more or less accurate 20 dB attenuation of the control signal since the ITC 502 input has an impedance of 10 kOhm.
Following our discussion earlier when we realized that the AC electronics of the 1811 may be saturating, since our RF power (at the mod freq of 33.59 MHz) is near or over 55 microW, I added an additional 10dB attenuator before the EOM. The total attenuation is now 40 dB. To compensate for this I removed the 10 dB attenuator at the input of the LB1005.
Everything seemed to lock once again when the gain on the LB1005 was increased from 5 to 6.
I'm trying to make sense of these noise curves in relation to the free running noise I measured earlier with the three corner hat (3CH). The free running frequency noise of the S laser as measured by the three corner hat (attachment 6 from elog 2740) should be the same as the estimate off the free running noise using the PDH error signal and normalizing out the loop suppression ('open loop estimate' in attachment 2 of elog 2775). Here's what I'm noticing:
We should certainly try to resolve these discrepancies... perhaps we are seeing extra noise due to the electronics used for locking (the PDH measurement includes the LB box, analog RF electronics, a long DB9 cable to ADC that was observed to inject noise around 100 kHz only partially attenuated by our ferrite toroid, etc). There might also simply be a bug in the noise budget script, I'll check it out.
I agree that the more-than-1/f dependence in the transfer function from attachment 1 above seems fishy. It's above 10 kHz, so it can't be due to the influence of the temperature control loop.
I've moved Shruti's NoiseSpectra.ipynb script to the cryo_lab scripts repository, and pushed the version she uploaded earlier. I also added the data to cryo_lab/data/PDH/Noise with git lfs.
I found a couple bugs in the script, and made some modifications
Following these modifications, the noise at 10 kHz - 100 kHz is closer to that measured by 3CH. The updated open loop transfer function and noise curves are attached. I'm not chasing after the remaining discrepancy yet, since we expect that the PDH error signal was saturating during the attached measurement (see Shruti's elog from today for what we're doing about that).
[chris, aaron, shruti]
We (Aaron, Shruti) re-measured the PDH error signal slope for calibration since the previous measurements were for the settings before the mode-matching was optimized.
The cavity pole has changed but the peak-peak voltage of the PDH error signal seems roughly the same as measured on Thursday before optimizing the mode-matching. It seems like the different temperature setting we are now at has changed the polarization of light entering the cavity; there is no half-wave plate in the path between the fiber launch and input coupler.
I used the above estimate of the cavity pole and response along with the data measured on Friday to obtain a calibrated noise spectrum (red curve in Attachment 2), then for data above 100 Hz I used the linear estimate of the open loop gain and roll-off shown in Attachment 1 to obtain the blue curve in Attachment 2.
All data and the jupyter notebooks are in Attachment 3
I saved all the data from the Moku I measured today in the mokuliquidwb Google Drive.
I made a careful measurement of the cavity length with a high-precision rule, and got 582 mm. The FSR of our ring cavity is about 515 MHz.
I'm measuring the pk-pk voltage and frequency spacing of the PDH error signal to get the cavity response. I've converted the peak separation from seconds to Hz by taking the separation of the sideband zero crossings to be twice the modulation frequency (33.59 MHz), and assuming the triangle wave drive is a true linear ramp. The slope of the line connecting the peaks in the PDH error signal is a factor of 2 shallower than the derivative of the PDH error signal near zero (see this note from Tobin Fricke, and we also confirmed this numerically).
As a check, I've also recorded drive voltage at the sideband crossings. The control signal calibrated using the drive voltage should eventually give us the same noise estimate as the error signal calibrated with the cavity response.
We noticed some distortion of the error signal near either turning point of the current drive. We measured the power transmissivity of the input coupling mirror to be closer to 0.02 than 0.10 (by measuring the power before and after that mirror, with the cavity unlocked), probably because we have not set the polarization and the reflectivity is slightly higher than specified for the other polarization. With the lower transmissivity, the cavity pole is consistent with expectation.
We're inclined to believe the higher frequency measurements, since the low frequency one was made at low amplitude and thus had some distortion of the error signal close to where the drive turned around (and the 1/f frequency noise).
We did try to make the measurement at 10 kHz and 100 kHz, which should still be below the cavity pole... but didn't see a clean error signal.
Made a couple measurements of the noise spectra (PDH error signal, control signal) at various frequencies. Haven't grabbed them yet to upload.
We've noticed that the ratio of transmitted / reflected light (MON_RATIO) monotonically increases as we increase the PDH control setpoint for the temperature loop (that is, higher currents always increase this ratio). We noticed that the TRANS_MON and REFL_MON channels had some offset with the beam blocked (-300 and +15 counts respectively), but negating these offsets does not change the behavior.
Later, with the cavity locked I (aaron) adjusted the input steering mirrors to maximize MON_RATIO. The transmitted beam spot and PDH error signal both look cleaner. Moreover, after improving the mode matching MON_RATIO is no longer monotonic with PDH_SET. Perhaps that behavior was an artifact of some higher order mode resonances. Messed around with the combination of attenuators, gain, limits, etc. Before realignment and this work MON_RATIO was at most ~2.8; after it's reliably > 8. Should really check the DC responsivity of the photodiodes to determine if this is a reasonably good number, but the spot looks bright.
Also increased the limiter window on the LB box output to the full range... though that turned out to be only +- 5V, rather than +- 10V specified in the datasheet. Also, I'm driving the 10 kOhm input impedance current mod in directly, rather than T-ing off into a 50 Ohm terminator... not sure why this should be preferable? The output of the LB box is current limited into 50 Ohm (only supplies +- 20 mA, regardless of the voltage limiter), and with the attenuator I wouldn't expect reflections.
There's some 100 kHz oscillation present even with the loop off. It's somewhat affected by stressing the DB9 cable to the ADC, so perhaps adding some extra turns around our ferrite toroid would eliminate this.
There is also a 'closed loop' way to make this measurement.
At the end of the day, we would like to know the coefficient from 'frequency to PDH error,' as well as that from 'control signal to frequency.' If we measure one and the open loop transfer function, we hae the other. We require either detailed knowledge of the cavity parameters, or an independent measure of the laser frequency. Fortunately, because we can drive the laser frequency, our independent frequency discriminator doesn't need to be as quiet as our cavity.
Earlier, I set up a 'delay line frequency discriminator' to measure the Teraxion laser frequency noise in a three corner hat with our two Rio lasers. The same discriminator can be used to measure the transfer function from the PDH error summing point to the laser frequency as measured by the delay line.
Alternatively, since we expect the PDH error signal response to frequency deviations to be flat, we could measure the beat note frequency with the moku phasemeter at a single frequency and do a 'lock in' measurement in post processing.
I ended up debugging labutils/tektronix/tek_tools.py to grab this data from the scope.
I'm sweeping the laser current with a 0.5 Vpp triangle wave at 100 Hz attenuated by 10 dB. On the scope I'm measuring the PDH error signal and the triangle wave before the attenuator, triggering once only on the triangle wave. Data are in cryo_lab/data/PDH/210630_PDH_sweep.txt, and the analysis in cryo_lab/scripts/PDH_calibrate.ipynb does the following:
This is not a great procedure. The PDH error signal has some features, and the data underconstrain the free parameters. The best fit is nowhere close to expectation (for example, estimates the cavity length at 19m, compared to about 0.5 m), and shouldn't be trusted. The variances for some of the fit parameters are large compared to the estimated values.
We've been measuring the amplitude spectrum of our PDH error signal in V/rtHz. We'd like to calibrate that into Hz/rtHz of phase noise on our laser.
To measure the voltage-to-frequency responsivity of our laser driver and laser, we can sweep the current modulation input with a triangle wave while measuring the PDH error signal. Fitting the PDH error signal tells us the conversion from Volts to Hz (at wherever we inject the current modulation), the product of carrier and sideband powers,
To make the measurement, I'll
Given the responsivity of laser frequency to excitations at mod in, we can calibrate the PDH control signal into units of Hz/rtHz. Alternatively, we could use the slope of the fitted PDH error signal and the FSR to calibrate the PDH error signal into units of Hz/rtHz.
I started making this measurement on the moku, but found some pernicious high frequency noise... possibly from the capacitance of the cable over to the electronics rack? We've seen it a few times before, and it produces a characteristic periodic structure in the FFT. Adding a 1.9 MHz lowpass filter after the function generator does not remove this noise, and it does not appear on the Tektronix oscilloscope monitoring the PDH error signal. Attachment 1 shows the measurement on moku.
Instead, I'll make the measurement by running a cable from the function generator to the TDS 3024B oscilloscope and record the traces over ethernet. The error signal still is a little more complicated than I'd like, probably due to the presence of higher order spatial modes... but I'll see what the fit says.
I ran an ethernet cable from the network switch on the PSOMA rack to the scope, and turned on GPIB by following instructions in the Tektronics manual. I tried dumping data from the scope over gpib using scripts I had been using at the 40m, now in the cryo_lab/scripts repo... but didn't have much luck. Chased around error messages for a while, and tried debugging tds3014.py, but didn't get it working.
Here's how to add slow channels to the framebuilder DAQ:
sudo systemctl restart rts-edc
sudo systemctl restart rts-daqd
Now that we are generating noise budgets, we'd like to compare our observed phase noise with that expected from the physical noise sources. Chris pointed us to some useful papers a while back, and I'm going to start documenting my further reading on the PSOMA wiki's noise budget page.
How did you get the framebuilder to recognize the slow channels defined in SoftIOC? I recall we ran into some problems with that last time.
I added your ndscope config file to the cryo_lab/scripts repo. Thanks!
The glitches seem to come from the slow controls output and temporarily result in an actuation voltage of +-10 V even when the limit for that channel was set to +-2 V in the PID script. This triggers the 'WIN' light and a beep from the ITC 502 while also losing the lock.
Aaron and I also had observed this last week.
We were able to measure the loop transfer functions with the latest settings of KI=0.5 and PDH_CTL offset=2000cts on the slow control without being affected by the glitches too much. Chris also set up all the slow control channels so that they can be viewed with ndscope. In this we could also see that the transmission monitor sometimes glitched but the loop remained locked.
Updated measurement similar to elog 2759
I noticed the -B input of the LB servo was connected to the input of the Moku (via a 20 dB attenuator). I removed this connection. I also noticed that the PID control loop was still running in a tmux session ('temp_PID') on spirou; if you were trying to run the loop in a separate process, I could see that leading to some oscillation. It looked like the loop was only started once in the tmux session, which would have been yesterday before modifying the config file... so I suspect that's why the loop was oscillating. We should run this PID loop as a service on cominaux eventually.
For the last several days, we have been seen some ~MHz oscillations appear in the PDH error and control signals, even in the 'quiet' operation modes we found. Shruti noticed the signal disappeared from the control signal when we unplugged the cable connecting the control signal to the fast ADC. The DB9 cable is long, since it runs from the PSOMA rack to the cymac rack. We wrapped the DB9 cable 10 times around a ferrite torroid, and the oscillation disappeared!
We are also seeing some odd glitches in the temperature tune channel. The output of the Acromag DAC (as measured on moku oscilloscope, and indicated by the TEC hitting its window limit) has glitches where it hits the negative voltage limit (-10 V). The TEMP_TUNE epics channel is showing no such glitch, so it's almost certainly a hardware issue. We weren't able to reliably reproduce the glitch.
We played around with the servo settings to get a stable lock point. I didn't capture much data, since the glitches kept killing the lock.
I changed the error signal for the PID slow control to be the PDH control signal by modifying the file 'PIDConfig_SLDTemp.ini' in cryo_lab/scripts/temp_control on spirou.
The control signal does zero out when I actuate the loop, but the PID error signal shows strange oscillations when the control signal cable is plugged into the breakout board.
[aaron, shruti, chris]
We swapped in a level 17 mixer, since the level 7 may have been saturating. We also switched from SLP-1.9+ to SLP-5+ after the mixer.
We continued setting up slow temperature control. Chris suggested nulling the LB servo offsets with the inputs terminated at 50 Ohms, instead of tuning them for the closed loop. With the new choice of offsets, we aren't seeing the 100 kHz oscillation.
In the locked state with temperature control handling the low frequency, we seem to not be locked exactly on resonance. The PDH error signal is the process for both current and temperature control. We used the ratio of cavity transmission to reflection (X1:OMA-ERC_TRANS_MON / X1:OMA-ERC_REFL_MON) to assess how close we are to resonance, and stepped around the PDH setpoint on the temperature control loop to maximize the ratio. However, at some point before the ratio is maximized the current loop loses lock.
I suspect some stage of the PDH servo box is straying too far from its linear range. When we change the PDH setpoint on the temperature loop, it changes the DC level of the PDH error signal at the input of the LB servo box. Therefore, the signal entering the PI filter strays from zero. The deviation is about 20 mV at the LB box error monitor point when we lose lock (compared to +- 330 mV nominal range). I spent some time tweaking the input offset to adjust for the new setpoint, but wasn't very successful. I later realized we could feed the temperature PID setpoint to the -B input of the LB box, which would then adjust for the offset introduced by the temperature control loop. We'll try it tomorrow.
Finally, we updated the PID locking script to turn on only when enabled by X1:OMA-SLD_TEMP_EN, and when the cavity is locked (indicated by the trans mon channel X1:OMA-ERC_TRANS_MON_OUT16 reading > 50 counts). When the locking script is running, the logic is as follows
Chris also added a GPIB controller to our ITC502, so eventually we can control TEMP_TUNE and read back TEMP_MON over GPIB instead of with Acromag channels. To use GPIB, local current control must be disabled, so this would require us to use the custom current driver or handle PDH locking at high frequency by phase modulating at the EOM.
I just switched the mixer back to level-17 and changed the low pass filter to SLP-5+ (5 MHz corner)
I observed an unexpected behavior this afternoon that I still can't explain. I managed to get the cavity locked using the LB box servo in LFGL mode. When I turned off the servo box by switching to 'lock off' mode, the cavity maintained lock and the PDH error signal was passed through to the current modulation point. Only the LB servo was driving the modulation point, and the temperature tuning was also off. My understanding from the LB manual is that in 'lock off' mode, no control signal is summed into the output signal... so why was the PDH error signal passed through?
Later, we started controlling the temperature of the laser diode using some slow epics channels.
We observed a 100 kHz oscillation in the noise spectrum after this procedure. We weren't able to change the oscillation by tuning the laser current (within 10 mA) or servo gain (while maintaining lock).
We measured the open loop transfer function of only the LB servo box (feeding back its output to -B), and didn't see a feature at 100 kHz or an oscillation in the noise spectrum. We measured the transfer function in both 'lock on' and 'LFGL' modes. We did observe a broad peak near 4.5 MHz in the noise measured at the LB error monitor (attachment 1, 2. The sharp peaks are artifacts from the Moku present even with no input connected).
Data are available in the ligo.wbridge google drive. Attachment 7 shows the broad 100 kHz oscillation on the PDH error signal in purple.
We measured the OLTF of the LB1005 servo by feeding back to itself with the setting 'LFGL' (Low Frequency Gain Limit) set to 40 dB, INT (pure integrator until it hits LFGL), and gain of 5.1 at 300 kHz.
I (Shruti) think the gain setting was slightly different today which makes the green curve slightly higher in magnitude than the orange curve, but otherwise it seems to track it and do nothing strange. The orange curve is the TF of the LB1005 derived when the servo is used to lock the laser to the PSOMA cavity as in elog 2759. The phase for both measurements also seems to be the same up to 1 MHz.
Data for LB1005 in Attachment 4 and remaining data used for the plots in Attachments 3 and 4 of elog 2759.
After these changes we measured the loop TFs again. It is strange that the phase of the open loop first increases and then decreases.
Also there is a weird dip at 80 kHz (right above the UGF) in both the Plant TF and the full open loop TF.
The LB1005 measured separately and in the full closed loop differ by ~4dB, the full loop setting resulting in the lower curve, even with the same gain setting. Otherwise the two run almost parallel, at least below 1 MHz.
The data for this is in Attachment 6.
I swapped out the level 17 mixer in our PDH setup for a level 7 (ZFM-2-S+), and put it all in a box (attachment 1).
This let me remove the 10 dB attenuator before the LB box, though I had to add a 6 dB attenuator on the LO.
I measured the open loop transfer function again with the new mixer, and saw a 34 kHz UGF (attachment 2. I wasn't very careful to maximize the gain of the LB box). No correction was needed, since there is no longer an attenuator at either input of the LB box.
Having added the attenuator, A(s), at the input A of the LB1005 the loop algebra is changed slightly: Attachment 3 has the algebra and Attachment 4 helps with understanding the symbols. I have just considered this attenuator separately from the plant and servo.
Attachment 2 is all the individual closed loop transfer functions that were recorded to calculate the open loop ones.
Attachment 3 has the data, settings, and screenshots recorded from the Moku to calculate OLTFs
Attachment 4 is the Jupyter notebook used to generate Attachments 1 and 2
Attachment 5 has the loop algebra and diagram
Attachment 6 is a diagram of the setup depicting the loop components
Indeed, we were able to eliminate the oscillations we had been seeing by adding a 10 dB attenuator between the PDH error signal and LB box input A, and changing the attenuator at the LB box output from 20 dB to 10 dB. [We also swapped out our ZFM-3H-S+ for ZFM-2H-S+, which has a 2 MHz low frequency cutoff compared to 50 kHz. Swapping mixers did not resolve the oscillation]
"import numpy as np\n",
"import matplotlib as mpl, matplotlib.pyplot as plt\n",
We messed around with the LB box today. Here's my attempt at a narrative from the wandering.
We are measuring transfer functions using the Moku and LB box error points.
We first checked on an oscilloscope that we see no saturation at any of the monitor points (PDH error signal, LB error point, or current control point). We noted that the mean voltage at the LB box error point was reasonably close to zero (-2 mV). Then, ran a moku transfer function measurement with the following settings on the moku and LB box
We noticed that the control signal is much smaller than the PDH error signal, which seemed surprising at first blush since the LB box has a bunch of gain. However, the low frequency drifts of the control signal are much larger than those of the PDH or LB box error points (about 1 V drifts of the control compared to mV drifts of the error signal), which makes sense. And at high frequency the gain is falling off as expected.
I set the input voltage offset of the LB box by tuning the PDH error signal (on oscilloscope) to 0 V with the cavity locked; in retrospect, this isn't a rigorous procedure unless the temperature control is handling the DC error. With the input offset dial at 4.68 (-160 mV), the PDH error signal is centered at 0-2 mV a few mV drift over minute timescales. Before adjusting the input offset, the error signal was centered around -150 mV, which meant there actually was some clipping of the PDH signal! The input stage of the LB box saturates at +- 330 mV. The rms of the PDH error signal is 200 mV. Perhaps we should use a lower power mixer to avoid saturating the LB input (currently at level 17).
THe LB box manual shows the electronic schematic for the servo in Figure 7. We again zero'ed out the inputs to the various amplifier stages by doing the following with both inputs (A, B) open and sweep range turned off:
Attachment 2 shows the PDH signal and LB error point, so the math channel gives PG. Attachment 3 shows the PDH signal and control signal, so the math channel gives P. Attachment 4 shows the control signal and LB error point, so the math channel gives G.
I measured the voltage from X1:OMA-S_TEMP_TUNE, and found caputing some value on that channel resulted in seemingly random voltages from that DAC channel. Modifying the epics record for X1:OMA-S_TEMP_TUNE to match the other analog output channels fixed the problem, namely commenting out the PREC, ASLO, and SCAN fields. The temp tune channel now reads the actual voltage from Acromag analog output channel 0.
I renamed the fast channels for clarity, and created some subsystems.
The 'TEMP TUNE' input is relative after all with a coefficient of 0.2 kOhms/Volt. Max input voltage 10 V. (Attachment 1)
The 'TEMP OUT' is absolute (as expected) with a coefficent 2 kOhms/Volt.
Attachments 1 and 2 are the same plots in elog 2751 but overlaid. They are the noise spectra measured at the output of the servo.
Comparison between the LB1005 servo controller (yellow) and SR560 pre-amplifier(red) when the cavity is locked to the fundamental (TEM00) mode as seen on the monitor. Also shown in this plot (in blue) is the noise spectrum when the cavity is not locked to the fundamental, i.e., the temperature is detuned such that nothing was visible on the transmission camera monitor, but the SR560 servo is on.
Noise spectra measured with the SR560 as the servo, but with different gains. All were measured while the cavity was locked to the TEM00 mode as seen on the transmission monitor.
I picked up 4 packages from Downs (three from ThorLabs and one from MiniCircuits)
Ran more cables to the ADC/DAC for PSOMA, and started setting up the soft channels to do slow control of the temperature setpoint.
Beware, the temp tune setting seems to be an 'absolute' setpoint rather than a relative tuning on top of the setpoint from the front panel. We'll be testing this out in more detail.
Discussed the lab layout with Aaron today and combined some ideas from both attachments in the previous elog.
IT would be interesting to see an overlay of the ASD of the control spectra (SR560 low gain, SR560 high gain, LB1005 high and low gain). These are all directly comparable since they are at the actuator point. Might help us figure out where the peaks are coming from.
Yesterday Rana pointed out the peaks at 350 kHz and its harmonics suggesting that the loop was oscillating. He also added a RG850 long pass filter 3mm thick to the transmission PD. Despite the specs mentioning that the transmission at 1550nm was over 99%, this signal seems to have decreased (yellow trace in Attachment 5).
I also adjusted the servo gain at the SR 560 and found that the loop could 'lock' even with a gain of 5. I was not able to lock with gain of 2. Previously, the gain was set to 50.
Attachments 1 and 2 are the PDH signal measured after the SR560 from its 600 Ohm output.
In Attachment 1, the cavity is PDH locked using servo (SR560) gain of 5. The peak at ~350 kHz and its harmonics are visible. In Attachment 2, I tuned the temperature away from the locking point while the servo is still active and the peaks are still visible. The same oscillations are also seen in Attachment 5.
Attachment 3 and 4 are taken from the fast channels in the DAQ system. The gain at the SR560 was set to 50 for the reading in Attachment 3, and was set to 20 for the reading in Attachment 4. The gain setting of 50 seems to show better noise performance than 20 as seen on the digital system.
The purple trace and its persistence in Attachment 5 shows that the strength of this oscillating signal varies. This was measured with a gain setting of 5.
The oscillations were also seen when I locked the cavity with the LB1005 servo controller with gain=5 (lowest that allowed lock), PI-corner set to INT. Attachment 6 is the power spectrum of the output of the LB box when the cavity was locked.
Using the channels we set up yesterday, we are measuring the PDH error signal and transfer functions.
We would like to start recording our PDH error signal on cymac, both for noise budgeting and to provide slow feedback to the laser temperature.
Today we ran a couple cables from the PSOMA rack to the fast ADC/DAC boxes. Then, updated the x1oma model to record the N and S PDH error signals as _DQ channels. Next step is to define some softIOC channels for the PID controller. Attachment 1 shows the status lights after modifying the x1oma model, and disabling the models for older Cryo Lab experiments.
We got a new HEPA FFU yesterday. I wanted to see if the particle count has dropped as a result, but the minute and longer trends are not available... apparently no trends have been logged for about three weeks. I see from systemctl that the rts-edc (realtime system EPICS data concentrator) loaded but failed to run. Restarting that service eventually restored the frames. We should get an email when this happens.
We are about to purchase a new clean enclosure for the PSOMA table, and while we've got facilities modifying the sprinklers would like to consider alternative floor plans for the lab. Here are two possible directions to go.
Attachment 1: We've removed the cryo Qs optics table, and moved the workbench to the center of the room. Desks are now located at the N and S walls of the room, and PSOMA table is close to the same location. Other cabinets are mostly unchanged, but I bumped the cymac rack over to improve our access to those cables.
Attachment 2: A more radical proposal. Move the workbench to the W wall to put a work area near the sink and decongest that corner. Move the vacuum cabinet a little north and optics cabinet a little south, making the optics a little easier to access. The wire rack moves to the S wall, since it doesn't have swinging doors and could overlap the lab's air intake slightly without blocking anything. PSOMA table is centered in the room, letting us consolidate the electronics racks and associated cables to one part of the room. I like this layout, but it might be tricky to move so many cabinets.
For reference, the existing floor plan is approximately the same as Johannes' diagram from 2016.
Update: Labelled the PSOMA optical table with dimensions. Other items in the lab are approximately to scale. I quite prefer the second option with the PSOMA table in the center of the room, as in attachment 2.
I'm measuring the noise of the cryo cavs current drivers. They are labelled with D1500207, and their traveler numbers are S1600247 for the W driver and S1600248 for the E driver.
First, I used a BNC breakout and multimeter to measure the DC voltage across a 20 Ohm resistor, while the interlock pins were connected to 50 Ohms. I found
Next, I wanted to measure the resistance of the diode at some usual temperature and current setpoints. I was overloading my SR560 buffer at DC, so instead I'm using a lock in amplifier to make the measurement at AC.
If the Busby-to-SR554 system doesn't give the same responsivity as SR554 or Busby-to-flukemeter, I can't trust it to tell me the correct resistance of the laser diode. Might try the measurement again to see if I've missed something (it's not the lockin input coupling or filter settings visible in the photos, I tried), but if there's another approach I'm interested in hearing.
I went digging for what TEC settings Johannes had been using for those lasers, and what x1cry channels I might use to measure their PV curve to get a current noise.
Strangely, I can't find the x1cry medm master files. I recently copied over these files into the x1oma medm directory, then made some modifications (rm'ed some files unnecessary for x1oma). I'm seeing those modifications reflected in the medm/x1cry/master directory, as well as medm/x1oma/master. Here's my bash history
I might not have actually lost data, since it looks like x1cry/master contained the actual master crymaster.adl, plus several backups. However, any changes I make in x1cry/master (eg, renaming the file) are reflected not only in x1oma/master, but also in the backups in medm/archives/x1cry_*/master. The files I'm working on are not linked, and the archives certainly shouldn't be affected by updates to the main files, so I don't know why this should happen.
Ah, I didn't realize x1cry/master was linked to some other directory. Now x1oma/master is linked to its own directory.
Now measuring the Teraxion laser beating with the Rio lasers for cryo cavs experiment. The E Rio laser is SN 5597; the W Rio laser is SN 5601.
I'm testing the WX beat note first, using the configuration attached to the above post. The Teraxion laser is sending 262 uW to our 1611.
I set up the attached configuration. The cryo cavs lasers are driven by the custom current drivers. I only have one remaining TEC controller (the other cryo cavs controller was moved to PSOMA rack). To drive the other TEC, I've moved the ITC510 from PSOMA rack to cryo cavs rack, and am using it to control the East TEC. Our TED 200 C is controlling the West laser TEC.
I'm getting frequent proxy errors when uploading pdfs to the elog. Started yesterday, continuing today. Error message below.
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /Cryo_Lab/.
Reason: Error reading from remote server
beyond ~70 Mhz, there will be some frequency dependence due to the frequency dependent loss in the cables. Perhaps also in the mixers and amplifiers.
I suggest we just stick to the 10-20% cal uncertainty for now. If this setup seems good, however, we can rebuild it in a more robust fashio by ordering parts that are smooth out to 500 MHz.
I'm repeating the above measurement with a shorter cable (122 cm). The path length difference is now ~107 cm, which means the distance between adjacent nulls should be 93 MHz. If the beat note wanders by less than about 16 MHz, we should be linear enough. I decided against a shorter cable to ensure I'm within the 250 MHz bandwidth of the moku spectrum analyzer during calibration.
Calibrating the new delay line box with the marconi:
This time, I am recording the output from the delay line discriminator on moku while measuring the spectra with SR785. Should provide a check at the end that everything makes sense.
Due to the drift and small current change, the above aren't a great measurement of 'Hz per Amp' for the laser diodes. For example, if I assume the change in beat note frequency between the upper and lower null measurement of SX beat is due to changing the laser current of the S laser, then use that to estimate the expected change in beat note frequency of the NS beat going from the lower to upper null LD current, I'm off by 47 MHz compared to the observed change in beat note frequency between NS lower and upper null.
Here's a new calibration for both lasers, based on the NX and SX beat notes (up to sign):
This still seems implausible to me. Our HP 8560E is a wider band spectrum analyzer, but it's doing some weird mode hop thing. I'll use the above for now. At least I have observed the S laser to have a larger frequency deviation per mA across a few measurements, and it's also consistent with my observing larger frequency drifts when the S laser is involved in the beat note.
The current noise measurement of the ITC510 is still too high..... attached is the three corner hat measurement from the SR785. I'll redo the current noise again and get the plot readable tomorrow.
Update: Oh, I'm just missing the G=100 from SR560 on the current noise measurement. With that factor, the ITC510 I below the beat note spectra. Will update the plots today.
Update: plots attached, now removing the filter from SR560. All attached plots are from the measurements by SR785.
I'm repeating the measurement above, this time with the delay line interferometer in a box. The cable length is slightly different -- I was using a 3 m BNC cable for the delay line before, and today made my own ~3 m SMA cable. The RF power level is also somewhat reduced, since I moved the attenuator before the splitter to avoid having to open the box and attenuate one leg of the interferometer. SR560 settings are same as yesterday.
I'm also calibrating with the marconi, rather than stepping around the laser current to null the beat note signal. The interferometer doesn't change between measurements.
Obviously, lots of drift throughout these measurements. I'll analyze but not much trust these results. One workaround to deal with the drift would be to increase the FSR by shortening the delay line, at the expense of some signal. Could also first lock the laser to the cavity, then make the same measurement (or even with a longer delay line).
I also noticed the effect of asymmetry splitter-delayline-mixer IFO by some DC offset at the bright/dark fringes.
I put the splitter, mixer, and delay line in a box. The box is a little smaller than would have been ideal so I'm not completely satisfied with the strain relief, and one of the SMAs rotates due to the locking washer being overtightened... but I think it'll do. Innards attached,
I'm repeating this measurement, this time recording the current noise of the commercial driver before each measurement for reference. Will update tomorrow with additional measurements, plots.
The measurement parameters for delay line frequency discriminator are:
According to the datasheet (PSOMA wiki 'documents' page), the lasers come with a recommended temperature setpoint (T_set on the datasheet). This setpoint may either lie on the upper hysteresis branch, or lie outside of the hysteresis region... but according to our datasheet, our lasers' T_set lie in the upper hysteresis branch. If we observe spectral distortions, this indicates the temperature is outside the recommended range or operating on the lower arm of the hysteresis. To achieve a low noise operating point
Notes on current noise measurements:
I confirmed the inventory of LIGO equipment in cryo lab. Liz requested photos of these tags to clear things up.
Shruti and I confirmed that the dimensions for the enclosure make sense. We measured
Note to self: line the corner of the drop ceiling with some foam.