40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  PSL, Page 51 of 52  Not logged in ELOG logo
ID Date Author Type Categorydown Subject
  2232   Wed Sep 12 16:27:19 2018 anchalDailyProgressBEATBack to beat

Attached are transfer function measurements of the North and South Cavity Reflection RFPD (14.75MHz resonant RFPD) along with dark noise around 14.75 MHz.

The transfer functions are measured by injecting into the test in port and reading out from RF port at -15dBm source power. The noise spectra are measured by shorting the test in port and taking spectrum from RF port when the detectors are on. In both measurements, the photodiode is blocked with a beam dump.
These measurements were required because of the conclusions made in PSL:2230. Indeed as suspected, the south path resonant RFPD measuring reflection of the cavity at 14.75 MHz has a ~100 times weaker response than the north counterpart as seen in the attached plots. Since the dark noise of south RFPD is about half of the noise of north RFPD (see plot 2), it suggests that south RFPD circuit itself is not working properly and is not amplifying the signal enough. Andrew mentioned that he and Craig saw this earlier and decided to shift FSS to higher frequencies with crystal oscillators. We have the OCOX preamp for 36 MHz and 37 Mhz ready to go with RFPDs at 35.5 MHz that can be tuned to these frequencies. So future steps are to replace the RFPDs with these 35.5MHz ones and tuning them to 36 MHz and 37 MHz and putting in broadband EOM driven by resonant EOM drivers at these frequencies. See future posts for updates on these steps.

Edit:[09/14/2018, 16:12] Changed plots to physical units. Used 2k Transimpedance for Bode Plot and 2.5kHz bandwidth (801 points in 2MHz) for noise plots.

Edit:[09/22/2018, 10:12] Added how measurements were taken, the reason for them and some conclusions. I'm getting into the third year now!

Attachment 1: NorthandSouth_14750kHz_RFPD_Measurements.pdf
NorthandSouth_14750kHz_RFPD_Measurements.pdf NorthandSouth_14750kHz_RFPD_Measurements.pdf
  2233   Fri Sep 14 00:57:14 2018 ranaDailyProgressBEATBack to beat

please replace TF and noise plots with ones that have physical units on the y-axis: V/A for the Bode plot and W/rtHz for the noise plot

  2237   Fri Sep 21 18:10:53 2018 ranaDailyProgressBEATBack to beat

I don't understand what that means. Please provide 10x more details on how the measurement was made.

Also, clearly one of these traces is not like the other. What does that mean ???

Quote:

Attached are transfer function measurements of the North and South Cavity Reflection RFPD (14.75MHz resonant RFPD) along with dark noise around 14.75 MHz.

Edit:[09/14/2018, 16:12] Changed plots to physical units. Used 2k Transimpedance for Bode Plot and 2.5kHz bandwidth (801 points in 2MHz) for noise plots.

 

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

  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.

  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
  945   Fri Apr 27 10:30:57 2012 FrankNotesAcousticsacoustic damping from plexiglas and sandwich structures

sandwich structures using plexiglas : "Damped Windows for Aircraft Interior Noise Control" http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.79.9176

bare plexiglas: http://www.eplastics.com/Plastic/Plastics_Library/Plexiglass-Noise-Reduction

 

  948   Tue May 1 03:12:58 2012 frank, taraDailyProgressAcousticsacoustic enclosure for input beam

We started making the acoustic enclosure around the input beam area (second half of the table, before the chamber). The frame is done. We haven't received all items for the panels yet, so we just tried to use the aluminum bubble wrap as test panels. And we just used a piece of plastic planes to cover the top. There is no improvement in acoustic coupling yet.

 

IMG_0849.jpg

  950   Tue May 1 23:58:21 2012 frank, taraDailyProgressAcousticsacoustic enclosure for input beam

We added the lid on top of the enclosure. More work is needed to complete the box.

    We made the closing lids by cutting a 1/8" acrylic panel. A strip of soft foam was added between the frame and the lids to form a seal.

    We did a qualitative test by placing a white noise source inside the box and listening. The aluminum bubble wrap we used did not provide good noise reduction. So we replaced one side by a plastic piece (~1/8" thick) with a damping pad on. It could damp the noise pretty well. I'll borrow a blue bird microphone from Den tomorrow, so we can measure the TF or just the relative noise signal to check how much attenuation we get from our structure.

 

IMG_0851.jpg

  951   Wed May 2 19:48:32 2012 frank, taraDailyProgressAcousticsacoustic enclosure for input beam

      We measured the frequency response(microphone out/signal to speaker) to see how well we can shield the outside acoustic.  The test panel did help reducing the acoustic coupling, but there is still room for improvement.

     Den lend me a blue bird microphone from 40m.  So we setup a measurement to compare two panels we have. The first one was what we made yesterday (plastic with damping pad), the second one was the aluminum panel(1/8" thick) with soft foam on the inside and foam strip on the edge where the panel met the frame.

     ==setup==

     We measured the frequency response between the microphone signal and the speaker driving signal. The source was white noise (band limit) 100Hz - 6.5kHz, 1.4V. The output has a T so that one was sent to the speaker, another one was for chA.  The SR785 chB input for microphone signal was floated  since the mic gave differential output. This should prevent the pre-amp output to see "ground" at the output and break the opamp.The measurement was average over 5000 samples.

      We measured with the speaker on and off (but the white noise ref to chA was still connected) to check we have a good SNR for every setup. Three setups were:

  • 1) wihout panel (see fig1),
  • 2) with plastic panel + damping pad (see fig2,left),
  • 3) with aluminum panel + soft foam (fig3, right).

.IMG_0853.jpg

fig1: setup, with the panel remove.

IMG_0854.JPG

fig2: two panels for testing. Left, a plastic piece with damping pad attached on (from yesterday). Right, an aluminum panel with soft foam

IMG_0852.jpg

fig3: panel under test.

 

result.png

fig4: result.

  ==conclusion + plan==

    From the plot, it is not very clear if the aluminum panel (panel2) is better than the plastic one (panel1). It might be that noise coming from other panels(which we have not changed) is the dominating signal. We will put the mic in a smaller container surrounded by acoustic damping with an opening for the material/structure to be tested. Then we can test a sample easily without removing/installing the panel all the time.

     For now, we are planing to use another kind of foam to put inside the box. We check by ears and found that it is better than the current foam we use with the aluminum panel.

  952   Thu May 3 22:26:14 2012 frank, taraDailyProgressAcousticsacoustic enclosure for input beam

We are still working on the acoustic shielding panels. The work should be done by tomorrow.

IMG_0855.JPGIMG_0856.jpg

Fig1: Left, one panel with damping foam + black pad on top( to prevent scattered light). Right,a panel with two layers of good damping material with a damping pad under it. This type can damp acoustic noise pretty well.

We prepared all sides of the acoustic box. However, we don't have enough damping materials, so all the panels are not similar, but they all have some soft foam to provide acoustic damping. All the holes for cables/ beam are marked and will be drilled tomorrow. 

  953   Fri May 4 20:19:58 2012 frank, taraDailyProgressAcousticsacoustic enclosure for input beam

The enclosure box for input optics are done. We still need to order more of the nuts for one panel, but the box should provide certain acoustic shielding for now.

We will measure the beat signal once the temperature stable.

IMG_0863.JPG

IMG_0864.jpg

    The box has four 1-inch diameter holes, 2 for periscope, one for input beam, another one is for the beam to RCAV curve mirror which we cannot fit in the box.

    We had to rearrange the cable for ACAV AOM to have fewer cables going in and out the box. The cable for driving the AOM was remade so that it did not block the panel.

  955   Wed May 9 03:11:33 2012 frank, taraDailyProgressAcousticsacoustic enclosure for input beam

I check the performance of the enclosure box for input optics. It neither improves the beat signal that much.

   ==Is the acoustic box good?  No==

   To check how good the acoustic shield can be, I measured the beat signal and feedback signal to ACAV AOM when the lid were on and off. There were no much improvement in both signals, see fig1 below.

IO_lid_compare.png

fig1, beat signal and ACAV feedback, converted to frequency noise. Beat signals between the lid close and open (red, purple) are very similar. Feedback signal to AOM are also the same (blue, cyan). I plot the 4 traces together to see if there are any coincided peak, so I can know where it happens (beat path or input optics). Note the peak at 280 Hz in Cyan trace is not real, it pops up after ~50Avg. I could not find its origin yet.

    ==Is it really acoustic coupling?  Yeah, kind of==

    The results were so similar between the lid open and close, so I wondered if those were really acoustic. To test this, I turned off the two computer (PC and fb2) and remeasured the beat. Those computers' fans are quite loud when they are on. For fb2, the fans still work even when it is shut down, but definitely much quieter. The beat signal was improved a bit, see figure 2. The results were real, I repeated them twice. Note that the room are still not totally quiet with the two computers off, sounds from sun machine and electronic rack are still there, and they are as loud as the two computer and closer to the beat setup as well. 

computer_compare.png

fig2: beat signals when the computer are on (blue) and off (red), several peaks are obviously reduced when the computers are off.

  ==discussion and plan==

    Since the computer are sitting on the floor, it is not certain if the peaks due to the computers are from acoustic transferred through air or vibration transferred through the ground. But the peaks in question are at high frequency (almost 1kHz), and we have 3 stage seismic isolation on (except floating table). It is very likely that these peaks are caused by acoustic. To make sure that they are really acoustic, I'll float the table and repeat the measurement again.

  972   Wed May 30 23:39:15 2012 frank, taraDailyProgressAcousticsacoustic enclosure for input beam

We started installing the new acoustic enclosure box for the beat path. It covers the whole beat setup and the part for power detection. The walls are installed. The lid will be made later.

 

IMG_1300.jpg

ELOG V3.1.3-