Today we go the beat to converge on the 26 MHz resonance of the resonant transmission beat detector. Anchal and I took a TF of the PLL and found the UGF to be 40 kHz, sufficient for a BN spectrum. Beat not power was about -1 dBm.
Sorry no beat spectrum, we lost lock with the south path autolocker turned off and the cavity heat PID didn't realize and knocked the BN way off. Going to take another 12 hours for it to settle down again.
It looks like the spectrum was about 0.1 Hz at its lowest point (>3 kHz). We saw that there was a very prominent narrow peak at about 2.8 kHz. We had a look at the mixer monitor signals and saw that the narrow peak was coming from the south path FSS. After doing a cross spectrum between the beat and the north and south FSS it became apparent that a significant portion of our noise is coming from the south FSS somehow. We need to track down exactly what would be coupling in a 2.8 kHz narrow peak and also the broader noise of the south FSS.
I suspect it might be a photodetector issue. We had excess noise is one path relative to the other before and swapped detectors and field boxes. We never quite diagnosed it but it could well be that the 14.75 MHz tuned detector that is now in the south path is responsible. The first thing to check is the TF by injecting into the test port. Also the dark noise should be checked around 14.75 MHz. The optical TF can also be taken with the Jenny rig at the 40m. Now might be a good time to switch modulation frequencies to 36 MHz and 37 MHz. These are fine for HOM spacing and we have the Wenzel crystals ready to go. We also have two detectors tuned to 35.5 MHz sitting on the shelf and BB EOM drivers that just need stuffing onto boards. This might take Anchal a week to do, he seems to be good with electronics.
Another unresolved problem is the residual AM from the 14.75 MHz phase modulators. I was never really able to reduce this down and keep it down. Thermal or alignment drift seemed to make it really hard to minimize. It could be bad alignment though the crystal or thermal drift. They have insulating hats on but they still are less than optimal. An ISS will do a bit to suppress noise opened up by this effect but we would like to solve it properly.
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!
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
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 ???
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.
Since it doesn't hurt:
Code and Data
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.
I did two identical runs (I wasn't sure if I was seeing the truth from my first run) with the following settings:
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.
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.
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.
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.
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.
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.
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.
For record, I took data of beatnote timeserieswith fasted sampling rate on Tektronix TDS 3034C (CTN_OSC_SN01).
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 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.
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! 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.
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
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.
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).
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.
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.
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.
Latest BN Spectrum: CTN_Latest_BN_Spec.pdf
Daily BN Spectrum: CTN_Daily_BN_Spec.pdf
South Common Gain: 24 dB! , Fast Gain: 14 dB
North Common Gain: 10 dB, Fast Gain: 10 dB
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.
Parallel relevant threads:
CTN:2514 : FSS Diagnostics - SN010 (South RFPD) Notch Improved
CTN:2517: TTFSS OLTFs with Maximum Gain
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.
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.
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!
Yesterday I took beatnote measurements and spanned gain values (COM and FAST) to see the variation in beatnote with them.
I took beatnote measurements and spanned gain values (COM and FAST) on South side to see the variation in beatnote with them.
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.
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.
Relevant elog post:
CTN:2521 and replies: Beanote Spectrum vs FSS Gain Values
CTN:2528: Cleaned up table; Installed hex beam dumps
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:
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.
With some of the changes done recently, the beatnote noise has lowered in the low-frequency region indicating reduction in scatter.
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.
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.
CTN: 2538 : Installed ISS on both paths using SR560s
CTN:2539 : Rana's suggestion on 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.
CTN: 2542: Installed New ISS on both paths using SR560s
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.
Last night I switched off all the fans in the lab and we have reached the lowest ever recorded beatnote noise.
CTN: 2551 : Comparison between Out of loop vs In loop RIN
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.
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.
CTN:2565: North path's buggy nature NOT solved
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
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.
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.
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.
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:
fig1: setup, with the panel remove.
fig2: two panels for testing. Left, a plastic piece with damping pad attached on (from yesterday). Right, an aluminum panel with soft foam
fig3: panel under test.
==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.
We are still working on the acoustic shielding panels. The work should be done by tomorrow.
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.
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.
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.
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.
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.
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.