40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  PSL, Page 7 of 52  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  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
  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
  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.
  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
  2425   Fri Sep 13 16:40:56 2019 anchalDailyProgressBEATNew channel added; BNSignUpdate made better
  • I added C3:PSL-PRECAV_BEATNOTE_FREQ_SLOPE2 as a new channel. This holds the seconds derivative of precavtybeatnote frequency in Hz/s/s.
  • The slope calculation code is separated now from sign update code.
  • Slope is now calculated with moving averageof changing quantity over 10s. This gives much better estimates of both the slopes.
  • Sign update is also more robust now. It checks if frequency counter is stuck for atleast 0.5s and last read BN frequency was less than 5 MHz.
  • Sign update also has a dead time on its trigger of 1 minute to avoid changing sign multiple times in a single jump.
  • So far, the sign update code is working eallygood. Hopefully, the cavity temperature control will not loose track now.
  2428   Mon Sep 16 17:05:00 2019 anchalSummaryBEATBeatnote Frequency stabalization

Over the weekend, I ran Relay Tuning method for the PID of beatnote frequency control. After CTN:2426 this needed to be done to fix the PID constants to appropriate value. The results of the tuning were:

Critical period Tc = 45.900000000000006
Critical gain Kc = 18.382414309527164
Suggested kp, ki, kd are 3.676482861905433, 0.16019533167343933, 56.25018778715313

RXA: Wah! crying precision help here

The relay amplitude was set to 0.5 W and I could see very good sustained oscillations which the code used to get above calculated values.


Testing performance

I tested the performance of PID today. Attached is the convergence of beatnote frequency, which happened in about 20 minutes only to 40 kHz offset value. After that point, the proportional gain of the PID is so high, that the actuator response essentially copies the fluctuations in the beatnote frequency itself. So no more stabilization happens. The integral constant is very low (I think it is required for quick convergence with no overshoot), so to travel this 40 kHz distance, it will probably take hours. But that's fine with us as our photodetectors work well enough with this offset too.

If you see the second plot, the beatnote did not drift beyond +/- 2kHz for over 40 min. I want to see if tonights beatnote will get any better due to this good stabilization.


Code And Data

Attachment 1: BeatnotePIDPerformance.pdf
BeatnotePIDPerformance.pdf BeatnotePIDPerformance.pdf
  2429   Mon Sep 16 18:03:33 2019 anchalNotesBEATQuick note: Detector changed to Sn101
  • Beatnote is stabalized to 27.3 MHz. Changing detector to SN101.
  • Reduced South PMC Variable Gain to -2dB from -1dB as it was oscillating. That's probably why 16th september BN was bad.
  • Changed bandwidth of Moku for frequency nosie measurement to 2.5 kHz.
  2440   Tue Oct 1 17:28:25 2019 anchalNotesBEATQuick note: Moku connected with USB

Liquid Instrument's Application Engineer at La Jolla told me that connection with moku might be mroe stable if it is directly connected to the computer through a USB cable. It still gets identified with Name, Serial Number or IP address, just the connection is mroerobust. So today, I have connected our moku with USB. I have seen in past couple of weeks that every few days the moku data transfer gets stuck or it fails to connect through LAN. So trying this out.

  2441   Wed Oct 2 12:22:44 2019 anchalDailyProgressBEATBeatnote Frequency long time series data

After the new PID parameters were tuned (CTN:2428), I waited for some time and the beatnote was stably locked to its setpoint of 27.34 MHz for over 2 weeks now. It is a good time to assess the beatnote frequency stabilization. Here I took data of 10 days and plotted it in three different timescales. The standard deviation plotter in light blue is calculated by standard deviation over 10 s of averaging of data. Green background means everything was locked at that time. Other than green would mean that either something was unlocked or there is a gap in the channel data (this case).


Conclusions:

  • Over 10 days, the beatnote hardly left +/- 2 kHz zone from the setpoint. Even with one standard deviation far away, the beatnote does note leave +/- 2.5 kHz zone. We are using Moku at 2.5 KHz bandwidth right now.
  • Over a day, here it was Sep 28th (Saturday), the beatnote is within +/- 2kHz even up to one standard deviation point. 
  • Over 1 hour which was between 1 am to 2 am on Sep 28th, the beatnote was similarly calm.
  • In the last plot, I have plotted drift over 60s in beatnote frequency which is our measurement duration. This drift doesn't even cross 1.5 kHz mark.

But

How good is good? We were so bad, I never did this calculation. Are we hitting boundaries of how good the thermal controls can anyway do? Is the remaining noise in beatnote spectrums just scatter noise or there is still room for improvement in beatnote stabilization. Food for thought.


Code and Data

Attachment 1: BeatnoteLongTimeSeries.pdf
BeatnoteLongTimeSeries.pdf BeatnoteLongTimeSeries.pdf BeatnoteLongTimeSeries.pdf BeatnoteLongTimeSeries.pdf
  2448   Tue Oct 8 16:48:07 2019 putInYourRealNameDailyProgressBEATBeatnote Frequency long time series data

comment on goodness of Temperature controls:

Since the frequency is wandering by ~3 kHz at the hours time scales, we can estimate the differential cavity temperature to be:

delta T = (1/CTE) * df / (c / lambda) = (1 / 5e-7) * (3 kHz / 300 THz) = 20 micro-K

If someone can plot the NPRO SLOW signals at the similar time scales, we would know what the CMRR is. But I think 20 uK is probably just fine. 

  2449   Wed Oct 9 16:08:39 2019 anchalDailyProgressBEATBeatnote Frequency long time series data

Whoever commented last, suggested a good idea. So I've here plotted the NPRO slow control voltage signals, converted into the inferred temperature of the cavities (see CTN:2415). I'm not so sure which CMRR the anonymous commentator is talking about. More clarification on that would be helpful.


Conclusions:

  • As the anonymous commentator said, the ideal temperature difference between the cavities would be around 20 uK, but that is clearly not the case as North Cavity varies more than 0.1 K while the South Cavity is relatively more stable.
  • This could also indicate that some external low-frequency noise source drifts the North Lasers frequency by corrupting the FSS.
  • The thermal dynamics of the two cavities should be similar unless same driven current causes starkly different emission of heat from the coil heaters (which are supposedly of same length).
  • Some more help in understanding these results are required, or atleast a person who can bounce back ideas with me.
  • So the can upgrade might be useful afterall. If anything, it will reduce the mysteries related to the cavities locked inside there for the last 5 years.

Code and Data

Attachment 1: BeatnoteLongTimeSeriesPart2.pdf
BeatnoteLongTimeSeriesPart2.pdf BeatnoteLongTimeSeriesPart2.pdf BeatnoteLongTimeSeriesPart2.pdf BeatnoteLongTimeSeriesPart2.pdf BeatnoteLongTimeSeriesPart2.pdf BeatnoteLongTimeSeriesPart2.pdf BeatnoteLongTimeSeriesPart2.pdf BeatnoteLongTimeSeriesPart2.pdf
  2460   Wed Oct 16 19:11:11 2019 anchalNotesBEATQuick note: Cavities locked; Changed BN Freq Counter Poll Rate
  • Follow discussion in thread  CTN:2451.
  • Changed polling rate of beatnote frequency counter to 1 Hz and the script is updating the EPICS channel at the same rate now.
  • Changed BNFreqSignUpdate and BNFreqSlopeCalc scripts accordingly.
  2461   Fri Oct 18 17:47:49 2019 anchalNotesBEATQuick note: BN Noise bakc to where it was.

Latest BN Spectrum: CTN_Latest_BN_Spec.pdf

Daily BN Spectrum: CTN_Daily_BN_Spec.pdf


  • Changed bandwidth of Moku PLL 10 10 kHz until beatnote frequency control settles back normally.
  • We are back to same position in noise but there are some extra sharp peaks which need to be looked at. But they are very small.
  2473   Mon Nov 4 20:13:44 2019 anchalNotesBEATQuick note: FSS Loop Gain Changes

South Common Gain: 24 dB! , Fast Gain: 14 dB

North Common Gain: 10 dB, Fast Gain: 10 dB

  2516   Wed Jan 22 15:20:00 2020 anchalNotesBEATNotch improved on FSS RFPDs. Gain values increased as well.

New Gain Values:

South Common Gain: 24 dB , Fast Gain: 18 dB

North Common Gain: 14 dB, Fast Gain: 14 dB

I incrased the above values as much as I could without getting oscillations in the loop.


RFPD Changes:

  • The North FSS RFPD SN009 (CTN:2512) and South FSS RFPD SN010 (CTN:2514) have been improved in terms of ratio of their peak transimpedance to their notch transimpedance by implementing an active notch in the output RF amplifier.
  • This was supposed to reduce non-linear effects (if any) because less of the 2-Omega frequency would go through the amplifier.
  • It seems like it didn't help at all as the beatnote noise spectrum is at the same place as before.
  • While the gain values of FSS have increased, the transimpedances of the RPFDs decreased after the changes,

Latest BN Spectrum: CTN_Latest_BN_Spec.pdf

Daily BN Spectrum: CTN_Daily_BN_Spec.pdf


Parallel relevant threads:

CTN:2514 : FSS Diagnostics - SN010 (South RFPD) Notch Improved

CTN:2517: TTFSS OLTFs with Maximum Gain

  2521   Wed Jan 29 14:49:48 2020 anchalDailyProgressBEATBeanote Spectrum vs FSS Gain Values

In a discussion with Craig sometime back, it was brought up what happens when I lower the gains of the FSS loops. So today I did a test which lowers the Common and Fast Gain values on the FSS boxes by 3 dB in each step and sees what happens to the beatnote.


Measurement

  • The measurement was done solely by bnvsFSSgains.py script present in the Data folder.
  • Before each measurement, the gain values are stepped and the script waits for 5 s before measurement is attempted.
  • Measurement is done through the usual mokuPhaseMeterTimeSeries.py script which is used for all beatnote measurements of the lab. Recently I was able to make it more robust with some discussion with liquid instruments application engineer.
  • All default settings were used except for duration which was kept to 10s to keep reasonable time series data file size.
  • SN101 detector's RF out coupled through a 10 dB directional coupler was used to make the measurement (as usual).
  • I ensured by watching the error signal on an oscilloscope that none of the FSS loops went into oscillation during the measurement. Its is hard to say for lower gain settings though if that happened or not.

Inference

  • The beatnote spectrum noise does not start going up until after the gains have been reduced significantly by around 12 dB at each stage.
  • Also, weirdly the beatnote spectrum was actually lower for 2 particular settings of gain which were midway. There the beatnote spectrum is only 2 times as much as estimated!
  • I'll repeat this measurement again to make sure this optimal gain setting region was not a coincidence due to some other parameter out of my control.
  • But since we do not see a clear scaling of beatnote noise with lowering of FSS gains, I think it is safe to infer that we are actually not limited by residual NPRO noise as has been the thesis for quite some time.

Data

Attachment 1: Beatnote_vs_FSSGain.pdf
Beatnote_vs_FSSGain.pdf
  2522   Wed Jan 29 15:58:26 2020 anchalDailyProgressBEATBeanote Spectrum vs FSS Gain Values
Quote:
I'll repeat this measurement again to make sure this optimal gain setting region was not a coincidence due to some other parameter out of my control.

Measurement

  • Everything is almost the same as the last measurement.
  • This time, if you notice from orange to yellow curve, I had to manually lower down the gain on the south common path by 12 dB instead of 3 dB to ensure the south path doesn't go into oscillations.
  • From there onwards, the gains were reduced normally by 3 dB in each step/

Inference

  • The beatnote spectrum indeed drops down to lowest when the gains are 3 dB below the maximum gains where I keep the loops.
  • Maybe keeping a large gain margin is important. But I need help to understand this result.
  • Also, it is kind of clear that the laser noise starts showing up from the yellow curve onwards only. So in current gain settings, the noise floor is probably due to something else.
  • Another weird fact I saw was that the RMS of error signal taken at "Mixer" port which is the TP5 point in LIGO-D040105-C_CTN_North increases significantly only after the gain values of the loop is decreased by more than 15 dB (to -1 dB each on FAST and COM).
  • The same thing can't be said for the south path where I see a gradual increase in this error signal RMS value as the gains are reduced.
  • If someone has a better idea of understanding these results or has some suggestions on further tests or a combination of parameter changes I should do, please let me know.

Data

Attachment 1: Beatnote_vs_FSSGain.pdf
Beatnote_vs_FSSGain.pdf
  2523   Thu Jan 30 10:55:22 2020 anchalNotesBEATLowest ever beatnote spectrum today.

Today we have measured the lowest beatnote spectrum till now. This happened because I set the FSS gain values to lower than the maximum I could reach.

FSS North South
Common Gain (dB) 11 21
Fast Gain (dB) 11 15

Latest BN Spectrum: CTN_Latest_BN_Spec.pdf

Daily BN Spectrum: CTN_Daily_BN_Spec.pdf


Relevant Elog Post:

CTN:2522: Beanote Spectrum vs FSS Gain Values

CTN:2518: NFSS Boost Stage

CTN:2514: SN010 (South RFPD) Notch Improved

CTN:2512: SN009 (North RFPD) Notch Improved!

Attachment 1: CTN_Daily_BN_Spec.pdf
CTN_Daily_BN_Spec.pdf
  2524   Fri Feb 7 09:57:32 2020 anchalDailyProgressBEATSpanned gain parameter space in NFSS and checked beatnote

Yesterday I took beatnote measurements and spanned gain values (COM and FAST) to see the variation in beatnote with them.


Method

  • I used BNspec.py with default settings (10 kHz bandwidth at 15.625 kSa/s for 60s) while spanning the parameter space of NFSS gains.
  • Every time the gain values are changed, a gainCycle.py is done and script waited for 10s before attempting beatnote measurement to let loops settle down.
  • The beatnote frequency was robustly within 2 kHz of 27.34 MHz during this whole measurement.
  • Overall experiment was run by spanParamSpace.py script.

Inference

  • I calculated the integrated total beatnote frequency noise in the frequency range 200 Hz to 1 kHz where the total noise is expected to be dominated by coating Brownian noise.
  • Interestingly, the beatnote noise in this range is not so much dependent on the NFSS loop gain values.
  • I notice a largely flat heatmap with no significant local minima.
  • This indicates that beatnote is indeed not limited by North NPRO residual frequency noise in this region at least.
  • I'm repeating this measurement today while scanning SFSS loop gains.

Data

Attachment 1: NFSS_Spanned_Beatnote_Variation.pdf
NFSS_Spanned_Beatnote_Variation.pdf
  2525   Fri Feb 7 18:12:03 2020 anchalDailyProgressBEATSpanned gain parameter space in SFSS and checked beatnote

I took beatnote measurements and spanned gain values (COM and FAST) on South side to see the variation in beatnote with them.


Method

  • I used BNspec.py with default settings (10 kHz bandwidth at 15.625 kSa/s for 60s) while spanning the parameter space of NFSS gains.
  • Every time the gain values are changed, a gainCycle.py is done and script waited for 10s before attempting beatnote measurement to let loops settle down.
  • The beatnote frequency was robustly within 2 kHz of 27.34 MHz during this whole measurement.
  • Overall experiment was run by spanParamSpace.py script.

Inference

  • I calculated the integrated total beatnote frequency noise in the frequency range 200 Hz to 1 kHz where the total noise is expected to be dominated by coating Brownian noise.
  • Unstable regions in the parameter space are clearly visible.
  • But as to the stable region, once the loop gets onto that, the noise does not change much, similar to North side.
  • So here as well, it seems like the beatnote noise is largely independent of the gain settings.
  • I'm unsure if I should look at this and the last measured data sets differently. Maybe I'm missing something.

Data

 

Attachment 1: SFSS_Spanned_Beatnote_Variation.pdf
SFSS_Spanned_Beatnote_Variation.pdf
  2526   Mon Feb 10 11:07:33 2020 anchalDailyProgressBEATSpanned gain parameter space in PMCs and checked beatnote

I took beatnote measurements and spanned gain values in the PMC to see if stability issues in PMC loops can be affecting the FSS downstream.


Method

  • I used BNspec.py with default settings (10 kHz bandwidth at 15.625 kSa/s for 60s) while spanning the parameter space of PMC gains.
  • The beatnote frequency was robustly within 2 kHz of 27.34 MHz during this whole measurement.
  • Overall experiment was run by spanParamSpace.py script.

Inference

  • I calculated the integrated total beatnote frequency noise in the frequency range 200 Hz to 1 kHz where the total noise is expected to be dominated by coating Brownian noise.
  • Unstable regions in the parameter space are clearly visible.
  • Ideally, the noise in beatnote frequency should have very minimal coupling with the gain values in PMC loops.
  • This has been found true indeed for the south side but not so much on the North side.
  • Very clearly there is a corridor from -3 dB to 8 dB in NPMC gain where noise remains low. We generally use 7 dB value.
  • But this might just be too bad PMC loop causing light amplitude noise in the output.
  • There is a bulge at 400 Hz in the beatnote freqeuncy noise. I can also see a broadened oscillation in PMC error signals around that frequency on both sides.
  • I'm afraid that maybe the North PMC is causing big mode mismatch at 400 Hz causing the noise in the beatnote frequency. Or is that not possible?

Data

Attachment 1: PMC_Spanned_Beatnote_Variation.pdf
PMC_Spanned_Beatnote_Variation.pdf
  2530   Wed Feb 12 10:01:04 2020 anchalNotesBEATIncreased sampling rate to 125kSa/s; lowest noise in higher frequencies

I have increased the sampling rate of moku to 125 kSa/s (fastest allowed) for the frequency-time series acquisition. After reading matermost chat of Sean Leavey etc, I felt I might have downconverted aliased noise as earlier sampling rate was just 15.625 kSa/s. This didn't change the noise below 1 kHz but we see some improvement above 1 kHz so I'll keep this from now on. The measured time series files are not around 900 Mb, so I'm not saving them and only keeping the psd calculated using modifiedPSD.py script.


Latest BN Spectrum: CTN_Latest_BN_Spec.pdf

Daily BN Spectrum: CTN_Daily_BN_Spec.pdf


Relevant elog post:

CTN:2521 and replies: Beanote Spectrum vs FSS Gain Values 

CTN:2528: Cleaned up table; Installed hex beam dumps

  2531   Thu Feb 13 15:27:18 2020 anchalDailyProgressBEATFurther iterated back and forth to optimized FSS Gains.

I took beatnote measurements and spanned gain values in the PMC to see if stability issues in PMC loops can be affecting the FSS downstream.


Method

  • I used BNspec.py with default settings (10 kHz bandwidth at 15.625 kSa/s for 60s) while spanning the parameter space of PMC gains.
  • The beatnote frequency was robustly within 2 kHz of 27.34 MHz during this whole measurement.
  • The overall experiment was run by spanParamSpace.py script.
  • First I spanned North gains using the last optimum values found for South Side and tried to span the area towards which we found minima earlier.
  • Next, I used the new minima found for North side and spanned region in South side.
  • This time, I used sum of the ASD of beatnote frequency between 300 to 600 Hz to determine improvement in noise overall.
  • Still, I would say, the improvement is hardly more than 5% over large areas of parameter space, meaning mostly BN noise is independent of these gains.

Final result

  North South
COM Gain (dB) 12 22
FAST Gain (dB) 10 17

Data

 

Attachment 1: FSS_Gain_Span.pdf
FSS_Gain_Span.pdf FSS_Gain_Span.pdf
  2532   Thu Feb 13 16:35:32 2020 anchalDailyProgressBEATBN Detector was saturated. Reduced laser powers.

I found that the beatnote detector was actually saturating and the output was not a good pure sinewave. I've reduced the laser powers reaching the intensity to avoid that so that 20 dB coupled output of beatnote remains around 200 mVpkpk. Following is the summary of changed settings:

  North South
Before locking reflected power (mW) 4.97 5.92
After locking reflected power (mW) 1.32 0.96
After locking transmitted power (mW) 2.96 3.38
After locking total accountable power (mW) 4.28 4.34
Estimated power loss (mW) 0.69 1.58

However, the beatnote did not change because of these changes showing that moku is strictly sensitive to zero crossings of the acquired signal rather than its shape near the edges.

  2535   Fri Feb 14 10:59:13 2020 anchalDailyProgressBEATBeatnote noise lowered in low frequency region

With some of the changes done recently, the beatnote noise has lowered in the low-frequency region indicating reduction in scatter.


Latest BN Spectrum: CTN_Latest_BN_Spec.pdf

Daily BN Spectrum: CTN_Daily_BN_Spec.pdf


Relevant elog post:

CTN:2530 : Increased sampling rate to 125kSa/s; lowest noise in higher frequencies

CTN:2533 : blocked NF1811 with hex beam dump

CTN:2535 : BN Detector was saturated. Reduced laser powers.

CTN:2531 : Further iterated back and forth to optimized FSS Gains.

  2540   Mon Feb 17 16:08:23 2020 anchalDailyProgressBEATBeatnote noise lowered in low frequency region with ISS

After installing the preliminary ISS, which I'll change tomorrow as per Rana's suggestions, we see some reduction in the beatnote noise in the lower frequency region. I think I should also have an estimate curve for the coupling of laser intensity noise into the final result. I can maybe make some sort of transfer function measurement from actuation on intensity to the beatnote frequency itself using moku.


Latest BN Spectrum: CTN_Latest_BN_Spec.pdf

Daily BN Spectrum: CTN_Daily_BN_Spec.pdf


Relevant elog post:

CTN: 2538 : Installed ISS on both paths using SR560s

CTN:2539 : Rana's suggestion on ISS.

Attachment 1: CTN_Noise_Budget_Effect_ISS_ON.pdf
CTN_Noise_Budget_Effect_ISS_ON.pdf
  2543   Fri Feb 21 16:22:04 2020 anchalDailyProgressBEATBeatnote noise lowered in low frequency region with ISS

After installing the new ISS, the noise is even lower in lower frequencies. Still no change in the noisy peaks at 400 Hz and around 800 Hz. There is also no difference in noise floor above 200 Hz.

Latest BN Spectrum: CTN_Latest_BN_Spec.pdf

Daily BN Spectrum: CTN_Daily_BN_Spec.pdf


Relevant elog post:

CTN: 2542: Installed New ISS on both paths using SR560s

Attachment 1: CTN_Noise_Budget_Effect_ISS_ON_New.pdf
CTN_Noise_Budget_Effect_ISS_ON_New.pdf
  2548   Tue Mar 3 10:02:12 2020 anchalDailyProgressBEATLowest ever beatnote spectrum today!

Measurement at 3 am in the morning today has been the lowest ever recorded beatnote noise. The lasers have been locked for more than a week and the temperature of the cavities is also very. The ISS gains were increased yesterday to 5x1000 on each loop. I've also added RIN measurement and implied photothermal noise.


Latest BN Spectrum: CTN_Latest_BN_Spec.pdf

Daily BN Spectrum: CTN_Daily_BN_Spec.pdf


Attachment 1: CTN_Noise_Budget_March03-2020.pdf
CTN_Noise_Budget_March03-2020.pdf
  2556   Thu Mar 12 11:06:35 2020 anchalDailyProgressBEATLowest ever beatnote spectrum today!

Last night I switched off all the fans in the lab and we have reached the lowest ever recorded beatnote noise.


Latest BN Spectrum: CTN_Latest_BN_Spec.pdf

Daily BN Spectrum: CTN_Daily_BN_Spec.pdf


Relevant posts:

CTN: 2551 : Comparison between Out of loop vs In loop RIN

Attachment 1: CTN_Noise_Budget_March11-2020.pdf
CTN_Noise_Budget_March11-2020.pdf
  2562   Wed Mar 18 12:51:22 2020 anchalDailyProgressBEATSuper beatnote measurement analysis results

On March 13th around 7:30 pm, I started a super measurement of the beatnote spectrum for over 2 days. The script superBNSpec.py took a beatnote spectrum every 15 minutes for a total of 250 measurements. The experiment was stable throughout the weekend with no lock loss or drift of the beatnote frequency. All data with respective experimental configuration files are present in the Data folder. HEPA filters were on during this measurement.


Analysis and Inference:

  • I first plotted time series of how beatnote frequency ASD at 300 Hz varies over the 2 days.
  • Remember, this is a median measurement done using function modPSD which uses modWelch function we wrote a while back (See CTN:2399).
  • Then I plotted the same for a bunch of frequencies from 200 Hz to 1 kHz.
  • It is clear that the time of the day does not have any major or meaningful effect on the beatnote spectrum. It mostly remains the same.
  • Finally, I took the median of the 250 ASD measurements.
  • I also calculated lower and upper bounds using RMS of difference between 250 upper and lower bounds and the median calculated above.
  • All the noise peaks are intact indicating that all noise sources are stationary and REAL (in Will Farr's language).

Data

Attachment 1: CTN_Beatnote_SuperMeasurement_March13-16.pdf
CTN_Beatnote_SuperMeasurement_March13-16.pdf CTN_Beatnote_SuperMeasurement_March13-16.pdf CTN_Beatnote_SuperMeasurement_March13-16.pdf
  2566   Mon Apr 13 16:52:30 2020 anchalDailyProgressBEATBeatnote measurements back on track

Since this morning atleast, I'm not seeing the North Path unstability (see CTN:2565) and the beatnote is stable and calm at the setpoint. Maybe the experiment just needed some distance from me for few days.

So today, I took a general single shot measurement and even after HEPA filers being on at 'Low', the measurement is the lowest ever, especially in the low-frequency region. This might be due to reduced siesmic activity around the campus. I have now started another super beatnote measurement which would take measurement continuously every 10 min is the transmission power from the cavities look stable enough to the code.

there is a new broad bump though arounf 250-300 Hz which was not present before. But I can't really do noise hunting now, so will just take data until I can go to the experiment.


Latest BN Spectrum: CTN_Latest_BN_Spec.pdf

Daily BN Spectrum: CTN_Daily_BN_Spec.pdf


Relevant post:

CTN:2565: North path's buggy nature NOT solved

Attachment 1: CTN_Latest_BN_Spec.pdf
CTN_Latest_BN_Spec.pdf
  16   Thu Nov 19 16:06:30 2009 AlbertoComputingComputersElog debugging output - Down time programmed today to make changes

We want the elog process to run in verbose mode so that we can see what's going. The idea is to track the events that trigger the elog crashes.

Following an entry on the Elog Help Forum, I added this line to the elog starting script start-elog-nodus:

./elogd -p 8080 -c /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg -D -v > elogd.log 2>&1

which replaces the old one without the part with the -v argument.

The -v argument should make the verbose output to be written into a file called elogd.log in the same directory as the elog's on Nodus.

I haven't restarted the elog yet because someone might be using it. I'm planning to do it later on today.

So be aware that:

We'll be restarting the elog today at 6.00pm PT. During this time the elog might not be accessible for a few minutes.

  17   Thu Nov 19 18:50:33 2009 AlbertoComputingComputersElog debugging output - Down time programmed today to make changes

Quote:

We want the elog process to run in verbose mode so that we can see what's going. The idea is to track the events that trigger the elog crashes.

Following an entry on the Elog Help Forum, I added this line to the elog starting script start-elog-nodus:

./elogd -p 8080 -c /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg -D -v > elogd.log 2>&1

which replaces the old one without the part with the -v argument.

The -v argument should make the verbose output to be written into a file called elogd.log in the same directory as the elog's on Nodus.

I haven't restarted the elog yet because someone might be using it. I'm planning to do it later on today.

So be aware that:

We'll be restarting the elog today at 6.00pm PT. During this time the elog might not be accessible for a few minutes.

 I tried applying the changes but they didn't work. It seems that nodus doesn't like the command syntax.

I have to go through the problem...

The elog is up again.

 

  167   Wed Jun 16 10:26:01 2010 FrankMiscComputerslatest medm screens from Hanford

got the latest screens from Hanford in order to avoid such problems again in the future. Someone has to search and replace the channel names for the ones we wanna use. They are currently located in the home directory on fb1. will copy them to the sun workstation asap...

  188   Wed Jun 30 00:37:49 2010 ranaHowToComputersPMC servo debugging

Quote:

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

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

 How sad. Stop using the floppies and get one of the GPIB-Ethernet converters from Dmass. You can download the python scripts from the 40m wiki.

  189   Wed Jun 30 00:59:13 2010 FrankHowToComputersPMC servo debugging

Quote:

Quote:

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

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

 How sad. Stop using the floppies and get one of the GPIB-Ethernet converters from Dmass. You can download the python scripts from the 40m wiki.

 we already have one but i was waiting for one the wireless bridge devices someone wanted to buy to make it wireless.

But why do you need a floppy to measure a TF?

  201   Wed Jul 7 20:02:53 2010 taraDailyProgressComputersBeam output is more stable

 

1) I just found out that the pbs + 1/4 waveplate in front of RefCav is not well aligned, so the length,as seen by the beam, is not 1/4 wavelength.

    Hence, the polarization is not turned 90 degree after double passing, and

    The reflected beam can go back to the laser and causes the power fluctuation we saw before.

    When the beam is blocked anywhere before RefCav, the beam output from PMC is very stable.

    I adjusted the PBS's angle and reduced the reflected power. Now the input power to PMC can go up to 50 mW without any fluctuation. 

 

2) I re-aligned the beam into RefCav, with Frank's help on gain adjusting,

    the transmitted power seems to be more stable. RefCav transmitted power RIN is posted below. I'll post the comparison between result at 40m soon. From a quick glance, RIN from 40m is at least 2 order of magnitude below

our result.

 

3) The PID control for slow actuator is up. I was adjusting it, but the medm screen was frozen.

    I reset it, and set the PID control (only P-part). The current setting for Proportional control(C3:PSL-FSS_SLOWKP) is +0.41.

 

Attachment 1: PSL_RF_RIN.png
PSL_RF_RIN.png
  231   Sun Jul 18 18:32:08 2010 FrankDailyProgressComputersMaster MEDM screen for RefCav experiment

i prepared a master screen for the refcav experiment.
This main screen contains all important numbers to figure out what the status of the experiment is.
It also contains several stripcharts which monitor important values like temperatures of the cavities, transmitted power levels etc over time.
It also has several buttons which link to the individual sub-screens which already exist for our subsystems.

medmScreen.png

  232   Sun Jul 18 23:59:52 2010 JenneDailyProgressComputersMaster MEDM screen for RefCav experiment

While I guess it's a nice idea to put a Success = 100 meter on all of our MEDM screens for motivational purposes, what are the units on this one / the meaning of it?  Everything else makes sense (except maybe for the strength....are strength and success related?), but the success is confusing.

Quote:

i prepared a master screen for the refcav experiment.
This main screen contains all important numbers to figure out what the status of the experiment is.
It also contains several stripcharts which monitor important values like temperatures of the cavities, transmitted power levels etc over time.
It also has several buttons which link to the individual sub-screens which already exist for our subsystems.

 

  233   Mon Jul 19 03:39:51 2010 RanaDailyProgressComputersMaster MEDM screen for RefCav experiment

Leave Frank alone!  His strength is already down to 47 and his PMC has -2mW of anti-energy coming out of it.

  235   Wed Jul 21 10:39:10 2010 FrankDailyProgressComputersMaster MEDM screen for RefCav experiment

i don't know the units for the strength, but it's showing how good the reception of the signal is.I can't be dBm or something like that, so i don't know what units they use for that kind of quality signal.

The success rate is basically percent. Same situation here, there is no explanation for this signal, but it goes from 0 to 100 so it's percent.
If the value drops below 100 that basically means that the sensor is close to the range limit or the batteries are empty and so the communication is bad and we are loosing some data points...

the reason for some funny numbers like getting energy out of the PMC is that most of those channels are not connected or not calibrated yet. The PMC refl power is an open input

Quote:

While I guess it's a nice idea to put a Success = 100 meter on all of our MEDM screens for motivational purposes, what are the units on this one / the meaning of it?  Everything else makes sense (except maybe for the strength....are strength and success related?), but the success is confusing.

Quote:

i prepared a master screen for the refcav experiment.
This main screen contains all important numbers to figure out what the status of the experiment is.
It also contains several stripcharts which monitor important values like temperatures of the cavities, transmitted power levels etc over time.
It also has several buttons which link to the individual sub-screens which already exist for our subsystems.

 

 

  236   Mon Jul 26 20:43:30 2010 FrankSummaryComputersnew workstation

i got an old workstation and have converted it into a new linux workstation for the PSL lab.
It's like one of the usual workstation but with only a single screen due to space limitations.

Name: WS5
IP-address: 10.0.0.25

users are root and controls. passwords the usual ones...

  245   Thu Jul 29 02:55:15 2010 DmassSummaryComputersboth cavities individually locked

I noticed that root built the last ATF model and this screwed some things up. I am not sure if this was also done with the PSL model, and if it might somehow cause network problems.

  247   Fri Jul 30 13:17:05 2010 FrankSummaryComputersRT code built using wrong user
i deleted the PSL compiled stuff and rebuilt it with the controls user. Someone wants to do this for the ATF
model as well...

<p>
<table width="98%" cellspacing="1" align="center" style="border: 1px solid rgb(72, 96, 144);">
    <tbody>
        <tr>
            <td style="background-color: rgb(72, 96, 144); color: white;" cellpadding="3px">Quote:</td>
        </tr>
        <tr>
            <td style="background-color: rgb(255, 255, 176);" cellpadding="10px">
            <p>I noticed that root built the last ATF model and this screwed some things up. I am not sure if
this was also done with the PSL model, and if it might somehow cause network problems.</p>
            </td>
        </tr>
    </tbody>
</table>
</p>
<p>&nbsp;</p>
  257   Fri Aug 6 00:43:09 2010 FrankSummaryComputerswifi bridges configured

as Mott can't finish the installation of the wifi bridges for the gpib-to-ethernet adapters a configured 4 devices today.
Username and password are clearly labeled on each device, they are the usual ones for administrator rights.

The 4 new devices have the following IP adresses:

10.0.1.6
10.0.1.7
10.0.1.8
10.0.1.9

i will finish configuring the gpib-to-ethernet adapters on Friday, one for each instrument in the labs.

i will update the network diagram as soon i decided which ip addresses the will get

  260   Fri Aug 6 22:24:46 2010 FrankNotesComputersmissing file for medm screens

- personal notes -

medm error message: loadGIF: Cannot open file:  /cvs/cds/caltech/scripts/utilities/nova_logo.gif

  273   Thu Aug 12 00:15:59 2010 Frank, MeganSummaryComputersnetgpib scripts working

Megan tested the gpib scripts today and they are working except that the plotting of the data doesn't work as some packages are still missing.
Unfortunately i couldn't install them with yum so i will do it later.
Anyway, taking data without the plot function is working ...

  299   Thu Aug 19 19:19:26 2010 taraNotesComputersslow actuator note

ACAV 0.2602 V

RCAV 0.1102 V

  310   Fri Aug 27 18:39:23 2010 taraNotesComputersDAQ

Dmass helps me initializing two channels for DAQ.

PSL1 connected to channel 28 which is C2:ATF-ACCoup_AC2_OUT_DAQ

PSL2 to channel 29 which is                    C2:ATF-ACCoup_AC3_OUT_DAQ

ELOG V3.1.3-