Between 0.5 and 50 Hz, there are a couple of regions where the Rio W laser noise dominates the three corner hat measurement. And, below 0.3 Hz, the Teraxion laser noise dominates the measurement. Today I'm going to try to quiet these two lasers a bit to make a slightly improved three corner hat estimate.
I'll be looking at the output of the delay line frequency discriminator (DFD) on the moku spectrum analyzer, so I've swapped in the 1.9 MHz lowpass filter for the one Rana was using to check the noise out at MHz.
I saved the following traces on an SR785, but with a nonfunctioning GPIB so ended up storing them on a floppy drive.
I saw minor improvements to the Rio W x Teraxion beat note spectrum, and took 20 minutes of data for each beat note. Dropbox upload failed several times, so I sent it to my laptop via ipad file storage and airdrop. After swapping fiber connectors and covering with foam, the system took ~15-30 minutes to equilibrate each time (though perhaps longer would have been prudent, since I still saw low frequency drift up to 4 MHz during the 20 min measurement time). No improvement to the estimate on Teraxion laser, and if anything the West laser was even more noisy relative to Rio E and Teraxion, across a wider frequency band (almost the entire band from 30 mHz - 90 Hz). The foam and turning off the HEPA FFU did reduce the noise below 1 Hz, especially for the Rio E x Teraxion beat note. Figure 1 uses maximal averaging for every 2-fold frequency increase, on 20 minutes of data taken today (attachment 2 reproduces the relevant figure from last week's data, without the Marconi reference for better viewing).
Attachment 3 is the updated Teraxion noise estimate.
Update: attachment 4 is a comparison of the frequency noise (uncalibrated) for three different configurations: after taping down the fibers, after adding foam, and after turning off the HEPA blowers. I'm not sure why turning off the HEPA blowers increased the noise, maybe should have let the system settle longer? Despite the overall higher noise floor with HEPA blowers off, several peaks between 10 and 100 Hz were reduced.
We found a heavily pitted cantilever from Zach's early fab runs, and mounted it in his clamp using the alignment jig and pins. We tried optically contacting one of the mirrors to the cantilever, but some combination of surface oxidation and roughness (or just inexperience) prevented us from making a bond. The surface of the cantilever had obvious defects, so we weren't very hopeful. We're seeing what Koji suggests for glue.
We're starting to make new cantilevers this week. Here is our process, largely drawn from Zach's thesis, based on the process from the Chao group (D1200849) and the standard techniques of hard mask etching.
Zach started with a 100 mm (4") undoped <100> Si wafer with 500 um thickness. He reports achieving similar mechanical Qs of the final cantilevers when starting with either SSP or DSP polished wafers, though we may want to investigate this further. To avoid spoiling too many large wafers, I'd like to start by processing our 2" x 280 um wafers that are leftover from the cryo Q experiment, and will inventory our larger wafers to determine what we should order. We also have some 3" wafers we can use to fabricate full-length (7 cm) cantilevers in smaller batches than had we used 4" wafer.
Zach's procedure calls for thinning the central region of the cantilever, which softens the suspension and improves isolation. I expect we'll want to evaluate our cantilevers before thinning, since the procedure to thin the central region is a bit tricky. When we do thin the cantilevers, we will not terminate the process at step 6 but instead continue with the following:
Materials we need to acquire are in bold
Our training status on the equipment is green for 'full user,' orange for 'supervised user,' or red for 'need initial training.
rather than the perfect solution to PSD estimates, how about using the code you already have and just change the binning a little more often than once per decade? i.e. stich together as you already did, but get more averaging in the noisy spots. Should be a very easy modification to the code.
I modified Aaron's DFD box: I replaced the SLP-1.9 (1.9 MHz low pass filter) with a 44 MHz low pass that we conveniently had in the lab.
The purpose of this is to measure the high frequency noise of some of our lasers to figure out if there's any difference between the RIO Planex and Teraxion NLL.
I did the hookup and everything looks good so far. So far I have measured the RIO E/W beat and the RIO E vs Terax beat.
Need to do some more data processing to get plots.
Some notes along the way:
Attaching beat note noise spectra showing the noise of the DFD (with no pre-amp, so probably Moku input noise), the RIO Planex (E & W lasers from the Cryocav table), and the Teraxion NLL. Looks like they're similar in HF noise.
Yesterday (August 25), I measured another 10 min at 488 Hz of Moku phasemeter data for the three pairs of beat notes. All three lasers had been on overnight, so there was no longer low frequency drift of the Teraxion laser. Rather than amplifying then picking off the beat note, I sent the RF output of the 1611 directly to the Moku's phasemeter input.
Today, I've been figuring out how to get more averages out of our data. One approach (the one used above) is a modification of Welch's method:
The above procedure sacrifices some frequency resolution at the higher frequencies in exchange for additional averaging. The tradeoff with resolution is necessary, because the window size determines not only the smallest resolvable frequency, but also the spacing of frequencies in the spectrum. For the spectra from the previous elog in this thread where N=10, the total measurement time is 10 minutes, and the sampling rate 488 Hz, there is evidently more noise higher in the frequency decade (7-9e^n) than lower (1-3e^n). More consistent averaging can be achieved by setting N=2, but at the expense of most of the high frequency resolution (only 33 frequency bins survive the procedure).
One workaround is to modify the procedure so the frequency binning is mostly set at the beginning, by the 'highest resolution' available. Then, perform Welch's method with as small a window as possible while still resolving the frequency bins. Care must be taken at high frequency: eventually, the 'FSR' of our Welch's method cannot resolve an f_0 difference in frequency into an integer change in the number of samples per segment. The spectrum can either be cut off at that frequency, or the procedure can continue while accepting nonstandard bin widths at high frequency.
Other workarounds are perhaps less desirable. One could accept nonuniform frequency binning, and simply compute Welch's method for every available choice of nperseg. This would maximize the number of averages in each bin, but especially at low frequency, there will be substantial correlation between adjacent frequency bins. Another workaround is to save the entire spectrum wherever evaluated, then combine the data later. One must again worry about correlations between the measurements: at high frequency, we would be combining coarse data with many averages with fine data with fewer averages.
Another approach entirely is to do something smarter than Welch's method. In our meeting today, Chris suggested I look into multitapering. Spectral estimates can reduce bias due to leakage by introducing a tapered window, at the cost of increased measurement variance. Welch's method heals the variance relative to standard tapering by overlapping the windowed segments, at the cost of some frequency resolution. Multitapering instead minimizes loss of information by increasing the number of degrees of freedom of the estimates. The Here are a few resources on the topic:
While checking out Percival and Walden, I stumbled across parametric methods for spectral estimation -- those where an early spectral estimate is used to refine the procedure and spectral estimate iteratively. Perhaps up the alley of some recent discussions at our group meeting.
Simply applying Gaussian error propagation is not quite right, because the PSD is exponential distributed (the ASD is Rayleigh distributed, see Evan's note T1500300). Each ASD is Rayleigh distributed with
For a large number of averages, the central limit theorem lets us estimate the mean of each PSD, , with normal distributed uncertainty and variance . Our three corner hat estimates of the ASD are based on the scaled, root mean-squared sum of three such PSD estimates, so for each frequency bin we can estimate the variance of the laser's ASD by
I'll use the final equation above, along with the number of averages, to estimate the uncertainty in each frequency bin of the final frequency noise ASD of the individual lasers. In particular, the filled region is .
[OK, I'm having a lot of trouble uploading pdfs to the elog this week, even with rasterizing. I've dropped these figures along with one set for the case of 'Welch's with no averaging' onto gaston under /home/controls/cryo_lab/Figures/3CH ]
I think these results warrant a more careful measurement, especially in the decade around 1 Hz. Also, the error bars are obviously way underestimated.
We uploaded the data from moku to dropbox, and pulled it to spirou via the web interface. Should give the workstations dropbox.
Later, I realized we could probably have done better by sending the output of the 1611 directly to the moku. Instead, we were amplifying +16 dB then using an RF coupler to pick off 1% for the moku.
After plugging back in all the cables, I was struggling to get the cavity locked again or seeing the transmitted beam on the monitor.
Today, following Aaron's suggestion, I removed the connection from the PDH mixer IF port to the oscilloscope and also the power splitter I had added earlier (now sending the IF output directly to the LB input only with the 10 dB attenuator). The cavity didn't lock right away but changing the gain to 6 and re-adjusting the input and output offset got the cavity locked again.
When we tried to get it on the monitor, we saw that the mode it locked to was a higher order mode misaligned in the vertical direction. We first aligned the beam vertically until we started seeing lower order modes and finally the TEM00 mode.
I adjusted the lenses a little to tweak the mode-matching after aligning the beam into the cavity for maximum transmission when locked. Calculating the mode-matching using the reflected beam when locked and unlocked shows that it is only 60% though.
The noise I was seeing last week on the ADC did not show up when driving the same channels directly with a function generator, only when buffering the function through the SR560. Wrapping the BNC several times around a ferrite toroid between the SR560 and ADC reduces the noise to close to the level of the ADC noise floor (there is a < 5 count pkpk sine wave cross-coupled into the adjacent channels for a ~2000 count pkpk sine wave on the channel of interest, but the signal carrying channel itself looks clean).
The SR560 that was overloading on battery last week is now also overloading on line power. I've swapped it with one of our functioning SR560.
Afterwards, I looked at the spectrum for the Rio E x Rio W laser beat note. Looked OK... there's some kind of filtering happening in my delay line though. If I watch the spectrum of the RF coupler's pickoff (1% between the amplifier and delay line box), the implied peak power entering the delay line box is ~ 5 dBm near any of the nulls (so ~113 MHz or 176 MHz), but over 15 dBm between the nulls. I hadn't noticed this behavior before (with the busted mixer and RF coupler before the amplifier).
I'm driving the input of the delay line box with 10 dBm from Marconi's RF output.
Ack!! stay out of the "Fix the SR560s" game Do not repair, do not send back.
Let's get a trustworthy measurement of the frequency noise ASAP.
I've borrowed one SR560 from CTN to get us by for now, but am wondering if I should order parts to make repairs, or simply send the units to SRS?
I replaced the mixer from my delay line box with a functioning ZFM-2-S+. I also replaced the lossy pink SMA cable (122 cm) with a slightly longer (150 cm) cable that I made from a spool of LCOM coax. I also replaced the shorter cables with solder soaked ones. The final build is in attachment 1.
I drove the delay line frequency discriminator with a swept sine from the Marconi, and observed a symmetric response in the IF output. Sweeping from 5 MHz to 80 MHz is in attachment 2, showing that the response is symmetric about zero from -107 to 108 mA.
I'll return later this afternoon for a more careful calibration and to take some data.
I'm calibrating the delay line discriminator by running a swept sine from the Marconi, and this time reading back on an acromag channel.
Attachment 3 is the first run (y axis in Volts), where the Marconi is ramping from 1 MHz to 240 Mhz, stepping by 10 kHz every 100 ms. There are some surprises. The output is linear until about 70 MHz, possibly because the mixer is only good down to 5 MHz. The upper half fringe is not symmetric to the lower half fringe, even comparing the curve only above 10 MHz.
I'm repeating the measurement with different sweep parameters: 1 MHz to 250 MHz, stepping 1 kHz every 50 ms. The steps will be somewhat faster than the Acromag's sampling rate, but those units dither so it should smooth out. I'll post some plots with the time axis converted to frequency when the data come in.
I'm taking this data today, here are the issues I've hit
We have 7x SR560 in need of repair in the cryo lab. Most of these (at least 5) are constantly overloading, which indicates the front end transistor and op amp need replacing. From SRS, these parts are $50 each, but I found I think the same parts on digikey (the FET transistor is LSK389B; the amp is OP37A) for about $10 each. There are at least 2 that need a new battery.
Rana noticed that my delay line is asymmetrical -- sweeping the frequency through a full cycle of the interferometer should reverse the sign of the output, but instead the output was biased negative.
Indeed, when I drive the mixer RF with 0.5 Vpp at 25 MHz from a function generator while supplying the LO with 7 dBm at 150 MHz from the Marconi (see attachment 1), my ZFM-3-S+ has an asymmetric waveform despite at most a few mV difference in the LO and RF DC levels (see the video in attachment 2). The same test with a different mixer (ZFM-1-S+) gives the balanced waveform in attachment 3.
I'll replace the mixer, and make a few modifications to the cables of my delay line box.
I'm repeating this measurement, but moving the photodiode and electronics to the cryo cavs table, so we don't send anything over a long, floppy fiber across the room. See attachment 1 for diagram.
I set up the measurement, but didn't take any data. What's the right way to find the IP address for these GPIB controllers? I ended up scanning with nmap, but suppose I should mess with prologix' netfinder tools to assign our controllers static IP addresses and just label them.
could the pumpdown plot be made so that the units are visible? Maybe use dataviewer or python?
We repeated steps 1-4 in elog 2789 and, with two people, managed to get the o-ring to stay in place while lowering.
During the vacuum testing, I'm continuing some lab maintenance, mostly cleaning up and labeling cables on the electronics racks.
The cantilevers cryostat vacuum line [edit: Aaron (May 2022) suspects I was pumping on the vacuum line only, not the chamber, as indicated in the previous log] has only reached 7 utorr (the reading on the gauge matches epics) after pumping overnight. I'm going to try manually actuating the gas ballast valve in case our roughing pump is manual-only.
After closing the gas ballast valve, the pressure drops below 7 utorr in under 30 minutes and is approaching 1 utorr. That's not the best I've seen from this pump, but should be good enough to continue diagnosing the cryostat.
To that end, I'm installing a new 2-270 Viton o-ring on the cantilever cryostat (needs name).
Facilities came to move out the cryo Q (central, rigid legs) optics table, and left us the legs. They also took the two desks from the lab. Lastly, they moved the PSOMA table to the center of the room and rotated it 90 degrees so its long axis runs EW. Afterwards, Shruti and I moved the PSOMA rack to the E end of the PSOMA table, directly across from the other two racks .
Attachment 1 is a screenshot of the temperature and particle count trends over the last 4 weeks. I need to figure out how to add axis labels on ndscope... the units for both temprature channels are F, relative humidity is %, and all particle count channels are log(counts). There is a factor of 10-1000 excess particle counts around the time of our lab rearrangement, mostly affecting the larger particle sizes. Humidity also experienced a mild increase. The AD590 temperature channel drops off because I turned off its power supply to accommodate our rearrangement, and haven't yet turned it on again. The daily and weekly particle count fluctuations are interesting, presumably dictated by lab access.
Today we are testing the pumping station while pumping on just some blanked off Ts and the vacuum gauge. Last time, we pumped on the vacuum hose leading to the closed Key valve at the cryostat, and observed the pressure level off near mtorr, before eventually reaching only several utorr. The turbo should really have no trouble getting to utorr pumping on just hose sections, so we'll try to observe some better pumping action today.
I continued preparing the PSOMA table and cryo lab for moving out the central optics table and 2 desks tomorrow:
The SR560 on the PSOMA rack are still plugged in to a power strip connected to the wall, but that is the only remaining cable running from the PSOMA rack or table. I'll return tomorrow morning to finish securing and wrapping the PSOMA table. Other than that, should be ready to move.
I did a rough calibration of the South laser diode's temperature-to-frequency response near 9.02 kOhm and 140 mA by
Since the temperature control loop is slow, the deviation in the current control signal upon stepping the TEC knob, along with our known Hz/mA calibration, tells us the frequency deviation of the laser in response to the temperature step. When the system equilibrates at a new temperature tuning, the difference of the old and new temperature tuning tells us by how much we stepped the control knob.
I observed about 1000 counts (0.3 V, assuming 10 V / 2^15 counts) deviation in the current control channel, corresponding to 890 MHz (assuming 148 MHz/mA as measured earlier, and 20 mA / V_modIn according to ITC 502 data sheet). The average temperature tuning changed by about -0.26 V, corresponding to -0.05 kOhm (the coefficient of the temperature tuning input on ITC 502 is 0.2 kOhm/V). This implies the South laser diode (SN 104987) -1.7 GHz/kOhm. Because the temperature was set near 9 kOhm, the resistance-to-temperature curve for the diode's temperature monitor tells us the temperature-to-frequency coefficient is about 630 MHz / K.
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.