40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 PSL, Page 33 of 52 Not logged in
ID Date Author Type Category Subject
446   Mon Jan 10 10:37:43 2011 JanNotesPEMTable versus ground

I have taken a few days of data with the T240 standing on the ground (and not on the optical table). I expected horizontal particle trajectories to lose some of their ellipticity. And that's indeed the case (left ground, right table):

So the table is doing something to the displacement at high frequencies. Note that you cannot compare absolute displacements in these plots. They are individually normalized so that the maximum dispalcement during that time seen in any of the channels is equal to one. You can also compare H/V ratios (left ground, right optical table):

The 0.1Hz-1Hz peak in the table data is gone. My first thought was that this may be related to the table, but the peak height also varied during the table measurement and is getting stronger again right now. So maybe there is a table effect, probably not (too low frequencies). Moving the seismometer to the ground, the H/V ratio above 1Hz has dropped to something significantly below 1. In principle you can use this information to measure the Poisson ratio of the ground, but only by making a few assumptions: (a) the spectrum is determined by Rayleigh waves, (b) the ground is half-homogeneous. In this case, the dashed line in the following figure tells us what the Poissson ratio is:

The H/V ratio should be frequency independent if the two assumptions were true. This is not the case, so our assumptions are wrong. Only the 1Hz to 10Hz range seems ok. Below 0.1Hz we sort of know that the seismic displacement is not driven by Rayleigh waves, but local sources causing heavy tilts that cannot be associated with Rayleigh waves (which is quite a non-trivial statement). Maybe we should also not forget that it may be possible that temperature changes, air currents and pressure changes may also couple into the low-frequency data. This is always the problem at the surface. You need to spend a lot of money to make good seismic measurements above ground. Between 0.1Hz and 1Hz it is also not completely surprising that the model fails (the ratio is too close to 1) since large scale heterogeneities break the half-homogeneity of the model. The weird structure above 10Hz is mysterious, but again since seismicity is likely driven by local sources at these frequencies, one would not expect a simple picture to form.

447   Mon Jan 10 13:28:36 2011 JanSummaryPEMWeekly plots; start date 2010-12-25

These two plots are just for completeness. In a few minutes I will be able to post the plots for the third week, which could be more interesting since it contains the transition from table to ground. I don't understand why the low-frequency disturbance is "out of phase" with the high-frequency one. It's maybe the last sign of Tara before he left, so he seems to be out of synch with the rest of the world.

448   Mon Jan 10 14:27:11 2011 JanSummaryPEMWeekly plots; starting date 01/01/2011

So I don't know what's going on, but the table is doing something really terrible. Maybe it vibrates as a response to ventilation, whereas the coupling of ventilation to ground is comparatively weak. Anyway, this is the end of PSL seismic measurements. Data will be kept on one of the machines in 058f. In principle, I could convert the data into frames and copy it to another location, but it may be too much work. I can always easily produce .mat files with averaged spectra etc. Let me know.

1583   Tue Oct 6 09:11:48 2015 Aidan, AntonioDailyProgressPEMIt's alive! Newport temperature sensors resurrected

We finally got the temperature sensors broadcasting to EPICS channels again - well, in part anyway. There are a lot of configuration issues to work out (refresh rate, saving to frames, license for OPC server, battery monitors, data precision). But at least we can now see a temperature sensor channel in EPICS that corresponds to a live measurement. The configuration to get the data from the remote unit to EPICS is shown in the attached block diagram.

More details can be found here:

Attachment 1: ZCDR_PEM_OPC.pdf
1815   Mon Jan 23 14:18:31 2017 Aidan, AntonioSummaryPEMIt's alive! Newport temperature sensors resurrected

The (Windows 7) computer that runs the OPC server is in the TCS Lab. The EPICS server on this machine needs rebooting at the moment.

More critically, we need a framebuilder running on the network in order to save these channels to file for future trending. A slow EPICS framebuilder is all that is necessary.

 Quote: We finally got the temperature sensors broadcasting to EPICS channels again - well, in part anyway. There are a lot of configuration issues to work out (refresh rate, saving to frames, license for OPC server, battery monitors, data precision). But at least we can now see a temperature sensor channel in EPICS that corresponds to a live measurement. The configuration to get the data from the remote unit to EPICS is shown in the attached block diagram.   More details can be found here: https://nodus.ligo.caltech.edu:30889/ATFWiki/doku.php?id=main:experiments:psl:menu

2129   Sun Mar 11 18:43:07 2018 CraigDailyProgressPEMNotes from today's work

Today I buzzed the table and determined there was a strong 500 Hz dirty resonance on the first steering mirror after the PMC.
This caused me to go around tightening bolts everywhere, including the offending steering mirror and the optics around it.  This did not reduce the resonance.
I tightening the PMC REFL steering mirror as well, and this caused a misalignment onto the PMC REFL PD.  This took me a little while to figure out why the North path refused to lock.  I realigned the PMC REFL steering mirror into the PD.
After I got the North PMC locking again, the North path itself was not locking anymore.  I reranged the autolocker slow volts, but this did not help.
Turns out the North Trans PD threshold voltage was not high enough.  This is likely because of the bolt tightening, causing some slight misalignment into the North cavity, lowering the overall circulating power in the cavity.  I lowered the autolocker threshold from 1.1 volts to 1.0 volts, and aligned the North Trans PD.  We need to rescan the North cavity to get better alignment/mode matching, but I'm gonna put this off until we replace this offending 500 Hz post-PMC steering mirror.
While I was realigning the Trans PD, I noticed that even touching the trans optics tables causes large ~1Hz oscillations in the trans voltage.  This is definitely exacerbating any scattering problem we have.  Also, the Trans PD output for both paths is "breathing", going up and down with a period of about a minute.  This is bad for our autolocker's threshold.  It's possible that we should build two periscopes for the north and south paths to eliminate these elevated tables which cause coherent oscillations on all trans optics.  We could copy Tara's front periscope design.

2130   Mon Mar 12 01:25:23 2018 CraigDailyProgressPEMNotes from today's work

More notes:
1) The AOMs temperature drift are probably responsible for the "breathing" we're seeing in the Trans DC PDs.  We should get the ISSs working again as soon as possible.  Probs need thermal hats for the AOMs to stop thermal drift.

2) I am unable to access current CTN Lab data on fb4 using my python method from a few elogs ago.  (Now to get on our workstation you have to access through port 22: $ssh -Y controls@131.215.115.216 -p 22) I am also unable to access data using data viewer directly on fb4... It says Connecting to NDS Server localhost (TCP port 8088) Connecting.... done No data found read(); err=Bad file descriptor read(); err=Bad file descriptor T0=18-03-10-06-36-21; Length=10800 (s) No data output. All of this used to work. This needs to be resolved tomorrow. Additionally, I think that the fb4 frame times are off by two days, because when I press "Time Now" in Data Viewer it gives me some time from March 10th (It's March 12th right now). This is especially confusing because the$ date command on fb4 gives the correct time, but the frames are not at the correct time.

3) I created nine new channels for autolocker tuning in real time.  awade should use these in autolocker.py in Git/cit_ctnlab/ctn_scripts/.  I already put the channel names in the three .ini files, ALConfig_NCAV.ini, ALConfig_SCAV.ini, and ALConfig_NPMC.ini.  Will need to restart acromag to activate these channels.
Channels:
On acromag1, in ~/modbus/db/PMCInterfaceControls.db
C3:PSL-NCAV_PMC_AUTOLOCKER_SLOW_SWEEP_BOTTOM
C3:PSL-NCAV_PMC_AUTOLOCKER_SLOW_SWEEP_TOP
C3:PSL-NCAV_PMC_AUTOLOCKER_SLOW_SWEEP_STEPSIZE
On acromag1, in ~/modbus/db/AutoLockerSoftChannels.db
C3:PSL-NCAV_FSS_AUTOLOCKER_SLOW_SWEEP_BOTTOM
C3:PSL-NCAV_FSS_AUTOLOCKER_SLOW_SWEEP_TOP
C3:PSL-NCAV_FSS_AUTOLOCKER_SLOW_SWEEP_STEPSIZE
C3:PSL-SCAV_FSS_AUTOLOCKER_SLOW_SWEEP_BOTTOM
C3:PSL-SCAV_FSS_AUTOLOCKER_SLOW_SWEEP_TOP
C3:PSL-SCAV_FSS_AUTOLOCKER_SLOW_SWEEP_STEPSIZE

 Quote: Today I buzzed the table and determined there was a strong 500 Hz dirty resonance on the first steering mirror after the PMC.  This caused me to go around tightening bolts everywhere, including the offending steering mirror and the optics around it.  This did not reduce the resonance. I tightening the PMC REFL steering mirror as well, and this caused a misalignment onto the PMC REFL PD.  This took me a little while to figure out why the North path refused to lock.  I realigned the PMC REFL steering mirror into the PD. After I got the North PMC locking again, the North path itself was not locking anymore.  I reranged the autolocker slow volts, but this did not help.  Turns out the North Trans PD threshold voltage was not high enough.  This is likely because of the bolt tightening, causing some slight misalignment into the North cavity, lowering the overall circulating power in the cavity.  I lowered the autolocker threshold from 1.1 volts to 1.0 volts, and aligned the North Trans PD.  We need to rescan the North cavity to get better alignment/mode matching, but I'm gonna put this off until we replace this offending 500 Hz post-PMC steering mirror. While I was realigning the Trans PD, I noticed that even touching the trans optics tables causes large ~1Hz oscillations in the trans voltage.  This is definitely exacerbating any scattering problem we have.  Also, the Trans PD output for both paths is "breathing", going up and down with a period of about a minute.  This is bad for our autolocker's threshold.  It's possible that we should build two periscopes for the north and south paths to eliminate these elevated tables which cause coherent oscillations on all trans optics.  We could copy Tara's front periscope design.

2131   Mon Mar 12 15:22:42 2018 Craig, JaimeDailyProgressPEMNotes from today's work

Note on (2) from below:
It seems that fb4's system time is fine.  I have synced up ws1 as well so that both system times are okay by installing ntp: $sudo apt-get install ntp. This worked automatically on ws1. Jaime and I restarted fb4, but only ten minutes after doing so, fb4's frame time was three minutes behind. Jaime suspects this is because the frame gpstime (C4:DAQ-DC0_GPS) is unregulated. Jaime is currently working on preventing fb4 frame time drift. Quote: More notes: 1) The AOMs temperature drift are probably responsible for the "breathing" we're seeing in the Trans DC PDs. We should get the ISSs working again as soon as possible. Probs need thermal hats for the AOMs to stop thermal drift. 2) I am unable to access current CTN Lab data on fb4 using my python method from a few elogs ago. (Now to get on our workstation you have to access through port 22:$ ssh -Y controls@131.215.115.216 -p 22)
I am also unable to access data using data viewer directly on fb4...  It says

Connecting to NDS Server localhost (TCP port 8088)
Connecting.... done
No data found

T0=18-03-10-06-36-21; Length=10800 (s)
No data output.

All of this used to work.  This needs to be resolved tomorrow.
Additionally, I think that the fb4 frame times are off by two days, because when I press "Time Now" in Data Viewer it gives me some time from March 10th (It's March 12th right now).  This is especially confusing because the \$ date command on fb4 gives the correct time, but the frames are not at the correct time.

3) I created nine new channels for autolocker tuning in real time.  awade should use these in autolocker.py in Git/cit_ctnlab/ctn_scripts/.  I already put the channel names in the three .ini files, ALConfig_NCAV.ini, ALConfig_SCAV.ini, and ALConfig_NPMC.ini.  Will need to restart acromag to activate these channels.
Channels:
On acromag1, in ~/modbus/db/PMCInterfaceControls.db
C3:PSL-NCAV_PMC_AUTOLOCKER_SLOW_SWEEP_BOTTOM
C3:PSL-NCAV_PMC_AUTOLOCKER_SLOW_SWEEP_TOP
C3:PSL-NCAV_PMC_AUTOLOCKER_SLOW_SWEEP_STEPSIZE
On acromag1, in ~/modbus/db/AutoLockerSoftChannels.db
C3:PSL-NCAV_FSS_AUTOLOCKER_SLOW_SWEEP_BOTTOM
C3:PSL-NCAV_FSS_AUTOLOCKER_SLOW_SWEEP_TOP
C3:PSL-NCAV_FSS_AUTOLOCKER_SLOW_SWEEP_STEPSIZE
C3:PSL-SCAV_FSS_AUTOLOCKER_SLOW_SWEEP_BOTTOM
C3:PSL-SCAV_FSS_AUTOLOCKER_SLOW_SWEEP_TOP
C3:PSL-SCAV_FSS_AUTOLOCKER_SLOW_SWEEP_STEPSIZE

 Quote: Today I buzzed the table and determined there was a strong 500 Hz dirty resonance on the first steering mirror after the PMC.  This caused me to go around tightening bolts everywhere, including the offending steering mirror and the optics around it.  This did not reduce the resonance. I tightening the PMC REFL steering mirror as well, and this caused a misalignment onto the PMC REFL PD.  This took me a little while to figure out why the North path refused to lock.  I realigned the PMC REFL steering mirror into the PD. After I got the North PMC locking again, the North path itself was not locking anymore.  I reranged the autolocker slow volts, but this did not help.  Turns out the North Trans PD threshold voltage was not high enough.  This is likely because of the bolt tightening, causing some slight misalignment into the North cavity, lowering the overall circulating power in the cavity.  I lowered the autolocker threshold from 1.1 volts to 1.0 volts, and aligned the North Trans PD.  We need to rescan the North cavity to get better alignment/mode matching, but I'm gonna put this off until we replace this offending 500 Hz post-PMC steering mirror. While I was realigning the Trans PD, I noticed that even touching the trans optics tables causes large ~1Hz oscillations in the trans voltage.  This is definitely exacerbating any scattering problem we have.  Also, the Trans PD output for both paths is "breathing", going up and down with a period of about a minute.  This is bad for our autolocker's threshold.  It's possible that we should build two periscopes for the north and south paths to eliminate these elevated tables which cause coherent oscillations on all trans optics.  We could copy Tara's front periscope design.

1694   Mon Aug 1 18:47:58 2016 awadeSummaryPLLPresent electronic configuration of the PLL loop

Post documenting the set out of the PLL electronics and cable routing.

We were having trouble with the PLL electronics in obtaining a beat note error signal and lock. We can see a beat note of 17 dB clearance above the DN level on the spectrum analyzer.   This post is to document the present configuration and the powers present at the mixer before I start to troubleshoot (aka pull it apart).

Schematic of the PLL electronics stage attached below.  Settings for the Marconi and SR560 are also below. I would noted that there is a low pass filter on the output of the phase detector (which I assume is a mixer) that extracts the (omega_LO - omega_sig) but has nowhere for the dumped (omega_LO + omega_sig) signals to go.  I'm guessing the non-DC signals are getting reflected directly back into the ZRPD-1+. I can't imagine that is great if back reflections start to form parasitic competing signals with the beat note signal.

Marconi 2023A
Carrier Frequency = 75.526 MHz (close to PD beatnote)
RF Level = +13 dBm
FM Devn 10.0 kHz (set by Ext DC)

SR560
Filter cutoff = DC
Coupling = DC
Source  = A (B port terminated with 50 ohm)
Inv = On
Gain Mode = Low noise
Gain  = 50

The spec sheet for the ZRPD-1+ indicates that it is a Level 7 mixer with a damage threshold at 50 mW, so the +13 dBm probably isn't a risk but may be saturating the mixer.  I don't have a calibrated power level for the RF PD input, but it is low (definitely not +7 dBm).  At this stage we either need to improve the beat note or implement some kind of amplification so that both the PD-RF input and LO inputs into the phase detector are matched at the ideal +7dBm level.

At this stage both PDH control loops are ringing with DC signals that are very angular (and about 10% of the total DC signal). The angluarness would indicate that they are probably both railing somewhere or converting an control-error signal to amplitude modulations.  Previously we have diagnosed this back to imperfect polarization input into the fast control BB-EOMs.  I checked both North and South path and the inputs to the all EOMs (the 14 MHz and fast control) are very well aligned to 's': modulator polarization is not the issue. Antonio had this very well optimized form yesterday.

Tuning laser temperature around on the north path, it is apparent that there are some new/stronger HOMs around the region of our TEM00 modes. This is only a qualitative observation. It is possible that over time our mounts have drifted and the alignment is off.  This is now on my list of things check and to tune up.

At this stage the PDH loop issues need to be resolved as they are impeding efforts to reliably form an observable beat note.

The process of unlocking and re-configuring for alignment and other types of diagnostic measurements is cumbersome.  There are BNCs popping out of the experiment everywhere that are also mostly unlabeled.  It would be much nicer to have all the useful control signals and PD signals coming out at a central point, preferably next to the computer interface and electronics rack where we lock and tune gains/temperatures.  I will gradually start migrating the cabling over to that side of the table and then install labeled 'patch lines' that are routed to mounted BNC panels around the table. This way there is a central location close to where we perform locking etc but it is relatively easy to patch through signals and oscilloscope trigger lines for temporary oscilloscopes situated around the table. This also means that consistent labeling can be applied.

It is not a great idea to label the cables with label-writer tape or color code them with electrical tape.  From experience the glues in these breakdown in 2-5 year timeframes either flaking off or leaving a sticky residue that is almost impossible to remove with solvents that don't also dissolve the BNC cable plastic. Heatshink can be good as it can be cut off and doesn't have glue. Otherwise a cable tied labels work well. We have some of these.

It also distresses me a little that BNCs cables are routing HV around the table without a clear system for distinguishing these cables. By Murphy's law these will one day be plugged into something sensitive. Some of them are labeled by are not marked clearly as HV. If I can find some red heat-shrink that fits over the ends of the BNC cables I might start labeling HV lines with a consistent markings to lower the risk of mix ups.

Attachment 1: 20160801_ElectronicLayoutOfPLLLoop.pdf
1871   Fri Aug 18 21:34:00 2017 Craig, awadeDailyProgressPLLPLL OLGTF

We took a open loop gain measurement of our PLL.

We used the Agilent 4395A to supply an excitation on the order of -35 dBm. We plugged the excitation into the B source of the SR560 preamplifier while keeping the A source the output of the low passed phase mixer, and switched the source on the SR560 to A-B.  The gain of the SR560 is two.  The Marconi was set to 98 MHz carrier with 800 kHz of FM modulation range.

OLG = o1/o2, as pictured below.  I plugged the SR560 output (the actuation signal, aka o2) into the R port on the Agilent, and plugged the SR560 input (the error signal, aka o1) into the A port, and then took the transfer function.

From the plot our UGF is at 100 kHz with 100 degrees of phase margin.

Next I need to properly calibrate the Marconi in Hz/Vrms, so I can calculate our trans beatnote spectrum in Hz/rtHz.

Attachment 1: 20170818_211017_PLL_OLGTFs.pdf
Attachment 2: PLLDiagram.jpg
Attachment 3: PLL_OLGTFs.tar.gz
1964   Mon Oct 30 17:25:26 2017 Craig, awadeNotesPLLPLL OLGTF

Just measured the PLL OLGTF.  Here is an ascii diagram.

EXC
|
Beatnote --->( + )----->[H]-------> Error Signal

^                |
|                |
Actuation Signal <----------[A]
<-----

H is the SR560 preamplifier.  A is the Marconi RF signal generator.  To get the PLL OLG, first we measure from EXC to the error signal with the loop open.  Then we close the loop and measure again.

The first measurement gives us H(f).  The second gives us H(f)/(1 - G(f)) where G(f) = H(f) A(f) is the PLL open loop gain.

I have a script in ctn_labdata/scripts which takes in open and closed loop measurements and gives OLGs called OLGCalculator.py.  Then I used iris.py to plot the OLGTF shown below.  The tar that iris.py produces is included.

Our phase locked-loop open loop gain unity gain frequency is around 30 kHz.  This should be okay for our purposes, with sufficient gain to suppress low-frequency (~300 Hz) noise.

Next step: calibrated spectra.

Attachment 1: OLG_from_PLL_Suppressed_Gain_TF_30-10-2017_164727_TF.pdf
Attachment 2: OLG_from_PLL_Suppressed_Gain_TF_30-10-2017_164727.tgz
Attachment 3: Marconi_PLL_Settings.jpg
Attachment 4: SR560_PLL_Settings.jpg
1972   Tue Nov 7 17:09:23 2017 Craig, awadeDailyProgressPLLCommunication with Marconi through GPIB

Using EQ's netgpib infrastructure, I was able to communicate with our PLL Marconi remotely.  This will enable us to continually lock our PLL despite the crazy MHz-per-hour fluctuations in the trans beatnote frequency we see.

In the labutils/netgpibdata/ git repo, there is a function called netgpibcmd.  If you know your GPIB's IP address, make sure it's on your network, plug it in to the back of the Marconi and look up the GPIB address in the Marconi's menus.

In the PSL lab, our GPIB's IP address is 10.0.1.63.  Our Marconi's GPIB address was 17.  So I typed in:

./netgpibcmd -i 10.0.1.63 -a 17 'CFRQ 90.0MHz'

This changed the Marconi carrier frequency to 90.0 MHz.

Other convenient commands:

'CFRQ?' queries the Marconi for its current carrier frequency.  The '?' at the end of any of the following commands will return the Marconi's current settings.

'FM:DEVN 10kHz' changes the frequency modulation rails to 10 kHz/Vrms

'RFLV 13dBm' changes the radio frequency signal level to 13 dBm.

'RFLV:ON' turns on the carrier frequency output.  You can also turn it off using 'RFLV:OFF'

'MODE FM' changes the mode to frequency modulation, as opposed to phase modulation 'PM' or amplitude modulation 'AM'.

'MOD:ON' turns on the modulation of the carrier frequency.

I plan to write a script called Marconi2023A_BeatnoteTrack.py which takes in a PLL control signal channel and a railing voltage.

If the control signal gets close to the rail, the script automatically adjusts the Marconi carrier frequency by a percentage of the FM modulation to get the PLL control voltage back to zero.

In order to do this, however, I need to fix our acromags.  Acromag maul (10.0.1.42) should have 4 ADC channels we can use, but all of them are railed at -8 volts.  Gotta see what's up.

EDIT: Fixed the acromag maul.  Turns out the analog input channel names in some of the .db files were the same.

For instance, C3:PSL-PLL_CONTROL_SIGNAL and C3:PSL-VACCAN_TEMP were both reading from C3:ACROMAG_INPUT7.  Since the TempCtrl.db file was initialized by iocInit last, the -8 volts I was seeing for the C3:PSL-PLL_CONTROL_SIGNAL was actually the output of the uncalibrated C3:PSL-VACCAN_TEMP.  To rectify, I changed all the analog input channel names in LaserSlowControlsAndMonitors.db from C3:ACROMAG_INPUT7 to C3:ACROMAG_INPUT_MAUL7.

1973   Tue Nov 7 20:56:48 2017 CraigDailyProgressPLLPLL Beatnote Tracking through GPIB

 Quote: Using EQ's netgpib infrastructure, I was able to communicate with our PLL Marconi remotely.  This will enable us to continually lock our PLL despite the crazy MHz-per-hour fluctuations in the trans beatnote frequency we see.

I added the script Marconi2023A_BeatnoteTrack.py to the labutils/netgpibdata/ git repo which tracks our transmission cavity beatnote in real time.

The script adjusts the Marconi carrier frequency as the PLL control voltage approaches too close to the rails.  The rails are defined within the script, and are not yet customizable, but it would be a very simple thing to do.

The script adjusts the carrier frequency up or down by the FM deviation value itself.  So if your FM deviation value is 10 kHz, like ours, then your carrier frequency of 90 MHz will be adjusted either down to 89.99 MHz or up to 90.01 MHz.  This is not robust, and other users will have to adjust the rails and the amount and direction of adjustment based on their personal setups.

I'm going to leave this running in our lab overnight while tracking with stripTool to see if anything crazy happens.  If the PLL somehow gets out of range, the script will shut itself off, so nothing bad will happen to our electronics.

1975   Thu Nov 9 00:20:02 2017 CraigDailyProgressPLLPLL OLGTFs with different Frequency Modulation Levels

With the help of the PLL autolocker, I retook the OLG of the PLL with a frequency modulation level of 10 kHz and 3 kHz.

I did this because we have new beatnote spectra in the can at both levels of frequency modulation and we would like to calibrate and add to the noise budget.  The new spectra are in the ctn_labdata/ git repo under ./cit_ctnlab/ctn_labdata/data/20171108_TransBeatnoteSpectrum/

I calculated this PLL OLG the same way I did so previously through the SR560 preamp.  This result is plot 2.

I wasn't convinced this was right, so I did it again my calculating the PLL OLG from the mixer error signal through some OUT1/EXC = G/(1 + G) math.  This result is plot 1.

The results matched up pretty well:

The 3 kHz FM Deviation PLL OLG had a UGF of ~2.3 kHz in both plots 1 and 2.

The 10 kHz FM Deviation PLL OLG had a UGF of ~5 kHz in plot 1, and ~4.3 kHz in plot 2.

I was doubtful because this is so much less than our previous PLL OLG UGF, which was ~30 kHz at 10 kHz FM Devn.  The preamp gain is down to 100 from 200, but not clear otherwise why the PLL UGF is down 6 times as opposed to just 2 times...

With this in hand we should be able to easily calibrate the low-actuator noise spectra we took earlier today.

Attachment 1: OLG_from_PLL_OUT1_over_EXC_FM10kHz_08-11-2017_225218_JustBode.pdf
Attachment 2: OLG_from_PLL_OUT1_over_EXC_FM10kHz_08-11-2017_225218.tgz
Attachment 3: OLG_from_PLL_CTRL_over_EXC_FM10kHz_08-11-2017_235017_JustBode.pdf
Attachment 4: OLG_from_PLL_CTRL_over_EXC_FM10kHz_08-11-2017_235017.tgz
Attachment 5: PLL_SR560.jpg
Attachment 6: PLL_Marconi.jpg
Attachment 7: PLL_Agilent.jpg
1976   Thu Nov 9 10:55:45 2017 awadeDailyProgressPLLPLL OLGTFs with different Frequency Modulation Levels

Just to check, you used the Aglient to do this so to the 50 Ω loading will affect the mesurment.  From the picture it looks like the mixer output is loaded and the excitation (50 Ω assumed) is plugged into a high impedance input of the SR560.  The post injection point readout is the 50 Ω port, but that will be reporting half the value that the marconi high impedance input sees. There are a couple of different factors of two dividing and mulitplying but I think maybe its a factor of four off between the excitation and actuation out signals.  Loading the mixer with an extra 50 Ω halves the value of the loop gain compaired to when it is not connected there.

 Quote: With the help of the PLL autolocker, I retook the OLG of the PLL with a frequency modulation level of 10 kHz and 3 kHz.  I did this because we have new beatnote spectra in the can at both levels of frequency modulation and we would like to calibrate and add to the noise budget.  The new spectra are in the ctn_labdata/ git repo under ./cit_ctnlab/ctn_labdata/data/20171108_TransBeatnoteSpectrum/ I calculated this PLL OLG the same way I did so previously through the SR560 preamp.  This result is plot 2. I wasn't convinced this was right, so I did it again my calculating the PLL OLG from the mixer error signal through some OUT1/EXC = G/(1 + G) math.  This result is plot 1. The results matched up pretty well: The 3 kHz FM Deviation PLL OLG had a UGF of ~2.3 kHz in both plots 1 and 2. The 10 kHz FM Deviation PLL OLG had a UGF of ~5 kHz in plot 1, and ~4.3 kHz in plot 2. I was doubtful because this is so much less than our previous PLL OLG UGF, which was ~30 kHz at 10 kHz FM Devn.  The preamp gain is down to 100 from 200, but not clear otherwise why the PLL UGF is down 6 times as opposed to just 2 times... With this in hand we should be able to easily calibrate the low-actuator noise spectra we took earlier today.

I was double checking the UGF of the PLL and was getting the strange results of 8 kHz UGF with the standard settings of 10 kHz/V and SR560 set to 23 dB gain (Marconi was set to +13 dBm RF power level). In the past we got 30 kHz for this configuration.

Since then an acromag channel was connected to the same 600 Ω output of the SR560 as the Marconi signal generator. This was to monitor the state of the PLL loop so that the Marconi center frequency could be adjusted (through GPIB and a python script) to always have the PLL locked.

It turns out that the acromag channel monitoring the BN DC level is overloading/lowpass filtering the 600 Ω input. Attached below is a transfer function of the SR560 with 2x100 gain setting (no filtering): here the BN has been disconnected this is just the preamp itself. With the acromag connected it appears to add a pole at 3 kHz. This will have changed the PLL loop response in recent measurments.

---

I have now moved the acromag to the 50 Ω buffered output of the SR560, reported voltages should be the same (acromag is high impedance) but the loop now has the expected 30 kHz as before.  Calibrations of previous week should be taken with a grain of salt.

1996   Mon Dec 4 19:33:48 2017 Craig, awadeDailyProgressPLLMarconi Noise Floor Measurement

I became suspicious of our PLL noise floor when looking at scattering spectra this weekend.  It seems at high frequency we are limited by SR560 noise.

The PLL has been locked at Marconi FM Devn of 10 kHz lately, with SR560 preamp gain of 500.  The SR560 has ~10 nVrms/√Hz noise floor, so multiplying by 500 gives around ~5 µVrms/√Hz, which is close to the noise we're seeing above 2 kHz.

Here are two test spectra we took today by locking one Marconi sine wave to the other with our PLL.  The input Marconi was at 101 MHz and -17 dBm, around the same stats as our current beatnote.

The dark blue line is the noise floor with Marconi FM Devn of 1 kHz and SR560 gain of 200.  The light blue is with Marconi FM Devn of 5 kHz and SR560 gain of 500.

From this plot we can see that SR560 noise is hurting us, not Marconi noise.

Edit awade Tue Dec 5 10:34:23 2017: I think maybe the default settings we were using was Marconi slop = 10 kHz/V and SR560 gain of 200 and the 1kHz/V setting we were upping the gain on the SR560 by factor 10 to maintain the same UGF.  But I might be wrong.

Edit awade Tue Dec 5 10:39:01 2017: Also, we need to note the LP settings, I think they were 1 MHz in the case, so unlikely they are important. Might need to test for lower frequency BNs as well, but as it isn't Marconi noise then probably not the issue.

Attachment 1: StitchedSpectrum_MarkoniNoiseSpectra_CarrierFreq_101MHz_FMDevn_1kHz_Span_102p4kHz_Avg_40_PreampGain_200_04-12-2017_180227.tgz
Attachment 2: StitchedSpectrum_MarkoniNoiseSpectra_CarrierFreq_101MHz_FMDevn_1kHz_Span_102p4kHz_Avg_40_PreampGain_200_04-12-2017_180227_Spectra.pdf
1997   Tue Dec 5 21:50:05 2017 Craig, awadeDailyProgressPLLLow Noise RF Amplifier Added to

We noticed the dang SR560 is injecting noise into our beatnote spectrum at high gain.  I found a ZHL-3A low-noise RF amplifier and we've added it in after the transmission beatnote RFPD and in front of the new mixer (ZX05-1MHW-S+) in our PLL loop to amplify our beatnote with low noise.

Our beatnote is ~100MHz.  Amplitude is 2 dBm.  The noise figure of the RF amp at 100 MHz is ~5.5.  RF amplifies the beatnote to 19 dBm (we attached a 10 dBm attenuator to avoid saturation of our mixer, which is rated to 23 dBm RF input).

Before adding in the RF amp, the PLL OLG UGF is ~25kHz.  The SR560 gain is 20.  The Marconi FM Devn is 10 kHz/V.

After adding the RF amp, I took the same spectra with the same PLL settings as before to get a direct comparison.

The plot shows the direct comparison.  The pictures show the settings of the PLL.

Edit (awade) Thu Dec 7 21:23:50 2017: Put the actual part/model numbers.  Links die after a time, you need to actually list the part otherwise it will be a mystery.

Attachment 1: StitchedSpectrum_AfterRFAmp_PLLControlSignal_MarconiFMDevn_10kHz_SR560Gain_20_Avgs_30_Span_102p4kHz_05-12-2017_225050_Spectra.pdf
Attachment 2: StitchedSpectrum_AfterRFAmp_PLLControlSignal_MarconiFMDevn_10kHz_SR560Gain_20_Avgs_30_Span_102p4kHz_05-12-2017_225050.tgz
Attachment 3: 20171205PLLHardware.jpg
Attachment 4: 20171205PLLSR560Preamp.jpg
Attachment 5: 20171205PLLMarconi.jpg
1998   Wed Dec 6 22:55:37 2017 CraigDailyProgressPLLMixer Calibration

Koji met with awade and I today, and told us to understand our PLL noisebudget before doing anything else.  That way, we can know exactly what limits us and can be exact when we reduce noise.  Now the real work begins.

To make a proper PLL noisebudget, we are going to measure shot noise, dark noise, VCO noise, SR560 noise, PLL OLG, and calibrate everything into Hz/rtHz.  This will take a couple of days.

Today, I calibrated our mixer into mV/deg.  I figured out how to set up the Marconi master-slave using the 10 MHz frequency reference they have on the back, then set both Marconi's to 100 MHz RF out at +13 dBm.  I checked the 100 MHz output of each Marconi on the oscope (figure 2).  By adjusting the slave Marconi carrier frequency phase in the menus, I was able to control the relative phase of the PLL.

I then mixed the Marconis together.  I changed the phase from 0 degrees to 180 degrees, recorded the mixer output voltage, and plotted it in Figure 3.

I got a mixer calibration of 7.111 mV/deg at the maximum slope, or 407.4 mV/rad.

Next, we will use this to find the audio frequency noise of the Marconi by feeding the mixer output back to the slave Marconi.  More to come.

Attachment 1: MarconiMasterSlaveSetup.jpg
Attachment 2: Marconi10MHzPLL.jpg
Attachment 3: 20171206_MixerCalibration_mV_per_deg.pdf
1999   Thu Dec 7 00:18:09 2017 KojiDailyProgressPLLMixer Calibration

Specify the power levels at LO and RF inputs. They must be matched with the actual power levels.

2000   Thu Dec 7 14:20:52 2017 CraigDailyProgressPLLMixer Calibration

[Unfinished post]

Took another mixer measurement with LO = 13 dBm and RF = 2 dBm.  Plotted both together.

 Quote: Specify the power levels at LO and RF inputs. They must be matched with the actual power levels.

2001   Thu Dec 7 14:21:41 2017 CraigDailyProgressPLLMixer Calibration

Took another mixer measurement with LO = 13 dBm and RF = 2 dBm.  Plotted RF = 13 dBm and RF = 2 dBm together.

 Quote: Specify the power levels at LO and RF inputs. They must be matched with the actual power levels.

Attachment 1: 20171207_MixerCalibration_mV_per_deg.pdf
2002   Thu Dec 7 15:56:53 2017 Craig, awadeDailyProgressPLLCalibrated Freerunning Marconi Noise

We measured the freerunning Marconi noise and calibrated it (Plot 2).

We are interested in the audio band frequency noise of the Marconi, so we mixed down two of them together, one as the LO at 13 dBm and one as the "beatnote Marconi" at 2 dBm.  Both Marconis were set to 100 MHz.

The equation I used for calibration was

$S_{f}(f) = \dfrac{S_V(f)}{\sqrt{2} M L}\times f$

where Sv(f) is the ASD from the SR785, M is the mixer factor in volts/rad, L is the low pass filter, and f is the measurement frequency in Hz.  The root 2 compensates for the noise from two Marconis.

From my previous elog on the mixer calibration:

$M L = 0.208 \, \frac{V}{\text{rad}}$

so I scaled the SR785 measurements by 3.40 and $f$ to get $S_f(f)$.

There are strong peaks in this freerunning spectrum, the biggest one at around 84 Hz.  This goes away when you lock the loop.  A closed loop analysis of the Marconi is forthcoming.

Attachment 1: FreerunningMarconiNoiseDiagram.jpg
Attachment 2: StitchedSpectrum_FreeRunningMarconiNoise_MarconiFMDevn_1kHz_Avgs_30_Span_102p4kHz_07-12-2017_151610_Spectrum.pdf
Attachment 3: StitchedSpectrum_FreeRunningMarconiNoise_MarconiFMDevn_1kHz_Avgs_30_Span_102p4kHz_07-12-2017_151610.tgz
2008   Mon Dec 11 22:41:12 2017 CraigDailyProgressPLLNew PLL calibrated spectra / jupyter notebook

I created a new jupyter notebook which illustrates how we are calibrating our PLL, since this generated confusion last time.  I what I called "Marconi noise" is actually PLL readout noise.

I took a full suite of PLL control signal spectra and PLL error signal spectra, as well as a PLL OLG measurement.

Plot one shows the PLL measurement, plus a linear fit I made to get the UGF.

Plot two shows the calibrated beatnote spectra from the control signal (dark blue) and the error signal (light blue).

Plot three shows our PLL block diagram which is embedded in the jupyter notebook.

EDIT: Plot four is the new noisebudget. See the HTML version here.

In plot two, there are two crossovers between the calibrated spectra.  To me this means that one of our limiting noise sources is not the beatnote, and is increased artificially between the error and control signals.  Most likely culprit is the SR560.  Plans for a low noise amplifier are underway.

PLL OLG unity gain frequency: 1.311 kHz

Marconi FM Devn: 1 kHz/V

SR560 Preamp Gain: 20 V/V

The above implies a mixer/low pass filter TF of about 0.07 V/rad, since UGF = Marconi * Preamp * Mixer * LowPass (see jupyter notebook for a clearer explanation).

Beatnote Strength: -2 dBm at 122 MHz.

I am in the process of putting this in our noisebudget.

I have to make a script which splices together the error and control signal calibrated spectra into a single spectrum at the UGF.  Should be a quick thing.

EDIT: Just included this in the new noisebudget.  See plot four.  I created a calibrated spectrum splicer which cuts and pastes two calibrated spectra together based on whether it originated from a control signal or error signal spectrum.

Important sidenote:  Andrew just came in here and flicked on the air compressor which is pressurizing the nitrogen bottle which is floating the table.  When I looked at our PLL right after he turned on the compressor, the noise dropped by a factor of 4 at least, allowing much easier locking of the PLL.  This is not immediately quantifiable, I was just standing there when it happened.  Should be investigated further.

Further investigate revealed that turning on the air compressor drastically improved our mode matching, which is optimized for a floated table.  Our beatnote strength quickly increased from -2 dBm to +4dBm.  We need to get a stable pressure on our table at all times, rather than this slow losses over the day from the air compressor.

Attachment 1: 20171211_223559_PLLOLGUGF.pdf
Attachment 2: 20171211_223333_CalibratedBeatnoteSpectrum_fromcontrolSignal_Spectra.pdf
Attachment 3: 20171211_223333_CalibratedBeatnoteSpectrum_fromcontrolSignal.tgz
Attachment 4: PLLBlockDiagram.jpg
Attachment 5: 20171212_001039noiseBudget.pdf
2031   Fri Jan 5 12:29:55 2018 CraigDailyProgressPLLPLL Mixer Circuit Board Made and Attached to Rack #EOM
Attachment 1: PLLMixerCircuitboard.jpg
2126   Fri Mar 9 02:15:08 2018 CraigDailyProgressPLLPLL Autolocker is all

I just wrote a huge elog explaining the entire PLLautolocker.py but the ELOG ate it.
Basically, it works.  It's on acromag1 in a tmux session.  Check out the sweet MEDM screens I made.  You can use them to control PLLautolocker.py.

2284   Wed Jan 16 22:07:44 2019 awade, anchalDailyProgressPLLPLL noise from the Marconi 2023A FG

This is not a detailed post as I didn't collect data.  We need to check the actual noise performance of the Marconi and compare.  It seems like the marconi used in the PLL has some nasty frequency spikes and generally higher noise.

Today I dug out a Wenzel crystal OCOX oscillator (Freq 24.483 MHz) from the QIL lab to check the performance of the Marconi FG against a stable reference. These crystals are a good reference to compare to as they should have a noise floor of -165 dBc/Hz vs the marconi performance of -124 dBc/Hz (@ 20 kHz) operating at 470 MHz (datasheet didn't have values for smaller freq).

The output is +13 dBm so I attenuated by 13 dB to give a simulated BN signal of about 0 dBm (gives mixer gain 0.210V/rad).  This was then substituted for the beat note signal and and the PLL was locked with the Marconi carrier close to the nominal crystal frequency.  Marconi slope was set to 1 kHz/V, LO carrier was +13 dB into mixer (lv13), SR560 gain was 20.  Screen shot picture (attached below) shows the original Marconi (labeled #539) in the reference trace and the spare PSL lab Marconi (labeled BD90200).  Sorry there is no data capture, I was using the SR785 from the EEshop that isn't configured for our lab IP addresses.

What we see is at least 10 dB worse performance for exactly the same marconi settings.  We can also see that there is also a huge spike at about ~1kHz.  This could be the source of some of the humping in the BN spectrum. Not sure about this but maybe some of the LF noise in the spectrum gets convoluted about this strong spike, smearing noise out at the higher frequencies.

The Marconi in the cryo lab, from the cryo-CTN experiment was also procured.  The noise on that Marconi was even lower and did not have any spike artifacts. However, I was able to see a bit of a spike when the external modulation voltage was a little bit negative.

I then messed around with some of the settings buried in the menu, I turned the external RF clock reference off on the cryo Marconi and also activated the RFDC null with the modulation BNC 50Ω terminated.  After I had changed some of these things I was not quite sure if I recovered the same noise performance from the better units.  Also, I noticed that the 10 kHz/V range on the cryo Marconi didn't want to lock at all, it was as if there was no actuation going on; it worked fine on settings <=4 kHz/V, just not higher, not sure what is wrong here.

We need to do some detailed measurements tomorrow at a range of different frequencies to nail down exactly what is going on here.  As the VCO noise in the PLL loop is not suppressed by the loop gain, this goes strait to the bottom line of the BN spectrum.  We need to know that PLL is not limited by the Marconi noise.

Measurements to do:

1. PLL BN spectrum with all three Marconis at 24.483 MHz for 0.5 kHz, 1 kHz, 5 kHz and 10 kHz
2. PLL BN spectrum with all three Marconis at doubled/ tripled and quadrupled frequencies (or whatever Wenzel crystals we can get) to check if its just this frequency range
3. Debug cryo Marconi and see why it won't lock PLL on the 10 kHz range
4. Stabilize Marconi to external Rb clock from cryo lab and see if performance is improved
5. (optional) run 10 MHz line along back of labs to PSL lab from cryo so we have a GPS stabilized reference to work with (low priority)

---

Also, we want to take some BN with the old Marconi swapped out.  You should have all the data you need for drift of AD590 sensor traducers by now. The old TIA circuit is so badly designed that its almost certainly doing a feed forward from room temperature to can heaters. Either install the new circuit proto or turn the vacuum can thermal controls OFF completely. Just install what you have and use the secondary circuit as a your tester.  But don't spend any more time making everything perfect: you are getting 1/t returns on your time on this one. You'll want to box it up and make a yellow Styrofoam insulator box to shield it more from room temp changes.

Attachment 2: IMG_4877.JPG
2286   Fri Jan 18 13:10:02 2019 anchalDailyProgressPLLPLL noise from the Marconi 2023A FG

I took the noise spectrum of beat note in PLL when it is fed with a low noise Wenzel Crystal Oscillator of frequency 24.483 MHz and doubled frequency 48.967 MHz.

### Method:

• Instead of feeding Beat note from cavities, I fed crystal oscillator signal to the mixer in PLL.
• We tried to keep the strength of the crystal oscillator signal similar to beatnote strength from cavities which is around 0 dBm.
• At 24.483 MHz, the signal was -0.1808 dBm.
• I also took readings with a frequency doubled signal. Frequency was doubled by splitting the 24.483 MHz signal and mixing the two outputs at a mixer with an appropriate phase delay in one path.
• At 48.967 MHz, the signal was -1.16 dBm.
• Spectrum was taken for 4 different actuation slopes (S) at Marconi, 0.5 kHz/V, 1 kHz/V, 5 kHz/V and 10 kHz/V. The gain of SR560 (A) was changed accordingly to keep S*A = 500 kHz/V. This was the maximum we were able to achieve without overloading the SR560.
• Two different Marconi were tested. One is labeled '#539' and other one is labeled 'PD9020'. We tried to work with a third one from cryo lab but it was giving a weird GPIB error 'Fractional N-Loop High' without GPIB-Ethernet controller connected at all RF Level above -90 dBm.
• During all measurements, Marconis were using external frequency standard (direct mode) and were connected to Rubidium Frequency Standard SRS FS725 10 MHz sine wave output.
• Each measurement was taken in two parts, one with linewidth 16 Hz up to 1.28 kHz and one with linewidth 128 Hz up to 102.4 kHz. RMS averaging was done for an averaging factor of 100. BMH window was used.

### Conclusions:

• Marconi '#539' won the race with lower noise at all frequencies.
• The plots show noise for the beat note frequency but since the crystal oscillator is about 25 dB less noisy then Marconi, this noise is almost entirely due to Marconi and SR560. SR560 has ~ $2 \, mHz/\sqrt{Hz}}$ noise contribution above 10 Hz for all actuation slope values (this remains constant as S*A = 500 kHz/V always).
• Clearly lower actuation slope decreased the noise due to Marconi significantly. So we would like to keep drift of beat note frequency of cavities as low as possible.
• One alarming concern is the presence of a sharp peak in Marconi noise at ~900 Hz. This will mix with low-frequency noise of incoming beat note frequency and would create humps near kHz region.
• We need to figure out why this peak is there in the Marconi noise spectrum and what we can do to take it off.
• Possible candidates: Spurious cross-coupling with something else, reflections between the mixer and low pass filter in PLL due to impedance mismatch, inherent peak in SR560??
Attachment 1: MarconiPLLNoiseAnalysis.pdf
Attachment 2: Marconi_PLL_Noise.zip
2287   Mon Jan 21 19:01:11 2019 anchalNotesPLLPLL Transfer Function and Noise Study

I see that we were lacking in complete documentation of PLL transfer function and noise analysis. I made this document for the same.

https://git.ligo.org/cit-ctnlab/ctn_noisebudget/blob/master/technicalNotes/Beatnote_PLL_Loop_Study.pdf

Edit Fri May 17 14:02:14 2019:

Above link is no longer maintained. Now there is a DCC doc (see LIGO-T1900263) for this analysis.

2288   Tue Jan 22 19:04:51 2019 anchalDailyProgressPLLNew Focus 1811-FC Dark noise Measurement

We suspected if the wideband RF detector New Focus 1811-FC could be the source of noise floor through its dark noise. So I took dark noise spectrum measurements today of this photodetector.

### Method:

• I blocked the photodetector with a beam dump.
• First I took the spectrum directly from the RF port using HP 4395A in spectrum analyzer mode, from 0 to 130 MHz with 3kHz ResBW and 50 averages.
• I converted dBm to V_rms using 10**((P_dbm-13)/20) and then divided by np.sqrt(3e3) to get spectrum in Vrms/rtHz.
• Next, I measured the dark noise spectrum by mixing it down with a local oscillator using the same ZX05-1MHW mixer we use in the PLL.
• First I used the Wenzel crystal oscillator at 24.483 MHz as LO.
• Then I used Marconi at the same frequency for comparison.
• I also took mixed down measurements for 27.34 MHz(Resonant RFPD peak point), 50MHz, 75 MHz, 100MHz and 125MHz.
• All these later measurements were taken by SR785 from 0 to 102.4 kHz (in 3 steps) with rms averaging of 100 factor and BMH windowing.

### Conclusions:

• Contrary to our expectation, mixed down dark noise is more than the direct dark noise from RF port. The mixer should have same conversion loss for dark noise and should also be suppressing one quadrature, so the output from the mixer should be less noisy.
• I think I have missed something in these measurements. It looks too bad to be true. In past, we have been running beat note measurements with S*A (Actuator Slop x Amplifier gain) of 200-500 kHz. With the measured noise after mixing down, it would correspond to 0.6 - 1.5 Hz/rtHz.
• We do have a noise floor around these values but we also have measurements going below 1 Hz/rtHz, so something seems fishy.
• At the time of writing this post, we quickly did a dark noise measurement with the resonant RFPD at 27.34 MHz with Marconi and its dark noise after mixing down is around 12 nV/Hz. Much much better!

Edit Tue Jan 22 20:06:00 2019

## Correction:

• When we measured resonant RFPD, measurements made more sense. The direct noise from RF port was higher and the noise after mixing down was lower by conversion loss and factor of sqrt(2) due to the suppression of one quadrature.
• So we decided to measure the wideband RFPD again. To our surprise, this time the measurements made sense. PFA the new plots with new measurements.
• The mystery is still on for what caused the measurements to be bad earlier. We can not find anything that we changed except for switching RFPDs back and forth.
• So from new measurements, it seems like mixed down dark noise is at the level of 100 nV/rtHz. It is higher at other frequencies mostly because of Marconi's inherent noise. We should trust the result with crystal oscillator (black curve) more.
• This would correspond to 50 mHz/rtHz of flat noise contribution from the dark noise. This is way below the measured noise floor in our beat note spectrums. So phot detector dark noise is off the hook (for now).
• We need to continue our search for the culprit.
Attachment 1: NewFocus1811-FC_DarkNoiseSpectrum.pdf
Attachment 2: NewFocus1811-FCDarkNoiseSpectrum.ipynb.zip
Attachment 3: NewFocus1811-FC_DarkNoiseSpectrum_New.pdf
Attachment 4: NewFocus1811-FCDarkNoiseSpectrumNew.ipynb.zip
2291   Wed Jan 23 11:43:02 2019 awade, anchalDailyProgressPLLNew Focus 1811-FC Dark noise Measurement

The first measurement here seems like a smoking gun for limiting noise.  A mixer down converted noise of 1.3 µV/rtHz (directly out of the mixer) with a S*A (VCO + SR560) gain of 200 kHz/V would be 0.26 Hz/rtHz. That would be consistent with the noise floor of the more recent BN PSDs. The PLL open loop gain will change this estimate, but the 200 kHz/V gives a lower bound. This initial measurement of NF1811 noise was a factor of ten more than spec for this detector. It should be ~100 nV/rtHz (equivalent to input ref noise of 2.5 pW/rtHz at peak responsively).  We should have traced back to the source of this earlier, but now that we know its a potential problem we should double check if we're having issues with BN noise floor not matching up with the noise budget.

Its weird that the second measurement of the same NF1811 seems to show it performing closer to its spec value. The setup for measurment was exactly the same.  I should note that when we were making these measurements we switched the BN cable from the NF1811 to the resonant 27.34 MHz detector and back again.  I also wiggled the power cable at the time. I've seen in the past that when there is a power connector issue, the NF1811 can produce something that looks like signal but with RF oscillations if there is a problem with one of the power rails.  We probably should have checked at the time with an oscilloscope to see if there were any issues with the RF signal coming out of the NF1811.  It could be that there was some kind of oscillation or other bad thing going on and the act of unloading and reloading the output with 50 Ω and wiggling the power connector some how got it back to proper operation.

For now we should should recheck the NF1811 dark noise (after mixing down) before making another BN measurement and not touch connectors on the detector side in case there is a flaky connection.

You definitely​ saw the higher noise state, so I wouldn't dismiss it yet. I guess we won't know if the reduced noise second measurement will bring down out noise floor until we see a BN measurement.

Quote:

We suspected if the wideband RF detector New Focus 1811-FC could be the source of noise floor through its dark noise. So I took dark noise spectrum measurements today of this photodetector.

### Method:

• I blocked the photodetector with a beam dump.
• First I took the spectrum directly from the RF port using HP 4395A in spectrum analyzer mode, from 0 to 130 MHz with 3kHz ResBW and 50 averages.
• I converted dBm to V_rms using 10**((P_dbm-13)/20) and then divided by np.sqrt(3e3) to get spectrum in Vrms/rtHz.
• Next, I measured the dark noise spectrum by mixing it down with a local oscillator using the same ZX05-1MHW mixer we use in the PLL.
• First I used the Wenzel crystal oscillator at 24.483 MHz as LO.
• Then I used Marconi at the same frequency for comparison.
• I also took mixed down measurements for 27.34 MHz(Resonant RFPD peak point), 50MHz, 75 MHz, 100MHz and 125MHz.
• All these later measurements were taken by SR785 from 0 to 102.4 kHz (in 3 steps) with rms averaging of 100 factor and BMH windowing.

### Conclusions:

• Contrary to our expectation, mixed down dark noise is more than the direct dark noise from RF port. The mixer should have same conversion loss for dark noise and should also be suppressing one quadrature, so the output from the mixer should be less noisy.
• I think I have missed something in these measurements. It looks too bad to be true. In past, we have been running beat note measurements with S*A (Actuator Slop x Amplifier gain) of 200-500 kHz. With the measured noise after mixing down, it would correspond to 0.6 - 1.5 Hz/rtHz.
• We do have a noise floor around these values but we also have measurements going below 1 Hz/rtHz, so something seems fishy.
• At the time of writing this post, we quickly did a dark noise measurement with the resonant RFPD at 27.34 MHz with Marconi and its dark noise after mixing down is around 12 nV/Hz. Much much better!

Edit Tue Jan 22 20:06:00 2019

## Correction:

• When we measured resonant RFPD, measurements made more sense. The direct noise from RF port was higher and the noise after mixing down was lower by conversion loss and factor of sqrt(2) due to the suppression of one quadrature.
• So we decided to measure the wideband RFPD again. To our surprise, this time the measurements made sense. PFA the new plots with new measurements.
• The mystery is still on for what caused the measurements to be bad earlier. We can not find anything that we changed except for switching RFPDs back and forth.
• So from new measurements, it seems like mixed down dark noise is at the level of 100 nV/rtHz. It is higher at other frequencies mostly because of Marconi's inherent noise. We should trust the result with crystal oscillator (black curve) more.
• This would correspond to 50 mHz/rtHz of flat noise contribution from the dark noise. This is way below the measured noise floor in our beat note spectrums. So phot detector dark noise is off the hook (for now).
• We need to continue our search for the culprit.

2337   Mon May 6 20:49:03 2019 anchalNotesPLLUsing PLL for Frequency Noise Measurement

I have finally completed the documentation for mathematical analysis of using PLL for frequency noise measurement. This document also contains noise analysis for various sources.

https://dcc.ligo.org/T1900263

127   Mon May 24 09:56:19 2010 ranaLaserPMCPMC is almost ready to be locked

You should make sure not to blow up the PMC PD: i.e. the total power on the PD out of lock should be less than 100 mW. The beam size on the PD should also be ~0.5 mm diameter with the actual beam waist being more like 0.3 mm dia.

PD should also be tilted by ~30 deg from normal incidence and the reflection dumped. Its OK if the RF output saturates somewhat at the peak of the PDH signal, but the in-lock RF level should be below ~50 mVrms into 50 Ohms.

128   Mon May 24 19:30:15 2010 ranaLaserPMCPMC is almost ready to be locked

 Quote: You should make sure not to blow up the PMC PD: i.e. the total power on the PD out of lock should be less than 100 mW. The beam size on the PD should also be ~0.5 mm diameter with the actual beam waist being more like 0.3 mm dia. PD should also be tilted by ~30 deg from normal incidence and the reflection dumped. Its OK if the RF output saturates somewhat at the peak of the PDH signal, but the in-lock RF level should be below ~50 mVrms into 50 Ohms.

The power is small, our laser is 100 mW. The power on the PD is not saturated. Right now it's receiving ~10mW. It's tilted a bit and the reflected beam is blocked appropriately.

165   Tue Jun 15 21:28:57 2010 FrankMiscPMCPMC servo problem fixed

found the problem why the PMC servo card wasn't working: the medm screens on the sun workstation didn't have a toggle button for the disable signal for the variable gain amplifier (AD602). this signal was set to "disabled" by default and because there was no button to enable it Tara couldn't get the servo to work. added a toggle button on the screen, PMC is now locked stable

the PMC seems to be very dirty. If we lock it in s-pol the transmitted power is only 7%, even if 60% are going into it (didn't try to optimize it). the rest is dumped in the pmc. switched back to p-pol but should think about cleaning the mirrors. we also have first contact. i think it's worth a try and we can't loose much. peter has also spare mirrors (and a spare spacer)

168   Wed Jun 16 19:43:00 2010 taracLaserPMCPMC and EOM alignment

We try optimizing the PMC transmission in P wave. The maximum we can get for now is ~82%.

The 21.5 EOM is prealigned. We will do fine adjustment again when insulating cables are made.

EOM alignment means to align the polarization of the beam to match the applied electric field in the EOM. This will minimize the amplitude modulating effect.

There are 3 degrees of freedom, 2 for EOM positions, another one is the polarization of the beam.

The 35.5 EOM is also pre aligned, the signal is very small, probably because of its broadband type. I use 4395A spectrum analyzer to see the peak at 35.5 MHz, but it's really hard to tell if I minimize it or not.

I see the thermal effect on EOM crystal clearly when I adjust the EOM. After I minimize the Amplitude Modulation (AM) and left the EOM for awhile, the misalignment gradually increase.

Frank suggests that the calibration of the error signal should be done, so that we can approximate how well the temperature must be controlled to reach our noise budget. I'll think about that measurement.

As I finished my elog, the peak at 35.5 just went up. Case in point.

170   Mon Jun 21 19:19:12 2010 taracLaserPMCProgress on PSL setup: Tuning phase shift/RF power for PMC

All SMA cables for locking RefCav are made and wired up in their places.

We decide to turn the power up to 50mW before it enters PMC. With ~80% efficiency, we get 40 mW out.

I adjusted RF power and phase shift for PMC and saved it in the init file so that next time we reboot the crate, the values will be set.

Next: I'll lock the RefCav and optimize the alignment.

177   Mon Jun 28 19:06:40 2010 taracDailyProgressPMCPMC acting weird

This morning, the PMC couldn't be locked to the laser. The FSS servo was disabled during that time.

When the gain/ RF power were adjusted, PMC was locked to the laser, but the coupling efficiency dropped from 80% to 40%.

I try adjusting the mirror, but it's not the alignment problem because I couldn't increase the efficiency.

So after the noise budget party with Jan and Frank, I check if the EOM works looking at the error signal from mixer out.  The laser frequency is scan at +/- 10V @ 100 Hz.

I'm not sure what is the corresponding freq span, but it must be less than 43 MHz(21.5 MHz x 2) because

three peaks of the signal could not be seen with +/- 10V span, so I use a voltage calibrator to slowly adjust the temperature and see the rest of the signals.

Nevertheless, the signals are there, so I try to lock the PMC again, and now the efficiency back to almost 80% again ( I have to re align again because of the earlier adjustment. The mixer out channel is monitored when I set the PMC gain to make sure there will be no oscillation.

I'm not sure what happen, loosen connectors, mode hopping in the laser, etc. I'll see if I can track this down , otherwise we could not have a stable locking system.

186   Tue Jun 29 17:57:40 2010 taracNotesPMCcoupling eff vs Temperature

We had a problem with power coupling efficiency to the PMC.  Sometime it changes from 80% to 40% or less.

When the temperature of the NPRO is varied by a voltage calibrator @ slow actuator input of the laser controller,

at certain T(V), the coupling efficiency drops from 80% to 40% or less. This might be mode hopping.  However, the transmitted beam power still oscillates ,

and one can see the beam spot pulsating on the screen. I thought it might be mode hopping too, but after changing T, the fluctuation of the power has not gone, there is some suppression though. So it might be the servo. I'll check the TF of the servo and compare it with the schematic, D980352-B-1.

187   Tue Jun 29 23:56:38 2010 taracNotesPMCPMC servo debugging

I was going to check the TF on each stage of PMC's servo.

Unfortunately, I couldn't find the floppy disc drive, so I slide the sliders (gain, RF power) around. When I add more RF power (from 1V to 7V) to 21.5 MHz EOM, the oscilaltion subsides*.

(*5 mins later I came back to turn down the RF power to 1 V again, and the beam was perfectly locked for a few minutes before fluctuated again)

It's not a long term solution, but I note this for further debugging.

One thing about the gain, I see the TF of the whole PMC servo, when I increase the common gain from 0 to ~8 dB, the magnitude of the TF gets higher. If I increase more gain to ~ 10dB or something, the magnitude goes down . So there might be sth wrong about the opamp that controls the gain.

190   Wed Jun 30 11:34:37 2010 FrankHowToPMCPMC fixed

the reason why you had this flickering problem was that you had too much power on the RFPD in reflection of the PMC. You already saturated it.
I also reduced the RF power as the error signals were not signals anymore, just spikes.

my new settings are:

RF power : 3.0
Phase : 2.5
PMC Gain: 14dB

reduced laser power to 40mW. Transmitted power is 32mW .You have to exchange the output coupler mirror in front of the RFPD in order to increase the power. I think 32mW is enough, it's something like 13mW per cavity.

191   Wed Jun 30 12:31:22 2010 taracHowToPMCPMC fixed

 Quote: the reason why you had this flickering problem was that you had too much power on the RFPD in reflection of the PMC. You already saturated it. I also reduced the RF power as the error signals were not signals anymore, just spikes. my new settings are: RF power : 3.0 Phase : 2.5 PMC Gain: 14dB reduced laser power to 40mW. Transmitted power is 32mW .You have to exchange the output coupler mirror in front of the RFPD in order to increase the power. I think 32mW is enough, it's something like 13mW per cavity.

Ok, I'll find another output coupler mirror and replace the current one, and make sure that it will not saturate the RFPD.

192   Wed Jun 30 12:39:17 2010 FrankHowToPMCPMC fixed

Quote:

 Quote: the reason why you had this flickering problem was that you had too much power on the RFPD in reflection of the PMC. You already saturated it. I also reduced the RF power as the error signals were not signals anymore, just spikes. my new settings are: RF power : 3.0 Phase : 2.5 PMC Gain: 14dB reduced laser power to 40mW. Transmitted power is 32mW .You have to exchange the output coupler mirror in front of the RFPD in order to increase the power. I think 32mW is enough, it's something like 13mW per cavity.

Ok, I'll find another output coupler mirror and replace the current one, and make sure that it will not saturate the RFPD.

the saturating power seems to be much to low. it saturates at .5V DC, usually you can have something like 2V or so. So we should propably fix the PD even if it is working with lower power levels.

For now it's much more important to connect all the signals to the DAQ and lock the refcav. You still have to make a lot of cables, like the ones going to the laser (fast & slow), RFPD DC, PMC and refcav transmitted light, refcav RFPD DC etc.

220   Thu Jul 15 15:08:46 2010 FrankNotesPMCcurrent values to lock system

personal notes to lock system remotely:

for PMC:
PMC voltage 203.5V --> DC offset -3.258
slow DC value : 0.15
PMC transmission value: 0.291V

226   Thu Jul 15 20:30:30 2010 FrankNotesPMCPMC scan

PMC scanned using slow actuator (NPRO temp)

360   Tue Sep 14 20:14:37 2010 taraDailyProgressPMCPMC open loop TF

Today I measured open loop transfer function of PMC loop.

The measurement has two parts.

First the swept sine signal is sent to FP2 test point, TP4 is connected to A, TP3 is connected to B,

the magnitude, B/A, gives us [C][D][E] .

For the second part, the swept sine is sent to ext DC channel,

TP3 is connected to A, and TP4 is connected to B.

this is the TF of [F][A][B]

======================================================================

[A]--<FP2>-----[B]-----{TP4} ------[C]-----[D]---<Ext DC> ----[E] ---- {TP3}----[F]-----> back to [A]

======================================================================

The magnitudes and phase from both measurements are added up

to get the whole open loop TF of PMC loop [A][B][C][D][E][F].

UGF is ~1k Hz.

PMC setup

Gain 30dB (mzx)

LO PWR 0.585

Power input 30.9 mW

PMC_PHCON 2.5 + 180 flip

I'll verify that the schematic matches up with the real circuit we are using.

Attachment 1: pmc_bode.png
362   Wed Sep 15 22:43:41 2010 taraDailyProgressPMCchecking pmc servo

I checked PMC circuit to make sure that the schematic matches the actual board.

This is important because we want to make sure that it works exactly the way it should.

This is also useful when we want to modify it.

I check R and C on the board, everything seems fine except R2.

It says 9091 F which matches the schematic (9.09 k), but a multimeter reads 4.5 K, I might measure it wrong.

I also measured the TF between TP2 and TP4, I'll attach the result.

When I measured TF between TP3 and TP8,  I did not fully push the card into the socket, and this killed PA85 when I applied high voltage to the card.

Koji found me an unused Mach-Zender card at 40m. I replaced its PA85 for PMC card.

I tried it. This time, I made sure that the card was properly in its place, I screwed it down to the crate.

Then I connected PD cable, LO cable, HVout then HVin.

However, it sitll does not work , no high Voltage coming out. Only low voltage ~0.5 V which changes with the value on the PMC DC control slider.

I don't know if I accidentally killed it during the transplant operation.

It's a very bad day to be PA85.

Attachment 1: D980352-D.pdf
363   Thu Sep 16 15:16:28 2010 taraNotesPMCPMC card is working

When I showed Frank that the card did not work, I mentioned that I got electric shock when I connected high voltage input to the card.

Frank realized that it happens only when the connector is not grounded, and it was not. The ground connection from HVin to the card

was broken, It's hard to see unless I touched the wire that connected the board to the female BNC on the panel. I replaced that rigid wire by a flexible wire.

Now the PMC card is working fine, and the original PA85 might not be broken at all.

364   Thu Sep 16 22:50:12 2010 taraNotesPMCPMC servo TF on simulink

I'm working on Simulink model to calculate PMC's open loop gain. For now, all the parameters for frequency discriminator are copied from linfss6.m.

I'll work on correcting those parameters later.

The simulink model will allow us to learn how external noise will look like in our system.

The bode plot for PMC's TF is plotted in fig1.

I'm not sure why the measurement on both magnitude and phase looks bad at low frequency (f<10 Hz).

I think the model (fig2) is not correct because of the wrong units ( angular frequency,w, to frequency, f.) I'll check  this again.

The phase part seem to be completely wrong.

The parameters, (for example, cavitiy pole, frequency discriminator) for  the TF are not confirmed yet. I'll elog them once I verify them.

*******************************

Yesterday, I had a chance to test U6(OPA 27) in the schematic.The measurement agrees very well with the computed result, see fig 3.

The signal from source out was sent through FP2 test. TP2 and TP4 were connected to channel A and B on SR785 respectively.

SR785 was set to swept sine mode, frequency span from 1Hz to 10^5 Hz.

So we know that at least one part of the servo works properly.

Attachment 1: UGF_bode.png
Attachment 2: UGF_bode_com.png
Attachment 3: U6.png
365   Sat Sep 18 01:12:03 2010 taraSummaryPMCLISO model of the PMC servo

I started work on a LISO model of the PMC servo - it does not yet agree with reality.

Yesterday, I measured the open loop gain (OLG) of the PMC loop.

It consists of two parts, which are the PMC servo's OLG and the rest, i.e. OLG of photodiode, PMC, PZT actuator.

Knowing each part's OLG is useful for modification.

Since we are going to do most modification on the PMC's servo, we want to know what is its TF.

This is where LISO comes in. I use it to simulate the TF of the PMC servo.

I don't know how to model AD602, because it is not actually an opamp and therefore not in the LISO opamp library.

The datasheet says it has -3db at 35MHz. Thus, for our region of interest, it probably has a flat response. It is just an

I'm not sure how to use LISO to calculate poles and zeros of my model yet. I'm reading the manual.

This simulation will be compared with the measurement.

Once we verify that all the parts behave the way they should, we can think about the modification.

We want to modify the TF because even though we maximize the gain slider, the system is still stable

( no sign of oscillaltion from too much gain.) It means we can still optimize our TF for better stability.

Lastly, knowing the servo's OLG and the whole loop OLG,

we can compute what is the OLG of the rest of the system by simple subtraction.

I hope the quality of this elog entry is improved, however slightly it might be. It has motivation why I do what I do, details, and people who want to reproduce my work should be able to follow it.

Thanks Koji for a useful discussion on how to elog properly.

The attached plot shows modeled transfer function of the PMC Servo card + PZT capacitance.

Components' names in LISO code are taken from the schematic

Attachment 1: 2010-09-18_01-06-08.png
Attachment 2: pmc.fil
#  Noise sim for pmc servo
# Tara C, 2010_09_17
#
#
#

r   R41  49.9   n0   gnd
l   L1   20u    n0   n1
r   R42  470    n1   n2
c   C4   82p    n2   gnd

... 56 more lines ...
ELOG V3.1.3-