I'm not sure how but the alignment into south cavity became terrible over time. Maybe I accidentally changes persicope alignment but I am pretty sure I didn't go near this area since I last aligned it (PSL:2316).
Today, I was able to get mode matching of 55% only.
I have finally completed the documentation for mathematical analysis of using PLL for frequency noise measurement. This document also contains noise analysis for various sources.
Please read and let me know if you have any comments.
Either by the mighty presence of Craig who came down to lab for few minutes or because of my recent updates in path alignment (see PSL:2335, PSL:2334 ), the PDH error signal in the south path looks almost as healthy as it ever was.
Attached is the data taken from oscilloscope with while scanning laser pzt at 3 Hz with 2 V peak-to-peak sinewave.
I measured modulation depth to be 0.373 by scanning the slow control voltage and reading powers in carrier and sidebands. Then I used the ratios of Bessel functions to estimate the modulation depth, which seems higher than expected.
The differences in the expected and the measured values good be due to many reasons like wrong modulation depth measurement, wrong responsivity (I used 0.75), wrong mixer loss and voltage divide estimation based on MAX333A datasheet values etc. So overall, this looks good enough that I can just move on. I am not sure how this actually happened.
Edit Mon May 13 16:40:21 2019 :
Corrected the transimpedance value of SN010 used. I was referring to a wrong value before. The have made the calculation by backtracing from the data in taken in CTN:2247, dividing by MAX4107 old gain (560/(0.5*113) +1), multiplying by the new gain (680/75 +1), dividing by old voltage division of (50/70) and multiplying by new voltage division of (50/100). The details are in this notebook.
Log of changes made to SN010, Schematic D980454-00;
1) Changed R1 to 680 Ohm and R2 to 75 Ohm. Replaced Max4107 with a new one.
2) Changed R6 to 50 Ohm. This changes the voltage division at output.
Log of changes made to SN009, Schematic D980454-00;
1) Changed R6 to 50 Ohm. This changes the voltage division at output.
Edit Wed May 15 19:47:42 2019:
See https://nodus.ligo.caltech.edu:30889/ATFWiki/doku.php?id=main:experiments:psl:rfpd for latest changes in RFPD.
I have made a SMA cable of length 1.952m after optimizing phase delay of LO. This is giving the maximum PDH error signal.
For future reference, I'm saving present setup details:
From the ratio of off-resonance value and error signal pk-pk at OUT1, we can check in future if everything is same as right now. From ratio of off-resonance value and dip value, we can check cavity mode matching in future.
I today shifted our modbus (db files for EPICS channels, ioc command files and docker-compose file to run the services) over to this git repo.
Through this, we would have version control now so that we can revert back to a working stage if something causes an error in the hosting of the channels. All db files are updated every 5 minutes by dbFilesUpdate.py in ctn_scripts. So we should try to commit the changes manually once in a while to the repo. This is there so that locally the files track changes in the settings and parameter values but we also have version controlled history in git for long reverts.
On another note, it is important to start the docker processes in a particular order. To ease with this, I have added a restartAll command in the .bashrc of ioc3server which looks like this:
#Restarts all teh EPICS channels and python scripts in the correct manner.
sudo docker-compose start dbFilesUpdateOneTime
echo 'Updating db files before restarting...'
while true; do
if [ -z `sudo docker ps -q --no-trunc | sudo grep $(sudo docker-compose ps -q dbFilesUpdateOneTime)` ]; then
echo 'dB files updated. Shutting down python scripts...'
sudo docker-compose down
echo 'Now restarting the EPICS channels...'
sudo docker-compose down
sudo docker-compose up -d
echo 'Checking if the python scripts are down...'
sudo docker-compose down --remove-orphans
echo 'Starting python scripts...'
sudo docker-compose up -d
So every time a new channel is added. After doing git pull, one should use this command or the commands listed above in order to make sure the channels and python scripts boot up in the right fashion.
Edit Mon May 13 12:17:23 2019: Updated restartAll() function to do a last time db files update before restarting.
We have changed the logbook name from PSL_Lab to CTN. To keep all the links working, I ran the attached script in a local copy of the log files and then copies them back to the server. The script essentially just changes PSL_Lab from all hyperlinks to CTN. Now, all such links are working. However, the front text of the links was not changed to avoid unnecessary tweaking. So in most of them, the front test still says PSL:XXXX but the links are correct.
I tuned the intensity control and changed autolock parameters to get 2.6 mW light at the output of cavities on both paths. At present, the South Path has 74 % mode matching and North Path has 63% mode matching. These numbers were higher yesterday, so I'm suspecting something shifted over a day.
I also maximized gains on PMC loops and FSS loops:
In FSS loop, I kept gain margin of 0.64 dB (i.e. the oscillations are seen at 0.2V above the set value of Common Gain) and in PMC loop, I kept it at 2 dB. I yet have to characterize noise in the FSS error signal and see what I can make better. On another note, I did a rough calculation today and I think shotnoise intercept current for our RFPDs is ~2.6 mA which means atleast 3.45 mW light should be falling on them for them to be shotnoise limited. I have to check the validity of my rough estimation but if this is true, then our FSS RFPDs are not shot noise limited.
I was finding myself changing thresholds every time I change power levels. Also, the fastmon rms monitors were not working with the docker-compose. I'm listing all script and medm changes since the sad departure of awade:
I'm attaching screenshots of modified medm screens.
For gaining about 3.45 mW of light after reflection from cavity on resonance when mode matching is about 60%, 8.63 mW light needs to fall at the cavity. There were three major obstacles in doing this which were resolved as follow:
Also, I have finally started an ATF wiki page to keep documentation of all RFPDs and changes to it. I'll make sure this page is updated and this page should be the reference point in future.
On another note, I'm seeing a steady decline of mode matching on both paths even when I'm staying far away from the alignment. Something is going on which needs to be fixed. After a discussion with awade, following are the suspects:
I'll fix the mode matching again before leaving today and will see if any big changes happen overnight.
As suspected in CTN: 2346, the mode matching of the cavities is deteriorating and eventually alignment is getting screwed due to possible lab temperature fluctuations. I left yesterday with south cavity mode matching to about ~70% but in the morning today, I found that the resonance is completely lost and a higher order mode with vertical fringes is resonant. Same is the case with North one which had shifted to a much higher order with vertical fringes. So clearly, I need to switch back on the vacuum can temperature stabalization.
Similar to South Path, I have inserted a beam splitter in the north PMC reflection path. This is a BS1-1064-90-1037-45UNP beamsplitter set such that about 10% light is transmitting. See optical layout for the path changes. I found that the modulation depth fro North PMC PDH was already low enough (0.246), so I did not reduce it. I have changed the DC transimpedance of North Cavity Reflection RFPD SN009 similar to the south side to 929.09 Ohms. This has given us ee-way to increase light intensity in the path with autolockers still working.
I installed the new board LIGO-D1800304 with an external voltage regulator and breakout box for handling acromag channels. See attached photos. The transimpedance amplifiers required a parallel capacitor in the feedback path for avoiding oscillations. Since these are temperature sensors and we do not care much about high-frequency noise, I added 1 nF capacitors at the COMIT3,9 and 11 positions. This should give us a bandwidth of 10 kHz. The channels are as follow:
With the new sensors, I have set relay autotune test to happen overnight with relay amplitude of 0.75V and 0.75 offset for 16 hrs. This should tell us optimal PID parameters. Hopefully, these measures will make the can temperature stable enough which I'll try to set around 33 degrees (my guess setpoint to keep good enough cooling rate). Then with Andrew's new script, the cavity temperature control was pretty good and hopefully we'll lower the overall drift of beatnote.
After the vacuum can is heated, I aligned the north cavity again today to about 60% mode matching. however, I'm seeing a weird oscillation in the mixer channel of FSS board which is very big (5 Vpp) and is happening alongside a large power fluctuation in transmitted light. See attached plot from oscilloscope of reflected DC level and the micer channel from FSS. The repition rate of the oscillations make this a 7.35 kHz noise. I have never seen this before. Further, these oscillations are completely unaffected from chaning COM gain or the Fast gain in the FSS path. Comments required.
Code and Data
Today I took a beat note noise measurement to see where we are. Attached is the updated noise budget.
Edit Thu Jun 6 14:17:34 2019 Anchal : Above in red.
Edit Tue Aug 13 17:08:46 2019 anchal:
The PLL Readout noise added on this plot was erroneous and I can't find where it came from either. So the noisebudget attached is wrong! I was a dumbo then.
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:
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.
Last week, the default GNOME Classic desktop environment of WS1 started giving hiccups. I was unable to see any medm screens. I restarted the computer assuming that will solve it but then I was unable to login from the graphical user interface. That was weird as I was able to ssh into the computer and do whatever I want. So it seemed that some graphics engine was unable to run. On login screen, after typing in the correct password, a black screen would appear and it would go back to the login screen. This is mentioned in various forums on the internet as "login loop". Taking advice and directions from Jamie, I tried to troubleshoot this to the best of my ability but we both were unsure in the end what was the problem. Our best guess is that installation of LSCsof package upgraded some graphics library beyond the capability of the present system. I tried all different desktop environments and I was able to login only through GNOME on Wayland (supposedly bleeding edge for debian 8). Another mystery is that I found medm uninstalled from the computer. I installed it back with:
sudo apt-get install medm
And I found that GNOME on Wayland is still usable option. After some more discussion with Jamie, I decided to upgrade the OS to next stable version debian 9. I followed the instructions on:
to dot and have successfully upgraded to debian 9. However, still only "GNOME on Wayland" is the only desktop environment through which we can login without facing a login loop
On another note, I found today that clicking the scroll button over a medm channel screen (which ideally displays the channel name) freezes the computer. The mouse pointer disappears and the computer does not respond to anything. Again, I can ssh into the computer and do anything. This problem goes away on restart.
So bottom line is, the overall system environment of ws1 is becoming messy and old and ideally we should do a clean install of a new os (something like Jon did in QIL). But I was heavily discouraged for doing so as it seemed it will take a lot of time to setup a new workstation.
Due to recent cleanup and upgrades in our computer environment in lab, this workstation ws1 is a mere looking window in the experiment. There are no active scripts that it runs (except a precavity beatnote reading) and the experiment can be carried out without it present as well. However, it is nice to keep a computer loaded with EPICS, nds2, python environments and a screen to carry out day-t-day functioning of the lab.
I found today that all this while, the channel values shown on our FSS_Interface medm screen and used by rmsMonitor.py for gain cycling were somewhat arbitrary numbers. It took me a while to figure out that the channel voltage is 10 times what reaches the AD602 on TTFSS board. Maybe awade knew about this but there was no documentation on this. Anyways it seemed bogus to increase the gain of FSS loops in arbitrary units. I added four more channels with _DB suffix which carry the physical units (in dB) of the Common and Fast gains in FSS loops. The older gain channels are calc channels now which calculate the channel voltage required from dB value. Everything has been tested to work correctly with the changes. My next steps are to step by step check all transfer functions in the FSS loop and find the culprit.
I just took Scott's notebook and added code to integrate the input-referred temperature noise power spectral densities over different bandwidths of frequencies to see what noise we should expect with 16 Hz sampling and what does the measured data suggests. The expected total noise sum is below 1mK for bandwidth up to 10 Hz and the measured total noise is below 0.3 mK up to 10Hz bandwidth. In my opinion, this circuit has passed the test if our experiment and the analysis is correct subject to Rana's opinion.
Measurement setup and analysis:
Calling out for help
Edit Fri Aug 9 09:50:24 2019 anchal:
The last measurement was taken in the wrong way and hence it was mismatched. The ground pin was connected to the wrong position. I retook data today and seems like EOM path and is all healthy :). But the other mismatches still need to be investigated. The Code and Data are updated through git.
Edit Thu Jan 23 19:33:55 2020 anchal:
The mismatched were there because the stage saturates when boost is on. Need to take that measurement with appropriate offset applied through AO Offset. This is done in this CTN:2518.
Following points are in relation to previously used noisebudget.ipynb file.
Following points are in relation to the new code at https://git.ligo.org/cit-ctnlab/ctn_noisebudget/tree/master/noisebudget/ObjectOriented.
The new noise budget code is ready. However, there are few discrepancies which still need to be sorted.
The code could be found at https://git.ligo.org/cit-ctnlab/ctn_noisebudget/tree/master/noisebudget/ObjectOriented
Please look into How_to_use_noiseBudget_module.ipynb for a detailed description of all calculations and code structure and how to use this code.
In the previous code, while doing calculations for Thermoelastic contribution to Photothermal noise, the code used a weighted average of coefficients of thermal expansion (CTE) of each layer weighted by their thickness. However, in the same code, while doing calculations for thermoelastic contribution to coating thermo-optic noise, the effective CTE of the coating is calculated using Evans et al. Eq. (A1) and Eq. (A2). These two values actually differ by about a factor of 4.
Currently, I have used the same effective CTE for coating (the one from Evans et al) and hence in new code, prediction of photothermal noise is higher. Every other parameter in the calculations matches between old and new code. But there is a problem with this too. The coating thermoelastic and coating thermorefractive contributions to photothermal noise are no more canceling each other out as was happening before.
So either there is an explanation to previous codes choice of using different effective CTE for coating, or something else is wrong in my code. I need more time to look into this. Suggestions are welcome.
The effective coating CTR in the previous code was 7.9e-5 1/K and in the new code, it is 8.2e-5 1/K. Since this value is calculated after a lot of steps, it might be round off error as initial values are slightly off. I need to check this calculation as well to make sure everything is right. Problem is that it is hard to understand how it is done in the previous code as it used matrices for doing complex value calculations. In new code, I just used ucomplex class and followed the paper's calculations. I need more time to look into this too. Suggestions are welcome.
I saved the traces of old and new noise budgets as txt files and then plotted them together to understand the differences between the codes. One can refer to CTN:2250 for a summary of calculations of old noise budget.
There is no distinction in the calculation of this contribution after the changes made in CTN:2388, but there is still a difference (which reaches to around 20% above 1 kHz). This is maybe because of interpolation errors when taking the differences. But I'm not sure about this. This can take a sanity check from others as well.
The following calculations had no differences between the two noise budgets and the contribution differences are also none or minimal.
I had aligned the North Cavity before the weekend and was about to align south one today when I saw that the modematching on the North Cavity has fallen to 20%. This is a tell-tale sign of vacuum can temperature changing too much. When I checked, indeed the temperature sensors were railing to their lower most value of 26.599 Celcius. Same for both in-loop and out of loop sensors. While the table top temperature sensor was giving a meaningful value.
I first checked point by point the temperature sensor board LIGO-D1800304. From ADC all the way back to the AD590s.The two sensors were indeed giving a voltage of 4.8 V through a transimpeadance of 16.25k which meant 295.385 uA of current corresponding to 22.23 Celcius. So indeed the sensors were telling me that the can had cooled down to almost room temperature over the past 2 days.
I checked the framebuilder logs to figure out what has happened. The temperature was being stabalized at 34.38 Celcius by the PID script. At around 15;20:25 Aug 16, 2019 PDT, the temperature starts decaying. Infact, I should use this data in future to calculate current time constant of temperature decay of the can through the insulation. The table temperature was around 19 Celcius all this time. I found out that FB4 is not recording the channels that I have added later. I need to look into this as well.
Attached is the decay plot of the temperature
After a deep search through elog, CTN:2043 and CTN:2045 are the most relevant latest post. Kira and Kevin worked on this heater drier circuit and I'm doubting that something blew up in this circuit CTN:1903. I guess this would be my first point of attack.
Another possibility is that the heater load got disconnected. Well, I just checked the resistances and I get values of 38, 70, 70 and 38 Ohms. These are the right values according to CTN:1750. This is not the issue.
Lastly, the worst possible issue would be that the temperature sensors are reporting wrong temperature. But looking at the the properexponential decay of temperature reported by them, I would first assume that they are working fine.
See CTN:2394 for the symptoms and investigation. Open this post at CTN:2395 to see the chain of previous work on this circuit.
I updated ctn_scripts\channelFramebuilderConfigFileCreator.py to work with the new format of modbus hosting through docker (and cleaned it a bit). Also, from now on, C3CTN.ini will stay in the ctn_scripts repo to have version control.
I have run this once and followed instructions from CTN:2014 to restart frambuilder daqd process so that all new channels are logged as well.
I found out that FB4 is not recording the channels that I have added later. I need to look into this as well.
Utilizing the fact that the heater stopped last Friday, I fitted the day to extract out a time constant for cooling down of the Vacuum Can through the present insulation. Attached is the fit. The time constant has come out to 2.298 +/- 0.001 hr.
Infact, I should use this data in future to calculate current time constant of temperature decay of the can through the insulation.
I aligned the south cavity today achieving a nice 70% mode matching. While doing so, I realized a big issue that was gone unseen before the heater circuit blew up. I saw that since the vacuum can temperature control was active and was making a lot of jumps here and there all over the 1.5 A range, the Sorenson power supply isn't so good in keeping up with such sudden current changes. In effect, I think the Vacuum Can Heater's PID control signal gets coupled to the overall power supply coming from Sorenson.This +- 24 V rail was connected to EOM drivers earlier. Because of the poor design of EOM drivers, the EOM's are constantly at a DC voltage of +24V from this Sorrenson Power supply with only a passive filter. I could see today that when vacuum can PID was on, the laser frequency was haphazardly changing making it much more difficult to align the cavity. I was able to align it in minutes once I switched off the vacuum can PID.
So moral of the story is, keep the vacuum can heater circuit alone and Sorrenson Power supply is exclusive for it.
I shifted the EOM driver's power supply to Kepco which supplies for other rack-mount electronics as well.
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.
The new noisebudget code follows Hong et al . PRD 87, 082001 (2013) calculations to calculate Coating Brownian noise. This calculation uses different loss angles for bulk and shear strain. In fact, the calculation uses different loss angles for each layer as well if known. The closest reported values I could find are from Penn et al. JOSA B 36, 4, pp C15-C21 (2019). They used mechanical ringdown measurements of large disks and COMSOL modeling to estimate the bulk and shear loss angles.
I used these values and compared the change in the estimate of coating Brownian noise contribution. Attached is the result.
If the loss angles values reported by Penn et al. are correct, then our Coating Brownian noise would actually be buried beneath all other noise contributions. So I'm not sure what is correct, what is not? Is my understanding of this wrong somewhere?
The old calculations were described in CTN:2250.
I would like some guidance on this.
Edit Wed Aug 28 10:49:45 2019 anchal:
I did a mistake in the plot earlier. The new data was in PSD, not ASD, so it needed to be square-rooted before comparing with the old data. I've updated the plot now.
It seems like the induction of new values and new method changed the effective coating loss angle (used in the previous calculations). If Penn et al. values are correct the expected Coating Brownian noise contribution has actually increased by about a factor of 5. However, I'm not sure where the previously used effecting coating loss angle value of (2.41 +/- 0.2)e-5 came from. Complete noisebudget is coming soon.
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.
We need to switch out normal flat-faced beam dumps with triangular cavity beam dumps in all places where they are not present. Following is a summary of beam dump status
Total Normal Beam Dumps behind PMCs: 12
Attached is the latest noise budget calculated using the new object-oriented script.
Parameter files and all noise contribution PSD data.
Note that since we used Penn et al. JOSA B 36, 4, pp C15-C21 values for shear and bulk loss angles of the coating and used Hong et al . PRD 87, 082001 (2013) calculation procedure, as pointed in CTN:2401, the estimated coating brownian noise contribution is more than previously calculated and dominates the total estimated noise from about 20 Hz to 20 kHz. Also, the PLL noise was switched with Moku Frequency Noise measured in CTN:2357
The experiment configuration file is attached. Major differences are:
Beatnote Measurement Data
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.
Following Rana's test done in 40m:1986, I have programmed the lab to go through a similar test. Following things will happen:
So this will happen three times. In between, the cavity heater PID control will have 7.5 hrs to stabilize the beatnote frequency and at 3:00 am as usual beatnote measurement will happen.
All channels are being recorded at FB4 in QIL so we can look back the relevant channels after the test is over. Putting a sticky note in QIL for not to interrupt FB4.
All details regarding TTFSS boxes present in CTN has been updated at this page in ATFWiki
I have added fields of who made the changes, on which box and on which board to make this change log more readable. These fields should be followed from now on.
Relevant circuit schematics, photos and zero models are kept in ctn_electroncs/TTFSSzeroCTN repo to keep a version history of changes as well. This should be updated everytime any change is made to the boxes from now on.
Note: The current updates were made by using Andrew's change log and verifying that no other changes have been mentioned in our elog history other than the change log. However, if the real circuit has any changes which people did not log, then they are not present in these schematics or model. These, if they exist, will be added as soon as we find them.
I'm skeptical of your FSS changes over the past year. Can you please link to the DCC entry that has the actual, real, as-built, as-modified FSS schematics? i.e. including all changes no matter how minor.
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.
Daily noise budget plots are now pushed to these links.
CTN Daily Beatnote Spectrum
Here, all beatnote spectrums since Aug 27, 2019 are plotted in an alpha scaled manner. The darker the plot, more recent it is.
CTN Latest Beatnote Spectrum
Here, the latest 3 days of beatnote spectrum is plotted.
Attached are the results of this step test.
For record, I took data of beatnote timeserieswith fasted sampling rate on Tektronix TDS 3034C (CTN_OSC_SN01).
The plan of action has been moved to a new wiki page for better documentation.
I used the calibration of North and South NPRO control voltage to frequency change from CTN:1948.
Then using the following formula:
where S is the calibration slope for NPRO from volts to the frequency
is the coefficient of thermal expansion of fused silica,
c is the speed of light 299792458 m/s
The offset was adjusted so that at t=0, the cavity temperatures is the same as the vacuum can in-loop temperature sensor reading at t=0.
This gave for the South Cavity -22.456 K/V and for the North Cavity -23.489 K/V
The South Cavity temperature changed 0.511 K, 0.539 K, and 0.565 K in the first step on the three days. Mean response to the first step is 0.538 K.
The North Cavity temperature changed 0.520 K, 0.574 K, and 0.639 K in the first step on the three days. Mean response to the first step is 0.578 K.
The South Cavity temperature changed -0.878 K, -0.860 K, and -0.863 K in the second step on the three days. Mean response to the second step is -0.867 K.
The North Cavity temperature changed -0.903 K, -0.933 K, and -0.910 K in the second step on the three days. Mean response to the second step is -0.915 K.
Edit Fri Sep 6 12:01:49 2019 anchal in RED above.
Found out that there is a bored hole in the spacer so the laser doesn't travel in fused silica actually. So the refractive index used above is wrong.
Updated calculations and plots for the same.
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.
I was looking at the error signals of PMC servo and found some systematic oscillations in NPMC error signal at around 500 Hz.
So, I connected back the beatnote to the Marconi PLL and used the error signal from there to measure beatnote - NPMC error signal cross-spectrum. Here, the channel marked Mixer Out on the Servo card is FP3Test port which is marked as 'Mon1' on the schematic (latest schematic). This channel is essentially the output of mixer buffered with gain 1 through an LT1128. Note that currently on North side, we are using FP2Test to send the PD signal in with an external mixer.
Something is either physically wrong near North PMC or the card might have developed some bug, which needs to be tested.
I opened the NPMC servo box and ran TF analysis up to all test points and compared with their zero model. Everything looks normal in these transfer functions.
So the oscillations might be happening due to closing of the loop. I'll take a measurement of total open-loop transfer function next with the PDs and PZT in the loop.
Updated schematics and Zero Model
It turns out that the noise is either injected through the EOMs or through some mechanical oscillation in the table or through RFPD SN020. The servo card was working normally. However, since I had opened up the box, I used this opportunity to increase the first stage gain on the FP2test input and also made it 50-ohm input impedance by adding a 51 Ohm resistor in parallel to R8. Now, beware that on the actual board, R5 and R8 labels are actually swapped. This helped keep the gain set by AD602 to 7 dB now, instead of 30 dB maximum. This way we are able to increase the gain more instead of getting saturated. The hunt for 500 Hz bump would move to finding on table sources now.