40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  ATF eLog, Page 55 of 56  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  2318   Fri Mar 29 16:00:21 2019 awadeDailyProgressWOPORemeasuring TF Homodyne Photo Detector B after switching out foil cap

This set of measurments turned out to be bad. The OP27 (±15V supplies) with 50 Ω series at the output + 50 Ω load impedance seemed to be saturated.

The rest of this post is a stream of conciseness.

As noted in previous post (ATF:2316) the PD unit B in the homodyne had a slightly reduced HF response, possibly due to the use of a foil cap in the PD bias supply low pass.  I removed this and resmeasured.

Unit B TF: measured NF1611 DC voltage of  312 mV (@ 50Ω impedance), PD DC output voltage was - 566 mV (@ 50 Ω impedance).  Here the photodetector has transresistance is 6.8 kΩ. The NF1611 detectors have a DC path gain of 10 kΩ and an AC path gain of 700 Ω. From this the R_PC is xxx.  Here I ignore the overall phase (at ~1 MHz as the pi phase shift length is 150 m, so negligible).  This was a bad measurment, something was up with the circuit saturating way too low.  

Changed 100 Ω series on output to 50 Ω to make it more strait forward to understand how it works with 50 Ω load. 

Unit A TF: measured NF1611 DC voltage of  658 mV (@ 50Ω impedance), PD DC output voltage was 1.42 mV (@ 50 Ω impedance).  Here the photodetector has transresistance of 6.8 kΩ. The NF1611 detectors have a DC path gain of 10 kΩ and an AC path gain of 700 Ω. From this the R_PC is 0.3151.  Here I ignore the overall phase (at ~1 MHz as the pi phase shift length is 150 m, so negligible).  This measurment could have be saturating the current output of the OP27, likely that numbers here are not right.

After examining the output of detector B it became apparent that the output was saturated for powers of more than ~20 mA laser diode drive. 

Unit B TF: measured NF1611 DC voltage of  312 mV (@ 50Ω impedance), PD DC output voltage was -566 mV (@ 50 Ω impedance).  Here the photodetector has transresistance is 6.8 kΩ. The NF1611 detectors have a DC path gain of 10 kΩ and an AC path gain of 700 Ω. From this the R_PC is -0.3748.  Here I ignore the overall phase (at ~1 MHz as the pi phase shift length is 150 m, so negligible).   100 Ω  (50Ω + 50 Ω) loading is too low, OP27 open loop gain and voltage swing range slew starts to sag below 150Ω loading.  These results are bogus.

This time I measured with 50 Ω on the oscilloscope for apples-to-apples comparison with what the Aglient 4395A was seeing.  Turns out I think I was saturating the photodetector current wise in the first round of measurments. All of the above is probably not right and should be disregarded.  Also, later I switched to a AD829 as the op amp of choice so the above is not much use for characterizing the detector performance anymore.  The OP27 isn't really spec'ed to operate with loads this low and only has its full band with for output loads of >2 kΩ.  

  2324   Wed Apr 10 13:10:45 2019 awadeDailyProgressWOPORebuild of WOPO homodyne detectors using AD829

[awade]

This post details the rebuild I made of the transimpedance amplifiers (TIA) for the homodyne detectors.  My previous iteration of this design failed to take into account the output swing limitations and current draw limitations at the output of the op amp.  It turns out that the OP27 was not the best choice here.  On the face of it its GBP and input referred noise were fine for a ~ 1 MHz detection.  However, operating the chip with 5V output voltage (to get 10 dB shot noise clearance from thermal noise) and with output impedance on order of 150 Ω meant that the frequency response was not as expected (see ATF:2316). 

A better choice is something like AD829 which is designed for driving signals directly into 50Ω terminated outputs.  The updated design is illustrated below.

Here the transimpedance gain has been lowered to 2 kΩ to lower the relative input referred noise contributed by the AD829's slightly higher current noise.  Here the optical power can be increased to give the same effective output signal.  In this case increase optical power and lowering gain keeps the thermal noise clearance below shot noise constant but improves the clearance of the AD829 input current noise.

 

Scaling of thermal noise relative to shot noise given DC output voltage

For reference the thermal noise of the TIA is given by the Johnson noise

\delta n_\mathrm{thR} = \sqrt{\frac{4k_BT}{R_\textrm{fb}}}

where k_B is the  Boltzmann's constant, T is the temperature (300K) and Rfb is the feedback resistor value.  Also here the shot noise is

\delta n_\mathrm{SN} = \sqrt{2 e^- \mathcal{R}P_\textrm{PD}}

Where e is the charge on an electron (1.602e-19 C), R is the photodiode responsivity (~0.8 A/W), and P_PD is the power on the photodetectors (0.5-5 mW).  Keeping in mind that there is a maximum voltage swing (V_max) on the output of the op amp, this comes from its current driving capability into a given load, then the feedback resistance (TIA gain) is limited to 

R_\textrm{fb} = \frac{V_\textrm{Max}}{\mathcal{R} P_\textrm{PD}}

The noise clearance, given a maximum output voltage, is then given by the ratio

NR = \frac{\delta n_\mathrm{SN}}{\delta n_\mathrm{thR}} = \sqrt{\frac{e^-V_\textrm{Max}}{2kT}}

Power on the photodiode and responsivity cancel out for the noise clearance.  Assuming we are not optical power limited then the thermal noise ratio (clearance below shot noise) is wholly determined by V_Max and the physical constants e, k_B and T.  For room temperature (300 K) this reduces to the rule of thumb 

NR \sim 4.4 \sqrt{V_\textrm{Max}}

Keeping the V_max to within 3 V means that we will get a thermal noise clearance factor of 7.6 below shot noise (8.8 dB). V_max of 5.2 volts will give 10 dB clearance. Ok I guess. 

Choosing AD829

Koji suggested the AD829 as a replacement to OP27.  AD829 has applications in driving 50 Ω/75 Ω loads in video applications and has some nice noise characteristics.  The bottom line is that it has 1.7 nV/√Hz input voltage noise, 1.5 pA/√Hz input current noise, can do a ±3 V voltage swing into 150 Ω load (DC coupled), and is fast (600 MHz uncompensated, with 230 V/µs slew).  There are some quirks.  AD829 seems have have a weird 80 MHz feature that causes oscillations if not compensated properly.  I did a bit of modeling in LISO and then just decided to build it once I found that ~2 kΩ gain was about right for ensuring that the dark noise wasn't dominated by the op amp current noise.

Because I was building on proto-board I wanted to ensure that there was as little parasitic capacitance as possible.  I built the whole amplifier + PD onto a single SOIC-14 to 0.1 pitch adaptor (Adafruit SMT Breakout PCB for SOIC-14, Part No. 1210), pictured below.  The small footprint and short trace lengths between critical pins means that there is a lower chance of parasitic impedance causing instability or impact on bandwidth.  

Top view of Unit B TIA with PD mount soldered directly to inverting pin and positive bias
TIA at earlier stage of construction for both unit A and unit B
shows feedback resistor and capacitor soldered on reverse side (these passive
components are stacked on top of each other).

The feedback resistor (2 kΩ) and feedback compensating capacitor (15 pF ceramic + 3 pF nominal pin parasitic) were soldered directly to the reverse side where the TSSOP-14 pins were connected through vias to the top side.  This minimized the path length of this electrical signal.  I scratched off pads that were unused in case they shorted or were a source of crosstalk.  The photodiode mount pin was soldered directly to the edge of the board to minimize distance.  The power bypassing capacitors were SMT 100 nF ceramics (5%) that were soldered directly to the SMT breakout with the shortest path to ground on that board (see pictured).  The other photodiode pin was soldered to +5 V (-5V) supply pin in unit A (unit B).  The opposite biasing makes subtracting the signals using a summing circuit easier but may affect the overall TF response. There is no power regulation, I'm planning to use batteries to power these circuits.

In my initial tests I had no compensating capacitor attached to pin 5.  I inserted a 40 pF ceramic capacitor in place of the photodiode and looked at the AD829 output pin with a high impedance probe on an oscilloscope.  I immediately saw 80 MHz oscillations.  I don't really need a super high bandwidth so I went strait to the maximum recommended choice for pin5 compensating capacitor of 68 pF.  This makes AD829 unity gain stable with 66 MHz bandwidth (slew 16V/µs) but is more than enough for my needs.  This killed the high frequency RF ringing junk. Maybe less capacitance here would have worked, but this performance is enough for my needs and gives some certainty about the op amps stability (ignoring input capacitance compensation).

At the output I added 100 Ω of series resistance to limit the loading on the op amp and current draw when 50 Ω terminated.  With 50 Ω terminating impedance this makes a 150 Ω to ground.  Providing the output DC swing is kept within 3V the op amp should behave as expected.

The whole thing fits together very nicely on a single SMT breakout board. Making it compact will hopefully avoid any issues with stray capacitance messing up the performance.  I have then mounted this on a larger proto board for ease of installing in the experiment. Paths to the output SMA output are thin wire and not routed through the underlying board. Only power and ground is routed through the board, all other pins to the op amp disconnected. 

 

Transfer function PD

I measured the signal transfer function of the above TIA units using the Jenne rig at the 40 m.  It took me a number of tries: I made the mistake of loading the DC port of the NF 1611 detector with 50 ohms (which resulted in too much current draw and affected the LF response of the witness detector); there were also some issues with the polarization/positioning onto the beam splitter there that made it not 50:50 (it was 69:33 ), I moved the fiber launch a bit to get the splitting right and retook measurements after that; also I initially had the current set too high on the laser current driver which I think was saturating its response.  I'll skip over the details and just present the final measurement. I've included a zip in the attachments with the data that logs some more of the details of my failed attempts.

I used the same calibration as used in PSL:2247.  Here the laser diode current was set to 25.0 mA, which is 1.51 mW of 1064 nm, and the AC excitation into the laser was set to -21 dBm (19.9 mV rms).  Power on the witness detector was measured to be 0.79 mW and that on the PD under test was 0.75 mW (as measured with a power meter).  Units of measurement were linear magnitude and phase in degrees. DC voltages were measured with 1 MΩ impedance.

Unit A: using 25 mA current into laser and -21 dBm sweep I get DC on PD of 1.20 V (into 1 MΩ) and a DC voltage of NF1611 detector of -2.13 V (into 1 MΩ).

Unit B: using 25 mA current into laser and -21 dBm sweep I get DC on PD of 1.07 V (into 1 MΩ) and a DC voltage of NF1611 detector of -2.12 V (into 1 MΩ). 

The calibrated TIA current to voltage gain is plotted below:

A notebook detailing all the attempts is attached below.

 

 

Quote:

This set of measurments turned out to be bad. The OP27 (±15V supplies) with 50 Ω series at the output + 50 Ω load impedance seemed to be saturated.

Attachment 1: BasicSchematic_TranImpPD_AD829.pdf
BasicSchematic_TranImpPD_AD829.pdf
Attachment 4: WOPO_HDPD_AD829_2kohmTranImpGain_UnitAandBandLISO.pdf
WOPO_HDPD_AD829_2kohmTranImpGain_UnitAandBandLISO.pdf
Attachment 5: 20190405_TFHDPDs_AD829Design_LargeBoard.zip
  2327   Mon Apr 22 19:35:16 2019 anchal and awadeSummaryWOPOShot Noise Intercept Current measurement of Photodiodes

Andrew measured the output voltage noise of photodiodes through an AC coupled pre-amplifier (G=200, 0.7 nV/rtHz) while varying the intensity of white light falling on it. The setup uses a regular 2xAA flashlight (torch) with an incandescent bulb to illuminate the photodiode. The flashlight focus is adjusted to give a non-expanding beam and a 25.4 mm (1") lens is then used to focus the collimated beam down. The total power of light was controlled by trimming it with an iris.


Data Analysis:

Below is the fitting of data to estimate the shotnoise intercept current. Here the fitted function is the quadrature sum of input referred shot noise and dark noise modeled as an equivalent shot noise quanitiy i_snint (called intercept current):

i_\textrm{in} = \sqrt{2e^-(i_\textrm{pc}+i_\textrm{snint})}

I have included zip file with data and notebook in it as well. With measured shotnoise intercept current of 48 ± 7 uA and 31 ± 7 uA, we are good to go to use these for measuring shot noise with light power in the order of 5.0 mW falling on the photodiodes. With 5.0 mW (~3.9 mA) on each PD, this gives us a clearance of 10dB from the dark noise floor on average for each detector.  Plots with fits are attached below.

Attachment 2: WOPO_BHD_Photodiodes_SNInterceptAnalysis.pdf
WOPO_BHD_Photodiodes_SNInterceptAnalysis.pdf WOPO_BHD_Photodiodes_SNInterceptAnalysis.pdf
Attachment 3: 20190419_MeasuredInterceptCurve.zip
  2331   Tue Apr 30 19:52:14 2019 awadeHowtoWOPOConfiguring Zurich box server

As I couldn't find this on the 40m elog/wiki I'm putting notes here on how to configure a fresh webserver + python server for the Zurich box (model HF2LI) that runs an autobooting service job. 

The Zurich box (model HF2LI) has no front panel interface.  All controls are done from a USB interface to a host computer (running windows or Ubuntu/Debian).  This computer then hosts a web-server that runs an interface in a browser (through http) or responds to requests from python/matlab/labview/C API over the network.  

Installing data and webserver 

Set up on a Linux box is fast and easy from a fresh install.  A thin low powered computer is ideal. Start with a fresh install of Debian, use the latest stable release. Then download the latest stable release for the HF2LI, HF2IS, HF2PLL instruments from the Zurich downloads page.  You’ll probably want the 64bit linux. You can untar this file with

> tar xzvf LabOneLinux<arch>-<release>-<revision>.tar.gz

(Insert your filename details above)

Then cd into the directory it created and run

> sudo bash install.sh

It will ask a bunch of questions, just hit enter and y all the way through. The install should immediately boot the HF2 data server at the end.  You can check the data server is running with

> ziService status

Now plug in your Zurich box using the USB cable. Note: there are ethernet ports on the box, but these are NOT for network ethernet.  If the box is powered up the data server should find the box.  

Running the web server

In another terminal you’ll want to to start a Webserver so you can view the box status, settings and live data.  Go to another terminal and run

> ziWebServer

Your Zurich device should now be exposed on port 8006 of that machine.  You are read to go.

Now on that computer you can got to http://localhost:8006, alternatively on any other computer on the network you can go to the host machine’s IP address and see your Zurich interface.  I.e. if the computer IP is 192.168.1.121 then go to http://192.168.1.128:8006.  

Remote access

If you wanted to access the Zurich interface remotely (outside network) you can do some SSH forwarding if you have a gateway machine to outside the lab.  The standard command for this is 

> ssh -nNT -L <clientport>:localhost:<hostport> <controls>@<Host-IP-Address>

where controls is the username, Host-IP-Address is the IP address of the machine to be forwarded from, clientport is the port on your machine (the one you are ssh'ing from) and hostport is the port on the remote machine (for Zurich this is 8006).  Then when you go to http://localhost:<clientport> and you'll see Zurich interface.

Python API

Since the release 2.18 (Nov 2018) the python access tools are now just in Pypi.  You can install them with pip:

> pip install --upgrade zhinst

This should now allow you to use python API to access your Zurich box.

 

Setting up service to keep host alive from when box is booted

You’ll want to set up a service on your Debian box with systemd.  Make a unit

> cd /etc/systemd/system

> sudo vim ziServer.service

You must use sudo to be able to save the file here.

Paste the following in, this assumes that your username and its group is called controls on your machine:

[Unit]
Description=Zurich Instruments HF2LI data server
After=syslog.target network.target

[Service]
User=controls
Group=controls
WorkingDirectory=/home/controls/services/
ExecStart=/bin/bash -c "exec ziServer"
Restart=no
RestartSec=30

[Install]
WantedBy=multi-user.target


Tip: in vim you can type “:set paste” to get exact paste without auto indent etc.

Save the file and exit.  You'll also need to create the working director, or change the above to your desired directory

> mkdir /home/controls/services/

Finally, tell systemd to look for new things:

> systemctl daemon-reload

and enable the service,

> systemctl enable ziServer.service

and manually start the service,

> systemctl start myservice.service

It should be running, try to see if this is so:

> ps | grep ziServer

It should run on reboot of the machine and restart every 30 seconds if it crashes for whatever reason. Try rebooting the host machine to check it is still running

Configuring web-server service

Follow the above steps to also auto load the webserver with a unit file named /etc/systemd/system/ziWebServer.service:

[Unit]
Description=Zurich Instruments HF2LI web server
After=syslog.target network.target

[Service]
User=controls
Group=controls
WorkingDirectory=/home/controls/services/
ExecStart=/bin/bash -c "exec ziWebServer"
Restart=no
RestartSec=30

[Install]
WantedBy=multi-user.target

 Now you have a local network ready server for accessing the Zurich box through a web browser.

  2332   Wed May 1 14:34:53 2019 awadeDailyProgressWOPOOutput chain and demodulation of squeezing signal

The detectors have been verified to have a low intercept current, that will give us good clearance of our shot noise to dark noise (at least as measured in the <100 kHz band).  The question is if we can make a ~ 1 Mhz measurement of squeezing without extra noise in that readout chain dominating over our expected 1 dB squeezing.

The plan is to use the Zurich box (model HF2LI) to mix down quantum enhancement from 1 MHz in our homodyne detector.  This will be well above most of the classical noise of the laser and other acoustic pickup from the environment.  

The Zurich box has a input referred noise of 5 nV/rtHz above 10 kHz and operating at at the higher end of its sampling rate. It has a couple of nice features that would make it well suited to the task.  We can use the lock in amplifier instrument to digitally mix down signal from 1 MHz and output one or both of the i/q quadratures to its digital output ports.  From this instrument we can also set the bandwidth of the 

Output noise of Zurich is 25 nV/rtHz, so I'll need some gain factor to boost signal if readout is done from the external ports. Relative gain of the two paths can be changed manually by typing values into boxes, but might be tought to do a direct ballenced subtraction within the box live if the real time drift is large.

 

Laser diode modulation port on Diabolo has a signal bandwidth of 5 kHz, so can't really be used to generate a reference signal.  

  2345   Thu May 16 16:52:46 2019 awadeHowtoWOPOZurich box python access

The Zurich box can also be accessed via a python API.  Its a little bit opaque in some points on how this works as their documentation is a little thin on actual examples.  I've included a jupyter notebook and equivalent .py file for future reference.  This code is tested and has worked with the Zurich box data server at IP address 10.0.1.23.  It shows exactly how settings can be modified and how data can be read back using their poll command.

Notebook includes all instructions for setting the Zurich HF2LI box up from scratch. 

 

Attachment 1: ZurichPythonAccess_MWE.zip
  2349   Wed May 22 15:07:09 2019 awadeDailyProgressWOPODemodulation and subtraction for homodyne detector with Zurich box

For the detection of squeezed light the homodyne detector  is now configured for digital subtraction in post processing. The measurement scheme is now to take the output of the two TIA amplifiers (see QIL:2324 and QIL:2327), digitize​ them directly at 210 MSa/s (5 nV/rtHz input ref noise) with the Zurich box and demodulate both detector streams using its internal FPGA at about 1 MHz.  The Zurich box allows for direct sampling of the signal out of the FPGA which can then be downloaded either through the web interface or the python API. The signal chain is illustrated below:

Whiteboard illustration of WOPO HD detector chain
WOPO homodyne detection chain (see attachments at bottom for high resolution)

The basic approach is to mix down the shot noise limited light from some higher frequency (somewhere in the range 100kHz - 8 MHz) and then compute the ideal subtraction factor from a short (10 sec) segment of data.  The method for optimization is to compute the time domain subtracted signal for a given balancing factor (SF) and compute the goodness of subtraction from the RMS of the signal.  An fmin search is done to find the ideal subtraction factor (SF) for shot noise limited light.

It wasn't immediately clear to me what demodulation​ frequency to choose, the low pass filter and the digitization sampling rate. So I set up a python notebook and did a few sweeps of these parameters to find the best combination of parameters. This book is attached below as 20190514notebook_ZurichDemodeCompairTests.ipynb in a zip. I've pickled data for replotting if needed later.  

Sweeping the demodulator 4th order LP corner frequency

At present the detectors are illuminated with 4.5 mA worth of light (as measured from DC voltages / TI gain).  This should give about 25 nV/rtHz at the output of the photodetector, as measured by the Zurich box.  Fixing the demodulation frequency at 500 kHz and the sampling rate at 30 kHz I found empirically that the when the LP filter (4th order) was kept at 10 kHz and below the minimum subtracted signal converged to about 30 nV/rtHz (about what I expected).  With the demodulation frequency set much higher than this, the minimum subtracted signal no longer converged to the predicted SN level.  Maybe there is some aliasing thing going on here.  The outcome of this experiment is that clearly the demodulation LP filter should be set to at least 1/3 of the sampling rate for the time domain rms minimization to work.  

Selection of sampling frequency

I did a similar sweep with the sampling rate while keeping the demodulation frequency fixed at 500 kHz and the demodulation low pass fixed at 10 kHz.  The conclusion was basically the same: as long as the demodulator low pass was kept within 1/3 of the sampling frequency then the method of computing the ideal subtraction factor using the total time domain rms as a cost function returned the minimum possible differential noise.

Selection of demodulation frequency

The demodulation frequency choice is a tricker one.  Initially I selected 1 MHz but was getting excess noise above what I expected for shot noise. I then looked at a single channel on the Zurich's scope in FFT mode.  Data is plotted below

Basically the plot shows that there is a strong peak at about 900 kHz. This is due to the relaxation oscillation of the laser.  When the laser's noise eater is turned on this peak is damped with some tradeoff of slightly higher noise at lower frequencies. So when choosing a demodulation frequency it is best to select something well below 1 MHz. I'm not sure if it is best to turn the noise eater off if the demodulation frequency is set well clear of the 900 kHz peak.  It seems like there is a noise penalty for the noise eater loop at all other frequencies. 

With the noise eater on I then did a sweep of the demodulation frequency while keeping the low pass filter at 10 kHz and the sampling rate at 30 kSa/s.  I've plotted the median ASD value in the band between 100 Hz and 1 kHz as an indication of the minimum SN level after digital subtraction verses the demodulation frequency.  Plot below.  There is a hump at about 1 MHz that should be avoided, and spikes at 87 kHz and just below 300 kHz but anything else in the range of 100 kHz to 700 kHz should be fine.  

Current selected configuration

So for now, based on the above sweeps of parameters, I have selected demodulation frequency of 600 kHz that is low passed at 10 kHz with a 4th order filter and sampled at 30 kSa/s.  As an example of optimized subtraction I have plotted the two homodyne channels along with the subtracted differential signal (optimized by minimizing subtracted time domain rms) and the dark noise (using the same subtraction value).

Here the clearance from the dark noise floor doesn't seem so great.  The input referred noise of the Zuirch box is 5 nV/rtHz per channel.  Also the equivalent output noise from the PDs at this point is 2.5 nV/rtHz.  As these are uncorrelated noise processes this would place the noise floor at about sqrt(5^2*2+2.5^2*2) = 7.9 nv/rtHz, pretty close to what we are actually seeing. 

One option here is to pre-amplify the PDs before going into the zurich box.  A standard mini-circuits amplifier like ZFL-500LN+ has an input referred noise of 1.6 nV/rtHz which would bring the dark noise floor down to something closer to 4.2 nV/rtHz.  I'll keep going without any pre-pre-amplification for now and see what I can do with 532 nm pumping.  There should be enough clearance to see at least something if it is there.

 

 

Attachment 2: Sweep_DemodLPFValues.pdf
Sweep_DemodLPFValues.pdf
Attachment 3: SingleHDChannel_RelaxOscillations_CompairNoiseEaterONOFF.pdf
SingleHDChannel_RelaxOscillations_CompairNoiseEaterONOFF.pdf
Attachment 4: DemodFreqSweep_median100Hzto1kHz_vsdemodFreq.pdf
DemodFreqSweep_median100Hzto1kHz_vsdemodFreq.pdf
Attachment 5: CompairSubtractedSignalToDarkNoise.pdf
CompairSubtractedSignalToDarkNoise.pdf
  2352   Thu May 23 15:29:58 2019 awadeDailyProgressWOPOMaking time domain measurement of noise power in homoydne with WOPO pump on

In order to see squeezing I want to scan the phase of the homodyne relative to the squeezed light and see the variations in noise power as a function of time. 

Excess 532 nm dumped on detector A

From my initial scans it seems like there is excess noise of a factor of 1.5 above shot noise (see below).  This is only present with 532 nm pump injected. It could be anit-squeezing washing out with some phase noise bluring across the sample time of 0.1 seconds or maybe RIN from residual 532 nm present at one of the photo detectors.

After injecting light into the WOPO for some initial tests it was apparent that there was about 1.4 mW of waste 532 nm light exiting the fiber launch on the detector A path. About 16 µW gets through to the detector from the dichroic mirror reflection. A quick measurement of 532 nm power on detector B show that there was about 49 µW coming out of that fiber end with 0.2 µW making to the photodiode. The 50:50 splitting doesn't apply for non-design spec wavelengths of fiber splitter.   The InGaAs detectors have a pretty poor responsivity at this wavelength but the pumping light on detector A was enough to create a DC voltage of 1.36 mV. After dividing through by detector gain of 2kΩ this is equivalent to about 0.68 µA of DC power on the detector A.  This suggests a responsivity of order 0.014 A/W.  There isn't enough light on detector B to create any DC voltage. 

The imbalance here, with the 532 nm light, means that there is a mechanism for coupling in 532 nm RIN into the measured output signal.  Not sure if the RIN would be all that high at the 600 kHz (that I'm planning to mix down from) but it would be a good idea to remove it anyway.  I'll look for a another HR1064/HT532 dicroic mirror to attenuate this 532 nm component a little more.

 

 

Quote:

For the detection of squeezed light the homodyne detector  is now configured for digital subtraction in post processing. The measurement scheme is now to take the output of the two TIA amplifiers (see QIL:2324 and QIL:2327), digitize​ them directly at 210 MSa/s (5 nV/rtHz input ref noise) with the Zurich box and demodulate both detector streams using its internal FPGA at about 1 MHz.  The Zurich box allows for direct sampling of the signal out of the FPGA which can then be downloaded either through the web interface or the python API. T

Attachment 1: RMSFunctionTimeCompairingSNWithInjected532nmpump.pdf
RMSFunctionTimeCompairingSNWithInjected532nmpump.pdf
  2354   Sun May 26 21:24:38 2019 awadeDailyProgressWOPOExcess noise when pumping: checklist for Monday.

There are a few other possibilities for the excess noise when injecting pump, this is a checklist for me to run through tomorrow:

  1. Its possible that the waste pump light from the 532 nm is heating the fiber beam splitter a bit.  This might cause imbalance when I go to measure the noise level for pumped WOPO.  I checked both channels detector on the oscilloscope with 532 nm turned on and off.  I couldn't discern a change in the balancing​.  I will need to look closer tomorrow with the actual zurich demodulated data.  Task for tomorrow is to compare the BS balancing with 532 nm on and off.  This can be done by tuning the WOPO temperature down by 15 C (to put it outside the phase matching region) and running the SN measurement with 532 nm on and off;
  2. The excess wasted 532 nm my also be locally heating the SPDC chip, so the ideal phase matching temperature might not be right.  I will try a series of temperature steps much smaller than the FWHM of the phase matching sinc curve and see if turning the temperature down/up makes a difference;
  3. Check the scanning of the 532 nm PZT is actually working.  Loop the patch cable back to the launch of the light into the fiber and use some of the dumped light from the 532 nm power control to make an interference measurement.  Here a large fringe visibility is not super important.  Just need to be able to count fringes/volt;
  4. Need to verify how much light is making it into the WOPO.  This is difficult to do directly.  But a quick check is to see how much is making it out the other side.  The PM 1064 nm fiber should carry the 532 nm pump light out the other side of the WOPO without too much loss.  Check with power meter how much 532 nm is coming out other end of WOPO;
  5. Need to document the level of power fluctuations of the 1064 nm LO light in the homodyne.  This could be leading to the fluctuating power level that is present after upping the demodulation band width and boxcar window.  If this is an issue I need to figure out quickly how to up the noise band width so that the boxcar window can be made very small and data capture is faster that the power varations of the 1064 nm.  If we had some DC monitor we might be able to correct this out in post processing;
  6. I could just be smearing anti squeezing over both measurement quadratures.  Need to check my measurement sweep times and confirm my boxcar window for scanning noise as a function of time is narrow enough;
  7. Consider if adding some minicircuits pre-amps before zurich would make measurment of SN -> SQZ clearance clearer.
Quote:

In order to see squeezing I want to scan the phase of the homodyne relative to the squeezed light and see the variations in noise power as a function of time. 

Excess 532 nm dumped on detector A

From my initial scans it seems like there is excess noise of a factor of 1.5 above shot noise (see below).  This is only present with 532 nm pump injected. It could be anit-squeezing washing out with some phase noise bluring across the sample time of 0.1 seconds or maybe RIN from residual 532 nm present at one of the photo detectors.

After injecting light into the WOPO for some initial tests it was apparent that there was about 1.4 mW of waste 532 nm light exiting the fiber launch on the detector A path. About 16 µW gets through to the detector from the dichroic mirror reflection. A quick measurement of 532 nm power on detector B show that there was about 49 µW coming out of that fiber end with 0.2 µW making to the photodiode. The 50:50 splitting doesn't apply for non-design spec wavelengths of fiber splitter.   The InGaAs detectors have a pretty poor responsivity at this wavelength but the pumping light on detector A was enough to create a DC voltage of 1.36 mV. After dividing through by detector gain of 2kΩ this is equivalent to about 0.68 µA of DC power on the detector A.  This suggests a responsivity of order 0.014 A/W.  There isn't enough light on detector B to create any DC voltage. 

The imbalance here, with the 532 nm light, means that there is a mechanism for coupling in 532 nm RIN into the measured output signal.  Not sure if the RIN would be all that high at the 600 kHz (that I'm planning to mix down from) but it would be a good idea to remove it anyway.  I'll look for a another HR1064/HT532 dicroic mirror to attenuate this 532 nm component a little more.

 

 

Quote:

For the detection of squeezed light the homodyne detector  is now configured for digital subtraction in post processing. The measurement scheme is now to take the output of the two TIA amplifiers (see QIL:2324 and QIL:2327), digitize​ them directly at 210 MSa/s (5 nV/rtHz input ref noise) with the Zurich box and demodulate both detector streams using its internal FPGA at about 1 MHz.  The Zurich box allows for direct sampling of the signal out of the FPGA which can then be downloaded either through the web interface or the python API. T

 

  2356   Wed May 29 15:24:33 2019 awadeDailyProgressWOPOUpdate to checklist

I had a look at a few of these things.  I've found that it doesn't seem to be caused by heating of the beam splitter, while turning 532 nm on an off I see no change in the balancing of the beam splitter.  It appears that on remeasuring the data on Tuesday I found that there had been some glitching of the digitized data readout.  

Suspicions for now is that there is not as much pumping light making it to the chip as a thought and that bandwidth resolution of the time scan scan was a little too wide.  I have shortened the scan, increased the noise bandwidth of the demodulation and will widen the width of the low pass filter on the noise-time scan to increase the time resolution.

I'm also implementing proper subtraction of the signal that uses both the I and Q quadratures so that all the information about the relative phase and amplitude of the digitized signals is properly mixed down by the FPGA inside the Zurich.

Notebook with demo of the subtraction is attached in a zip below.

Quote:

There are a few other possibilities for the excess noise when injecting pump, this is a checklist for me to run through tomorrow:

  1. Its possible that the waste pump light from the 532 nm is heating the fiber beam splitter a bit.  This might cause imbalance when I go to measure the noise level for pumped WOPO.  I checked both channels detector on the oscilloscope with 532 nm turned on and off.  I couldn't discern a change in the balancing​.  I will need to look closer tomorrow with the actual zurich demodulated data.  Task for tomorrow is to compare the BS balancing with 532 nm on and off.  This can be done by tuning the WOPO temperature down by 15 C (to put it outside the phase matching region) and running the SN measurement with 532 nm on and off;  Doesn't appear to be true I don't see any change in ballencing once I looks more carefully with 532 nm pumping on and off.
  2. The excess wasted 532 nm my also be locally heating the SPDC chip, so the ideal phase matching temperature might not be right.  I will try a series of temperature steps much smaller than the FWHM of the phase matching sinc curve and see if turning the temperature down/up makes a difference; I stepped through temperatures from the ideal set point of 60.99 C down to 58.00 C I saw some possible anti-squeezing peaking at 60.30C but was unable to reproduce this result.  I'll try again once I've implemented the quadrature subtraction in python dict form.
  3. Check the scanning of the 532 nm PZT is actually working.  Loop the patch cable back to the launch of the light into the fiber and use some of the dumped light from the 532 nm power control to make an interference measurement.  Here a large fringe visibility is not super important.  Just need to be able to count fringes/volt;
  4. Need to verify how much light is making it into the WOPO.  This is difficult to do directly.  But a quick check is to see how much is making it out the other side.  The PM 1064 nm fiber should carry the 532 nm pump light out the other side of the WOPO without too much loss.  Check with power meter how much 532 nm is coming out other end of WOPO;  I see 21 mW at the output of the patch cable.  There is visibly a lot of waste light exiting the fiber through the cladding.  Its not clear how much is being lost.  It looks bright to the eyes but that doesn't mean its all getting lost there.
  5. Need to document the level of power fluctuations of the 1064 nm LO light in the homodyne.  This could be leading to the fluctuating power level that is present after upping the demodulation band width and boxcar window.  If this is an issue I need to figure out quickly how to up the noise band width so that the boxcar window can be made very small and data capture is faster that the power variations of the 1064 nm.  If we had some DC monitor we might be able to correct this out in post processing;
  6. I could just be smearing anti squeezing over both measurement quadratures.  Need to check my measurement sweep times and confirm my boxcar window for scanning noise as a function of time is narrow enough;  I'm fixing this with the update to quadrature subtraction, widening demodulation noise bandwidth and implementing proper LP scipy.signal.filtfilt filtering instead of the bad box car method.
  7. Consider if adding some minicircuits pre-amps before zurich would make measurment of SN -> SQZ clearance clearer. Adding pre-amps is still a good idea, just not absolutely necessary at this point

 

Attachment 1: 20190528_ProperIQReconstructionAndLPFilteringData.zip
  2723   Tue Feb 22 07:53:06 2022 YehonathanUpdateWOPOWaking up WOPO

{Shruti, Yehonathan}

On Friday, we came down to QIL to poke around the WOPO setup. The first thing we noticed is that the setup on the wiki page is obsolete and in reality, the 532nm light is coming directly from the Diablo module.

There were no laser goggles for 532nm so we turned on the 1064nm (Mephisto) only. The pump diode current was ramped to 1A. We put a power meter in front of Mephisto and opened the shutter. Rotating the HWP we got 39mW. We dialed it back so that 5mW is coming out of the polarizer.

The beam block was removed. We disconnected the LO fiber end from the fiber BS - there is light coming out! we connected a power meter to the fiber end using an FC/PC Fiber Adapter Plate. The power read 0.7mW. By aligning the beam into the LO fiber we got up to 3.3mW.

We connected the BHD PDs to the scope on the table to observe the subtraction signal. Channel 2 was negative so we looked at the sum channel.

Time ran out. We ramped down the diode current and turned off Mephisto.

Next time we should figure out the dark current of the BHD and work toward observing the shot noise of the LO.

  2725   Fri Feb 25 17:09:53 2022 shrutiUpdateWOPOWaking up WOPO - green beam

[shruti, yehonathan]

SHG and 532 nm beam alignment

Yehonathan brought over 532nm/1064nm laser goggles from the 40m.

  • We turned on the 1064 nm Mephisto, and set the pump current initially to 1.5 A (which gave us ~30 mW of output)
  • We then turned on the doubling crystal. It took a while to reach its setpoint temperature of 110 C. Initially (without adjusting the SHG cavity parameters) we saw less than a microW of power after removing the beam block and opening the shutter.
  • Playing around with the SHG cavity settings, we realized that
    • Setting the switch to "Auto" is how to nominally operate the 532 nm beam
    • "Scan" is useful for scanning the cavity, the amplitude of which can be controlled by the "Scan amplitude" knob. "Standby" seems to effectively turn off second harmonic generation
    • "Offset" knob tends to change the amount of green power generated and adjusting the "Gain" simultaneously helps stabilize this power (with some difficulty)
  • On increasing the laser driver current to 2 A and adjusting the temperature setpoint to 109.7 C, we were able to see 100 mW of green power!
  • Next, we played with the alignment into the fiber, seeing that initially there was barely any power at the other end of that patch cable
    • We adjusted the waveplate near the laser head to give us 5.3 mW of power right before coupling into the fiber
    • Adjusting a single mirror (the nearer one) did not result in much gain, so we simultaneously adjusted the two steering mirrors and achieved about a 50% coupling. (Our readings suggested it could be the max)
    • At  the end of the alignment: 2.74 mW at the output and 5.46 at the fiber input
  • Reconnecting the fiber to the waveguide, without adjusting the temperature of the advr waveguide, we saw that the fiber at the output of this crystal seemed to glow.
    • The power measured at the end of the output fiber (fiber after the waveguide) was 0.6 mW. Not entirely sure what the contribution of loss was in the decrease from 2.74 mW through the waveguide.
  • The laser is still ON although the shutters to the green and IR paths are closed. Safety glasses required before opening shutters.

 

Questions about the setup

  1. The spec sheet on the wiki mentioned PM980 and PM480 input and output fibers, respectively for the waveguide operating as an SHG, what were being used instead were P3-1064PM-FC2 and P3-488PM-FC2. Is this a significant source of loss that can be easily remedied?
  2. Yehonathan mentioned that stimulated Brilluoin scattering occurs in all fibers above a threshold. What is the threshold for the the ones used in the setup? We probably want to operate below this threshold.

 

Our next step would be to measure the LO shot noise.

 

 

 

  2727   Wed Mar 2 14:38:55 2022 YehonathanUpdateWOPOWaking up WOPO - some more fiddling and a plan

{Shruti, Yehonathan}

We made some a list of some random questions and plans for the future. We then went down and found answers to some of those:

1. Why is there no Faraday isolator in the 1064nm beam path? (edit: turns out there is, but inside the laser, see pictures in this elog).

2. Do the fibers joined by butt-coupling have similar mode field diameter? If not it can explain many loss issues.

a. In the green path we find that according to the SPDC datasheet the 532nm fiber (coastalcon PM480) is 4um while the input thorlabs fiber (P3-488PM-FC2) coupled to it has an MFD of 3.3um. This mismatch gives maximum coupling efficiency of 96%. Ok not a big issue.

b. At the 1064nm output the SPDC fiber is PM980 with MFD of 6.6um while the BS fiber is 6.2um which is good.

3. What is the green fiber laser damage threshold? According to Thorlabs it is theoretically 1MW/cm^2 practically 250kW/cm^2 for glass air interface. With 3.3um MFD the theoretical damage threshold is ~ 80mW and practically  ~ 20mW. It doesn't sounds like a lot. More so given that we could only get 50% coupling efficiency. How much is needed for observable squeezing? There is the possibility to splice the fiber to an end cap to increase power handling capabilities if needed.

4. Is stimulated Brillouin back scattering relevant in our experiment? According to this rp photonics article not really.

5. How much green light is left after the dichroic mirrors? Is it below the shot noise level? Should check later.

In addition, we found that the green fiber input and the 1064nm fiber output from the SPDC were very dirty! We cleaned them with a Thorlabs universal fiber connector cleaner.

 

 

 

 

  2728   Fri Mar 4 11:49:45 2022 shrutiUpdateWOPOWaking up WOPO - attempts at readout

[Yehonathan, Shruti]

1. Doubling cavity and green beam

Since we had left the lasers ON with the shutters closed we wanted to see if the powers measured after opening the shutter would be similar to what it was when we left. We realized that opening and closing the green shutter destabilizes the doubling cavity (the FI is after the shutter and the shutter does not seem to be a good dump), which in turn changes the SHG crystal temperature (possibly because of the power fluctuation within the crystal). Re-opening the shutter requires some tuning of the temperature and offset to recover similar output power. Finally, after some tuning, we were able to see 156 mW of green light.

 

2. Attempt at measuring LO shot noise

  • We want to measure the BHD output A-B channel, which we expect to be dominated by shot noise since all the classical noise would be canceled when optimally balanced, but found that one of the PDs was inverted so that the sum of the two channels would be what we needed to measure. Since the SR 560 has only an A-B option, we used a second SR 560 to invert the B channel before subtracting
  • Operating at an LO power of ~4 mW did not give us sufficient clearance from the dark noise in each channel with the SR 560s, which was around the max power I believe we're supposed to use for the BHD LO
  • Somehow measuring the output directly, without the SR 560, gave us some clearance over the dark noise at ~1 MHz and higher (possibly because 1 MHz is the SR560's BW) so we decided to measure the time series of both channels together and do the optimized subtraction and FFT offline

3. Subtracted noise signal spectra [Attachment 1]

  • The plots show the noise spectra of the channels measured individually. The 'gain adjusted' means that A was multiplied by 1.05 and B by 0.95 in order to get the two plots to more or less line up
  • We used the Moku to measure the timeseries at a sampling rate of 10.2 MS/s for a period of 1.2 ms with AC coupling and 50 Ohm impedance. Elog 2324 suggests the designed measurement was for a 50 Ohm load so we should be impedance matched but I'm yet to convince myself
  • Our estimate for the shot noise was 77 nV/rtHz for 4 mW of power and 87% QE, using a TI gain of 2kOhm (the black dashed line in the plot). If we were impedance matched the yellow trace must be higher than this estimate
  • In our next measurements, we will also record the dark noise, carefully measure the power. There is obviously sonething wrong with the plot

 

 

30 Mar 22 edit: script here, data here

Attachment 1: LO_shot_noise.pdf
LO_shot_noise.pdf
  2731   Thu Mar 10 17:12:01 2022 awadeUpdateWOPOWaking up WOPO - attempts at readout

[awade]

Good to see this experiment being revived.

1. The design of this laser had a number of flaws and one of them is this sensitivity to backreflections at 532 nm. I mostly just disabled the doubler's lock and closed the shutter for good measure, but probably best not to leave flickering around in an unstable state when you're away.

2. I built in the inversion in the second channel to give myself the option to electronically subtract: something that didn't end up being very practical compared to just digitally recording channels and subtracting in post.

  • I'm surprized the SR560 don't given you clearance there.  Nominally these units are 4 nV/rtHz if you operate in low noise mode AND gain=100 (see p21 of the manual), below this gain gives you 10-60 nV/rtHz noise. When I built the PD circuits I did verify that I was getting the clearanceI expected.  At 1 mW on each photodiode one would expect order =sqrt(2*h*c/lambda0*Responisvity*Power)*Gain ~ sqrt(2*6.626e-34*3e8/1064e-9*1e-3*0.7)*2e3 = 32 nV/rtHz.  
  • A few things to verify:
    • check the DC voltage (just with a multimeter) to see true power picked up by diodes, this should be 1.4 V for about 1 mW of 1064 nm;
    • Make sure you're AC coupled into SR560, there is no way you operate at gain 100 or above and also not saturate for 1 mW (~1.4 V amp output DC) of light
    • at 2kΩ gain you should expect the noise floor to be of order =sqrt(4*kB*T*G)=sqrt(4*1.38e-23*300*2e3)~5.8 nV.  Only just clear of the SR560 spec, and about equal to typical actual performance.  To see this level you might want to pre-amplify with a Femto amplifier, the 40m Busby box or the ganged amplifier box I made for the CTN lab (its black with gold writing, Anchal knows the one). A dark measrument like this may have a little offset that you can either null or just AC couple with a minicircuits DC block;
    • Take a terminated (50 Ω) measurment of your ADCs when you collect your PD 'dark' data. Even better also collect terminated SR560 data. And put these on the plot.  Moku:Labs have ~30 nV/rtHz @100 kHz and above.  Just be sure you're measure photodetectors and not Pre-amp or ADC noise. Moku nominal input refered noise is 13.9 nV/rtHz * sqrt(1+220kHz/f).
    • If you can't get any quick progress, try all the above with minicircuits lower noise amplifiers.  They have plenty of bandwidth and go to higher frequencies.
  • Just measureing the output of the PD directly, with no subtraction or amplification, I'd say you are looking at laser technical noise at about 1 MHz: this is what the subtraction is for, to null the LO noise effects to only listen to signal port.  Maybe somethings burried in the subtracted signal offline, but you need some simultaneous termianated measurements back long the signal chain to put some bonds on what is the limiting noise here.

3. Subtracted noise spectra

  • These gain numbers sound right to me.
  • The AD829 is designed to drive this combined 150 Ω load, I would stick to 50 Ω terminations for now. On the topic of mokus: again verify its input referred noise and pre-amplify accordingly.  Also there is a choice of "Normal" or "Precision" acquisition mode, I think the right choice is precision (this should have the right filters to kill aliasing from the downsampling)
  • ~70 nV/rtHz shot noise sound about right to me.  Not clear why a subtracted signal doesn't seem to reach this.  Once again, measure the actual DC voltage output from the TIA to get the true absorbed photons and use that to calibrate your estimate.  

We should chat some time on zoom about more details (rana can forward my details).  Hope this enought to go on for at least the homodyne part of the experiment.  

  2733   Wed Mar 16 12:22:44 2022 YehonathanUpdateWOPOWaking up WOPO - attempts at readout

{Shruti, Yehonathan}

Yesterday, we measured a bunch of noises.

We wanted to have as reference the Moku noise, the PDs noise, and measure the shot noise of the LO again.

Attachment 1 shows the Moku noise measured by just taking data with no signal coming in. We tried both the spectrum analyzer (SA) and the oscilloscope tools, with and without averaging, and the difference between the channels.

For some reason, the SA has a worse noise figure than the oscilloscope and the difference channel doesn't give us any special common-mode rejection. Also more averaging doesn't help much because we are already taking 1.2ms of data which is way longer than 1/RBW=0.2ms we are taking here.

From now on we use the oscilloscope as the spectrum analyzer and to its noise we refer as the Moku noise floor.

Moving on, we try to measure the PD dark noise. Given that the PD dark noise floor is ~ 6nV we don't expect to see it with the Moku without amplification. Attachment 2 shows that indeed we couldn't resolve the PD dark noise.

We then opened the LO shutter. We measured with a power meter 1mW and 1.15mW coming impinging on the PDs. The voltage readings after the preamp were 1.66V for the white fiber, and 1.93 V for the red fiber. These values suggest responsivities of 0.830 and 0.834 respectively.

The PDs were measured using the Moku scope and subtracted digitally with some small gain adjustment (0.93*ch1-1.07*ch2) between the channels. The result is shown in attachment 3 together with the expected shot noise level.

1. There is not enough clearance for detecting squeezing.

2. Expected shot noise level is still too high. Does the 2kohm preamp gain go all the way above 1MHz??

Attachment 1: Moku_Noise.pdf
Moku_Noise.pdf
Attachment 2: PD_Connected_no_light.pdf
PD_Connected_no_light.pdf
Attachment 3: Diff_Channel.pdf
Diff_Channel.pdf
  2735   Tue Mar 22 09:19:38 2022 shrutiUpdateWOPOWaking up WOPO - back to green path

[Yehonathan, Shruti]

Yesterday we went back to fiddling with the green path. Soon after opening the green shutter and then switching the doubling cavity to 'AUTO' we were able to see 150 mW of green light. We were able to replicate this a couple of times yesterday.

Since we had earlier removed the green fiber from the fiber launch to clean its tip, the coupling into the fiber turned out to be quite poor. As can be seen in Attachment 1, Yehonathan pointed out that a lot of green light was being lost to the cladding due to poor coupling. He then played around with the alignment and finally was able to see 65% coupling efficiency. This process seemed to involve a great amount of trial and error through several local power minima.

Attachment 2 shows that the coupling between the two fibers at the 532 nm input of the waveguide is quite poor (there is visible light being lost in the cladding). Furthermore, this light intensity decreases as we get closer to the waveguide meaning this light is being dissipated in the fiber. Even at the 1064 nm output where we expect to see squeezing there is some remnant green light.

We wanted to test if the green leakage reaching the PDs were causing additional noise. For this we just looked at the spectrum analyzer on the Moku (after amplifying 100x with the SR 560) and saw no difference in the noise spectrum with and without the green shutter being open. Although, we're not convinced with this measurement since we were not able to find good quality SMA cables for the entire path. Moving around the BNCs seemed to change the noise. Also, near the end, we noticed some coupling between the two channels on the Moku while measuring the noise that seemed to cause additional noise in one of the channels. We did not have sufficient time yesterday to probe this further.

Attachment 1: before_opt.jpg
before_opt.jpg
Attachment 2: around_waveguide.png
around_waveguide.png
  2759   Wed Apr 20 00:12:12 2022 YehonathanUpdateWOPOStill figuring out the readout electronics and fixing of some stuff

{Yehonathan, Shruti}

1. Grabbed 30Hz-3GHz HP spectrum analyzer from the Cryolab. Installed it in the WOPO lab under the optical table. We figured out how to do a zero-span measurement around 10MHz. The SA has only one input so we try to combine the signals with an RF splitter. We test this capability by sourcing the RF splitter with 10MHz 4Vpp sine waves from a function generator and measuring the output with a scope. We measure with the scope 1.44Vpp for each channel. The combined channel was 2.73Vpp. We then realized that we still don't have a way to adjust the gains electronically, so we moved on to trying the RF amplifiers (ZFL500 LN).

We assemble two amps on the two sides of a metal heatsink. We solder their DC inputs such that they are powered with the same wire (Attachment 1). We attach the heatsink to the optical table with an L bracket (Attachment 2).

We powered the amps using a 15V DC power supply and tested them by feeding them with 10MHz 10mVpp sine waves from a function generator. We observe on a scope an amplification by a factor of ~ 22. Which makes a power amplification of ~ 26db consistent with the amplifiers' datasheet.

We couldn't find highpass filters with a cutoff around 1MHz, so we resumed using the DC blocks, we test them by feeding white noise into them with a function generator and observing the resulting spectrum. First, we try the DC blocks with a 50 Ohm resistor in parallel. That happened to just cut the power by half. We ditch the resistor and get almost unity transmission above 20kHz.

Moving on to observing LO shot noise, we open the laser shutter. We find there is only 0.7mW coming out of each port of the fiber BHD BS. We measure the power going into the BS to be 4mW. This means the coupling between the LO fiber and the BS fiber is bad. We inspect the fibers and find a big piece of junk on the BS fiber core. We also find a small particle on the LO fiber side. We cleaned both fibers and after butt coupling them we measure 1.6mW at each port. We raise this power to 2mW per port.

We connect the outputs of the PDs to the amps through the DC blocks. The outputs of the amps were connected to the Moku's inputs. The PDs were responding very badly and their noise was also bad. We bypass the amps to debug what is going on. We connect the PDs to a scope. We see they have 300mV (attachment 3) dark noise which is super bad and that they hardly respond to the light impinging on them (attachment 4). We shall investigate tomorrow.

Attachment 1: 20220419_153109.jpg
20220419_153109.jpg
Attachment 2: 20220419_164600.jpg
20220419_164600.jpg
Attachment 3: 20220419_184248.jpg
20220419_184248.jpg
Attachment 4: 20220419_184233.jpg
20220419_184233.jpg
  2760   Thu Apr 21 10:33:33 2022 shrutiUpdateWOPOStill figuring out the readout electronics and fixing of some stuff

[Yehonathan, Shruti]

 

First we turned on the relevant instruments for this experiment after the power shutdown:

- Main laser drivers and doubling cavity controller. We set the current to 2 A as we had it before.

- The waveguide TEC. We tried setting it to 60.99 C (for maximum efficiency) but the temperature ramps up much faster and over shoots the setpoint. So we had to do what we did earlier which was to adiabatically change the setpoint from room temperature and finally set it to something like 63 C so the actual measured temperature stabilizes at ~60.9 C. How do we change the PID parameters on this controller? The settings don't seem to allow for it.

- PD power supply, oscilloscopes, function generator, SR 560s lying nearby

 

Then we tried to probe further what was going on with the PDs (TL;DR not much made sense or was reproducible)

  • Initially we were sending in 12 V from Ch1 of the Tenma power supply and \pm15 V to the mini-circuits RF amplifiers from Ch2 of the same Tenma. When we tried to observe the DC voltage levels (before amplification) and the noise (after amplification) but they did not make sense to us as described in the previous elog.
  • Then we disconnected the RF amplifiers and switched the power supply for the PD transimpedance amps to Ch2 of the Tenma. Briefly we were able to see 2 V DC at each output (as expected for the ~1.3 mW of light incident  on each PD) when measured with the multimeter. On the scope we were seeing that one of the PDs was dominated by 60 Hz fluctuations with a much lower
  • We tried to switch it back to Ch1 but even the DC levels seen by the multimeter were bogus (~1 V for one of the channels and 2 V for the other)
  • When we switched the power supply to a HP one taken from CTN, the DC levels on both channels seemed ~1V without any light and the noise somehow seemed lower with some incident light

 

Possible next steps

  • Even though the AD 829 data sheet says it can be operated at up to 15 V, it is possible that we damaged both of them somehow when cycling the power. Elog 2324 also says that it was designed to be powered at \pm 5 V. We could replace both op-amps and measure teh transimpedance TFs before and after the change
  • Use different PDs. Maybe temporarily try with just the ThorLabs PDA20CS or similar with ~20 mW of LO power and measure the shot noise (possibly also squeezing).
  2762   Mon Apr 25 11:08:35 2022 YehonathanUpdateWOPOStill figuring out the readout electronics and fixing of some stuff

{Shruti, Yehonathan}

We realized that the PD amp circuit only requires a 5V DC supply so we try that. One of the PD had the right response, although only after cycling the input impedance from 50ohm to 1Mohm which is weird. The other one (which produces the negative signal) was complete bonkers.

We remove the home-built PDs and put 2 Thorlabs PDs (forgot the model) with a bad dark current but a decent response and high saturation current. With these PDs we are limited by the PD noise to about 1.25db od squeezing when 30mW LO is detected on each PD without using electronic amplifiers. Attachment 1 shows the different noise spectra we measured.

We maximize the coupling efficiency before boosting the LO power. For some reason, the coupling between the LO fiber and fiber BS deteriorated but there was no apparent dirt on them upon inspection. We crank up the power and measure PD outputs using the Moku oscilloscope. The PD signals were subtracted digitally, but now we were not able to get the shot noise even after fine-tuning the gains. What went wrong? maybe it's because the PDs have separate power supplies?

Details later...

 

Some analysis in this notebook

  2764   Thu Apr 28 14:12:20 2022 YehonathanUpdateWOPOStill figuring out the readout electronics and fixing of some stuff

{Shruti, Yehonathan}

We went to the e-shop to investigate the PD circuits. Completely confused about the behavior of the PDs we decide to gain some sanity by testing a sample AD829 on a breadboard with resistors and capacitors similar to those in the design of the PD circuits shown here. The PD is replaced by a voltage source and a 2kOhm resistor such that 0db gain is expected. We first measure the TF of the opamp with the Moku just with the resistors (attachment 1) then with the compensation capacitors.

We tried powering the opamp with shorting V- to ground like we did in the WOPO lab (for some reason this was how it was connected) and got garbage results (attachment 3).

We then turned to retesting the PD circuits with a proper powering scheme. However, connecting +/-5V and ground from a power supply resulted in the output of the PD circuit being ~ -2V even when the PD is taken out which might suggest that the opamps have really gone bad.

Attachment 1: JustTIR.pdf
JustTIR.pdf
Attachment 2: TIR_WithCapacitors.pdf
TIR_WithCapacitors.pdf
Attachment 3: OnlyV_plus.pdf
OnlyV_plus.pdf
  2777   Thu Jun 2 10:28:26 2022 YehonathanUpdateWOPOInstalling 1811 PDs

[Shruti, Yehonathan]

We took newport 1811 PDs, one from CTN lab (suspicious) and one from (I forgot) for their high gain and low dark noise.

The detector diameter is small 0.3mm, but our focusing is sufficient:

The mode field diameter of the PM980 fiber is ~ 6.6um. The beam is collimated by a Thorlabs F240APC-1064 with f = 8.07mm and focused with an f = 30mm lens. It means that the diameter at the focus should be roughly 6.6um*30/8.07 = 0.024mm which is well within the PD active area.

 

We place the PDs at the focal point of the lens at the BHD readout. The impinging optical power was set to be ~ 0.6mW at each port. In one of the PDs, we measure the DC response with a scope to be ~ 5.5 V/0.6 mW ~ 9e3 V/W. According to the specs, the DC monitor as a response of 1e4 V/A while the responsivity of the PD itself is ~ 0.8 A/W at 1064nm so the overall responsivity is ~ 8e3 V/W.

However, the second PD's DC response was bonkers: we measured it to be ten times less. The AC response might still be OK since it is a different port but we haven't measured it yet.

  2796   Wed Jul 20 15:55:41 2022 YehonathanUpdateWOPOInstalling 1811 PDs

{Yehonathan, Paco}

We comfirmed that the DC ouput of one of the 1811s is bad. We set out to measure the AC response of the PDs.

For this, we decided to use the current modulation on the Diabolo laser which is rated to have 0.1 A/V and a bandwidth of 5kHz. We calibrated the current to optical power by swiping the current and measuring the power at the homodyne PDs using a power meter. The laser power before the 1064nm PZT mirror was measured to be 5mW.

Attachment shows the measurement and a linear fit with slope=0.97 mW/A.

We drove the current modulator using a sine wave from a function generator with 1kHz 0.5Vpp. When we looked on the PD AC signal port in the Oscilloscope we saw 2 Vpp 12Mhz signal. We passed the signal with a low pass filter but again we saw mostly noise.

We took the PDs to the 40m PD test stand but we accidently fried Jenne's laser.

Next, we should just use the Moku network analyzer instead of the scope to measure the response in the QIL using the Diabolo current modulator.

Attachment 1: Diabolo_Current_Power_at_PDs.png
Diabolo_Current_Power_at_PDs.png
  2800   Tue Aug 23 22:23:06 2022 awadeUpdateWOPOInstalling 1811 PDs

I recall at one point we had one of these NF1811 with a broken power suply pin.  It was from a limited production run with the smaller micro 3-pin power connectors. Maybe check yours is not that one.  

Long story short it still responded with only the positive rail but DC will gave a bad photovoltaic mode response and the AC had a large unstable oscillation that was only viewable on a high speed scope (if I recall right higher than the 125 MHz nominal bandwidth).  I would check the power-in pins aren't bent/broken and also check the AC out on a higher speed scope (i.e. >=500 MHz).

  65   Tue Jul 22 18:43:06 2008 DmassComputingfubardigital control broken.
I tried to restore the hacked up oms control system via a series of escalating measures.

a) I ssh'ed into the FE computer (oms) and did "startoms"
-that seemed to run, but there were errors in the status window of screen "C2OMS_GDS_TP.adl" next to the red light FB0, of type 0x2001 if I recall correctly

b) I then tried to remake the oms FE code via the commands in Tobins elog entry
- make oms
- make install-daq-oms
- make install-oms
- make install-screens-oms
Nothing upon restarting the FE. No more error messages from the FB0 button now. possibly more broken than before.

c) Stefan and I then did a "sudo reboot" on oms, still nothing.

We found as the last line in the log file
/cvs/cds/caltech/target/c2oms/log.txt
"DAQ init failed -- exiting"

It appears that the daq no longer starts. I have sent Alex an email, and have tried calling him several times (have not gotten a pickup).
Daqconfig is also brokenish on the non FE computer (ws1). It gives "Error: can't read "y": no such variable" on startup, and will not display anything.

I will be working on getting Rich Abbott's PDH box up and running to lock the PMC while I twiddle my thumbs on the digital stuff.
  67   Fri Jul 25 14:59:24 2008 DmassComputingfubardigital control broken.

Quote:
I tried to restore the hacked up oms control system via a series of escalating measures.

a) I ssh'ed into the FE computer (oms) and did "startoms"
-that seemed to run, but there were errors in the status window of screen "C2OMS_GDS_TP.adl" next to the red light FB0, of type 0x2001 if I recall correctly

b) I then tried to remake the oms FE code via the commands in Tobins elog entry
- make oms
- make install-daq-oms
- make install-oms
- make install-screens-oms
Nothing upon restarting the FE. No more error messages from the FB0 button now. possibly more broken than before.

c) Stefan and I then did a "sudo reboot" on oms, still nothing.

We found as the last line in the log file
/cvs/cds/caltech/target/c2oms/log.txt
"DAQ init failed -- exiting"

It appears that the daq no longer starts. I have sent Alex an email, and have tried calling him several times (have not gotten a pickup).
Daqconfig is also brokenish on the non FE computer (ws1). It gives "Error: can't read "y": no such variable" on startup, and will not display anything.

I will be working on getting Rich Abbott's PDH box up and running to lock the PMC while I twiddle my thumbs on the digital stuff.


With the assistance of a benevolent Rob, the above problem was identified and fixed.

While looking at the logfile for C2oms, we found the script omsfe.rtl was crapping out because there were no daq channels set to acquire. We fixed this by manually setting one of the channels to acquire in C2oms.ini and uncommenting it. We then dropkicked the framebuilder by telneting in via
> telnet fb0 8087
and doing a shutdown. This should be equivalent to clicking the DAQ Reload button on the oms FE Diagnostic medm screens. This fixed the problem of the daq not starting, and we could get realtime data via dataviewer. To start recording it in the daq again, we just need to edit "C2oms.ini" to reflect which channels we are interested in recording.

It appears we can still not toggle channels to acquire via the daqconfig gui. I will worry about that more when I have a version control screens here that I am happy with, and harrass Alex.

We also found something interesting when we tried to interact with the system via DTT. It seemed that the system wanted there to be a link tpchanm1 pointing to tpchanC2, but the creation and subsequent annhilation of this link seemed to not effect the system. When we looked closer, the file we expected to define all the test points, /cvs/cds/caltech/chans/param/tpchn_C2.par, was full of objects for the atf system. The file that the system appears to actually get its definitions of these from was /cvs/cds/advLigo/build/omsepics/oms.par.

Rob says that this was an indication that something in the series of "make ___" commands is broken, as they should have overwritten this file at some point.
  192   Wed Jul 22 20:40:13 2009 AidanLab InfrastructurefubarFiling cabinet lock engaged ... with no key

This happened mysteriously and had absolutely nothing to with me. The fact that I was the last person to open the filing cabinet before this happened is circumstantial and beside the point.

Will get the lockshop onto this in the next couple of days. In the meantime, just try and exercise your clairvoyance.

  244   Mon Aug 10 20:14:11 2009 AidanLab InfrastructurefubarFiling cabinet lock engaged ... with no key

Quote:

This happened mysteriously and had absolutely nothing to with me. The fact that I was the last person to open the filing cabinet before this happened is circumstantial and beside the point.

Will get the lockshop onto this in the next couple of days. In the meantime, just try and exercise your clairvoyance.

 

 

Fixed! The key is now hanging in the second bay from the right above the main bench.

  470   Mon Dec 7 14:01:18 2009 AidanComputingfubarFront-end is down ...

I tried to make a change to the front-end in Simulink and compile it on fb0 - which is supposedly now our front-end machine. For some reason it won't build the .rtl file that is the front-end itself. When I tried to revert to the backed-up model I had the same problem. It doesn't look like anyone has tried to rebuild the front-end since late September and there have been some changes to the network since then.

I'm going to track down Alex and sort this out.

  520   Thu Jan 7 17:27:04 2010 ZachLab Infrastructurefubartip of the iceberg

Aidan and I began circling the holes in the ventilation system with Sharpies this afternoon, only to find that the situation was even worse than we thought before (which was already bad). Below is a picture of one particularly bad section (compare with Frank's previous post). We can continue to highlight each one, but by the time we are done the entire lab will look like this--maybe I should have chosen 'fugly'. The worst leaks are not the small ones that can be seen on the sides and bottom of the ducts, but rather the HUGE gaping holes on the top sections of nearly every joint in the system. I am fairly sure that even if we were to highlight each and every hole, we will not get PMA to fix each one. Rana suggests that we at least get them in to fix the largest ones for the time being.

00001.jpg

  565   Fri Jan 29 17:53:03 2010 DmassComputingfubarMental Computing Broken

I was attempting to replicate the pwelch command using the numerical recipes formula for the Welch's Periodogram PSD estimate. Koji helped me figure out that the calculation was missing a factor of bandwidth, and even though it said explicitly it was a PSD, it was a power spectrum. He also helped me figure out some stupid errors I was making in indexing.

I have recreated the algorithm now, and am going to use this, along with TFestimate to do frequency domain subtraction. I think this could still be a good thing even with the MZWino code, but it will be good to at least compare.

  574   Thu Feb 4 00:59:23 2010 ranaComputingfubarELOG restarted: no more .ps files

I restarted the ELOG on NODUS just now. Our attempt to set up error logging worked - it turns out ELOG was choking on the .ps file attachment.

So for the near future: NO MORE .PS files! Use PDF - move into the 20th century at least.

matlab can directly make either PNG or PDF files for you, you can also use various other conversion tools on the web.

Of course, it would be nice if nodus could handle .ps, but its a Solaris machine and I don't feel like debugging this. Eventually, we'll give him away and make the new nodus a Linux box, but that day is not today.

To restart the elog:  http://lhocds.ligo-wa.caltech.edu:8000/40m/How_To

  736   Wed Apr 28 09:24:01 2010 AidanComputingfubarelog craziness - test to try and crash elog

 - apparently PDFs work okay. Frank is reporting continual crashes from last night when uploading a graph of the particle counter in different formats from Firefox in Windows.

Attachment 1: 40m_figure_ETM.pdf
40m_figure_ETM.pdf
  1068   Mon Sep 20 13:41:33 2010 ranaComputingfubarrouter was down so I power cycled it
  1073   Mon Sep 20 22:47:27 2010 AlastairMiscfubarliso

 I added some instruction to the ATF internals/scripting bit of the wiki for installing liso.  Since it needs gnuplot and this requires all kinds of other stuff it seemed like a good plan to document it for future generations.

In short the message is simple.  If you're using a mac then you should install X-code from your OSX dvd and then install MacPorts.  Your life will be greatly enriched and future dealings with all things linux will be nicer.

  1115   Fri Oct 29 17:31:41 2010 AlastairLab InfrastructurefubarOld white board

RIP Old Whiteboard

I found the old white board and got a photo of the info before the goons who removed it can throw it away.

As a tribute to the old whiteboard, I think that Aidan in particular will appreciate this

 

Attachment 1: photo.JPG
photo.JPG
  1116   Sat Oct 30 14:09:20 2010 Curious GeorgeLab InfrastructurefubarOld white board

Quote:

RIP Old Whiteboard

I found the old white board and got a photo of the info before the goons who removed it can throw it away.

As a tribute to the old whiteboard, I think that Aidan in particular will appreciate this

 

 Why did we switch whiteboards?

Why would we let them throw this one away?

 

  1122   Mon Nov 1 16:35:15 2010 AlastairLab InfrastructurefubarOld white board

Quote:

Quote:

RIP Old Whiteboard

I found the old white board and got a photo of the info before the goons who removed it can throw it away.

As a tribute to the old whiteboard, I think that Aidan in particular will appreciate this

 

 Why did we switch whiteboards?

Why would we let them throw this one away?

 

 Don't ask me George, I have no idea.  We now have a huge door sized white board though, and a sort of fake wall covering up the door.  I'm just assuming that at some point the old one will be gone since it no longer has a wall to live on.  Any more questions?

  1328   Wed Mar 2 09:14:01 2011 ghostwriterMiscfubardump or optics lab?

100_1228.JPG

100_1229.JPG

100_1227.JPG

100_1226.JPG

100_1230.JPG

100_1228.JPG

  1334   Thu Mar 3 00:36:11 2011 ZachMiscfubardump or optics lab?

optics lab

 

lab_is_clean.png

Quote:

100_1228.JPG

100_1229.JPG

100_1227.JPG

100_1226.JPG

100_1230.JPG

100_1228.JPG

 

  1564   Wed Nov 9 00:39:52 2011 ZachLaserfubarWhat not to do to a dogclamp

This is what one of the stainless steel dogclamps looked like when I removed it from the vacuum chamber today. This is most likely from the improper configuration we have to use them in due to space constraints, but could also be as a result of improperly pitching them (by using the right counter-height). This is one reason I have opted to use the longer screws from now on.

busted_dc1.png busted_dc2.png

  287   Thu Aug 27 20:00:59 2009 AlastairLab Infrastructurestuff happensLenses

I ordered some lenses for the lens kit.

  288   Thu Aug 27 21:40:20 2009 (not) AlastairLab Infrastructurestuff happensLenses

Quote:

I ordered some lenses for the lens kit.

 What focal lengths/coatings

  289   Fri Aug 28 10:26:12 2009 AlastairLab Infrastructurestuff happensLenses

Quote:

Quote:

I ordered some lenses for the lens kit.

 What focal lengths/coatings

I chased this up this morning.  Even though I made the order directly through techmart (not as a spot buy) Newport have not received it.  I'll put it in again.  The lenses will have the AR18 anti reflection coating for 1000-1550nm.

I'm ordering two each of the following:

KPX103 - f=175

KPX106 - f=200

KPX109 - f=250

KPX112 - f=300

KPX115 - f=400

KPX118 - f=500

KPX121 - f=700

KPX124 - f=1000

I'm ordering one each of the following:

KPX100 - f=150

KPX097 - f=125

KPX094 - f=100

KPX091 - f=88.3

KPX088 - f=75.6

KPX085 - f=62.9

KPX082 - f=50.2

KPC037 - f=-75

KPC034 - f=-100

KPC028 - f=-200

  290   Fri Aug 28 10:52:35 2009 AlastairLab Infrastructurestuff happensLenses

Quote:

Quote:

Quote:

I ordered some lenses for the lens kit.

 What focal lengths/coatings

I chased this up this morning.  Even though I made the order directly through techmart (not as a spot buy) Newport have not received it.  I'll put it in again.  The lenses will have the AR18 anti reflection coating for 1000-1550nm.

I'm ordering two each of the following:

KPX103 - f=175

KPX106 - f=200

KPX109 - f=250

KPX112 - f=300

KPX115 - f=400

KPX118 - f=500

KPX121 - f=700

KPX124 - f=1000

I'm ordering one each of the following:

KPX100 - f=150

KPX097 - f=125

KPX094 - f=100

KPX091 - f=88.3

KPX088 - f=75.6

KPX085 - f=62.9

KPX082 - f=50.2

KPC037 - f=-75

KPC034 - f=-100

KPC028 - f=-200

 Gina has checked through the PO and Newport should definitely have received it, but they claim they did not.  This is the third time that I know of recently that we've had trouble with ordering this way from Newport.

---  The new order has now been put through and has arrived at Newport ---

  291   Fri Aug 28 12:26:14 2009 DmassLab Infrastructurestuff happensLenses

I thought we wanted the straight up 1064 only coating on these (AR.33)?

According to Newport:

  • Ravg <0.5% for AR.18
  •  Ravg <0.25% for AR.33

 

  292   Fri Aug 28 12:39:00 2009 AlastairLab Infrastructurestuff happensLenses

Quote:

I thought we wanted the straight up 1064 only coating on these (AR.33)?

According to Newport:

  • Ravg <0.5% for AR.18
  •  Ravg <0.25% for AR.33

 

 That would probably be better, but I'm just replacing like with like in the lens kit just now.

  356   Mon Sep 28 20:40:53 2009 AidanMiscstuff happensPlease do not leave the permanent marker by the whiteboard ...
  367   Wed Oct 7 02:47:41 2009 AidanMiscstuff happensDigital camera is in my office
  476   Wed Dec 9 11:53:42 2009 FrankLaserstuff happenslaser data unavailable since 1 week

the laser data is not available since i left last week. Can some plz check the IBM laptop computer sitting in the rack on top of the HV power supply. plz reboot/turn it on and boot windows (not linux). if you don't choose it from the boot menu while booting it will be running linux by default.... thanks

ELOG V3.1.3-