40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  PSL, Page 26 of 52  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  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.

  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.

  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
  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.

 

  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.

  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
  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.

  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
  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.

  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.

  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.

  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
  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
  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
  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
  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
  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
  2369   Mon Jul 22 19:11:54 2019 anchalNotesComputersWS1 upgraded to Debian 9, still showing some glitches

Last week, the default GNOME Classic desktop environment of WS1 started giving hiccups. I was unable to see any medm screens. I restarted the computer assuming that will solve it but then I was unable to login from the graphical user interface. That was weird as I was able to ssh into the computer and do whatever I want. So it seemed that some graphics engine was unable to run. On login screen, after typing in the correct password, a black screen would appear and it would go back to the login screen. This is mentioned in various forums on the internet as "login loop". Taking advice and directions from Jamie, I tried to troubleshoot this to the best of my ability but we both were unsure in the end what was the problem. Our best guess is that installation of LSCsof package upgraded some graphics library beyond the capability of the present system. I tried all different desktop environments and I was able to login only through GNOME on Wayland (supposedly bleeding edge for debian 8). Another mystery is that I found medm uninstalled from the computer. I installed it back with:
sudo apt-get install medm

And I found that GNOME on Wayland is still usable option. After some more discussion with Jamie, I decided to upgrade the OS to next stable version debian 9. I followed the instructions on:
https://phoenixnap.com/kb/how-to-upgrade-debian-8-jessie-to-debian-9-stretch

to dot and have successfully upgraded to debian 9. However, still only "GNOME on Wayland" is the only desktop environment through which we can login without facing a login loop

On another note, I found today that clicking the scroll button over a medm channel screen (which ideally displays the channel name) freezes the computer. The mouse pointer disappears and the computer does not respond to anything. Again, I can ssh into the computer and do anything. This problem goes away on restart.

So bottom line is, the overall system environment of ws1 is becoming messy and old and ideally we should do a clean install of a new os (something like Jon did in QIL). But I was heavily discouraged for doing so as it seemed it will take a lot of time to setup a new workstation.


Present Status

Due to recent cleanup and upgrades in our computer environment in lab, this workstation ws1 is a mere looking window in the experiment. There are no active scripts that it runs (except a precavity beatnote reading) and the experiment can be carried out without it present as well. However, it is nice to keep a computer loaded with EPICS, nds2, python environments and a screen to carry out day-t-day functioning of the lab.

  2370   Mon Jul 22 19:31:20 2019 anchalDailyProgressFSSFF Gain channels converted to physical units

I found today that all this while, the channel values shown on our FSS_Interface medm screen and used by rmsMonitor.py for gain cycling were somewhat arbitrary numbers. It took me a while to figure out that the channel voltage is 10 times what reaches the AD602 on TTFSS board. Maybe awade knew about this but there was no documentation on this. Anyways it seemed bogus to increase the gain of FSS loops in arbitrary units. I added four more channels with _DB suffix which carry the physical units (in dB) of the Common and Fast gains in FSS loops. The older gain channels are calc channels now which calculate the channel voltage required from dB value. Everything has been tested to work correctly with the changes. My next steps are to step by step check all transfer functions in the FSS loop and find the culprit.

  2374   Tue Jul 23 11:24:08 2019 anchalDailyProgressTempCtrlDifferential Temp. Experiment Data Analysis

I just took Scott's notebook and added code to integrate the input-referred temperature noise power spectral densities over different bandwidths of frequencies to see what noise we should expect with 16 Hz sampling and what does the measured data suggests. The expected total noise sum is below 1mK for bandwidth up to 10 Hz and the measured total noise is below 0.3 mK up to 10Hz bandwidth. In my opinion, this circuit has passed the test if our experiment and the analysis is correct subject to Rana's opinion.

Attachment 1: AD590_Differential_Noise_Integrated.pdf
AD590_Differential_Noise_Integrated.pdf
Attachment 2: AD590_Differential_Noise_Integrated.zip
  2378   Mon Jul 29 13:55:15 2019 anchalDailyProgressFSSNoise analysis of TTFSS

Measurement:

  • I first switched the input to TTFSS from PD to Test1. There is a switch which lets us do this. This bypasses the onboard mixer.
  • I set the COM gain in both boxes to 10 dB and FAST gain to 14 dB.
  • I shorted this Test1 port and measured the noise spectrum at the output ports that go to Laser PZT and EOM.
  • The spectrum was taken by WideSpecMeasSR.py, a new modified version fo SRmeasure script. This script starts taking spectrum from startFreq and spanFreq and continues doing measurement by shifting startFreq up and doubling the span to get a consistent number of points with good linewidth in each decade of frequency.
  • Next, I measured transfer functions from the Test1 port to these output ports using various attenuators to make sure the measurement doesn't saturate.
  • The measurement parameter files are attached and the attenuator configuration is mentioned in the notebook.

Analysis and Conclusions:

  • I divided the measured output noise with respective transfer functions to get the input-referred noise.
  • I did this so that we can compare the noises on the same scale.
  • It seems like the South Path's TTFSS is noisier on both actuation channels. Note that the gains were set same, so there is actually a difference in gain values and noise.
  • Input referred noise shows that North PZT path is the noisiest followed by South PZT path. I'll go noise hunting on these paths first then.
  • Also, we see clear 60, 180, 300, 420, 540, 780,900 and 1020 Hz (660 Hz is missing) peaks in the input-referred noise of North PZT output path.
  • Additionally, there are comparatively smaller peaks of 120 Hz and 240 Hz also present in North PZT output path.
  • On South path though, the peaks are lower and are present at 60, 180, 300, 780 and 900 Hz only.

Code and Data

Attachment 1: FSSNoiseAndTFAnalysis.pdf
FSSNoiseAndTFAnalysis.pdf FSSNoiseAndTFAnalysis.pdf FSSNoiseAndTFAnalysis.pdf
Attachment 2: FSSNoiseAndTFAnalysis.zip
  2384   Wed Aug 7 17:53:46 2019 anchalDailyProgressFSSInvestigation of North TTFSS Box

Measurement setup and analysis:

  • EOM and Laser PZT were disconnected and only the TTFSS box was being analyzed as a standalone circuit.
  • I used SR 785 to take transfer functions from 1 Hz to 102.4 kHz with 500 points, 1 settle cycle and 5 integration cycle. The template file used is in the code and data link below.
  • I used AG 4395A to take transfer functions from 103 kHz to 903 kHz with 1kHz IF bandwidth and 25 averages for some of the measurements. The template file is included.
  • 1st measurement was taken from Test1 input port at RF Board D0901894 to the OUT2 port on the common path in board D040105.
  • Remaining measurements are taken with Test1 input port terminated with 50 Ohm and input from Test2 port on the common path in board D040105 to various test points as marked on the plots.
  • I followed essentially same measurements on the zero model of the circuit from TTFSSzero package I recently created.
  • I then divided transfer functions to obtain testpoint to testpoint stagewise transfer functions, for both measured data and simulated data and compared the results.
  • In some cases where I felt data above 102.4 kHz is required, I used AG 4395A for that and concatenated the two results. Hence there is a step-change in measured transfer functions at 102.4 kHz in some cases.

Conclusions:

  • The first attached file, NorthFSSInvestigationMismatches.pdf has the plots which had a significant difference between measurements and simulations. Other stages are more or less working as expected.
  • Clearly something is off between test point 15 and test point 16. This is the third stage in PZT path where there is a notch and boost switch.
  • The boost is not working at all and our notch might be placed at a different place than simulations. However, simulations use 35 pF value for C46 on board D040105 which is just arbitrary and we don't really know the real tuned value.
  • From test point 16 to 18 too, there is significant difference after 10 kHz, but I'm not sure if this is an artifact of my measurement and simulation technique or not.
  • Finally, on the EOM Path, everything is good upto testpoint 12. It is right before the HV amplifier that there is a significant difference in what simulation suggests and what is actually happening.
  • I should maybe redo this last measurement with low excitation voltage to ensure nothing is railing.
  • Also, the appearance of a notch at 4 Hz is just very weird in this last simulation. It was not predicted by an earlier similar analysis using pyliso.

Calling out for help

Help Wanted


Code and Data


Edit Fri Aug 9 09:50:24 2019 anchal:

The last measurement was taken in the wrong way and hence it was mismatched. The ground pin was connected to the wrong position. I retook data today and seems like EOM path and is all healthy :). But the other mismatches still need to be investigated. The Code and Data are updated through git.


Edit Thu Jan 23 19:33:55 2020 anchal:

The mismatched were there because the stage saturates when boost is on. Need to take that measurement with appropriate offset applied through AO Offset. This is done in this CTN:2518.

Attachment 2: NorthFSSInvestigationMismatches.pdf
NorthFSSInvestigationMismatches.pdf NorthFSSInvestigationMismatches.pdf NorthFSSInvestigationMismatches.pdf
Attachment 3: NorthFSSInvestigation.pdf
NorthFSSInvestigation.pdf NorthFSSInvestigation.pdf NorthFSSInvestigation.pdf NorthFSSInvestigation.pdf NorthFSSInvestigation.pdf NorthFSSInvestigation.pdf NorthFSSInvestigation.pdf NorthFSSInvestigation.pdf NorthFSSInvestigation.pdf NorthFSSInvestigation.pdf NorthFSSInvestigation.pdf NorthFSSInvestigation.pdf NorthFSSInvestigation.pdf
  2388   Mon Aug 12 11:56:21 2019 anchalDailyProgressNoiseBudgetAdding specifics of discepancy

Adding more specifics:

Discrepancy #1

Following points are in relation to previously used noisebudget.ipynb file.

  • One can see the two different values of effective coating coefficient of thermal expansion (CTE) at the outputs of cell 9 and cell 42.
  • For thermo-optic noise calculation, this variable is named as coatCTE and calculated using Evans et al. Eq. (A1) and Eq. (A2) and comes out to (1.96 +/- 0.25)*1e-5 1/K.
  • For the photothermal noise calculation, this variable is named as coatEffCTE and is simply the weighted average of CTE of all layers (not their effective CTE due to the presence of substrate). This comes out to (5.6 +/- 0.4)*1e-6 1/K.
  • The photothermal transfer function plot which has been used widely so far uses this second definition. The cancellation of photothermal TF due to coating TE and TR relies on this modified definition of effective coating CTE.

Following points are in relation to the new code at https://git.ligo.org/cit-ctnlab/ctn_noisebudget/tree/master/noisebudget/ObjectOriented.

  • In my new code, I used the same definition everywhere which was the Evans et al. Eq. (A1) and Eq. (A2). So the direct noise contribution of coating thermo-optic noise matches but the photothermal TF do not.
  • To move on, I'll for now locally change the definition of effective coating CTE for the photothermal TF calculation to match with previous calculations. This is because the thermo-optic cancellation was "experimentally verified" as told to me by Rana.
  • The changes are done in noiseBudgetModule.py in calculatePhotoThermalNoise() function definition at line 590 at the time of writing this post.
  • Resolved this discrepancy for now.

Quote:

The new noise budget code is ready. However, there are few discrepancies which still need to be sorted. 

The code could be found at https://git.ligo.org/cit-ctnlab/ctn_noisebudget/tree/master/noisebudget/ObjectOriented

Please look into How_to_use_noiseBudget_module.ipynb for a detailed description of all calculations and code structure and how to use this code.


Discrepancy #1

In the previous code, while doing calculations for Thermoelastic contribution to Photothermal noise, the code used a weighted average of coefficients of thermal expansion (CTE) of each layer weighted by their thickness. However, in the same code, while doing calculations for thermoelastic contribution to coating thermo-optic noise, the effective CTE of the coating is calculated using Evans et al. Eq. (A1) and Eq. (A2). These two values actually differ by about a factor of 4.

Currently, I have used the same effective CTE for coating (the one from Evans et al)  and hence in new code, prediction of photothermal noise is higher. Every other parameter in the calculations matches between old and new code. But there is a problem with this too. The coating thermoelastic and coating thermorefractive contributions to photothermal noise are no more canceling each other out as was happening before.

So either there is an explanation to previous codes choice of using different effective CTE for coating, or something else is wrong in my code. I need more time to look into this. Suggestions are welcome.


Discrepancy #2

The effective coating CTR in the previous code was 7.9e-5 1/K and in the new code, it is 8.2e-5 1/K. Since this value is calculated after a lot of steps, it might be round off error as initial values are slightly off. I need to check this calculation as well to make sure everything is right. Problem is that it is hard to understand how it is done in the previous code as it used matrices for doing complex value calculations. In new code, I just used ucomplex class and followed the paper's calculations. I need more time to look into this too. Suggestions are welcome.

 

 

  2390   Tue Aug 13 11:59:56 2019 anchalDailyProgressNoiseBudgetChecking the differences between old and new noisebudget

I saved the traces of old and new noise budgets as txt files and then plotted them together to understand the differences between the codes. One can refer to CTN:2250 for a summary of calculations of old noise budget.


Coating Brownian Noise:

  • Old noise budget uses a simple formula from Harry et al. (2001) Eq 21.
  • New noise budget uses analysis of Hong et al . PRD 87, 082001 (2013) which takes into account different bulk and shear loss angles for each layer.
  • In this run, I used the same values of bulk and shear loss angles of both AlGaAs and GaAs, equal to 2.41e-5 +/- 0.482e-5 rad. This is the same value used in old calculations as well.
  • It is interesting to see that there is almost no difference (<5% mostly) in the prediction of two methods even though they were done with vastly different methods.
  • In the future, however, I would try to use different values. But there is no proper source for them. I can try using the coating loss angle values mentioned in Penn et al JOSA B Vol 36, Issue-4 (2019).

Coating Thermo-optic Noise:

  • Both new and old methods use the same formula from  Evans et al. (2008), Eq 4.
  • But to calculate the effective coefficient of thermo-refractive effect, the old method used a complex matrix calculation which I'm unable to follow. The value was 8.61e-5 1/K.
  • The new noise budget follows Evans et al. (2008) Appendix B to the best of my knowledge and generates a slightly different value of  8.2e-5 1/K.
  • However this changes the coating thermo-optic contribution by almost 50%!
  • IF ANYONE IS WILLING TO LOOK INTO THIS DISCREPANCY FOR A SANITY CHECK, I'LL BE REALLY HAPPY. CONTACT ME FOR MORE SPECIFICS.

Photothermal Noise:

There is no distinction in the calculation of this contribution after the changes made in CTN:2388, but there is still a difference (which reaches to around 20% above 1 kHz). This is maybe because of interpolation errors when taking the differences. But I'm not sure about this. This can take a sanity check from others as well.


No differences in:

The following calculations had no differences between the two noise budgets and the contribution differences are also none or minimal. 

  • Substrate Thermo-elastic Noise
  • Substrate Brownian Noise
  • Seismic Noise
  • PDH Shot Noise
  • PLL Oscillation Noise
  • PLL Readout Noise
  • Residual NPRO Noise
Attachment 1: ComparisonOfOldandNewNoisebudget.pdf
ComparisonOfOldandNewNoisebudget.pdf ComparisonOfOldandNewNoisebudget.pdf ComparisonOfOldandNewNoisebudget.pdf ComparisonOfOldandNewNoisebudget.pdf ComparisonOfOldandNewNoisebudget.pdf ComparisonOfOldandNewNoisebudget.pdf ComparisonOfOldandNewNoisebudget.pdf ComparisonOfOldandNewNoisebudget.pdf ComparisonOfOldandNewNoisebudget.pdf ComparisonOfOldandNewNoisebudget.pdf ComparisonOfOldandNewNoisebudget.pdf
Attachment 2: ComparisonOfOldandNewNoisebudget.zip
  2394   Mon Aug 19 15:54:51 2019 anchalSummaryTempCtrlVac Can Heater Driver not working!

I had aligned the North Cavity before the weekend and was about to align south one today when I saw that the modematching on the North Cavity has fallen to 20%. This is a tell-tale sign of vacuum can temperature changing too much. When I checked, indeed the temperature sensors were railing to their lower most value of 26.599 Celcius. Same for both in-loop and out of loop sensors. While the table top temperature sensor was giving a meaningful value.


Investigation begins

I first checked point by point the temperature sensor board LIGO-D1800304. From ADC all the way back to the AD590s.The two sensors were indeed giving a voltage of 4.8 V through a transimpeadance of 16.25k  which meant 295.385 uA of current corresponding to 22.23 Celcius. So indeed the sensors were telling me that the can had cooled down to almost room temperature over the past 2 days.


Framebuilder logs

I checked the framebuilder logs to figure out what has happened. The temperature was being stabalized at 34.38 Celcius by the PID script. At around 15;20:25 Aug 16, 2019 PDT, the temperature starts decaying. Infact, I should use this data in future to calculate current time constant of temperature decay of the can through the insulation. The table temperature was around 19 Celcius all this time. I found out that FB4 is not recording the channels that I have added later. I need to look into this as well.

Attached is the decay plot of the temperature


Possible points of problem

After a deep search through elog, CTN:2043 and CTN:2045 are the most relevant latest post. Kira and Kevin worked on this heater drier circuit and I'm doubting that something blew up in this circuit CTN:1903. I guess this would be my first point of attack.

Another possibility is that the heater load got disconnected. Well, I just checked the resistances and I get values of 38, 70, 70 and 38 Ohms. These are the right values according to CTN:1750. This is not the issue.

Lastly, the worst possible issue would be that the temperature sensors are reporting wrong temperature. But looking at the the properexponential decay of temperature reported by them, I would first assume that they are working fine.


Code and Data

Attachment 1: VacCanInloopTemp.pdf
VacCanInloopTemp.pdf
  2395   Tue Aug 20 11:19:35 2019 anchalDailyProgressTempCtrlVac Can Heater Circuit repaired

See CTN:2394 for the symptoms and investigation. Open this post at CTN:2395 to see the chain of previous work on this circuit.


Fixes:

  • I replaced the OPA140. This didn't solve the issue.
  • I also replaced the IRF630 MOSFET. For the heat sink, I just used the mica pad and no extra thermal glue.
  • I retouched the solder joints at some places.

Present State:

  • As usual, the sense resistor (1 Ohm) is getting very hot. The MOSFET is not unusually hot after about 10 min of supplying 1.5 A of current.
  • This circuit should be ideally printed on PCB with thick traces and a proper design for heat dissipation. We need to get out of this workaround protoboard circuit! Can be a starter project for a new student or an undergrad.
  • The signal input and heater output all are unnecessarily complicated different kinds of connectors. Particularly from DAC to the box, it could be a much simpler twisted pair of wires.
  • I noticed now that the Sorenson power supply was supposed to be exclusively used for these can heate drivers. It is presently being used for driving EOMs also. I'll switch the EOM drivers to the other Kepco supplies.
  • I checked for oscillations in the heater circuit as mentioned before. Seems like the steps taken before are still working file and I couldn't see any oscillations across the sense resistor.
Attachment 1: CircuitCloseup.jpg
CircuitCloseup.jpg
Attachment 2: BoxOverview.jpg
BoxOverview.jpg
  2396   Tue Aug 20 19:38:36 2019 anchalSummaryComputersFramebuilder re-configured

I updated ctn_scripts\channelFramebuilderConfigFileCreator.py to work with the new format of modbus hosting through docker (and cleaned it a bit). Also, from now on, C3CTN.ini will stay in the ctn_scripts repo to have version control.

I have run this once and followed instructions from CTN:2014 to restart frambuilder daqd process so that all new channels are logged as well.

Quote:

I found out that FB4 is not recording the channels that I have added later. I need to look into this as well.

  2397   Wed Aug 21 10:28:58 2019 anchalSummaryTempCtrlVacuum Can Step Response

Utilizing the fact that the heater stopped last Friday, I fitted the day to extract out a time constant for cooling down of the Vacuum Can through the present insulation. Attached is the fit. The time constant has come out to 2.298 +/- 0.001 hr.

Quote:

Infact, I should use this data in future to calculate current time constant of temperature decay of the can through the insulation.

Code and Data

Attachment 1: VacCanInloopTempDecayFit.pdf
VacCanInloopTempDecayFit.pdf
  2398   Wed Aug 21 16:17:47 2019 anchalDailyProgressTempCtrlLeave the Heater Circuit Alone!

I aligned the south cavity today achieving a nice 70% mode matching. While doing so, I realized a big issue that was gone unseen before the heater circuit blew up. I saw that since the vacuum can temperature control was active and was making a lot of jumps here and there all over the 1.5 A range, the Sorenson power supply isn't so good in keeping up with such sudden current changes. In effect, I think the Vacuum Can Heater's PID control signal gets coupled to the overall power supply coming from Sorenson.This +- 24 V rail was connected to EOM drivers earlier. Because of the poor design of EOM drivers, the EOM's are constantly at a DC voltage of +24V from this Sorrenson Power supply with only a passive filter. I could see today that when vacuum can PID was on, the laser frequency was haphazardly changing making it much more difficult to align the cavity. I was able to align it in minutes once I switched off the vacuum can PID.

So moral of the story is, keep the vacuum can heater circuit alone and Sorrenson Power supply is exclusive for it.

I shifted the EOM driver's power supply to Kepco which supplies for other rack-mount electronics as well.

Quote:
  • I noticed now that the Sorenson power supply was supposed to be exclusively used for these can heate drivers. It is presently being used for driving EOMs also. I'll switch the EOM drivers to the other Kepco supplies.

 

  2399   Fri Aug 23 18:15:49 2019 anchalDailyProgressBEATBeatnote after a while

The cavity temperature control (aftter the last fixes by Andrew) seem to be working good actually now that the Vacuum Can temperature is stabilized nicely. SO I didn't want to interfere with the PID's job which it seems is trying to reach to the set point almost critically. However, today, the beatnote came below 125 MHz, so we were in range with New Focus 1811 to take the spectrum. So I did it.


Two measurements

I used the coupled output from 20 dB coupler to feed the moku and use it's phase meter along with SR785 witht he previous PLL setup. Since the beatnote was still drifitng by around 10 kHz/24 sec, I took spectrum with linewidth of 1 Hz and used 20 averages to catch the PLL frequency noise in between its jumps. Simultaneously (almost), I took measurements with moku also to see if we can reliably switch over to moku. Good thing about moku is that it is faster in adjusting it's carrier frequency to lock to the signal and hence the jumps are unnoticeable. The attached plots are the measurements.


Uncertainty in moku's ASD plots!

Scott and I have written a modified PSD calculation function, which does everything same as a normal weltch function would do, but on top of it, it provides 15.865% and 84.135% percentile of all the individual segments the function used to calculate PSD. Also, the reported value is median and not mean. Further, this function implements welch function with different sizes of npersegment to ensure more averaging at higher frequencies and equal number of points in each decade. All this is done in mokuReadFreqNoise.py which uses modeifiedPSD.py. Linear detrending of data is also used before calculating the PSDs from the timeseries data provided by moku.


Conclusions

  • I think we can safely switch over to using Moku for measuring beatnote frequency noise, given it is available.
  • Beatnote obviously doesn't look so good. But at the point, the FSS aren't working as expected.
  • There is a weird peak at around 500 Hz which wasn't there before.
  • I'll add the noisebudget with new calculations using different values of Shear and Bulk Loss Angles soon. It is kind of difficult to get these values though.
  • My plan is to keep this functioning state all the time. I'll make sure the cavities are locked with good mode matching and near the desired beatnote frequency.
  • Then I'll focus on the known issues and sources of error and will keep monitoring the beatnote changes every 2-3 days.

Code and Data

Attachment 1: ComparisonOfMokuandSR785BeatnoteSpectrum.pdf
ComparisonOfMokuandSR785BeatnoteSpectrum.pdf ComparisonOfMokuandSR785BeatnoteSpectrum.pdf ComparisonOfMokuandSR785BeatnoteSpectrum.pdf ComparisonOfMokuandSR785BeatnoteSpectrum.pdf ComparisonOfMokuandSR785BeatnoteSpectrum.pdf
  2401   Tue Aug 27 18:56:58 2019 anchalDailyProgressNoiseBudgetWhat values of Loss Angles are good?

The new noisebudget code follows Hong et al . PRD 87, 082001 (2013) calculations to calculate Coating Brownian noise. This calculation uses different loss angles for bulk and shear strain. In fact, the calculation uses different loss angles for each layer as well if known.  The closest reported values I could find are from Penn et al. JOSA B 36, 4, pp C15-C21 (2019). They used mechanical ringdown measurements of large disks and COMSOL modeling to estimate the bulk and shear loss angles.

I used these values and compared the change in the estimate of coating Brownian noise contribution. Attached is the result.

If the loss angles values reported by Penn et al. are correct, then our Coating Brownian noise would actually be buried beneath all other noise contributions. So I'm not sure what is correct, what is not? Is my understanding of this wrong somewhere?

The old calculations were described in CTN:2250.

I would like some guidance on this.


Edit Wed Aug 28 10:49:45 2019 anchal:

I did a mistake in the plot earlier. The new data was in PSD, not ASD, so it needed to be square-rooted before comparing with the old data. I've updated the plot now.

It seems like the induction of new values and new method changed the effective coating loss angle (used in the previous calculations). If Penn et al. values are correct the expected Coating Brownian noise contribution has actually increased by about a factor of 5. However, I'm not sure where the previously used effecting coating loss angle value of (2.41 +/- 0.2)e-5 came from. Complete noisebudget is coming soon.

Attachment 1: ComparisonOfUsingDifferentLossAngles.pdf
ComparisonOfUsingDifferentLossAngles.pdf
  2402   Tue Aug 27 19:15:51 2019 anchalDailyProgressBEATDaily acquisition of beatnote started

I have started daily acquisition of beatnote from today onwards. This directory will contain beatnote spectrums taken everyday along with a yaml file containing logged channel values for experiment configuration. Our aim is to collect this data so that overall degradation/enhancement of beatnote can be plotted with time along with any significant changes in the crucial experiment parameters. This will also help in identifying gains or loss after any change on the table or scripts.


Some updates:

  • The vacuum can temperature is stabilized to within 10 mK, verified with an out of loop temperature sensor.
  • The Cavity heater PID is also able to reach near 27 MHz and at times stabilize the beatnote to better than 4 KHz/min drift.
  • My guess is, if left uninterrupted, the PID will eventually create a very stable beatnote frequency. If not, we can cross-check the correlation between table temperature and beatnote as both are being monitored continuously.
  • I shifted to SN101 Beatnote Detector today as we are close to its peak transimpedance.
  • The ws1 system's graphics are deteriorating even more. The medm screens distort after few hours and striptool plots do not work well with too many curves.
  • Major Focus Right Now: Understanding scattering with elog surveys and looking forward to ordering parts for new can designed by Andrew.
  2403   Wed Aug 28 09:49:44 2019 anchalSummaryscatterBeam Dump Status

We need to switch out normal flat-faced beam dumps with triangular cavity beam dumps in all places where they are not present. Following is a summary of beam dump status

Total Normal Beam Dumps behind PMCs: 12

Triangular Cavity Beam Dump Mount Requirements
Position South Path Present? North Path Present? Needed more?
PMC RFPD reflection 1 1 0
FSS RFPD reflection 1 1 0
PMC Back-reflection 0 1 1
BS Discard before PMC EOM 0 1 1
Faraday Isolator discard before cavities 0 0 2
Trans CCD (Common) 1 0 1
Trans ISS PD Reflection 0 0 2
Trans BS discard before PD 0 0 2
Beatnote NF1811 (Common) 1 0 0
Beatnote SN101 (Common) 1 0 0
Total     9

 

 

 

 

 

 

 

 

 

 


Present Inventory for triangular beam dumps and requirements
  Present Quantity in CTN Needed more according to the above table
Triangular Cavity Mounts 3 6
Square 1"x1" Black Glass 16 11
Rectangular 1"x1.5" (Estimate) Black Glass 4 0
Square 1"x1" Black Glass with Hole 4 0

Triangular Cavity Beam Dump
Triangular Cavity Beam Dump

 

  2404   Wed Aug 28 16:51:49 2019 anchalDailyProgressNoiseBudgetLatest noisebudget as of Aug 23, 2019

Attached is the latest noise budget calculated using the new object-oriented script.


Noise Budget Model:

Parameter files and all noise contribution PSD data.

Note that since we used Penn et al. JOSA B 36, 4, pp C15-C21  values for shear and bulk loss angles of the coating and used Hong et al . PRD 87, 082001 (2013) calculation procedure, as pointed in CTN:2401, the estimated coating brownian noise contribution is more than previously calculated and dominates the total estimated noise from about 20 Hz to 20 kHz. Also, the PLL noise was switched with Moku Frequency Noise measured in CTN:2357


Differences in the actual experiment from the model:

The experiment configuration file is attached. Major differences are:

  • Model uses 7mW of incident power. 8.8 mW was incident on North Cavity and 7.1 mW was incident on the South Cavity
  • Model uses 0.7+/-0.05 mode matching. North cavity was at ~0.65 and South was at ~0.77
  • Model uses temperature of 305 +/- 1 K. Vacuum can temperature was 306.53 K and table temperature was 292.23 K.

Beatnote Measurement Data


Inferences:

  • We aren't doing particularly better or worse than Nov 2017!
  • In fact there is a bump at around 500 Hz which was previously reported in CTN:2183 by Andrew and Craig as a scatter feature. So need to look into this.
  • FSS.... FSS!
Attachment 1: ExpStateAug23_2019Measurement_28-08-2019_175138_mean.yml
C3:PSL-HEATER_SHIELD_COM_POUT: '0.5'
C3:PSL-HEATER_SHIELD_DIFF_POUT: '0.476419'
C3:PSL-NCAV_FSS_COMGAIN_DB: '10.0'
C3:PSL-NCAV_FSS_FASTGAIN_DB: '10.0'
C3:PSL-NCAV_FSS_SLOWOUT: '3.39457'
C3:PSL-NCAV_REFL_POW: '3.10606'
C3:PSL-NCAV_TRANS_POW: '5.7418'
C3:PSL-PLL_AUTOLOCKER_BEATNOTE_FREQ: '105.765'
C3:PSL-PLL_AUTOLOCKER_FREQ_MOD: '10.0'
C3:PSL-PRECAV_BEATNOTE_FREQ: '105.765'
... 9 more lines ...
Attachment 2: CTNnoiseBudget_20190823.pdf
CTNnoiseBudget_20190823.pdf
  2405   Thu Aug 29 19:15:45 2019 anchalDailyProgressBEATDaily acquisition of beatnote started. Now Automated.

I have written a script which will trigger Moku every day at 3 am to take a beatnote timeseries measurement. It will then calculated the ASD of the data and will save important experiment configuration details in a log file. This will happen in ctn_noisebudget/Data/dailyBeatNoteSpectrum directory.

I have currently configured it to take timeseries for 60s with 10 kHz tracking bandwidth using Koji's SN101 beatnote detector. The cavity temperature control is working nicely with keeping the beatnote close to the peak frequency of 27.34 MHz, within 500 kHz of it atleast.

  2406   Fri Aug 30 17:31:56 2019 anchalDailyProgressTempCtrlVacuum Can Temperature Control Setpoint Step Test

Following Rana's test done in 40m:1986, I have programmed the lab to go through a similar test. Following things will happen:

  • At 3:30 am (roughly 30 minutes after the daily beatnote measurement), the cavity heater PID will be switched off.
  • The heating actuation will remain at what it was.
  • The setpoint of Vacuum Can temperature control will increase by 1^\circ C
  • Wait for 8 hrs.
  • The setpoint of Vacuum Can temperature control will decrease by 2^\circ C.
  • Wait for 8 hrs.
  • The setpoint of Vacuum Can temperature control will return to nominal value.
  • Repeat this next day until Sep 3rd is reached.

So this will happen three times. In between, the cavity heater PID control will have 7.5 hrs to stabilize the beatnote frequency and at 3:00 am as usual beatnote measurement will happen.

All channels are being recorded at FB4 in QIL so we can look back the relevant channels after the test is over. Putting a sticky note in QIL for not to interrupt FB4.

  2407   Fri Aug 30 18:25:31 2019 anchalMiscFSSup to date schematics

All details regarding TTFSS boxes present in CTN has been updated at this page in ATFWiki

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

I have added fields of who made the changes, on which box and on which board to make this change log more readable. These fields should be followed from now on.

Relevant circuit schematics, photos and zero models are kept in ctn_electroncs/TTFSSzeroCTN repo to keep a version history of changes as well. This should be updated everytime any change is made to the boxes from now on.

Note: The current updates were made by using Andrew's change log and verifying that no other changes have been mentioned in our elog history other than the change log. However, if the real circuit has any changes which people did not log, then they are not present in these schematics or model. These, if they exist, will be added as soon as we find them.

Quote:

I'm skeptical of your FSS changes over the past year. Can you please link to the DCC entry that has the actual, real, as-built, as-modified FSS schematics? i.e. including all changes no matter how minor.

 

  2408   Fri Aug 30 18:40:01 2019 anchalNotesBEATQuick note: BN detector changed to NF1811

Due to testing of CTN:2406 I expect the beatnote to be away from 27.34 MHz. So I have changed the beatntoe detector to wideband New Focus 1811 for the long weekend. It has badnwidth of 125 MHz.

  2409   Tue Sep 3 16:48:23 2019 anchalDailyProgressNoiseBudgetDaily updates on noise budget

Daily noise budget plots are now pushed to these links.

CTN Daily Beatnote Spectrum

            Here, all beatnote spectrums since Aug 27, 2019 are plotted in an alpha scaled manner. The darker the plot, more recent it is.

CTN Latest Beatnote Spectrum

           Here, the latest 3 days of beatnote spectrum is plotted.

  2410   Wed Sep 4 11:04:08 2019 anchalDailyProgressTempCtrlVacuum Can Temperature Control Setpoint Step Test - Results

Attached are the results of this step test.

  • The Vacuum Can Temperature PID reached the setpoint almost immediately.
  • The out-of-loop sensor has a different offset but shows same 1-degree change as an in-loop sensor.
  • In the FSS Slowout Voltages which control the NPRO Laser temperatures, we can see that South Slow PID goes to a steady-state more smoothly and without much oscillations.
  • While the North Slow PID shows some oscillations. I'm not sure what can be concluded from this observation.
  • Note that the cavity heater PID was switched off during these measurements but the heaters were left on to the values they were at before switching PID off.
  • The second attachment is an exponential decay fit of the slow voltage values after the two steps on each day on each path.
  • The values of these time constants vary from 3 hrs to 4 hrs depending on the day and path.
  • I was unable to convert the slow voltages to cavity temperature reliably. I found some estimates in CTN:2027 but they were not replied to positively. And the absolute value is still unknown, so this conversion would hardly give any new insight.
  • However, since temperature change would be some constant number only, it wouldn't affect the time constant estimate done here.

Code and Data

Attachment 1: VacCanStepResponse.pdf
VacCanStepResponse.pdf VacCanStepResponse.pdf VacCanStepResponse.pdf
Attachment 2: VacCanStepResponseFit.pdf
VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf VacCanStepResponseFit.pdf
  2412   Wed Sep 4 14:41:33 2019 anchalNotesBEATQuick note: BN detector changed to SN101 and other changes
  • Beatnote detector changed from NF1811 -> SN101
  • Tuned slightly modematching in North path. Increased by 3 %.
  • NFSS Fastgain increased to 14.
  • Switched off all auxilary equipments: Marconi 2023A, SR780, SR785 and AG4395A.
  • Moku is now directly connected to beatnote detector. (Earlier it was connected through a coupler)
  • Moku firmware update to 1.9 is done. Pymoku is upgraded to 2.8.0.
  • Flag '-a' added in dailyBNspec.py code to switch on 10x attenuation for large signals. This makes input range 10Vpp.
  • The new updates have caused some errors to creep in in remote control of Moku. So daily BN measurement is halted.
  2413   Wed Sep 4 15:08:51 2019 anchalDailyProgressBEATBeatnote Timeseries from Oscilloscope

For record, I took data of beatnote timeserieswith fasted sampling rate on Tektronix TDS 3034C (CTN_OSC_SN01).


  • I do see that that positive half cylce looks better than negative half cycle.
  • There might be some clipping happing on the negative peak, but can't say for sure.
  • Right now, it is 3.48 Vpp, so running moku with 10Vpp input range.
  • To the wise people around me, please let me know if there is something glaringly wrong with this signal.

Code and Data

Attachment 1: BeatnoteOsc.pdf
BeatnoteOsc.pdf
  2414   Wed Sep 4 17:31:19 2019 anchalNotesVacuumPlan of Action for Vacuum Can Flange replacement

The plan of action has been moved to a new wiki page for better documentation.

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

  2415   Thu Sep 5 11:15:06 2019 anchalDailyProgressTempCtrlVacuum Can Temperature Control Setpoint Step Test - Results

I used the calibration of North and South NPRO control voltage to frequency change from CTN:1948.

Then using the following formula:

\frac{\Delta T}{\Delta V} = \frac{S[\frac{Hz}{V}]}{-\alpha [\frac{1}{K}]\frac{c[\frac{m}{s}]}{\lambda [m]}}

where S is the calibration slope for NPRO from volts to the frequency

\alpha is the coefficient of thermal expansion of fused silica, 5.5\times10^{-7} K^{-1}

c is the speed of light 299792458 m/s

The offset was adjusted so that at t=0, the cavity temperatures is the same as the vacuum can in-loop temperature sensor reading at t=0.

This gave for the South Cavity -22.456 K/V and for the North Cavity -23.489 K/V

The South Cavity temperature changed 0.511 K, 0.539 K, and 0.565 K in the first step on the three days. Mean response to the first step is 0.538 K.

The North Cavity temperature changed 0.520 K, 0.574 K, and 0.639 K in the first step on the three days. Mean response to the first step is 0.578 K.

The South Cavity temperature changed -0.878 K, -0.860 K, and -0.863 K in the second step on the three days. Mean response to the second step is -0.867 K.

The North Cavity temperature changed -0.903 K, -0.933 K, and -0.910 K in the second step on the three days. Mean response to the second step is -0.915 K.


Code and Data


Edit Fri Sep 6 12:01:49 2019 anchal in RED above.

Found out that there is a bored hole in the spacer so the laser doesn't travel in fused silica actually. So the refractive index used above is wrong.

Updated calculations and plots for the same.

Attachment 1: VacCanStepResponseTempAxis.pdf
VacCanStepResponseTempAxis.pdf VacCanStepResponseTempAxis.pdf VacCanStepResponseTempAxis.pdf
  2416   Thu Sep 5 16:59:36 2019 anchalDailyProgressBEATBeatnote Frequency long time series data

Attached is captured beatnote frequency between Aug 27th 2019 to Today, Sep 5th 2019.

I have attached a few more zoomed-in plots as well. This code will serve us in the future as well. Only the green regions are where both cavities were locked and cavity heater PID was engaged. This data involves the experiment time of CTN:2406 and hence have the disturbances of that time as well.

Essentially, there is no fixed stability number one can really quote for this PID. It looks stable in regions, but at times it shoots up or down randomly. Maybe some of them are because of me doing something on the table, but some are late at night which can only be explained by the movement of ghosts.


fromFBread.py updated

fromFBread.py now has an optional flag -d for decimating the read data, so that smaller files are created. Example: -d 160 will decimate the data by a factor of 160 making a sampling rate of 0.1 Hz. It calculates mean of the data, for a block size of 160 (corresponding to 10s) and also calculates standard deviation in this block and adds that as additional columns in the read data. Hence the plots attached here have uncertainties as well.


Code and Data

Attachment 1: BeatnoteLongTimeSeries.pdf
BeatnoteLongTimeSeries.pdf BeatnoteLongTimeSeries.pdf BeatnoteLongTimeSeries.pdf
  2417   Thu Sep 5 19:32:02 2019 anchalDailyProgressPMCNorth PMC might be cause of 500Hz bump

I was looking at the error signals of PMC servo and found some systematic oscillations in NPMC error signal at around 500 Hz.

So, I connected back the beatnote to the Marconi PLL and used the error signal from there to measure beatnote - NPMC error signal cross-spectrum. Here, the channel marked Mixer Out on the Servo card is FP3Test port which is marked as 'Mon1' on the schematic (latest schematic). This channel is essentially the output of mixer buffered with gain 1 through an LT1128. Note that currently on North side, we are using FP2Test to send the PD signal in with an external mixer.

Something is either physically wrong near North PMC or the card might have developed some bug, which needs to be tested.


Code and Data

Attachment 1: BN_NPMCErr_CrossSpec.pdf
BN_NPMCErr_CrossSpec.pdf BN_NPMCErr_CrossSpec.pdf
  2418   Thu Sep 5 19:52:06 2019 anchalNotesBEATQuick note: FSS gain reduced, Moku input range changed
  • Changed North FSS Fast gain back to 10 dB.
  • Increased threshold for gain cycling to 0.1 on both FSS paths. This was probably the reason for increased BN noise yesterday.
  • Mokuis again taking signal from a 20 dB coupler.
  • Changed input range of mokuback to 1Vpp.
  • Marconi and PLL autolocker are back on.
  2420   Mon Sep 9 16:31:34 2019 anchalDailyProgressPMCNorth PMC open loop investigation

I opened the NPMC servo box and ran TF analysis up to all test points and compared with their zero model. Everything looks normal in these transfer functions.
So the oscillations might be happening due to closing of the loop. I'll take a measurement of total open-loop transfer function next with the PDs and PZT in the loop.

Updated schematics and Zero Model


Code and Data

Attachment 1: NPMC_openInvestifation.pdf
NPMC_openInvestifation.pdf NPMC_openInvestifation.pdf NPMC_openInvestifation.pdf NPMC_openInvestifation.pdf
  2421   Tue Sep 10 17:13:51 2019 anchalDailyProgressPMCNorth PMC Servo Card Upgraded

It turns out that the noise is either injected through the EOMs or through some mechanical oscillation in the table or through RFPD SN020. The servo card was working normally. However, since I had opened up the box, I used this opportunity to increase the first stage gain on the FP2test input and also made it 50-ohm input impedance by adding a 51 Ohm resistor in parallel to R8. Now, beware that on the actual board, R5 and R8 labels are actually swapped. This helped keep the gain set by AD602 to 7 dB now, instead of 30 dB maximum. This way we are able to increase the gain more instead of getting saturated. The hunt for 500 Hz bump would move to finding on table sources now.

  2422   Tue Sep 10 19:43:02 2019 anchalNotesBEATQuick note: Detector changed to NF1811
  • Changed detector to NF1811
  • Changes in NPMC servo card. See CTN:2421.
  • Updated noise budget with new bulk loss angle estimates as presented in LIGO-G1901676 and LIGO-G1901765
ELOG V3.1.3-