Johannes and I have taken the following equipment from the crackle lab to the 40m between Friday, June 1, and Sunday, June 3 2018.
Apart from the NPRO which was taken from the optical bench, everything else was taken from the storage cabinet by the lab entrance.
The gratings and aspheric lenses glued on the mounts were delivered to the lab on Thu.
The powermeter controler + S401C head was lent from OMC Lab. Returned to OMC Jul 15, 2020 KA
Log of the output power vs current in the 1064 nm (Innolight) pump laser. The crystal temperature was set to 45.5 C, and the current limit is set to 2.1 A
Two crystals from Raicol arrived. Picked them up from Downs today and inspected them (see photos below). The lengths are nominal (20 mm), they are serialized as 123 and 124, and the ends look like they have the specified (AR) coating. I reached out for Covesion two days ago to track the ovens so we can mount these guys, but have yet to hear back from them.
Received one Marconi 2023A (#539) from CTN and an SRS FS725 Rb clock. (See CTN/2605)
Covesion order arrived, containing 2x
See equipment borrowing note here.
Attempting TF measurement for resonant EOM driver, but not having luck reproducing the measurements done recently (Dec-03), so I started debugging the circuit. Both power supply connections (+- 18 VDC) seem nominal. The MAX2470 buffer regulated input is nominal at 5VDC. Looking at MMBT5551 HF transistor, base-emitter voltage is -0.60 VDC (nominal wrt -0.66 V). Using a scope, I feed a single tone (36 MHz, 190 mVpp) and look at the RFmon output and it looks ok (gain ~ 1). I changed the RFmon SMA cable and that seemed to do the trick... Bad cable (now in trash) stole my morning.
Tune EOM driver resonance to 35.993 MHz (shown below for reference).
UPDHv3 box (serial 17142) is bogus. While retrieving values of some of the components to plug into working zero model, saw the VGA stage is bypassed by a previously unnoticed hack. Verified this by taking TF and not seeing any changes with respect to the gain knob (shown below are zero's model TFs suggesting a tunable UGF from ~ 10 Hz to 1 kHz), so this box is not good for a standalone servo.
As suggested a few meetings ago, made a quick and dirty lock using a single SR560 and took measurement of something* CLTF (SR560 gain = 10) below. New goal is to find a decent replacement, for which decided to use RedPitaya's python API "pyRPL". Just using the GUI out of the box can also lock the cavity relatively quickly but neither method results in longer than 1 minute lock... so took one step back to polish the pdh error signal.
* Something = Use SR785 TF measurement with source on Ch1, and to B input in SR560. The SR560 in (A-B) mode, and demodulated signal connected to A. The loop was closed with the SR560 output driving the PZT, and Ch2 of SR785. Wouldn't call this CLTF...
With Aidan's assistance, I borrowed
for ~ 2 um imaging in the Crackle lab.
- First test to grab frames was done in my personal Win10 machine, with no success. Either I was unable to configure the server correctly, or the software "ArraySoft" is not supported in Win10. Upon contacting Heimann, I received instructions to update to a newer version but was warned that it's just a new GUI, nothing really changed from v1 --> v2. So didn't even bother.
- Instead, wrote a simple python-socket UDP server to catch the video stream. Most trouble happened when using temperature mode (command "K"). The client streams a bunch of zeros... My guess is that this unit does not have an internal temperature calibration, and one could in principle be uploaded but we probably don't care. Streaming in raw voltage mode (command "t") works well, as shown by the sample frame shown in Attachment 1.
- After recovering the CTN Win7 laptop from Radhika, I gave "ArraySoft" another change just to know the frames I was getting in python were not bogus. For this I pointed a 532 nm laser pointer straight to the sensor and got an image shown in Attachment 2. The key difference is the processing of the video stream. Attachment 1 is a single frame, while Attachment 2 is the average of 30 frames with no offsets present.
- Another issue present during this task was a faulty USB connection. Sometimes moving the sensor around would interrupt the stream (power lost). I carefully removed the case and exposed the TO-39 package and surrounding electronics to inspect and search possible failures but after seeing none, I swaped the USB power cable with my portable battery charger and had a more robust operation... So I dumped the old USB cable, and will get a new one.
- Since this one was borrowed from TCS lab, I placed an order for another one which will be set up permanently in the lab. Hopefully this will be enough for the OSA.
Today the DOPO v0 got disassembled to make way for the optical table swap. Most components have been stored in the white cabinet's bottom panel.
Following Koji's request, I took some time to clear the area surrounding the crackle chamber so it can be migrated to the former TCS lab.
I moved the DOPO setup which was sitting on a breadboard for easy transportation (Attachment #1) and placed into the other table in the lab. Attachments #2-3 shows the cleared area. Several instruments from the DOPO experiment still remain around the other side of the crackle chamber, if they need to be relocated I can move them as well.
How to move the large engine hoist through the narrow door
I assembled the second ECDL with a 19XX SAF gain chip (all pins remain disconnected), and a 14XX nm angle facet plate with a grating.
Attachments #1-4 show the final state of the housing along with the thorlabs current and temperature drivers. The remaining spare components (including screws, angle facet plates for the gratings and two SAF gain chips, one for each wavelength) are stored in a single box in the right top cabinet on the north end.
I took the Thorlabs PZT driver to the 40m for use with the BHD OMC.
It's dusty in here...
I was recently commissioned to do some noise measurements on the new AOSEMS. I set up a humble experiment in the LIGO e-lab to do some preliminary measurements:
I made a simple current-to-voltage converter out of an OP27E (using a 100-kohm feedback resistor) to use as the transimpedance amplifier for the readout. This results in a transimpedance of 0.1 V / uA. A simple schematic of the important elements is attached below.
DC power was provided without regulators directly from the laboratory DC supply in the lab. The value of 1.7 V across the LED was set such that the current through it was ~35 mA.
Rana and I took a few important PSDs (one of the DC supply, one of the OP27E with no supplied current, and two with the setup fully connected--one each with and without the PD covered), all from 250 mHz - 200 Hz, AC coupled. Using a sophisticated estimation method (called, by some, the "pick two points and approximate with a power law" method for lack of something fittingly elegant), we obtained a rough estimate of these spectral densities in order to compare them.
These were all converted into equivalent PD current noise. For all but the "supply" noise, this was done trivially by dividing by the transimpedance of the OP27E. For "supply", LED voltage noise had to be converted to PD current noise in the following way:
Z_LED = 1.7 V / 35 mA ~ 50 ohm
equivalent PD current noise = (I_PD / I_LED) * (measured supply voltage noise / 50 ohm)
where the PD-LED current ratio was found empirically to be (I_PD / I_LED) ~ 1 / 1000 by measuring the voltage out of the amp with full brightness (i.e. I_LED = 35 mA, no obstruction) and dividing by the transimpedance (see 2nd figure).
The third figure below is a plot of these spectral densities in common units. Somewhat expectedly, the noise of the "dark" configuration seems limited by the supply noise. However, the "bright" line seems to be dominated by something else. I'm not sure I see how it could be anything but the LED itself, but it is worthwhile to repeat this "test" with a better setup.
On the to-do list:
1. Voltage regulator/reference
Rana thinks that the AD587LN is a good choice of reference given its performance on some LISA tests. I am in contact with AD, and there is no longer a 'LN' package, but I am trying to get samples of the currently manufactured one that is most similar (AD587KNZ).
In the meantime, I am going to find some simple regulators downstairs or at the 40m.
2. Bandpass filter
I was advised that it is a good idea to build your own high/bandpass filter instead of relying on the spectrum analyzer's AC coupling function. I will be doing just this.
3. Switch to a better op amp
Like the AD743
I need to find a good way to hold the OSEM in place while I stick something in there with a micron drive without it being unreliably shaky.
We have LT1021-7 at the 40m, next to the Alberto's desk. This is the VREF for 7V.
In the meantime, I am going to find some simple regulators downstairs or at the 40m.
Tonight, I calibrated the AOSEM's response in [A/m]. I used a sophisticated rig consisting of:
1. One of those anodized Faraday isolator mounts to hold the OSEM
2. A translation stage with a screw gauge to jam something into it (gracefully)
3. Some DC power supplies and multimeters
4. My simple transimpedance amplifier sketched in the previous post (I did not bother upgrading the readout circuit for this measurement since I was just taking a relatively rough DC measurement)
I used a 9/64 hex key to simulate the shadowmaking magnet. A picture of the setup is attached below.
Some pertinent info:
- The current through the LED was maintained at 35 mA throughout the measurement. The measured voltage across it was 1.62 V, giving Z_LED = 46.3 ohm.
- The op amp supply voltage was +/- 10 V, and the PD bias was +10 V.
- The output voltage of the amplifier with the PD fully lit was 3.04 V (measured before and after the test). Note that this voltage increases slightly as the key is inserted due to reflections.
The second attachment is a plot of the photocurrent versus the position of the key (the x axis is shifted such that the key is roughly centered at x = 0, and x < 0 corresponds to the key being further inside). The response of the OSEM in the linear region is roughly 0.05 A/m.
Attached is the transfer function for the bandpass filter I built for the AOSEM readout. The schematic is primitively outlined below. The corner frequencies are what they should be (HP: 100 mHz, LP: 1 kHz)
The Johnson noise for the 1 k resistor is roughly 4 nV/rt(Hz). Frank says that it doesn't make sense to use much lower than 1 k if I'm putting it into an SR785.
10 uF 1 k
160 k > _|_ 160 nF
seems OK, as long as the current noise doesn't get you. To make sure you have to terminate the input to this filter and then look at the resulting noise in the SR785.
On Friday, Rana and I discovered that my transimpedance amp was oscillating like whoa at about 100 kHz. A little research showed this to be due to the input capacitance of the AD743 (~20 pF). To fix this, I put a 20-pF cap in parallel with the 100k feedback resistor, and that seemed to do the trick.
The relevant circuitry is shown in attachment 1. +/- 12 V DC was provided by voltage regulators (7912, 78M12). The voltage across the LED was measured to be V_LED = 1.61 V, and the current through it was I_LED = 31.6 mA, giving Z_LED = 50.9 ohm. The voltage out of the amp with a fully lit PD was V_out = -2.83 V, giving a photocurrent of I_ph = 28.3 uA.
I was concerned about noise that might be imposed by the bandpass filter, so I compared spectra I took with and without it (that is, AC coupled, no BPF, and DC coupled, with BPF). This comparison is shown in attachment 2. There appears to be no difference apart from the aliasing effects at low frequency.
After this, I took the real measurement, extending the range to 800 Hz, averaging 100x and with a linewidth of 1 Hz (I realize now that I should probably have done this with a smaller linewidth, so that I could see below ~1 Hz. I will repeat the measurement this week with better low-frequency resolution). The result can be seen in attachment 3, calibrated to displacement noise in m/rt(Hz) using the measured 0.05-A/m response of the OSEM in the linear region. The four lines are:
- Bright: noise in the OSEM with a fully lit PD
- Dark: noise in the OSEM with the LED off
- Amp: noise in the transimpedance amp with the input terminated
- V_LED: noise in the LED voltage
The first three spectra were taken at the output of the amplifier and calibrated back to meters using the transimpedance gain and OSEM response in A/m. The last was taken across the LED, and calibrated into meters using the values given in paragraph 2. All measurements were taken with the OSEM under a box and with the lights out.
It appears that we are still limited by our setup. The "Dark" noise is coincident with the amplifier noise, while the "Bright" noise is coincident with the LED noise. That said, it is fairly comforting that all this noise is at the level of around 10^-10 m or less, as we can probably expect the true noise of the OSEM to be lower than this. We will know this for sure once we have a truly quiet setup (starting with ultra-low-noise voltage references).
I was able to take some better measurements last night. I took data in two bands: 0-100 Hz, 0-1.6 kHz, each with 800 lines. This gives us a decent idea of what's going on at low and high frequency. Attached are four plots, two from each band. All measurements were taken with a box over both the OSEM and the readout circuit and the lights out.
The first two are low- and high- frequency comparisons of the noise in the full (bright) configuration as measured with no BPF and AC coupling vs with the BPF and DC coupling. There appears to be no difference apart from the expected effect above the pole at 1 kHz.
The next two are plots of the noise in various components and the full scheme calibrated into equivalent displacement noise. Everything is below ~10e-10 m/rt(Hz) with the exception of line peaks, and again it would appear that we are limited by our measurement equipment.
- The "dark" noise seems to be coincident with the "amp" noise with the exception of some extra pickup that increases at high frequency (seems to be line-related).
- The "LED" noise is coincident with the "supply" noise up until its 8-Hz corner frequency, after which it falls off as expected until it hits an apparent floor around 100 Hz.
- The "bright" noise seems to be coincident with the "supply" noise, while the "dark" and "amp" are much lower. This could be because the supply noise only shows up when there is an appreciable voltage at the output of the amp.
Have to think about this for a bit, but the next logical step is to turn the measurement setup into something solid (i.e. soldering, enclosure, etc.).
I got a few AD587KN (high-precision 10V reference) samples today from AD. I hooked them up to see how much quieter my DC supply would be. The results are pretty good, with the voltage noise reduced by a factor of 5-10 throughout. The first two attachments below are comparisons of the noise in
1. The +12V regulator (MC78M12) alone
2. The AD785KN reference with V_in = +12 V provided by the regulator
3. The same as in 2, only now with an additional "noise reduction" capacitor (a 1-uF capacitor from pin 8 to ground forms a LPF with an internal 4-k resistor, giving a corner frequency of 40 Hz to reduce high-frequency noise),
plotted with the same frequency ranges and settings as those in the previous post.
The reference comes very close to its noise spec of 100 nV/rt(Hz) @ 100 Hz. The only issue is that it seems to have much more line pickup than the regulator (which seems almost completely insensitive to line noise), and this is worsened by the extra capacitor. Attachment 3 is a close-up of the low-frequency spectrum around 60 Hz. I suspect that this will be alleviated somewhat when I move away from the breadboard phase.
I want to rig this up so that I can stabilize the supply voltage to the transimpedance amp and LED, but in order to do so I will need to build a higher-current source using a power transistor, like either of those shown in attachment 4 (the AD587LN is only able to provide <10mA).
Yesterday, I rebuilt Rana's low-noise LED driver in the Bridge elab. It is based on a 2nd-order active lowpass filter (using the Sallen-Key topology). The schematic is shown below. The circuit is essentially the same as the one Rana posted a few days ago, only the R and C values are all around twice what they are in his schematic. This results in the same corner frequency of fc = 0.03 Hz.
I hooked it up and measured Vsk,out = 9.76 V. I then used it to drive a 50-ohm resistor, and measured VLED = 1.71 V, then measured the current to be ILED = 33.5 mA.
After ensuring that it was supplying the correct voltage, I hooked it up to the LED and took a spectrum of the voltage noise across it over the two frequency bands I have been using in previous posts. The following are comparison plots of the noise here and the noise with the simple RC filter used before, calibrated to displacement noise.
RA: although these plots have Displacement in the y-axis, they are NOT measurements of actual displacement noise. They are estimates for the contribution to the displacement noise made by the LED RIN based on measurements of the voltage noise across the LED.
Something is clearly wrong: not only is the new configuration worse at lower frequencies, but the rolloff seems to go as 1/f and not 1/f2. Investigating after dinner...
OP27 current noise is too high - use AD743.
I retook the measurement from my last post, this time using an AD743 in place of the OP27 (per Rana's comment). The results are below.
RA: Although it says m/rHz, this is not measured displacement noise, but rather estimated displacement noise due to the LED noise. The previously measured conversion from the LED RIN to apparent displacement is used to convert from the voltage noise of the LED driver to the contribution to the OSEM's displacement readout.
Seems better than before, but not quite what expected. I observed that the transfer function of the S-K filter was what it should be up until a decade or two above the corner frequency, after which it appeared to spring zeroes out of nowhere and level off at high frequency. I tried to see what would happen if I changed the resistor values, and the following plot is what I got.
This plot seems familiar from my electronics courses, but I haven't put a finger on what is causing this behavior yet. I'm sure that the answer is somewhere in H&H (or in the brain of a kind soul who happens to be reading this--wink wink).
The low frequency noise looks pretty good now. The funny shape is most likely a thermal transient due to having not enough insulation. You need to droop some Kleenex over the circuit to stop the thermal air currents and then put a second box over the first box. Then its probably best to sit outside of the room when taking the measurement to reduce the human noise.
I tracked down some more AD743s at Wilson House 2.0 today (thanks to Rich). I was then able to simultaneously use 743s to both drive the LED and amplify the readout. Below is an 800-line DC - 25 Hz noise spectrum of
- The voltage across the LED (DC level: VLED = 1.59 V) -- AC coupled
- The output of the amp with a fully lit PD (DC level: Vout,full = -2.95 V) -- DC coupled, through bandpass filter
- The output of the amp with the LED out -- DC coupled, through bandpass filter
- The output of the amp with an open input -- DC coupled, through bandpass filter
all calibrated to equivalent displacement noise. For the LED plot, this was done by using the measured current ratio between the LED and the PD when fully lit along with the measured OSEM response of 0.05 A/m. The other three were converted using this response along with the transimpedance gain of the amp (100,000 V/A). For all measurements, the OSEM was covered by a box, and the circuit was draped with a cloth and put under a box within another box (to reduce air currents).
The funny low-frequency junk from the previous driver spectrum is gone--thanks to the isolation from air currents--but the line seems a bit higher overall (trying to figure out why). There also still seems to be the funny effect of noise added by the LED above the level of the voltage noise across it, and I think it's somewhat strange that the "Dark" noise is lower than the amp noise with no input. We can probably still do better..
This is the LISO estimate of the PD front end noise. It could be improved somewhat by using a higher value resistor, but there's no point.
The shot noise level for the 20-40 uA of current we have is more than 1 pA/rHz so we should be OK above 30 mHz.
So even the level of the dark noise below seems too high and also the 10,000 V/A statement. The feedback resistor we had used to be 100k...
10k was a typo--fixed.
I picked up the other AOSEM from the 40m today, so that I could compare it with the one I've measured in an attempt to get to the bottom of the noisy LED problem. It began uneventfully: I measured the impedance of the LED by connecting an ammeter in series and slowly increasing the voltage. I got ILED = 36 mA at about VLED = 1.7, giving ZLED ~ 47 ohms.
Then, I powered up the LED driver, and tested it with a 50-ohm resistor (as usual), measuring V ~ 1.7 across it. Having confirmed that everything was working properly, I hooked the LED up, and measured NO current. I hooked directly back up to the DC supply and found the same result. The thing appears to be blown, but I have no idea how. I went through every precaution I have been taking with the other OSEM, which worked fine when I switched it back in. Crap.
One thing I noticed before I hooked anything up was that the small white pieces attached to the LED and PD on either side of the OSEM opening were very loose when compared to the other OSEM. When I first measured no current, I tried applying some pressure to the LED side, and some current flowed across, but only about 1/10 of what it should have been.
EDIT: I have calibrated the y axis of the plot to meters
Last night, I got around to testing some of the other AOSEM samples, to see how the noise varied between them. What I found was rather strange: the noise in all the new ones (#s 2-6) was about the same, but they were all quite a bit noisier than the previous one I have been testing (#1). The only difference between them, as far as I can tell, is that the first specimen has a coil wound around it already, while the others just have a rubber band. Also, the newer ones all have an impedance of ~ 44-45 ohms, while I measured 47 ohms for the first (though, among the new ones, the slight variation in Z seems to have no correlation with the small differences in noise level). For those wondering, YES, I did remeasure the noise in the 1st one; I am not using old data.
Either my meddling with the old one has somehow made it quieter or something is amiss.
Norna and Rich: I am sorry for taking so long to get you this measurement. I plan to do the noise measurements on the standalone LEDs this week.
The following table gives the current through each OSEM's LED (measured using the voltage drop across the 238-ohm resistor in series), as well as the measured photocurrent (the DC output of the amplifier divided by its transimpedance gain of 100,000 V/A), and the ratio of the two. The plot from the previous post is reproduced below for analysis--I realized that I did still have this plot saved in units of V/rHz. In some cases (e.g. #3, #4), the noise level seems to be correlated to the photocurrent, but not all of them follow this pattern. The issue of #1 being significantly quieter than the other set remains, as well.
The Shaker project is coming along nicely. I am currently looking into using the built-in ability to download a waveform to the front end to do the sweeps, but we are running into memory problems, and I get the sense from Tony that it was not really designed to do this. Currently we are able to download a waveform to the frontend, run the generator according to it, and make a measurement over a full run of the waveform. If we can crack the limited time constraint and figure out the averaging, this is going to be the most straightforward solution.
I am working, in parallel, with Gert (who is out of the office at the moment) on using pure script to do this, although I am worried about starting and stopping the generator so frequently. Apart from anything else, there is a slight hang in the frontend when the generator start method is called; it is not noticeable when the button is pushed in the app, but I think it adds quite a bit of latency to the program. I am still waiting to hear from Gert about how to acquire a time series; hopefully we can figure that out by early next week, since it is critical. I am also not entirely sure how we force the program to do all the analysis on the time series after it is acquired. Ideally we would want the analysis to run in parallel and update the frontend continuously, but I am not sure this is possible with VBA (I don't think you can do multithreaded programming) and I am not sure I would know how to do so even if it is!
Engineering was very helpful showing me how to make the leads we need for the piezos; I will go crimp some more at the beginning of next week.
The new structures should be coming in soon, so we will have a dedicated structure for the piezo damping, at which point we can really get cracking.