40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  PSL, Page 6 of 52  Not logged in ELOG logo
ID Date Author Type Category Subject
  2357   Mon Jun 17 18:05:20 2019 anchalDailyProgressBEATMoku Frequency Noise Measurement

I thought, why not just measure Moku's own synthesized frequency output with itself. Attached plot shows the frequency noise measured this way. The measured noise is divided by the square root of 2 to get individual input referred noise of the phase meter.

Then I thought, maybe the phase noises in the synthesized frequency and phase noise of phase meter could be potentially canceling each other as they are coming through the same source. So I inserted a very long cable between output of Moku and it's phasemeter input so that the two things are time separated by at least 1 cycle of 27.34 MHz. I didn't want to open up and measure the length of these neatly packed SMA cables but they are surely more than 6.58 m (wavelength of 27.34 MHz in these cables) long together.


Conclusions:

  • I do not see any reason why this measurement would not be correct unless the correlation length of phase noise in time is really long and I need a cable which separates the input and output of Moku by many cycles of 27.34 MHz.
  • So under the above assumption, Moku's phasemeter input referred frequency noise is less than 1mHz/rtHz up to 4 kHz and is less than 0.1 mHz/rtHz up to ~250 Hz.
  • If these numbers are correct, we should be good to go with using Moku as our phasemeter instead of our clunky PLL.
Attachment 2: MokuSelfFreqNoiseAnalysis.pdf
MokuSelfFreqNoiseAnalysis.pdf
  2356   Fri Jun 7 17:42:06 2019 anchalDailyProgressBEATThree Corner Hat Method

A wise man told me to use three corner hat method to extract individual frequency noise information of Marconi, Moku and the Wenzel crystal. I updated my mokuReadFreqNoise.py to support frequency noise calculation for two channels and their difference.

I'm perplexed to see the result actually and I'm not sure if this is what was expected. 


Measurement details:

I did two identical runs (I wasn't sure if I was seeing the truth from my first run) with the following settings:

  • Both Marconi and Moku are directly connected to Rb 10 MHz clock with equal length cables.
  • Wenzel Crystal 500-13905 oscillating at 24.4835 MHz was connected to input 1 of Moku.
  • Marconi with set to same frequency was connected to input 2 of Moku. Note that modulation feature was not on in this experiment so the expected noise is lower than CTN:2286 experiment.
  • With two channels recording, the acquisition rate is 15.625 kSa/s only.

Analysis:

  • In the first plot, I just plotted the frequency noise of input 1 (Wenzel), input 2 (Marconi) and (input 2 - input 1) using mokuReadFreqNoise.py. Although I have checked this code multiple times, I really want a new set of eyes to go through it and confirm it is calculating this correctly.
  • I assumed that the difference between two channels will have negligible frequency noise of Moku itself and is a good approximation of frequency noise between Wenzel and Marconi.
  • In the second plot, I used the 3 corner hat method to calculate individual frequency noise ASDs of the three instruments. Some points are missing as the sum of two contributing PSDs was lower than non-contributing PSD at some points.
  • In the third plot, to disregard the assumption I have made above, I used data from CTN:2286 experiment. Remember though that in this experiment, modulation was on at 500 Hz/V actuation slope.
  • In the fourth plot, I used 3 corner hat method again but with CTN:2286 experiment data.

Implications:

  • Well clearly the 4th plot is useless. It is comparing two different versions of Marconi data, so it is essentially blurring out all data.
  • From 2nd plot, if this experiment was meaningful, even though Moku seems an order of magnitude more noisy than Marcon (which is just freely running), Moku's frequency noise is less than 2 mHz/rtHz upto 400Hz and if we ignore the bump at 500 Hz as some experimental artifact, is less than 3 mHz/rtHz upto 1 kHz. Expected coating brownian noise is between 4-10 mHz/rtHz from 100Hz-400Hz region.
  • Ideally, we would like an order of magnitude lower instrument noise than what we are trying to measure. So maybe Moku is not a good choice.
  • But I still am not sure if I should take strong inferences from this experiment because when I do low acquisition and use Moku's inbuilt frequency noise ASD plotter, I get results as attachment 3 which is also a check of how good my code computes the ASD.
  • This graph shows that the difference spectra is growing above 100 Hz contrary to previous results. This would mean that the frequency noise of moku is least above 100 Hz.  But that is not the case when I do a fast acquisition.
  • So overall, after today's efforts, I'm back to square one. I'm not sure if Moku should be used for frequency noise measurement
Attachment 1: MokuFreqAnalysis3CorHat_Run1.pdf
MokuFreqAnalysis3CorHat_Run1.pdf MokuFreqAnalysis3CorHat_Run1.pdf MokuFreqAnalysis3CorHat_Run1.pdf MokuFreqAnalysis3CorHat_Run1.pdf
Attachment 2: MokuFreqAnalysis3CorHat_Run2.pdf
MokuFreqAnalysis3CorHat_Run2.pdf MokuFreqAnalysis3CorHat_Run2.pdf MokuFreqAnalysis3CorHat_Run2.pdf MokuFreqAnalysis3CorHat_Run2.pdf
Attachment 3: MokuReadFreqNoiseCheck.pdf
MokuReadFreqNoiseCheck.pdf
Attachment 4: MokuFreqAnalysis3CorHat.zip
Attachment 5: IMG_20190606_192741.jpg
IMG_20190606_192741.jpg
  2355   Thu Jun 6 18:14:17 2019 anchalDailyProgressBEATMoku Lab Frequency Noise Analysis

I spent some time understanding moku and even though it has some flaws (like no scriptable channel for recording data), it seems like using the Phasemeter instrument in mokulab will get rid of all of our PLL problems.


Measurement details:

  • I connected a low noise Wenzel Crystal Oscillator of frequency 24.483 MHz in the input port of mokulab.
  • Using its phase meter app which has a maximum tracking bandwidth of 10kHz, we can directly record time series data of frequency and phase at a maximum acquisition rate of 125kHz.
  • If we set acquisition rate lower than 500 Hz, we can also see a real time frequency noise ASD through the iPad. This is good for day to day checking.
  • Mokulab records data so fast as its FPGA fills up the RAM directly. I was able to record 100s of data without reaching the limit of RAM memory.
  • Then, one has to transfer the data to from RAM to SDCard or Dropbox or iPad. Since I have a laptop with SDcard reader, I'm just using that.
  • The files are in binary format and we need to use their executable software to convert it into .csv or .mat. This software is not compiled for linux so we need to use our laptops for this step too.
  • This generates a very large file. I have written a python code which uses scipy.signal.welch to calculate PSD of the frequency data. I need comments on if this is a good function to use. The code is int he attached .zip file.
  • This code, mokuReadFreqNoise.py also uses this psd calculation multiple times to have 90 datapoints in each frequency space decade. For higher frequencies, the scipy.signal.welch function uses the time series in segments and averages as well.
  • I also used the data from CTN:2286 of our present marconi in PLL when instead of beatnote, the same crystal oscillator was at the measurement end.

Implications:

  • I'm unable to find datasheet of the model number of the crystal oscillator we have but all of them have less than -165 dBc/Hz Phase Noise at 1 kHz offset from the carrier. 
  • I'm not very sure how to translate that into frequency jitter noise.
  • But assuming (and mostly this assumption is very good) that this OCXO is much better than the synthesized frequencies of Moku or Marconi, what I am measuring in these experiments is actually frequency noise of the devices themselves.
  • And anyway, both measurements were taken essentially in the same way. The comparison shows that Moku Lab is doing much better in measuring frequency noise. So if we can keep the frequency drift of BN less than 10kHz/100s which is not too difficult and has been achieved with our modern day not so good temperature control.
  • When using external reference 10 MHz Rb clock, the noise in Moku is way lower than our expected coating brownian noise. So if the rest of the experiment works, moku would not give us problems of any noise floor in measurements.

Since it doesn't hurt:

Code and Data

Attachment 1: MokuFrequencyNoiseAnalysis.zip
Attachment 2: MokuFrequencyNoiseAnalysis.pdf
MokuFrequencyNoiseAnalysis.pdf MokuFrequencyNoiseAnalysis.pdf
  2354   Tue Jun 4 20:44:21 2019 ranaSummaryOthernext steps
  1. Fix the temperature control so that the fluctuation over hours time scale is low as Tara/Evan had it. This will allow for using the Marconi with a low FM range (or potentially none; we could just demod with a fixed frequency and directly digitize the IF signal in the CYMAC).
  2. Debug and fix the FSS misbehavior. Circuit creep in the last few years has degraded its performance relative to the in-loop performance achieved back in 2015.
  3. Recalculate the Brownian noise.
  2353   Mon Jun 3 17:44:30 2019 anchalDailyProgressNoiseBudgetNew Beat Note measurement

Today I took a beat note noise measurement to see where we are. Attached is the updated noise budget.


Measurement Setup:

  • I used wideband New Focus 1811 for detecting beat note. I was using the resonant Beat Note Detectot SN 101 only. I must have misinterpreted the connection as I was seeing about -1 dBm signal even after the BN detector being resonant. And that must have happened because we have increased the light intensity by a lot.
  • The cavity transmitted power levels are 5.2 mW (South) and 4.7 mW (North) with ~70% and ~60% mode matching respectively.
  • I didn't play around much with FSS gains but as of now, COM gain values are -0.3V (0.4 dB) and 2.5V (90 dB) in North and South Paths respectively. Fast Gain values are 1.4 V (54.8 dB) and 1.15 V (46.8 dB) respectively.
  • Marconi Actuation slope was set to 10KHz/V with carrier frequency drifting at less than 20 kHz/min. The carrier frequency was near 300 MHz, so it was outside the bandwidth of any detector we have. This measurement was completely bogus!
  • Gain of SR560 in PLL was set to 200.
  • With this, the bandwidth of the PLL was measured as 76.5kHz.
  • I took 4 different FFT sweeps at different ranges with averaging such that the measurement remains between carrier frequency jump. For now, I was doing the trigger manually by hand, but we intend to make this automated

Analysis and Result:

  • I'm still using the old noise budget notebook for plotting the results because of the unresolved issues mentioned in CTN:2277. I'll work on this as soon as we get to the point where careful analysis of this noise budget is indeed important.
  • Clearly, we aren't doing any better. I'm thinking of a new frequency noise measurement scheme which I discussed with Andrew before he left. This scheme might help us let go of any temperature control whatsoever.
  • More importantly, though, I definitely need to fix whatever is kicking the FSS and not letting me increase the gain of the feedback loop.

Edit Thu Jun 6 14:17:34 2019 Anchal : Above in red.


Edit Tue Aug 13 17:08:46 2019 anchal:

The PLL Readout noise added on this plot was erroneous and I can't find where it came from either. So the noisebudget attached is wrong! I was a dumbo then.

Attachment 1: 20190603_174101noiseBudget.pdf
20190603_174101noiseBudget.pdf
  2352   Wed May 29 18:50:18 2019 anchalDailyProgressFSSNorth FSS F and Crossover Frequency Measurement

I took the transfer function of North FSS side to see how much suppression we are doing. I took the transfer function by sending source signal to EXC port in common path and measuring transfer function as Source/OUT2 in AG4395a. The open loop transfer function is related to this by GOL = 1 - G2 (Source/OUT2) . Here G2 is the gain for source signal at the summing stage in common amplifier board which is -392/1.2e3 = -0.3267.

I have included an expected suppressed frequency noise plot assuming 104/f Hz/rtHz frequency noise of free running NPRO. We need to suppress much more in 100Hz-1kHz  to be able to see Brownian noise.
I have also measured crossover frequency between PZT and EOM actuation. It came to around 26KHz which is not bad. We just need to increase FAST GAIN a lot more and COM gan little bit so that crossover remains the same while we get a lot of suppression in 100Hz-1kHz range. I'll look into the source of glitched causing our EOM to become unstable when increasing the feedback gains.

Code and Data


Edit Mon Jul 22 18:55:22 2019 by anchal

The gain values given in the plots are wrong. Correct values are unknown,

Attachment 1: North_FSS_TF_Measurement_2019-05-29.pdf
North_FSS_TF_Measurement_2019-05-29.pdf North_FSS_TF_Measurement_2019-05-29.pdf North_FSS_TF_Measurement_2019-05-29.pdf
  2351   Thu May 23 15:56:22 2019 awadeDailyProgressFSSOscillations in North FSS Mixer Channel and power

~7kHz would be close to the cross over frequency wouldn't it? Maybe also see if you can capture PZT and EOM actuation signals in the same sweep (at their full bandwidth, i.e. careful of the montors filtering things off at higher frequencies).   

Also, an aside: you might want to also tar and attach data + plotting to elog as url links rot over time.

Quote:

After the vacumCans are heated, I aligned the north cavity again today to about 60% mode matching. however, I'm seeing a weird oscillation in the mixer channel of FSS board which is very big (5 Vpp) and is happening alongside a large power fluctuation in transmitted light. See attached plot from oscilloscope of reflected DC level and the micer channel from FSS. The repition rate of the oscillations make this a 7.35 kHz noise. I have never seen this before. Further, these oscillations are completely unaffected from chaning COM gain or the Fast gain in the FSS path. Comments required.

Code and Data

 

  2350   Thu May 23 15:45:48 2019 anchalDailyProgressFSSOscillations in North FSS Mixer Channel and power

After the vacuum can is heated, I aligned the north cavity again today to about 60% mode matching. however, I'm seeing a weird oscillation in the mixer channel of FSS board which is very big (5 Vpp) and is happening alongside a large power fluctuation in transmitted light. See attached plot from oscilloscope of reflected DC level and the micer channel from FSS. The repition rate of the oscillations make this a 7.35 kHz noise. I have never seen this before. Further, these oscillations are completely unaffected from chaning COM gain or the Fast gain in the FSS path. Comments required.

Code and Data

Attachment 1: NorthCavFSSOsc.pdf
NorthCavFSSOsc.pdf
  2349   Wed May 22 17:48:49 2019 anchalDailyProgressTempCtrlVacuum Can Temp Sensors restarted with new board

I installed the new board LIGO-D1800304 with an external voltage regulator and breakout box for handling acromag channels. See attached photos. The transimpedance amplifiers required a parallel capacitor in the feedback path for avoiding oscillations. Since these are temperature sensors and we do not care much about high-frequency noise, I added 1 nF capacitors at the COMIT3,9 and 11 positions. This should give us a bandwidth of 10 kHz. The channels are as follow:

CH No on Board EPICS Channel Name Temperature Conversion Function (ºC) Range (ºC)
1 C3:PSL-TEMP_TABLE = V/0.810875 + 27.30248869 13.860-40.745
2 C3:PSL-TEMP_VACCAN_INLOOP = V/1.625 + 33.3115385 26.604-40.020
3 C3:PSL-TEMP_VACCAN_OOL = V/1.625 + 33.3115385 26.604-40.020

Vacuum Can Temperature Control

With the new sensors, I have set relay autotune test to happen overnight with relay amplitude of 0.75V and 0.75 offset for 16 hrs. This should tell us optimal PID parameters. Hopefully, these measures will make the can temperature stable enough which I'll try to set around 33 degrees (my guess setpoint to keep good enough cooling rate). Then with Andrew's new script, the cavity temperature control was pretty good and hopefully we'll lower the overall drift of beatnote.

Attachment 1: Temp-Sensor-Box.jpeg
Temp-Sensor-Box.jpeg
Attachment 2: BreakoutBox.jpeg
BreakoutBox.jpeg
  2348   Thu May 16 16:34:30 2019 anchalDailyProgressNorth CavityChanges on North Path towards increasing power on FSS RFPD

Similar to South Path, I have inserted a beam splitter in the north PMC reflection path. This is a BS1-1064-90-1037-45UNP beamsplitter set such that about 10% light is transmitting. See optical layout for the path changes. I found that the modulation depth fro North PMC PDH was already low enough (0.246), so I did not reduce it. I have changed the DC transimpedance of North Cavity Reflection RFPD SN009 similar to the south side to 929.09 Ohms. This has given us ee-way to increase light intensity in the path with autolockers still working.

  2347   Thu May 16 13:46:46 2019 anchalDailyProgressTempCtrlAlignment disturbing due to lab temp changes

As suspected in CTN: 2346, the mode matching of the cavities is deteriorating and eventually alignment is getting screwed due to possible lab temperature fluctuations. I left yesterday with south cavity mode matching to about ~70% but in the morning today, I found that the resonance is completely lost and a higher order mode with vertical fringes is resonant. Same is the case with North one which had shifted to a much higher order with vertical fringes. So clearly, I need to switch back on the vacuum can temperature stabalization.

  2346   Wed May 15 19:00:26 2019 anchalDailyProgressSouth CavityChanges on South Path towards increasing power on FSS RFPD

For gaining about 3.45 mW of light after reflection from cavity on resonance when mode matching is about 60%, 8.63 mW light needs to fall at the cavity. There were three major obstacles in doing this which were resolved as follow:

  • PMC PDH becoming unstable: Too much light at the reflection of PMC PDH was making the locks unstable. This would be primarily due to the railing of RF amplifier in the RFPDs. To circumvent this problem, as Rana suggested, I discarded about 60% of light reflecting from South PMC by placing a beamsplitter (BS1-1064-50-1025-45S) instead of the last mirror that directs light towards it. Since it is ideal for 's' polarized light while the reflected light from PMC is 'p' polarized, the beam splitter is discarding more than 50% which is desirable. This allowed me to increase the light intensity much more than before.
  • PMC PDH Modulation Depth:  I found that the modulation depth for PMC PDH was really high. I measured it to be ~0.63 by directly measuring the transmitted light level of carrier and sidebands. I wasn't doing this before and the modulation actuation slope was too uncertain in the datasheet, hence I messed this up. Now, I have inserted a 9 dB attenuator to the modulation signal that goes to the resonant EOM for PMC PDH and now the modulation depth is ~0.23.
  • Decreasing Cavity Relf RFPD DC Transimpedance: SN010, South Cavity Refl RFPD had a DC transimpedance of 2222 Ohm which was getting saturated on 6.54 mW of light on the detector. This was making it hard for the autolocker scripts which rely on DC reflection value to estimate lock quality. Hence, I reduced this DC transimpedance to 1022 by changing R11 to 22 Ohms. Now we have more lee-way.

Also, I have finally started an ATF wiki page to keep documentation of all RFPDs and changes to it. I'll make sure this page is updated and this page should be the reference point in future.

https://nodus.ligo.caltech.edu:30889/ATFWiki/doku.php?id=main:experiments:psl:rfpd


On another note, I'm seeing a steady decline of mode matching on both paths even when I'm staying far away from the alignment. Something is going on which needs to be fixed. After a discussion with awade, following are the suspects:

  • Low nitrogen level in table legs: I have checked this already and it is between 45-50 psi, so we are good. I'm writing this down mostly for note taking purpose.
  • Cavity height changes: Currently, no active temperature control is in place. I'm seeing cavity resonance varying widely from one day to another. So the clamp of the cavities might be expanding/contracting over days changing the alignment into the cavity. Fixing vacuum can temperature control is important definitely.
  • Periscope or other steering mirrors relaxing: One reason might be that the periscope mirrors or other steering mirrors between Faraday isolator and cavity are slowly relaxing. I doubt this is the case because then it should have stopped after a certain time, but I'm seeing a steady decline in mode matching for 3 days now.

I'll fix the mode matching again before leaving today and will see if any big changes happen overnight.

  2345   Tue May 14 18:13:21 2019 anchalDailyProgressComputersAdded threshold channels in autolocker and fastmon rms monitor

I was finding myself changing thresholds every time I change power levels. Also, the fastmon rms monitors were not working with the docker-compose. I'm listing all script and medm changes since the sad departure of awade:

  • rmsMonitor.py is standalone now and does not depent on gaincycle.py.
  • rmsMonitor writes rms values in a channel and reads thresold value from a channel. There is also a switch to disable gain cycle functionality.
  • In FSS slow controls, I made channels for showing light power in mW (after calibration) and a channel that calculates mode matching. These values are of course not very accurate but will give us an idea.
  • I made thresholds into channels in the autolocker script. Autlocker script also had a logical bug with dealing with required states. I have fixed that now.
  • I have added threshold channels for PMC autolocker as well. Now, the threshold value can be changed by medm screens directly.
  • There is a new functionality in autlocker called tracking. When engaged, the autolocker top and bottom rails follow the changes due to slow pid so that a rough position of resonance is always in memory.

I'm attaching screenshots of modified medm screens.

Attachment 1: screenshots.zip
  2343   Mon May 13 19:12:56 2019 anchalDailyProgressOtherSet experiment for 2.6 mW transmission from cavities.

I tuned the intensity control and changed autolock parameters to get 2.6 mW light at the output of cavities on both paths. At present, the South Path has 74 % mode matching and North Path has 63% mode matching. These numbers were higher yesterday, so I'm suspecting something shifted over a day.

I also maximized gains on PMC loops and FSS loops:

  North South
PMC Gain (dB) 30 (Max) 21
FSS Common Gain (V) [32dB/V] 3.2 10 (Max)

In FSS loop, I kept gain margin of 0.64 dB (i.e. the oscillations are seen at 0.2V above the set value of Common Gain) and in PMC loop, I kept it at 2 dB. I yet have to characterize noise in the FSS error signal and see what I can make better. On another note, I did a rough calculation today and I think shotnoise intercept current for our RFPDs is ~2.6 mA which means atleast 3.45 mW light should be falling on them for them to be shotnoise limited. I have to check the validity of my rough estimation but if this is true, then our FSS RFPDs are not shot noise limited.

  2342   Mon May 13 16:54:15 2019 awadeSummaryComputersConverted all PSL_Lab links to CTN links

Awesome. Can you do the same for crosslinks to the old ATF_lab logbook name (ATF_Lab-> QIL)?

Quote:

We have changed the logbook name from PSL_Lab to CTN. To keep all the links working, I ran the attached script in a local copy of the log files and then copies them back to the server. The script essentially just changes PSL_Lab from all hyperlinks to CTN. Now, all such links are working. However, the front text of the links was not changed to avoid unnecessary tweaking. So in most of them, the front test still says PSL:XXXX but the links are correct.

 

  2341   Mon May 13 16:25:14 2019 anchalSummaryComputersConverted all PSL_Lab links to CTN links

We have changed the logbook name from PSL_Lab to CTN. To keep all the links working, I ran the attached script in a local copy of the log files and then copies them back to the server. The script essentially just changes PSL_Lab from all hyperlinks to CTN. Now, all such links are working. However, the front text of the links was not changed to avoid unnecessary tweaking. So in most of them, the front test still says PSL:XXXX but the links are correct.

Attachment 1: CorrectLinks.zip
  2340   Fri May 10 15:50:09 2019 anchalSummaryComputersmodbus shifted to a git repo for version control

I today shifted our modbus (db files for EPICS channels, ioc command files and docker-compose file to run the services) over to this git repo.

Through this, we would have version control now so that we can revert back to a working stage if something causes an error in the hosting of the channels. All db files are updated every 5 minutes by dbFilesUpdate.py in ctn_scripts. So we should try to commit the changes manually once in a while to the repo. This is there so that locally the files track changes in the settings and parameter values but we also have version controlled history in git for long reverts.

On another note, it is important to start the docker processes in a particular order. To ease with this, I have added a restartAll command in the .bashrc of ioc3server which looks like this:

#Restarts all teh EPICS channels and python scripts in the correct manner.
restartAll() {
        cd /home/controls/Git/cit_ctnlab/ctn_scripts
        sudo docker-compose start dbFilesUpdateOneTime
        echo 'Updating db files before restarting...'
        while true; do
                sleep 1
                if [ -z `sudo docker ps -q --no-trunc | sudo grep $(sudo docker-compose ps -q dbFilesUpdateOneTime)` ]; then
                        break
                fi
        done
        echo 'dB files updated. Shutting down python scripts...'
        sudo docker-compose down
        cd /home/controls/Git/cit_ctnlab/modbus
        echo 'Now restarting the EPICS channels...'
        sudo docker-compose down
        sudo docker-compose up -d
        cd /home/controls/Git/cit_ctnlab/ctn_scripts
        echo 'Checking if the python scripts are down...'
        sudo docker-compose down --remove-orphans
        echo 'Starting python scripts...'
        sudo docker-compose up -d
        echo 'Done!'
}

So every time a new channel is added. After doing git pull, one should use this command or the commands listed above in order to make sure the channels and python scripts boot up in the right fashion.


Edit Mon May 13 12:17:23 2019: Updated restartAll() function to do a last time db files update before restarting.

  2339   Thu May 9 12:16:55 2019 anchalSummaryFSSSaving PDH error signal values

I have made a SMA cable of length 1.952m after optimizing phase delay of LO. This is giving the maximum PDH error signal.

For future reference, I'm saving present setup details:

  • Off-resonance South Reflection RFPD SN010: 3.34 V
  • Resonance dip in South Reflection RFPD SN010: 2.98 V
  • Cavity Transmission Peak: 3.6 V
  • OUT1 peak-to-peak signal: 230 +- 5 mV

From the ratio of off-resonance value and error signal pk-pk at OUT1, we can check in future if everything is same as right now. From ratio of off-resonance value and dip value, we can check cavity  mode matching in future.

 

  2338   Wed May 8 20:03:43 2019 anchalDailyProgressFSSFSS PDH Error Signal on South Path is in good health

Either by the mighty presence of Craig who came down to lab for few minutes or because of my recent updates in path alignment (see PSL:2335, PSL:2334 ), the PDH error signal in the south path looks almost as healthy as it ever was.

Attached is the data taken from oscilloscope with while scanning laser pzt at 3 Hz with 2 V peak-to-peak sinewave.

I measured modulation depth to be 0.373 by scanning the slow control voltage and reading powers in carrier and sidebands. Then I used the ratios of Bessel functions to estimate the modulation depth, which seems higher than expected.

The differences in the expected and the measured values good be due to many reasons like wrong modulation depth measurement, wrong responsivity (I used 0.75), wrong mixer loss and voltage divide estimation based on MAX333A datasheet values etc. So overall, this looks good enough that I can just move on. I am not sure how this actually happened.

Code and Data


Edit Mon May 13 16:40:21 2019 :

Corrected the transimpedance value of SN010 used. I was referring to a wrong value before. The have made the calculation by backtracing from the data in taken in CTN:2247, dividing by MAX4107 old gain (560/(0.5*113) +1), multiplying by the new gain (680/75 +1), dividing by old voltage division of (50/70) and multiplying by new voltage division of (50/100). The details are in this notebook.

Log of changes made to SN010, Schematic D980454-00;

1) Changed R1 to 680 Ohm and R2 to 75 Ohm. Replaced Max4107 with a new one.

2) Changed R6 to 50 Ohm. This changes the voltage division at output.

Log of changes made to SN009, Schematic D980454-00;

1) Changed R6 to 50 Ohm. This changes the voltage division at output.


Edit Wed May 15 19:47:42 2019:

See https://nodus.ligo.caltech.edu:30889/ATFWiki/doku.php?id=main:experiments:psl:rfpd for latest changes in RFPD.

Attachment 1: SCavPDHError20190508.pdf
SCavPDHError20190508.pdf
Attachment 2: Cavity_Refl_RFPD_TI_After_Modifications.pdf
Cavity_Refl_RFPD_TI_After_Modifications.pdf Cavity_Refl_RFPD_TI_After_Modifications.pdf Cavity_Refl_RFPD_TI_After_Modifications.pdf
  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

Please read and let me know if you have any comments.

  2336   Mon May 6 20:12:22 2019 AnjaliSummaryEquipment loanBorrowed components

I borrowed the following components from PSL lab to QIL lab 

1. Mixer (Minicircuit, ZFM-3-S+)

2. RF amplifier (Minicircuit, ZFL-500LN)

3. IFR/Marconi 2023 A (# BD9020)

  2335   Thu May 2 15:55:18 2019 anchalDailyProgressSouth CavitySouth Cavity Alignment Fixed

I'm not sure how but the alignment into south cavity became terrible over time. Maybe I accidentally changes persicope alignment  but I am pretty sure I didn't go near this area since I last aligned it (PSL:2316).

Today, I was able to get mode matching of 55% only.

  2334   Thu May 2 14:38:41 2019 anchalDailyProgressSouth CavityCorrected input polarization into South Cavity

In this week's group meeting, Andrew mentioned that the polarization axes of the AlGaAs mirrors are not properly aligned and there are two close by resonances at different polarizations. I indeed was seeing a small blip near resonance during a laser PZT  scan. I fixed hte input polarization with the Half wave plate infront of South cavity at  (56,26). I've attached two scan measurements from oscilloscopebefoer and after the optimization. The transmission increased by 10.1%.

Code and Data

Attachment 1: SCavPolOptimization.pdf
SCavPolOptimization.pdf
  2333   Wed May 1 18:45:47 2019 anchalNotesOtherTo scale complete optical layout of CTN

I have completed making an optical layout for CTN lab. From now onwards, I'll update this layout if I make any major changes in the path.

https://nodus.ligo.caltech.edu:30889/ATFWiki/lib/exe/fetch.php?media=main:experiments:psl:ctn_optical_layout.pdf

Please comment if you think I should represent something better.

  2332   Tue Apr 30 18:55:06 2019 anchalSummaryElectronics EquipmentFollow up on TTL Trigger generator box

But I used AD620 which is an instrumentation amplifier, not opamp. I thought comparators are made with differential amplifiers (from Horowitz & Hill Sec 4.23) and since AD620 was a nice available instrumentation amplifier, I thought it would work (and it does work).

But this particular circuit that I made seems to be less general than I thought. 100 kOhm potentiometer makes it hard to fine tune the threshold. Also, I think I should have buffered the threshold voltage divider circuit because I see the threshold level changing with the incoming signal when the signal is more than the threshold. It doesn't affect my particular application, but I think that makes this a crappy TTL generator. But since my purpose has been served, I'll push optimizing and generalizing this box to some other day. Maybe my new SMD prototype boards would be handy.

Quote:

not all amps are good for use as a comparator

https://www.analogictips.com/faq-use-op-amp-comparator/

 

  2331   Tue Apr 30 18:07:49 2019 anchalDailyProgressFSSSpectrum of RFout from South Cavity Reflection RFPD

Today, I finally used the trigger generator to trigger near the start of the maximum of PDH error signal to get an FFT when the PDH error signal is near maximum.


Setup:

  • All connections are as in PSL:2326 except for the following changes.
  • The Mixer Channel output is fed into the TTL trigger generator box and the trigger is read in CH4 while Mixer Output is read in CH2 of the oscilloscope.
  • OUT1 of FSS box is read in CH3. Please refer PSL:2326  for detailed definitions of these connection points.
  • I took spectrum from HP4395A at 30 kHz Res BW and 197 points spanning 1.2 MHz around 37 MHz. This was done to keep FFT time low to 17.37 ms.
  • I set the trigger level such that FFT is done near PDH error peaks as shown in the first two time series plots taken from the oscilloscope.

Spectrum result:

  • The 37 MHz frequency was found to be at -15.61 dBm level. This corresponds to 104.87 mVpp at 50 ohm termination. This number matches well with the time series measured value from OUT1 which is supposed to be 0.36 times RFout (see PSL:2326).
  • I see two sidebands sort of at 36.72 MHz and 37.28 MHz which are created with 280 kHz mixing into 37 MHz.
  • My guess right now is that this 280 kHz is some mechanical oscillation in PMC which is getting mixed with 37 MHz at the EOM.
  • This 280 kHz modulation will remain in the signal even after mixing down and low passing of our FSS and was seen in time series data in PSL:2326 .
  • There is a tunable notch present in FSS box at D040105 through capacitor C46. I think it is here to be tuned to suppress such peaks but I'm not sure.
  • However, we still haven't found any damaging cause to RFout. There is no significant distortion and its level being spit out of the RFPD is actually low.
  • I measured input light on the RFPD at 2.08 mW. I measured modulation index using optical powers of the carrier (1.4V at transmission PD) and sidebands (58.3 mV at transmission PD). The transmission PD has a dark output of 27.2 mV. Using these numbers and taking ratio of Bessel's function, I found beta to be 0.298, close to expected 0.3.
  • These numbers say that RFout after divided down due to 50Ohm voltage divider should be 1.05 Vpp when we are measuring just 125 mVpp (OUT1/0.36) :(.
  • All things point to RFPD but nothing seems wrong with it. Should I go to 40m again and free space TF again?

DATA_DIRECTORY        ANALYSIS_CODE


Reply to Rana:

It is not a beat frequency, it is rather some other oscillation mode (probably mechanical oscillation through PMC) at 280 kHz mixing at the EOM as I mentioned above. Modulation frequecy is 37 MHz for this path. 14.75 MHz is the modulation frequency for PDH of locking South PMC.

Quote:

but if all systems are linear, where does this beat physically get generated? What are the actual modulation frequencies for the cavities?

 

Attachment 1: SCavReflRFoutSpecAnalysis.pdf
SCavReflRFoutSpecAnalysis.pdf SCavReflRFoutSpecAnalysis.pdf SCavReflRFoutSpecAnalysis.pdf
  2330   Sun Apr 28 22:31:39 2019 ranaDailyProgressFSSRF beats

but if all systems are linear, where does this beat physically get generated? What are the actual modulation frequencies for the cavities?

Quote:

I think I figured the source of this 281 kHz peak. 281 kHz  ≈ 37 MHz - 36.72 MHz, so it is the beat signal between 37 MHz and the 36.72 MHz signals. I think I should tune the RFPD more next time I open the cage to bring its resonance closer to 37 MHz.

 
  2329   Sun Apr 28 22:29:18 2019 ranaSummaryElectronics Equipmentshould I use an OpAmp as a Comparator?

not all amps are good for use as a comparator

https://www.analogictips.com/faq-use-op-amp-comparator/

  2328   Fri Apr 26 14:34:03 2019 anchalDailyProgressFSSTime series and spectrum analysis of RFout of SCavReflRFPD near resonance

I think I figured the source of this 281 kHz peak. 281 kHz  ≈ 37 MHz - 36.72 MHz, so it is the beat signal between 37 MHz and the 36.72 MHz signals. I think I should tune the RFPD more next time I open the cage to bring its resonance closer to 37 MHz.

Quote:
  • Next, I took a board spectrum from 0-500 kHz to spot that 290kHz we saw in time series data. Indeed there is a peak at 281 kHz of -66.36 dBm. This looked like a bigger oscillation in time series (~50 mVpp => -22 dBm but again, this data taking method is not really good). There are other nearby peaks at ~269 kHz and 2~284 kHz. I'm not sure why these peaks are here. But they can not be some standing wave in the cable as it will require ~700m long cable.
  2327   Thu Apr 25 20:24:27 2019 anchalSummaryElectronics EquipmentAdjustable TTL Trigger Generator Box

Today I made a standalone Adjustable TTL Trigger generator box. Following are some features:

  • The rising edge of output can be used to trigger all TTL compliant external trigger enabled equipment (oscilloscopes, HP4395A, SR785 etc.)
  • Uses AD620 at very high gain (G=5k) to create a comparator. Positive input is the signal and negative input is controlled with a 100 kOhm potentiometer.
  • The threshold can be set anywhere between +18V and -18V.
  • Powered internally with four 9V Alkaline batteries and has a switch to turn ON/OFF. Should last really long.
  • The output is through a 4.7 V Zener Diode which activates in reverse bias when the signal becomes 140 uV higher than the set threshold.
  • Input impedance equivalent to AD620.
  • The trigger is not latched and output goes to -0.7 as soon as the signal falls below the threshold.
  • Has a window port for checking the threshold.
  • The practical way of operating would be to see the signal and output of the box together in an oscilloscope first and fine tune the potentiometer to see triggers at the right point.
Attachment 1: Adjustable_TTL_Trigger_Generator_Box.pdf
Adjustable_TTL_Trigger_Generator_Box.pdf Adjustable_TTL_Trigger_Generator_Box.pdf
  2326   Wed Apr 24 16:01:55 2019 anchalDailyProgressFSSTime series and spectrum analysis of RFout of SCavReflRFPD near resonance

I took time series and spectrum of RF output of South Cavity Reflection RFPD through a 20 dB coupler.


Time Series Measurement Setup:

  • The RFout port of South Cavity Reflection RFPD SN010 was connected to IN port of ZFDC-20-5-S+. OUT port of the coupler is connected to TTFSS box's PD input port.
  • The CPL port of the coupler was connected to CH3 in TDS3034C oscilloscope at 50 Ohm input impedance and probe set to 10x to compensate for 20 dB loss in coupling and have  a real estimate.
  • CH1 of the oscilloscope is connected to the output of Cavity Transmission Photodiode.
  • CH2 of the oscilloscope is connected to OUT1 port of TTFSS box, which is connector J1 in D040105. This is supposed to be 0.36 times the RF amplitude level measured with 50 Ohm termination (hence voltage divided after final RF opamp stage in RFPD).
  • CH4 of the oscilloscope is connected to Mixer output port of FSS which is at the output of the first common amplification stage in D040105. This is supposed to be 3.16 times OUT1 value.
  • Data from the oscilloscope is downloaded using its web portal.
  • I scan the laser pzt near resonance at 2 Hz with 2 V peak-to-peak sine wave. Incident light on the RFPD was measured as 2.95 mW.
  • Except for first two measurements which were triggered by transmission peak, I triggered the rest of the measurements by PDH error signal peak.

Analysis:

  • First, I just triggered the data capture with a wide 400 ms capture (Sampling rate of 25 kSa/s). I found that RFout level is 210 mVpp instead of expected 1.495 Vpp. OUT1 level was 53 mVpp (which ideally should be 75 mVpp given 210 mVpp RFout level). Mixer out level is as expected so the first stage common amplification is definitely good.
  • Next, I zoomed into 250 kSa/s because very clearly there were some oscillations. It seemed like there was a strong ~240Hz oscillation in RFout. This oscillation is quite big too, almost 100 mVpp. But at this point, I'm not really sure if this was an artifact of using a coupler.
  • Next, I zoomed in further in time scale going to 250 MSa/s sampling rate. In a 40 us snap, I saw another amplitude modulation. This time it corresponded to 290 kHz.
  • Next, wanting to see 37 MHz signal, I zoomed into 1 GSa/s where 10 us snap clearly shows this 290 kHz amplitude modulation.
  • Zooming into this 1GSa/s data, I can see 37 MHz sine wave. I saw some sharp features near the edges.
  • So to be sure, I zoomed into 5 GSa/s where I saw the sine wave better. Near the top, there are no sharp edges but still, it is not nicely curved. The bottom definitely looks sharper than top. But these minute defects in the RF signal could be due to oscilloscope quantization error or something else.

Clearly, I needed to see what other frequencies are there in this RFout signal. So I decided to take a spectrum of the signal.


Spectrum measurement setup:

  • I connected the transmission photodiode signal to the external trigger input of HP4395A (this is in the back). I couldn't get the analyzer to trigger with PDH error signal, so I had to use the transmission peak.
  • I connected the CPL port form the coupler to the spectrum analyzer directly which always has 50 Ohm input impedance.
  • Later I realized I do not need to do this as I am anyways not using down converted signal from FSS for triggering or anything. But I decided to keep going to keep the two measurements consistent.
  • Hence, in the analysis, I added 20 dBm in the measured output to compensate for coupler loss.
  • All measurements were taken with automatic IF bandwidth setting, so it changes according to span and is marked in the graphs. I took 100 averages in all the measurements which were triggered individually by transmission peak. So measurements were roughly taken over 100s.

Spectrum analysis:

  • First I took a wide scan to get a relative idea of important frequency peaks. I see that 37 MHz is the most dominant frequency (thankfully) at -30.71 dBm, which corresponds to 20 mVpp.
  • The reason this value is so small is that the FFT is taken over 281.3 ms which is over a quarter cycle in PZT scanning. So triggering from transmission peak, this must be the spectrum of the region where the PDH error signal has died out mostly. I know this measurement sounds stupid at this point, but I realized this in hindsight only. Still, we get an idea of other frequencies present. I have a better plan too which is about to come in the next post.
  • Second in the race is a peak at 36.72 MHz at -40.66 dBm. I think this is because the SN010 RFPD actually has its peak at 36.67 MHz and not 37 MHz and the EOM driver on the south path doesn't have a sharp resonance and has about 2-3 dB gain at 36.67 MHz, so that's why we are seeing this another peak (my guess).
  • Third, in line is 29.5 MHz peak at -45.62 dBm. This is the second harmonic of RFAM (RAM for people who prefer this) of EOM behind South PMC used of PDH of PMC. This surprisingly leaks through the PMC and I have not been able to tune it down passively.
  • Next, I took a board spectrum from 0-500 kHz to spot that 290kHz we saw in time series data. Indeed there is a peak at 281 kHz of -66.36 dBm. This looked like a bigger oscillation in time series (~50 mVpp => -22 dBm but again, this data taking method is not really good). There are other nearby peaks at ~269 kHz and 2~284 kHz. I'm not sure why these peaks are here. But they can not be some standing wave in the cable as it will require ~700m long cable.
  • There is some more activity near 60 and 70 kHz of ~-60 dBm again.
  • In the very low side, I took a broad spectrum up to 1 kHz and we see a horrifying comb of 60 Hz harmonics with 180Hz and 60 Hz being the dominant once. But the magnitudes in this measurement do not make much sense in my opinion.
  • And then I realized, I forgot to take spectrum near 14.75 MHz (the frequency of PMC PDH lock) but then the triggering stopped working. I guess the temperature in the lab changed and the intensity of laser changed slightly enough to make transmission peak low. That's my theory, but I do not know for sure why triggering stopped working. It was a very clunky way of doing science anyways :(

Some conclusions:

  • Well, clearly the RF output is indeed not strong enough from this RFPD (7 times smaller actually).
  • The shape of 37 MHz wave is also questionable. There are many dominant other frequencies in this signal. Need better measurements.
  • The draconian 60 Hz harmonics family is here as well. However, I hope after down conversion, it doesn't matter much.

Better measurements?

  • To be honest, I wished I took the spectrum in a cleaner way, exactly knowing where I am triggering and what part of time series data is being Fourier transformed.
  • So I started making a TTL triggering box for the same. See next post for details.
  • Next, I'll reduce PZT scan frequency and maybe FFT points and take a quick FFT around the PDH error signal peak only using my new trigger box.

DATA_DIRECTORY        ANALYSIS_CODE

Attachment 1: South_Cavity_Reflection_RFout_Time_Series_Analysis.pdf
South_Cavity_Reflection_RFout_Time_Series_Analysis.pdf South_Cavity_Reflection_RFout_Time_Series_Analysis.pdf South_Cavity_Reflection_RFout_Time_Series_Analysis.pdf South_Cavity_Reflection_RFout_Time_Series_Analysis.pdf South_Cavity_Reflection_RFout_Time_Series_Analysis.pdf South_Cavity_Reflection_RFout_Time_Series_Analysis.pdf
Attachment 2: South_Cavity_Reflection_RFout_Spectrum_Analysis.pdf
South_Cavity_Reflection_RFout_Spectrum_Analysis.pdf South_Cavity_Reflection_RFout_Spectrum_Analysis.pdf South_Cavity_Reflection_RFout_Spectrum_Analysis.pdf South_Cavity_Reflection_RFout_Spectrum_Analysis.pdf South_Cavity_Reflection_RFout_Spectrum_Analysis.pdf South_Cavity_Reflection_RFout_Spectrum_Analysis.pdf South_Cavity_Reflection_RFout_Spectrum_Analysis.pdf South_Cavity_Reflection_RFout_Spectrum_Analysis.pdf
  2325   Wed Apr 17 10:40:54 2019 KojiSummaryEquipment loanBorrowing an IPA/Acetone glass bottoles CTN->OMC

I borrowed a small isopropanol glass bottle from CTN to OMC (Apr 17, 2019)

I borrowed a small acetone glass bottle, which was in the yellow solvent cabinet, from CTN to OMC (Apr 19, 2019)

  2324   Sat Apr 13 16:23:30 2019 anchalDailyProgressFSSSouth Cavity Reflection Path reset

Today I reset the reflection path from faraday isolator to the RFPD.

  • First I slightly turned the input BS on faraday isolator to make reflection beam more horizontal. Then I changed input polarization into isolator accordingly.
  • I removed one of the mirrors from the reflection path.
  • I added a 0th order half-waveplate right after the isolator. Earlier, there was no polarization control here. I tuned the waveplate to make all the light in p-polarization.
  • I also added a PLCX-25.4-46.4-UV-1064 lens in the path.
  • Beam profiler was not available, so I used my earlier a la mode calculation and reverse propagate light from the cavity to have a beam width of about 500 um at the RFPD.
  • Now, with 3.385 mW light falling on the photodiode, I see a DC output of 6.6 V. This is already more than expected value with 0.75 A/W responsivity. I think now we are definitely absorbing all of the light. I measured about 70 uW of light reflecting from the photodiode.
  • Angle of incidence is about 25 +- 5 degrees.
  • I also put back the triangular beam dump for reflected light from photodiode.

This certainly improved the amount of light reaching RFPD but the PDH error signal still looks the same. I'll directly hook up RFout of RFPD tomorrow to the oscilloscope and take some time series data to see any discrepancy with waveform shape.

  2323   Fri Apr 12 18:00:59 2019 KojiNotesFSSPhotodiode C30642 doesn't has enough bandwidth!

Yeah, I realized I understood the mentioned bandwidth wrongly. It is mentioned for a direct 50 Ohm load while we load our photodiode with a different resonant circuit.

I haven't made actual measurements for the shot noise intercept current similar to the link, but I made a ltspice simulation of the circuit and I believe the shot noise intercept current is about 0.15 mA. Yes we are good with that. This topic should close here. False Alarm.

  2322   Fri Apr 12 11:55:54 2019 KojiNotesFSSPhotodiode C30642 doesn't has enough bandwidth!

There is no problem. It is just a matter of noise requirement.

How much shotnoise intercept current do you require?
At the 40m, the 33MHz PD has the shotnoise intercept current of 0.52mA. https://wiki-40m.ligo.caltech.edu/Electronics/RFPD/REFL33
Is that enough? How much is yours?
You should be able to realize the similar value because the technology used for your resonant PD is the same as the 40m one, I suppose.

If you require super low noise like uA (=sub pA/rtHz current noise), then we will need a high gain and low junction capacitance.

  2321   Fri Apr 12 11:43:33 2019 anchalNotesFSSPhotodiode C30642 doesn't has enough bandwidth!

[ED by KA, catalogs should not be put on ELOG. This is public.]

Did we just miss this all along?

C30642 has a bandwidth of 20 MHz only. That means at 36 MHz and 37 MHz, the RF output would be -8.1 dB (0.3933) and -8.3 dB (0.3827) lesser than expected or maybe worse. However, this bandwidth is mentioned for load resistance of 50 Ohms, so I need to go into more details. But definitely will have to look into this.

Maybe we need to replace these with faster photodiodes. Do we have any of C30619 or C30641 in stock?

(NO - this is a incorrect interpretation of bandwidth in this case)

  2320   Wed Apr 10 19:05:29 2019 UltramanDailyProgressFSSSouth FSS problems

ALL YOUR LEGENDS ARE BELONG TO 24V !

  2319   Wed Apr 10 16:34:55 2019 anchalDailyProgressFSSSouth FSS problems

EOM Driver isn't driving hard enough

  • I suspected that the EOM driver circuit isn't driving EOM hard enough to produce a good modulation depth.
  • I was seeing the saturation of PDH error signal as I increase input power to the EOM driver.
  • I made a spice model and as expected, the driver circuit is limited by the power rails used for it. We are using +-18 V power rails which would limit to 36 V peak-to-peak output.
  • I made some transfer function measurements and power sweep measurements of the South EOM driver circuit to have real facts to go ahead as this circuit is highly unpredictable (it relies on the internal resistance of Emitter-Base junction for amplification)

South EOM Driver Measurements

  • I created a 20 pF capacitor by placing multiple BNC connectors together to simulate the load of EOM.
  • I used high impedance probe HP 41800A to measure the other end of this capacitor. I used 60 dB  (1:1000) attenuation for safety.
  • I made three sets of measurements for +_18V, +-21V and +-24V rails. In each set, I took a transfer function from 10MHz to 100MHz at -10 dBm power and a power sweep from -15dBm to 15 dBm at 37 MHz CW frequency.
  • I averaged over 50 times at the instrument.

Conclusions

  • As expected, the output of the driver saturates according to the power rails.
  • Also, the gain of the driver is dependent on the negative rail voltage.
  • So to achieve 0.3 modulation depth, we need t use power rails of +-21 V or above.
  • We have =-24 V power supply available, so might route two cables from rack to the EOM drivers. Only problem with that is the board has TPS71550 5V regulator on it which has input maximum of 24V only. I might need to bring down the +-24 V supply for the drivers.
  • Another thing I found from spice model is that the EOM output always has a DC offset equal to the positive rail value. In fact DC path is directly linked to the positive rail through some passive filtering but no active voltage regulation. This means that power supply low-frequency noise is directly going into the EOM.
  • This DC offset changes the polarization matching and creates RFAM. A quick back of the envelope analysis shows that fluctuations in power supply are directly proportional to RFAM generation with a factor of sin(V_dc*pi/210) or ≈ V_dc/66.84 times the PDH Error Signal, where V_dc is in volts.
  • At 60 Hz, the passive filter on the board is useless with 0 dB attenuation of any fluctuations in power. So change in frequency of light due to change in power supply at 60 Hz is directly coupled with a factor of 8.108 kHz/V.
  • With 10mV ripple in 20Hz-300kHz band (DCS33-33E), which is equivalent to 33.33 nV/rtHz of flat noise spectrum, effect on frequency would come to about 0.27 mHz/rtHz. Phew!
  • I think we should be fine. I'll do more rigorous calculations later.

Edit Thu Apr 11 15:58:47 2019: Corrected legend and a plot title.

Edit Thu Apr 11 16:16:03 2019: Added same measurements for North EOM Driver

Edit Thu Apr 11 16:31:30 2019: References:

https://doi.org/10.1364/OE.25.032985

https://doi.org/10.1364/OL.39.001980

https://doi.org/10.1364/JOSAB.2.001527

Attachment 2: South_EOM_TF_Analysis.pdf
South_EOM_TF_Analysis.pdf South_EOM_TF_Analysis.pdf South_EOM_TF_Analysis.pdf South_EOM_TF_Analysis.pdf
Attachment 3: North_EOM_TF_Analysis.pdf
North_EOM_TF_Analysis.pdf North_EOM_TF_Analysis.pdf North_EOM_TF_Analysis.pdf North_EOM_TF_Analysis.pdf
  2318   Tue Apr 9 14:35:30 2019 anchalDailyProgressFSSSouth FSS problems

This apparent problem is clear now. The test path has a 100 ohm resistor to ground (RF Board R10) which with rest of the resistances is creating a voltage divider at DC. The numbers make sense and FSS board is fine. Seeing this, the only option to get better PDH error signal and boost our discriminant is to increase modulation depth. Maybe the modulation depth is indeed not good enough. I'll make the "Apparent Modulation Depth" (Modulation depth calculated by PDH error signal and incident light power) equal to 0.3.

Quote:
PDH Error Signal

We have been experiencing an extraordinarily low PDH error signal on the South FSS. I think I have found the source of the problem here but not the cause.

  • I used an external mixer, ZFM-2-S+ and directly fed the downconverted signal into test port Test1. I wanted to check if the onboard JMS-1H is faulty.
  • But the error signal directly from the external mixer was the same as the mixer output channel on FSS box.
  • But the mixer output channel is supposed to have a gain of 2.61, which is not happening.
  • The problem is, I tried taking transfer functions of parts from the test port to the mixer output channel, and everything looks like design spec (Elliptical filter and inverting amplifier). But when I compare the error signal at the start of gain stage and at the input to the FSS box, Test1, I see that somehow after going through elliptical filter, the signal is suffering a loss of 1/3 and hence the later gain stage is just making it same again instead of actually amplifying the signal.
  • I'll look into this more tomorrow. I don't understand how the transfer functions are from SR785 look ok but the actual ratio of error signals seen on the oscilloscope is wrong. Do we really need the elliptical filter?

 

  2317   Mon Apr 8 19:19:02 2019 anchalDailyProgressFSSSouth FSS problems

The ghost in South Cav Refl RFPD

  • "Water doesn't boil if you watch it". I routed +5V through unused pin 6 on the sub-D 9 connector and used a breakout box to keep monitoring the +5V rail when in operation. The tripping just stopped happening!
  • Until this point, I was fairly sure that closing the RF cage lid or the case lid was causing the problem, but not it is no more happening.
  • This is an irreproducible problem and I can't delve more time on it. If this happens again, I'll look at it then.
  • I did replace a capacitor at the output of the 5V regulator today with a higher rating (25V) tantalum capacitor, but i don't think that was the reason for this issue. I also saw -0.7V in first power cycle but not in the next ones.

PDH Error Signal

We have been experiencing an extraordinarily low PDH error signal on the South FSS. I think I have found the source of the problem here but not the cause.

  • I used an external mixer, ZFM-2-S+ and directly fed the downconverted signal into test port Test1. I wanted to check if the onboard JMS-1H is faulty.
  • But the error signal directly from the external mixer was the same as the mixer output channel on FSS box.
  • But the mixer output channel is supposed to have a gain of 2.61, which is not happening.
  • The problem is, I tried taking transfer functions of parts from the test port to the mixer output channel, and everything looks like design spec (Elliptical filter and inverting amplifier). But when I compare the error signal at the start of gain stage and at the input to the FSS box, Test1, I see that somehow after going through elliptical filter, the signal is suffering a loss of 1/3 and hence the later gain stage is just making it same again instead of actually amplifying the signal.
  • I'll look into this more tomorrow. I don't understand how the transfer functions are from SR785 look ok but the actual ratio of error signals seen on the oscilloscope is wrong. Do we really need the elliptical filter?
  2316   Fri Apr 5 19:28:56 2019 anchalDailyProgressMode matchingRe-aligned South Path

Today I aligned the south path completely with about 60% matching with the cavity. I guess I got lucky or I really know how to do this correctly now (see PSL:2253).

I have just one last weird thing remaining in South Path. The South Cavity Reflection RFPD doesn't behave well with its RF cage lid on. More specifically, the +5V voltage regulator LM309H stops working for some reason and +5Vrail becomes -0.6 V. But with lid off, everything works. I was even able to lock FSS nicely. So something is going on which I am trying to understand for a long time now. I have replaced MAX4107ES, LM309H and capacitor at the input of LM309H, but nothing works. The RF cage has a layer of electrical insulation tape from the inside, so there is no chance of it shorting any tall component (only tall component is an Inductor, see PSL:2241). I'll look a little bit more into this on Monday but otherwise, I'll just go ahead and install RFPD without this RF cage lid. Anyways the box itself should provide pretty good insulation from RF interference. If anyone has any clues about this -0.6V issue, please help me.

  2315   Thu Apr 4 18:40:18 2019 anchalDailyProgressMode matchingRe-aligned South Path

PMC mode overlap was found to be 68.77%. I realigned this to 91.99%. Here, the percentage is the percentage of power that went through the PMC.

Then I found that the alignment into Faraday isolator in the south path was also very poor with only about 75% of light going through. I aligned this also to 87.11%, but unfortunately, due to this exercise, the south cavity is misaligned now.


However, this will help in keeping the required power low at the PMC stages. So for some reason, the PDH error signals of PMC locks on both paths saturate to some value and do not increase further. This is right after the mixer so it is not the fault of the Servo Cards. As I tried a pristine different RFPD too, it is not the fault of the RFPDs either. I checked the modulation depth, and it is good as well. So only two things can happen here:

  • Either the photodiode's fast response diminishes as more light falls into it (which shouldn't happen as the rates max photocurrent is 100 mA)
  • Or the mixer saturates in its capability to drive IF higher (which shouldn't happen since the rated max IF current is 40 mA which is enough for 4 Vp-p )

This problem seems unsolvable, so I basically have to keep power low enough at the PMC stage. My goal is to send 3 mW power on the cavities. Then the FSS RFPDs will be shot noise limited.


p.s. I know this seems too elaborate exercise at this point when I know a much larger issue, the 50 Hz noise source. But to investigate that, I need rest of the table working and since I'm sort of rebooting everything, I want to optimize it as good as I can and I want to keep the record of all problems and efficiencies as well.

  2314   Thu Apr 4 15:33:34 2019 anchalDailyProgressPMCRehabilitation of PMCs

Today, I tried to replace the Reflection Photodiode on South PMC with another 14.75 MHz Resonant (which from test port analysis has TI of 57623 Ohm at 14.75 MHz). Since this another photodiode had been sitting in box for months, I expect it to behave better if the power supply tripping incident caused any harm to the existing photodiode. To my surprise, the error signal turned out to be nearly same. With 6.765 mW incident power, PDH error signal is 900 mVp-p. So I am not sure what is causing this limitation on the output signal strength. From the comparison of sideband strength to carrier strength, we are definitely near 0.88 rad modulation depth. I'll reduce this to 0.3 to avoid power in higher harmonics. But the main concern is that there is some limiting factor because of which the error signal is not going high enough.

The reason I'm worried about this is that PMC lock looks robust enough that it remain locked all night, but whenever I try to scan laser pzt for FSS analysis, the PMCs get unlocked by just connecting a switched off function generator to the laser pzt. 

  2313   Wed Apr 3 16:23:26 2019 anchalDailyProgressPMCRehabilitation of PMCs

Since the last incident of power supply tripping, I tested all photodiodes and electronics in the lab one by one. During the process, I realized that we are using way too low power in our experiment. According to my calculations, the current RFPD are such that they will be shot noise limited only with more than 2.8 mW light falling on them.


North Path

  • The north path's PMC servo card was used with external mixers. I found that we were driving EOMs way too lightly with the modulation index of about 0.05 rad only.
  • The path from FPTest1 to the first summing junction had a MAX333A and a low pass filter of an arbitrary pole in it. We are already using an external in-line 19 MHz low pass filter after the mixer downconversion.
  • This path has something which has broken down as it is railing the rest of the circuit.
  • I switched to input point FPTest2 which directly goes to the inverting input of the summing junction. This however changed required LO phase delay by pi.
  • So I optimized the phase delay again and cut a RG-178 cable for it.
  • In the end, with 6.08 mW power falling on North PMC, I see PDH error signal of about 490 mVp-p with power going into EOM being 17.54 dBm (giving about 0.238 rad modulation index).
  • These numbers actually do not match expectations. I'm sure the modulation depth is correct as I cross-checked with sideband powers. So most probably the RF amplification is somehow getting attenuated.
  • However, the RF path looks fine when I did a TF analysis using Test Ports and used liso model to convert into how photodiode signal would behave. But this test didn't really go to high enough simulated photocurrent (to create photocurrent in the paths equivalent to 3 mW light, 144 V input is required).
  • Not sure why this is happening as the MAX4107ES chip on the RFPD is also new. All rails and voltage regulators are at nice values. There is no clipping as well as the PDH error signal is beautifully ideal.
  • But the PMC is locked robustly, so I'm gonna look past this for now.
  • 4.292 mW light is reaching the cavity.

South Path

  • South path's PMC was in good running condition even after the incident. So I didn't open the RFPD at all.
  • I did the same thing in this path, increased EOM driving signal to 17.54 dBm and measured PDH error signal.
  • This path has exceptionally attenuated RF response given this RFPD (SN001) was measured to have 14430 V/A AC transimpedance.
  • With 6.32 mW light falling on the RFPD, PDH error signal is 780 mVp-p.
  • The exact reason for low error signal is still a mystery, but the PMC is locking robustly with good looking PDH error signal.
  • The overlap at South PMC is poorer than North PMC because the incoming light has a lot of higher order modes.
  • 2.768 mW light is falling on the cavity. Clearly, this is not just higher more losses. More alignment is required on South PMC overlap so that more power can reach afterward.

Near future steps:

  • Do same analysis for FSS loops. Already have done some part in this regard.
  • Align the beams better everywhere.
  • Get beatnote and test beatnote detector.
  • Fix the actual ground loop noise issue!
  2312   Sat Mar 23 21:50:40 2019 anchalSummaryElectronics EquipmentPower tripping incident and follow-up

This week on 19th March in the evening, I was working on replacing the GND connections of the power supply with thicker wires and checking out any AC rms voltage between different ground points to look for ground loops. During this, I found that the high voltage power supply for PMCs wasn't directly grounded with the rest of the power supplies. These are Kepco PCX 200-0.1 MAT power supplies. From here onwards, I'll tell about this incident chronologically:

Before the incident:

  • Pins 4 (Sensing -) and 5 (Output -) were not shorted with a shorting clip to keep voltage regulation good.
  • Pins 8 and 9 were shorted. These pins are for the external resistor for voltage control. At this point, my understanding from the manual was that front panel voltage knob overrides this external voltage control.
  • Pin 5 was GND terminal for two such power supplies connected in series and operated at 80V each, totaling to 160 V for the single-sided rail of PA85 in the PMC servo boards.

The incident:

  • I removed the shirt between PIN 8 and PIN 9 leaving it open and used this clip to short PIN 4 and PIN 5. I also connected PIN 4 to the rest of the GND of other power supplies which is GND for the rest of the lab.
  • Then to test this, I switched on all power supplies, leaving one pair of +-24V power supplies at the bottom. I left them as at this point already, +18 V supply used for FSS boxes showed me a trip (it became a current source limiting to 3 A with about 3V voltage). Also, the Kepco power supplies for PMC where I did the changes shot to maximum 200V (instead of set 80V).
  • I shut down everything and rewired everything as before.

My understanding of what happened here:

  • Since short between PIN 8 and PIN 9 were removed, the external voltage control of Kepco power supply got activated and rose to maximum 200V making rail of PA85 in PMC servo card +280 V (Maximum allowed +450V).
  • This allowed the PMC PZTs to be driven to upto 280V (Maximum allowed being 200V) if the control signal required it to. So far after all the tests, I came to the conclusion that this didn't happen and PZTs are healthy.
  • The +18V power supply simply tripped because the FSS boxes use 18V rails to power 24V rail circuits as well in absence of power at 24V rails (which I didn't switch on yet). So the lesson here is that always switch on 24V rails power supply first for the FSS boxes.
  • Finally, this is just a guess, the sudden rise of Kepco power supplies to 200V might have sent a surge of charge to rest of the GND. It doesn't really make sense, but something must have happened because I found RF amplifier of PMC reflection RFPD dead after all of this.

Current state:

  • I replaced the MAX4107 RF amplifier in SN020 RFPD (and actually after doing this twice), this RFPD became as before with same transfer function as measured in PSL:2247.
  • I noticed that PDH error signal for South FSS was too low. Later I found this was just because Andrew added a microwave amplifier in the RF output which mismatched the phase matching of FSS PDH.
  • There are more findings on the South reflection RFPD and FSS of South path. I'll report this in a future post with some numbers.
  • I have tested all FSS boxes and PMC Servo cards as well as EOM drivers. Everything else in the lab seems ok at this point. The lasers are locking nicely and following Slow PID as well.
  • Regarding the ground loop issue which was the start point of all this, everything is status quo, so it is also there.
  2311   Tue Mar 19 16:39:20 2019 anchalDailyProgressFSSNeed to track down 60 Hz spike source in FSS

The bad news...

  • We were curious on actual actuation signal being sent to EOM by the TTFSS boxes.
  • So we opened the north path and hooked up clips to TP4 in D090183. This point is used for PCMON signal.
  • We found that there is a strong ~5V spike happening at this point at a rate of 60 Hz.
  • This spike rails the EOM and hands of the error correction to pzt which happens slower.
  • But when we increase the common gain in our circuit, this spike makes everything unstable at a much smaller gain then what we want to use.
  • This is clearly a leak from AC supply, from where and how is unknown at the moment.

The good news...

  • We got something to work at and hopefully this is our culprit.
  • If we get to remove this and increase our common gains high in FSS, we might get a deeper look in the noise.

Steps ahead:

☐ Reroute AC power cables separate from signal cables.

☐ Add chokes or loop cables around ferrite cores to increase impedance to ground loop current.

☐ Shield the FSS 37 wires cable with aluminium foil.

☐ Add a thick grouning from table to rack.

☐ Grounding all DC supplies to a single point in a star configuration with thick metal/wire.

☐ Check all DC power supplies if they are leaking these 60 Hz spikes.

☐ Removing the AC power strips from the table sides. Connect the camera power cables far way from table top.

 

  2310   Sun Mar 17 18:28:06 2019 awade and anchalSummaryComputersMigrating epics channels from acromag1 to c3iocserver: killing acromag1 services

Wandered into the PSL just now.  Slow controls were going wild.  Traced it back to the fact that acromag1 and its auto-restarting services were still live. The new dockerized python script services on C3IOCServer were fighting the Acromag1 machine processes.  I've copied the service scripts into the ~/Downloads/ folder of acromag1 and deleted them from /etc/init/.   I then rebooted acromag1 and the problems went away. 

We should achieve whatever is on Acromag1 and probably rebuild that machine with an operating system that is still in long term support 

Quote:
  • The migration of all EPICS channel hosting and all python programmes has been done from Acromag1 to C3IOCServer. Now Acromag1 is neither hosting anything nor running any codes.
  • All channels are hosted in C3IOCServer through docker services. The channels are grouped into 5 groups which can be independently stopped or restarted now. This will allow to cahnge any channels or add channels without disrupting everything else.
  • All python programmes (Autolockers, PID scripts etc) are also running as separate services.
  • All these services are run inside a container which is utilizing an IP address in our local netwrok. Addresses 10.0.1.96-127 are reserved for such services.
  • At any time, to see the list of services, ssh into C3IOCserver (ssh 10.0.1.36) and run sudo docker ps.
  • Using the container names, the services can be stopped (sudo docker stop container name), started (sudo docker start container name) or restarted (sudo docker restart container name)
  • To shut down all the python programmes, go to /home/controls/Git/cit_ctnlab/ctn_scripts and run sudo docker-compose down.   To start them again, run  sudo docker-compose up. To run it in background, use flag -d.
  • To shut down all the channels, go to /home/controls/modbus and run sudo docker-compose down. Rest instructions are as above.
  • For adding a new python script as a service, you would need to add any additional packages in /home/controls/Git/pyEPICSDocker/requirement.txt and run "sudo docker build -t pyep ." at the same directory. Delete any previous instance of the image to save space.
  • After this, add the service in Git/cit_ctnlab/ctn_scripts/docker-compose.yml following the examples of existing services.
  • If the packages are LIGO propietary, you would need to mount the cloned git dir into "/dev" folder in the docker-compose.yml file and add sys.path.append('/dep') in your python script. Follow example of netgpibpackage used in PLLautolocker.py.

 

  2309   Tue Mar 12 17:04:03 2019 anchal and awadeSummaryComputersMigrating epics channels from acromag1 to c3iocserver
  • The migration of all EPICS channel hosting and all python programmes has been done from Acromag1 to C3IOCServer. Now Acromag1 is neither hosting anything nor running any codes.
  • All channels are hosted in C3IOCServer through docker services. The channels are grouped into 5 groups which can be independently stopped or restarted now. This will allow to cahnge any channels or add channels without disrupting everything else.
  • All python programmes (Autolockers, PID scripts etc) are also running as separate services.
  • All these services are run inside a container which is utilizing an IP address in our local netwrok. Addresses 10.0.1.96-127 are reserved for such services.
  • At any time, to see the list of services, ssh into C3IOCserver (ssh 10.0.1.36) and run sudo docker ps.
  • Using the container names, the services can be stopped (sudo docker stop container name), started (sudo docker start container name) or restarted (sudo docker restart container name)
  • To shut down all the python programmes, go to /home/controls/Git/cit_ctnlab/ctn_scripts and run sudo docker-compose down.   To start them again, run  sudo docker-compose up. To run it in background, use flag -d.
  • To shut down all the channels, go to /home/controls/modbus and run sudo docker-compose down. Rest instructions are as above.
  • For adding a new python script as a service, you would need to add any additional packages in /home/controls/Git/pyEPICSDocker/requirement.txt and run "sudo docker build -t pyep ." at the same directory. Delete any previous instance of the image to save space.
  • After this, add the service in Git/cit_ctnlab/ctn_scripts/docker-compose.yml following the examples of existing services.
  • If the packages are LIGO propietary, you would need to mount the cloned git dir into "/dev" folder in the docker-compose.yml file and add sys.path.append('/dep') in your python script. Follow example of netgpibpackage used in PLLautolocker.py.
  2308   Tue Feb 26 02:45:20 2019 anchalNotesComputersMigrating epics channels from acromag1 to c3iocserver

We have been thinking for a while to migrate all epics channels from acromag1 (10.0.1.33) to c3iocserver (10.0.1.36) which is rack mount with the latest supported ubuntu Debian.

Unfortunately, my first attempt failed and I tried to put everything back to the status quo but the docker instance on iocserver which was running PMC interface is not working. Here are the steps I took:

  • I created a modified acromag.cmd file to be used in ioc4server with docker. The file is attached. All the running acromag cards and their db file addresses were added in this single file.
  • I copied all the relevant db files to /home/modbus/db/ in the iocserver computer.
  • I stopped the running docket container with NPMC and SPMC interface channels. I stopped AcromagBoot service on acromag1 and removed it from /etc/init/ (preserving the copy).
  • I rebooted acromag1 for a clean start. No channels were running at this point.
  • Then at iocserver, I ran:
    sudo docker run -dt --name AcromagChannels -v :/home/controls/modbus/acromag.cmd -v  :/home/modbus/db -p 5064:5064 -p 5065:5065 -p 5064:5064/udp -p 5065:5065/udp andrewwade/modbusepicsdocker
  • This started a docker container but I couldn't see any channel from acromag1 using caget. So either the channels are not broadcasted properly or the modbus command file is not running properly.
  • So, to go back to previous state, I stopped and removed container AcromagChannels and ran the previous IOCStart.cmd file with:
    sudo docker run -dt --name AcromagPMC -v :/home/controls/modbus/IOCStart.cmd -v  :/home/modbus/db -p 5064:5064 -p 5065:5065 -p 5064:5064/udp -p 5065:5065/udp andrewwade/modbusepicsdocker
  • I put back the AcromagBoot.conf file in acromag1's /etc/init and rebooted acromag1 again.
  • This brought back all the channels hosted by acromag1 but not the PMC interface channels from iocserver. So there is definitely some problem with the way I ran docker.

I couldn't debug remotely further for the cause of this problem. So the status is worse than I started. The PMC channels are not running and hence everything must be unlocked in the lab right now.

Edit Mon Mar 11 18:38:03 2019 (awade): crossed out Ubuntu added Debian

Attachment 1: acromag.cmd
dbLoadDatabase("$(EPICS_ROOT)/modules/modbus/dbd/modbus.dbd")
modbus_registerRecordDeviceDriver(pdbbase)

# Use the following commands for TCP/IP
# drvAsynIPPortConfigure(const char *portName,
#                        const char *hostInfo,
#                        unsigned int priority,
#                        int noAutoConnect,
#                        int noProcessEos);
# Example: drvAsynIPPortConfigure("c3test1","10.0.0.42:502",0,0,1)
... 93 more lines ...
  2307   Thu Feb 7 10:33:27 2019 anchalSummaryFSSComplete model of TTFSS box with TF and crossover analysis
Quote:

where ms is EOM phase slope (15 mrad/V) and V_EOM is the applied actuation voltage. As you wrote, that leads to

\delta \tilde f(f) = \frac{m_s}{2\pi} (-i 2 \pi f) \tilde V_{EOM}(f) = -i m_s f\tilde V_\textrm{EOM}(f) \quad [\textrm{Hz}/\textrm{V}]

 

This actually has units of Hz/Hz. Note, that \delta \tilde{f}(f) is just Fourier transform of frequency actuation, so it is unitless. I used this to get the transfer function of EOM actuation, from applied signal in V to resulting actuation in Hz, which is the prefactor of -\iota m_s f above having units of Hz/V.

Quote:

If we assume that the EOM is taking 100% of the load for canceling laser frequency noise at a given frequency then it follows that the applied voltage to exactly cancel laser frequency noise is 

\delta \tilde V_\textrm{EOM}(f) = \frac{S^\textrm{Laser}_f (f)}{\delta \tilde f(f)} = i \frac{10^4}{m_s} \frac{1}{f^2}\quad [\textrm{V}/\sqrt{\textrm{Hz}}]

So, if EOM is taking the whole load of frequency noise, actuation signal ASD would be:

\delta \tilde{V_{EOM}}(f) = \frac{TF_{EOMpath}}{-\iota m_s f} S_f^{laser}(f) \quad \left[ V/\sqrt{Hz} \right]

But obviously, this is wrong because this just assume that we are not feeding back the actuation signal at all. So instead, I assumed that if everything is 'ideally' working and we actually have the frequency noise suppressed by a teamwork of PZT and EOM, the incoming noise signal to EOM path's transfer function is:

\frac{1}{1+TF_{PZTpath}(f) + TF_{EOMpath}(f)} S_f^{laser}\quad \left[ Hz/\sqrt{Hz}\right]

So, the actuation signal generated for EOM by EOM path's transfer function in an ideally working loop is:

\delta\tilde{V_{EOM}}(f )=\frac{TF_{EOMpath}(f)}{-\iota m_sf}\frac{1}{1-TF_{PZTpath}(f) - TF_{EOMpath}(f)} S_f^{laser}\quad \left[ V/\sqrt{Hz}\right]

The error in the last plot in PSL:2305. is that I forgot to divide by -\iota m_sf since transfer functions in the code are from Hz to Hz. So I think this is the real error.

Quote:

One thing to note is that the above estimates are an upper bound assuming that the EOM is taking all of the load down to that frequency point and that the PZT path isn't fighting or out of phase with EOM.  To correctly compute the load on the EOM you are going to have to break down the EOM only portion of the loop from the laser frequency to the point of voltage injected into the EOM.  This can be done by effectively nesting the PZT loop into the round trip gain in a way similar to that described in Josh Smith's Thesis section 2.6.2.  Finding the actuation signal should be similar to finding the PLL actuation signal, at this point in the loop it is the G/(1-G)/A copy of the sensor noise.  In the high gain regime the applied EOM control signal should just be the laser frequency  divided by the EOM frequency slope. Of course you can compute for G_EOM OLG to get a true value with a bunch of algebra.

But on reading section 2.6.2 of Josh Smith's Thesis (which btw has a typo in Eq. 2.33 and 2.34), I did the thing of nesting the PZT path with the plant. So as per Eq. 2.31:

TF'_{PZTpath,roundtrip} = \frac{1}{1 - TF_{PZTpath}(f)}

is the transfer fucntion of Plant for the simplified loop with just EOM as the actuator. Then the actuation signal ASD would be (note S_f^{laser}(f) is free running laser frequency noise ASD):

\delta \tilde{V_{EOM}}(f) = \frac{TF_{EOMpth}(f)}{-\iota m_s f}\frac{TF'_{PZTpath,rountrip}(f)}{1-TF'_{PZTpath,rountrip}(f)TF_{EOMpath}(f)}S_f^{laser}(f)

which turns out to:

\delta \tilde{V_{EOM}}(f) = \frac{TF_{EOMpth}(f)}{-\iota m_s f}\frac{1}{1-TF_{PZTpath}(f)-TF_{EOMpath}(f)}S_f^{laser}(f)

Which is exactly the same as above. But still my model has this error. I'll fix it and post it soon. For readers in the future, the last set of equations are the only correct equations to the best of my knowledge.

ELOG V3.1.3-