where ms is EOM phase slope (15 mrad/V) and V_EOM is the applied actuation voltage. As you wrote, that leads to
This actually has units of Hz/Hz. Note, that is just Fourier transform of frequency actuation, so it is unitless. I used this to get the transfer function of EOM actuation, from applied signal in V to resulting actuation in Hz, which is the prefactor of above having units of Hz/V.
If we assume that the EOM is taking 100% of the load for canceling laser frequency noise at a given frequency then it follows that the applied voltage to exactly cancel laser frequency noise is
So, if EOM is taking the whole load of frequency noise, actuation signal ASD would be:
But obviously, this is wrong because this just assume that we are not feeding back the actuation signal at all. So instead, I assumed that if everything is 'ideally' working and we actually have the frequency noise suppressed by a teamwork of PZT and EOM, the incoming noise signal to EOM path's transfer function is:
So, the actuation signal generated for EOM by EOM path's transfer function in an ideally working loop is:
The error in the last plot in PSL:2305. is that I forgot to divide by since transfer functions in the code are from Hz to Hz. So I think this is the real error.
One thing to note is that the above estimates are an upper bound assuming that the EOM is taking all of the load down to that frequency point and that the PZT path isn't fighting or out of phase with EOM. To correctly compute the load on the EOM you are going to have to break down the EOM only portion of the loop from the laser frequency to the point of voltage injected into the EOM. This can be done by effectively nesting the PZT loop into the round trip gain in a way similar to that described in Josh Smith's Thesis section 2.6.2. Finding the actuation signal should be similar to finding the PLL actuation signal, at this point in the loop it is the G/(1-G)/A copy of the sensor noise. In the high gain regime the applied EOM control signal should just be the laser frequency divided by the EOM frequency slope. Of course you can compute for G_EOM OLG to get a true value with a bunch of algebra.
But on reading section 2.6.2 of Josh Smith's Thesis (which btw has a typo in Eq. 2.33 and 2.34), I did the thing of nesting the PZT path with the plant. So as per Eq. 2.31:
is the transfer fucntion of Plant for the simplified loop with just EOM as the actuator. Then the actuation signal ASD would be (note is free running laser frequency noise ASD):
which turns out to:
Which is exactly the same as above. But still my model has this error. I'll fix it and post it soon. For readers in the future, the last set of equations are the only correct equations to the best of my knowledge.
Hmm... Last estimate of V_rms applied to EOM can't be true.
If laser frequency noise is
Total frequency noise down to 1 kHz should then be 316 Hz_rms. As you've noted in your jupyter notebook the EOM frequency domain response to actuation signal goes as f, i.e.
This would indicate that the burden on the EOM becomes 1/f heavier in frequency because of the laser noise roll up and 1/f heaver because the EOM responds as f to signals in the Fourier domain. The above puts an upper bound on the ASD curve of load that the EOM is absorbing to cancel laser frequency noise.
Integrating the above V_EOM PSD down from high frequency will give the total V_rms load that the loop would need to apply to suppress laser frequency noise:
I've plotted this below and attached the notebook used for the calculation. It kind of looks like the maximum load at 1 kHz hits about 200 Vrms. Maybe I've gotten some factors wrong here but you can sort of see the scaling of how the maximum load on the EOM will look.
I added some more graphs to our FSS analysis.
I'm attaching the first results of the transfer function from liso model of complete TTFSS box. I've also attached the jupyter notebook with some important formulas used.
Both files are present in git/cit_ctnlab/ctn_electronics/TTFSS_lisomodel/ git repo.
I'm just posting results for the analysis I did so far. I'll be able to make better inferences with some more work I intend to do tomorrow.
Edit: Wed Feb 6 16:59:59 2019
The updated plot is at git. Added analysis of variation of crossover frequency and phase margin with changing Fast gain.
Edit Thu Feb 7 11:32:13 2019 :
Last plot in the attachment is wrong. See following discussion in PSL:2306 and PSL:2307
I checked the boost stage on U7 of LIGO-D040105-C on the south path box (37 MHz). It appears that Craig had changed its value to 6.8 nF to match the North path.
The resistor was actually 5.088 kΩ, instead of 5.6 kΩ as listed. The resistor was changed from the radial thick film (5.088 kΩ) to a thin film surface mount type (5.6 kΩ). I moved the capacitor from the switch (at the end of the wires) to immediately at the board. The switch on the side of the box now only has two wires to short the capacitor when we want to disable boost. This should mean that there is an integrator with a pole at DC and a zero at 4.2 kHz and won't have any funny feedback impedance due to long wires and switch. This now matches the North path.
Anchal is going to figure out how to increase gain of south FSS RFPD from ~1.5 kΩ to 2.5 kΩ of the north path. In the meantime I've added a mini circuits low noise amplifier to the output of the RFPD. This has a noise figure of about 3 dB and a gain of +24 dB. I put a 20 dB attenuator after the amplifier. I think the extra gain stage will only add a few mHz/rtHz to the input referred noise, so should be fine for now. Once Anchal has solved the crossover TF optimization he'll have time to fix this.
I'm implementing the suggested cap and resistor updates in the last post (PSL:2301).
I couldn't find any 100 nF or 33 nF caps in polycarbonate in WB EEshop. These haven't been manufactured since 2000 and I couldn't find stock at the 40 m either. Instead I used polypropylene as they have comparable specs (as far as I can tell) and should be good up to ~1 MHz (I think). If not, its easy enough to fix.
Replacements on D040105-C FSS servo board:
I also checked the boost that hacked onto U7 of the FSS servo board. This is a capacitor in series with R29 (5.6 kΩ). I checked the actual value it is 6.8 nF in the North FSS box. This combination (5.6 kΩ + 6.8 nF) in the feed back path of U7 gives a pole at 4.18 kHz. This should be enough to give an increase of gain of 10 dB by 418 Hz and 16.2 dB by 100 Hz. This is probably more than we need. It could be shifted down to 1 kHz (28 nF) if we do eventually reach 1 MHz UGF.
The loss of gain from changing R19 means that we are getting a factor 12.45 less gain in the EOM path. I turned the common gain slider up to max of 10V (+32 dB) and see a UGF 224 kHz. The loop is stable with boost on and fast gain set to -1.07 V and also with the boost off; the cross over for this configuration of gains is 11.3 kHz. The RMS noise on north PDH error monitor is 19.4 Vrms (just looking on the oscilloscope). It seems pretty stable for now, I'll take a TF later after a few more tweaks of values. Also its late and I want to go home.
Now we have a problem with gain, we need more of it. It looks like that if we could find gain of +10 dB somewhere we could push the UGF out to 593 kHz and have a healthy phase margin of 42 deg. If we can find more gain we can probably go further. The phase margin gets to 30 deg at 806 kHz so that might be a logical point to stop. However, there appears to be a little peaking at 750 kHz that we need to watch out for. Not sure what it is, don't think I've seen it before. We'll have a closer look at it when it becomes a problem, but we might need to reexamine tuning of notches or putting another notch in if the combination of OLG UGF and and boost mean we need to push out this far.
We could collect error signals and actuator signal PSDs and model the optimal ballance and crossover between PZT and EOM, but this will take weeks to build an actuate model. For now its probably faster and easier to see empirically if the EOM can handle the higher gains without running out of actuation range.
In terms of finding more gain, we can get a bit by boosting do any of the following:
We've hit a flat (white) noise floor at around 70 mHz/rtHz. Time to tally all the unaccounted for noises.
Here the FSS resonant detector dark noises were measured using a Lv13 ZX05-1MHW+ mixer with a 4th order LP + 50 Ω terminator on a SR785.
Frequency equivalent noise is just input referred noise divided by the PDH discriminator value. The PDH discriminator value is computer assuming gamma=0.3 rad modulation depth, visibility of 0.5, Finesse of 15000, cavity length 3.8 cm. This gives 4.4 nV/Hz for the slope of the error signal about resonance.
BN detector input referred noise is just input referred power divided by 1/2 Vpp of the beat note. For 0 dBm beat note, then input equivalent power is (dividing through 1.27 kΩ TI gain) works out to 0.25 mW/rad.
So the upshot is that there is too much FSS RFPD noise to see Brownian noise clearly but is not our current dominant noise source. We are missing about 69.6 mHz/rtHz.
I'm including this because it was a question we thought about and dismissed. There is a 100kΩ - 1 µF - 100 kΩ LP filter from the FSS offset channel into U3 on the servo board (R8-C5-R9, in D040105-C). There is an estimated 0.4 pA/rtHz of thermal current noise there. Also the AD829 has a current noise of 1.5 pA/rtHz (op amp U3). These are additive and indistinguishable from sensor noise. The mixer output equivalent voltage noise is just the equivalent voltage across R3 and R9 in the FSS RF board (LIGO-D0901894): i.e. 0.4 pA/rtHzx146 Ω = 58.4 pV/rtHz at mixer output. Dividing back through the mixer conversion, transformer coupler and PD gains (see PSL: 2242 for values and links) we come to some input referred noises in units of optical power tabulated below.
So electronic noise, at least from the point of summing the error signal with offsets is negligible. We might want to revisit this later, but most points of noise injection into the FSS loop will be suppressed by the closed loop function and will be small.
The current state of the FSS loops is ~180 kHz UGF for north and ~70 kHz UGF for south (woeful). South is worst because the RF PD has only half the TI gain and we are at maximum gain for the FSS variable gain stages. The whole point of these loops is to suppress laser frequency noise. Their current performance is just not good enough.
If we assume that the laser noise is modeled as
and that we need a clearance of 10 dB at the 100 Hz point where we expect to see Brownian noise (10 mHz/rtHz @ 100 Hz), then we need to get to 1 mHz/rtHz or a a factor of 1e5 1/(1+G) suppression. This means that its very likely that our current limitation is actually FSS loop bandwidth.
Naively if we assume 1/f loop shape, that means that we would need a UGF of 10 MHz to reach 1e5 gain by 100 Hz. Nope. Of course we have some loop shaping in the lower frequency reaches of the PZT path of the FSS. There is a boost pole-zero pair installed in the common path (PZT servo path U7) that uses R29 of 5.6 kΩ and capacitors of either 4.7 µF or 6.8 µF depending on the box. This would put the corners between 6.0Hz and 4.1 Hz, too low (don't know why so low). If we move the boost up to 1 kHz or higher then we would be able to reach 1 mHz/rtHz by 100Hz with a overall path open loop gain crossing 0dB at 1 MHz.
Right now we cannot turn up the gain of the loops much more than 200 kHz. We can see from looking at the EOM control signals that above a certain amount of OLG the EOM is taking too much of the actuation load and rails. Basically the the cut off frequency for the EOM servo is not aggressive enough and the EOM is working too hard in the frequency band below 10 kHz where the laser PZT should be doing the heavy lifting. I outlined some of the changes that need to be done in PSL:1902. This is based on Matt Evan's modifications of the MIT Squeezer FSS system.
MIT's FSS boxes are a few versions on from our FSS boxes but the main points remain:
In addition to this we want to modify the boost stage by removing the ~5 µF chunkers and trying something more like 28 nF or more. I think what we need here is a metal film cap (no ceramic) and the question is whether setting the corner so high will be an issue with it railing between locks if there is some kind of offsetting there. Maybe this isn't an issue.
These are relatively strait forward changes providing we have the appropriate capacitors in stock. It seems like boosting FSS UGF by offloading EOM path LF onto the PZT and making the boost good is the most obvious way to squash this noise and make fast progress. Lets try and hit the 1 mHz/rtHz target with a 1 MHz FSS UGF effort.
Efforts on characterizing thermal sensors need to wrapped up but we want to get to our actual noise source. The more recent PID improvements on the cavity temperature control (PSL:2295) have gotten us to a point where we have usable 1kHz/V VCO measurements which is as good as we need for now. Maybe a shift in effort from thermal control to laser stabilization is the best use of our time.
I've attached a block diagram of the FSS controls below. It shows at a glance the current configuration of the EOM, PZT and slow laser controls.
Edit awade Sat Feb 2 00:44:47 2019: Revised down FSS shot noise estimates based on correct sidebands, visibility and modulation depth values (from Tara's thesis).
The FSS at some point is going to be limited by shot noise. I understand that the apparent frequency noise should go as :
where h is plank's constant (6.626e-34), c is the speed of light (3e8), L is cavity length (36.83 mm), F is finesse (~15000), lambda is wavelength (1064 nm) and P0 is incident power (order 1 mW right now). The inherent frequency equivalent shot noise would then be , which for our cavities would be 30 mHz/rtHz for each path for 1 mW of incident power. Where does this leave the frequency noise of the transmitted light? Within the cavity line width does it not just pass all the frequency/phase noise?
Obviously our SN value will be slightly worse than this because we don't have excellent mode matching. But even in the ideal case do we have to use 100 mW of light to get to 10 mHz/rtHz where the brownian noise is at?
These may be stupid questions but I'm not sure how SN limited PDH frequency noise looks like on transmission from a reflection locked cavity.
So for 1 mW of power we should be getting 0.9 mHz/rtHz in the ideal case that MM to the cavity is perfect. So we are good on the ultimate SN limit of the FSS loops.
Edit awade Wed Jan 30 16:34:59 2019: Correction to original post the quoted spectum is and ASD not a PSD, I got the units wrong. Values are corrected above
 Black, E. D. An introduction to Pound–Drever–Hall laser frequency stabilization. Am. J. Phys. 69, 79 (2001).
that's a good start, but we don't care about the noise above 10 Hz. So you should re-take the data and plot from 1 mHz to 10 Hz. Instead of using SR785, just record the time series on a cymac somewhere. You can run a cable into Gabriele's lab if you have to.
Here are the noise spectrum and time series plots that were asked of me ages ago. Apologies for the delay. I've also attached the analysis files in .zip.
Even with a breadboard circuit and different opamps (see PSL:2268 for changes), the circuit has less than of input referred noise almost in all frequency range. The time series data also fluctuates less than during 32 seconds of data, so worst case, this circuit would be precise to at least 5mK. However, since this circuit has no bypassing capacitors and high drift resistors, the PCB version should perform even better. I'll do same analysis with a stuffed PCB board soon.
post a plot of the times series and noise spectrum
Here is a link on how to choose R and C:
On Friday, awade ran beat note measurement with resonant beat note photodetector to see how low we can get with improved SNR of this resonant detector. The method is the same as (PSL:2272) with 1000 measurements. The new noise budget is attached.
Results are little better than using the wideband New Focus 1811-FC.
Noise floor between 100-1000 Hz is about and above 1kHz it is .
The bumps at 150-160 Hz, 300 Hz, 800 Hz, and 900 Hz are still present. So their origin is something else in the experiment.
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.
About BN slope detector: I just made few extra EPICS channels to do this. But acromag1 hasn't rebooted since for testing if it works. However, since the pre-cavity beat note frequency counter fails to update values sporadically, there would be glitches in this slope readout as well. Another way is to do this in python keeping track of past few pre-cavity beat note frequency recordings.
About BN sign checker: I was working on this more like a side hobby project so far. I had successfully implemented it before when I was trying that semi-smart temperature control. I'll take a look again at BNFreqSignUpdate.py which needs to be run in a tmux session for this to work.
This will be more a problem down at the 27 MHz point that we want to lock to. As the set point is so close to the BN flip across 0 Hz any disturbance can drive our loop into this runaway state. Its not clear how we reject these glitches or reliably sense the flip across 0 Hz. Filtering pre-cav BN for glitches seems bad as it will introduce poles that then affect the loop. Trying to sense a change in BN slope (I think anchal implemented this?) will be hard if the slope is very shallow as it crosses, this will give confusion about the sign if the noise dominates over the derivative value.
Testing of this seems to confirm that lower intergrator values are the way to go. We had excellent locking with <1.2 kHz/min for a period of about 12 hours. This is almost good enought to move down to 500 Hz/V VCO slope with some averaging.
Settings were P=0.0015, I=0.000050, D=0.0. The heater diff value hovers around 0.68 W for a setpoint of 69.2 MHz.
Bad news is we had a glitch that spiked the pre-cavity BN detector frequency at about 5:07 am this morning. This spiked the intergrator value and drove the heater value up for about 30 min before the BN crossed the 0 Hz point. There wasn't enough time for the intergrator to wind back down the sign change of the BN frequency ment that the loop then just drove away from the setpoint eventually railing at 1.1 W diff heating.
This will be more a problem down at the 27 MHz point that we want to lock to. As the set point is so close to the BN flip across 0 Hz any disturbance can drive our loop into this runaway state. Its not clear how we reject these glitches or reliably sense the flip across 0 Hz. Filtering pre-cav BN for glitches seems bad as it will introduce poles that then affect the loop. Trying to sense a change in BN slope (I think anchal implemented this?) will be hard if the slope is very shallow as it crosses, this will give confusion about the sign if the noise dominates over the derivative value.
Machine learning would be helpful here maybe. If you include information about the laser slow frequency controls (for both lasers) its really obvious when the direction of the BN evolution is inconsistent with frequency direction of the laser evolution for both cavities.
For now I am going to narrow the hard stops on the PID script. This should prevent the loop from railing hard and taking hours to recover. It seems that without a drastic change in the environment temperature we will never need more than 0.1 W of movement either side for the actuator center point. I'll set the limits to [0.65, 0.75] W for now, this should be enough to gently hold the BN in the 0- 100 MHz range and will prevent hard railing way out of range.
Probably a lot of our problems of the PID tuning of the cavity temperature controls (for controlling BN freq) come back back to our P, I and D constants being too course. This is a hangover from earlier implementations of this script where the precision of the constants was set by limits on the EPICS channels max significant figures.
We no longer use the finite difference approximation for our discreet digital PID controller and are free to use a lot more precision on the accumulated integrator values.
I've made a modified version of the PIDLocker_beta.py script that divides the value of the P, I and D slider values by 1000 before doing all the usual operations to compute the actuation value. Here the integrator variable in the python script holds the previous loops value over and adds the error on every loop cycle at maximum precision allowed by numpy. The value of the actuation is then only rounded to 5 SF at the very last step.
To assist further with fine control of the heating I also changed the way the process variable is rounded before writing out to EPICS. The current operation in PIDLocker_beta.py (see PSL:2142) is to round up based on the lowest digit so 0.770465 -> 0.77047 and 0.770463 -> 0.77046. A better way is to do probabilistic rounding. If the last digit to be rounded off is 3 then there is a 30% probability of rounding up and 70 % probability of rounding down. Its a kind of poor man's oversampling. It allows us to get intermediate bits between ADC levels.
The script is a hacked version of PIDLocker_beta.py and is called PIDLocker_cavcontrol.py located in the ~/Git/cit_ctnlab/ctn_scripts dir. I've attached a copy (zipped) below and have committed into the git. During testing the script is running on a tmux session on ws1 using:
> python PIDLocker_cavcontrol.py PIDConfig_CAVHeater.ini
We only need a gentle push from the integrator to hold the BN in place and before it was overkill. Hopefully by lowering the gain on the 'I' term the 1/f component of the PID will not exceed the corner frequency of the cavity+heater system and stop the instabilities that we were seeing to this point.
For reference the probabilistic rounding code is given below:
'''Truncates a numpy float to given decimal places (dp)'''
return np.trunc(x * 10 ** dp) / 10 ** dp
def probRound(x, dp):
'''Rounds float to given decimal places (dp), with
last digit round done on a probabilistic basis.'''
xTrunc = truncFloat(x, dp) # Truncate to dp figures
xrem = x - xTrunc # find remainder of truncation
p = np.abs(xrem) * 10 ** dd # prob of rounding up based on trunc remainder
if np.random.uniform(0,1) < p:
xout = xTrunc + np.sign(x) * 10 ** -dd
xout = xTrunc
This test relay test was a failure. I got impatient late last night and downed the midpoint diff heating to 0.5732 W. There wasn't enough range on the upper side of the relay switch and BN flew past the 100 MHz setpoint and was around -400 MHz about 8:30 am this morning.
I did a bit of manual tuning driving the diff heater slider hard to 0.9732 W (common heater 0.48710 W) and then breaking the BN swing driving the opposite direction with diff heater of 0.4732 W for about 30 min. I'm now at about diff 0.73320 W and the BN is beginning to settle about 80 MHz on the other side of the BN 0 Hz crossing point. I think right now we should let it passively settle again so we can get another VCO=10 kHz/V BN measurement to see if recently reduced noise of NF1811 makes a difference (see PSL:2288).
I used the same measurement method as explained in (PSL:2272). Changes in the setup from before:
Today we checked FSS Common path and Fast path transfer functions to see unity gain frequencies and any possible optimizations.
I have switched off auto gain and offset tuner services. I'll start a beat note measurement today to see if our changes in FSS loop and reattaching wideband photo detector changed anything.
The first measurement here seems like a smoking gun for limiting noise. A mixer down converted noise of 1.3 µV/rtHz (directly out of the mixer) with a S*A (VCO + SR560) gain of 200 kHz/V would be 0.26 Hz/rtHz. That would be consistent with the noise floor of the more recent BN PSDs. The PLL open loop gain will change this estimate, but the 200 kHz/V gives a lower bound. This initial measurement of NF1811 noise was a factor of ten more than spec for this detector. It should be ~100 nV/rtHz (equivalent to input ref noise of 2.5 pW/rtHz at peak responsively). We should have traced back to the source of this earlier, but now that we know its a potential problem we should double check if we're having issues with BN noise floor not matching up with the noise budget.
Its weird that the second measurement of the same NF1811 seems to show it performing closer to its spec value. The setup for measurment was exactly the same. I should note that when we were making these measurements we switched the BN cable from the NF1811 to the resonant 27.34 MHz detector and back again. I also wiggled the power cable at the time. I've seen in the past that when there is a power connector issue, the NF1811 can produce something that looks like signal but with RF oscillations if there is a problem with one of the power rails. We probably should have checked at the time with an oscilloscope to see if there were any issues with the RF signal coming out of the NF1811. It could be that there was some kind of oscillation or other bad thing going on and the act of unloading and reloading the output with 50 Ω and wiggling the power connector some how got it back to proper operation.
For now we should should recheck the NF1811 dark noise (after mixing down) before making another BN measurement and not touch connectors on the detector side in case there is a flaky connection.
You definitely saw the higher noise state, so I wouldn't dismiss it yet. I guess we won't know if the reduced noise second measurement will bring down out noise floor until we see a BN measurement.
We suspected if the wideband RF detector New Focus 1811-FC could be the source of noise floor through its dark noise. So I took dark noise spectrum measurements today of this photodetector.
Edit Tue Jan 22 20:06:00 2019
Beat note is still not under control. Its drifting at 10 kHz/min, too much for a lower range marconi measurement.
We would like to bring the frequency down from ~140 MHz to something closer to 27.34 MHz of Koji's resonant BN detector. I'm going to try to use the relay auto locker feature of the PIDLocker_beta.py script again to get the BN to converge on some steady value (see PSL:2142). In the past the relay method was able to actually get a convergence to a BN value but failed to give good values as there was a thing with the cycle limit converging to zero in the case of these really slow BN thermal controls. I suspect this was due to a relay step that was too small, the asymmetry of the heater actuation and/or large time lag caused issues.
For now I'll leave the relay on overnight to see if we are able to get a good convergence with a relay step of 0.1 W about mean heater power of 0.77320 W and common power offset of 0.48710 W. The setpoint was left at 100 MHz, we will step it down to the 27.43 MHz gradually so as not to overshoot the BN past 0 Hz and flip the direction of the frequency.
The service running the PIDLocker_beta.py script for the cavity slow heater controls was stopped and was then manually restarted in a tmux session on ws1 using the following command:
> python PIDLocker_beta.py PIDConfig_CAVHeater.ini --autotune -d 0.1 -o 0.7732 -t 86400 -e
This should run the relay mode of the auto locker for 24 hours (86400 s) about a mean of 0.7732 W and a relay step of 0.1 W (bigger than in previous tests). We'll see how it goes and reassess tomorrow morning.
I see that we were lacking in complete documentation of PLL transfer function and noise analysis. I made this document for the same.
Edit Fri May 17 14:02:14 2019:
Above link is no longer maintained. Now there is a DCC doc (see LIGO-T1900263) for this analysis.
I took the noise spectrum of beat note in PLL when it is fed with a low noise Wenzel Crystal Oscillator of frequency 24.483 MHz and doubled frequency 48.967 MHz.
I wanted to take a direct spectrum noise measurement of the circuit. However, if I have simply hooked the output of the circuit to SR785, I wouldn't know if the noise is coming due to temperature fluctuations or due to circuit noise itself. So I made a quick subtraction circuit of unity gain with an OP27 and subtracted different pairs of channels and then took their spectrum using SR785.
First I shorted the input to the subtraction circuit and measured the spectrum. This gave me an estimate of output noise due to this additional circuit and SR785 measurement.
I assumed the gain of the subtraction circuit is just 1 so, the output noise of the circuit under test wasn't assumed to get amplified from subtraction circuit.
Then I took measurements of the difference of signals for each pair from CH0, CH1, and CH3 in both permutations. All measured spectrums are plotted in the first plot.
I used both permutations to nullify any effect of different gains in positive and negative inputs of the subtraction circuit due to slightly different resistor values.
Then I averaged the spectrum from the 2 permutations of difference and subtracted output noise of the subtraction circuit measured earlier in quadrature. These are plotted in 2nd plot.
Then for the Circuit 1 which was insulated from the environment, assuming the two circuits have identical noise, I divided by sqrt(2) to get individual channels output noise.
I subtracted this insulated individual channels output noise from the difference noise with 'open to environment' channel in quadrature to get an estimate of noise when the circuit is open to the environment.
The individual channel output noises are plotted in Plot 3.
There is a high peak at 60 Hz because of AC frequency. I am not sure about the origin of the 7 Hz peak. Other peaks look like reflections during the measurement.
There is about a factor of 2 improvement by insulating the box.
The circuit is designed for 1.625 mV/mK transduction.
Since EPICS channels are read at 16 Hz rate, we should be interested in the 0-16 Hz bandwidth. In this bandwidth, voltage output noise for the insulated channel is 0.79 mVrms and 'open to environment' channel is 1.74 mVrms.
So the noise wouldn't harm the designed 1mK sensitivity. In practice, even if these estimates are bad, the circuit should be ok for our needs.
So the only thing that can endanger our precision really would be temperature drift of circuit components on which we have already invested enough money and time during design.
So agreeing with Andrew, I'm going to go ahead and install these new circuits and directly see their performance towards improving BN spectrum as we think the Vacuum Can temperature is oscillating more than lab temperature due to poor circuits presently employed.
This is not a detailed post as I didn't collect data. We need to check the actual noise performance of the Marconi and compare. It seems like the marconi used in the PLL has some nasty frequency spikes and generally higher noise.
Today I dug out a Wenzel crystal OCOX oscillator (Freq 24.483 MHz) from the QIL lab to check the performance of the Marconi FG against a stable reference. These crystals are a good reference to compare to as they should have a noise floor of -165 dBc/Hz vs the marconi performance of -124 dBc/Hz (@ 20 kHz) operating at 470 MHz (datasheet didn't have values for smaller freq).
The output is +13 dBm so I attenuated by 13 dB to give a simulated BN signal of about 0 dBm (gives mixer gain 0.210V/rad). This was then substituted for the beat note signal and and the PLL was locked with the Marconi carrier close to the nominal crystal frequency. Marconi slope was set to 1 kHz/V, LO carrier was +13 dB into mixer (lv13), SR560 gain was 20. Screen shot picture (attached below) shows the original Marconi (labeled #539) in the reference trace and the spare PSL lab Marconi (labeled BD90200). Sorry there is no data capture, I was using the SR785 from the EEshop that isn't configured for our lab IP addresses.
What we see is at least 10 dB worse performance for exactly the same marconi settings. We can also see that there is also a huge spike at about ~1kHz. This could be the source of some of the humping in the BN spectrum. Not sure about this but maybe some of the LF noise in the spectrum gets convoluted about this strong spike, smearing noise out at the higher frequencies.
The Marconi in the cryo lab, from the cryo-CTN experiment was also procured. The noise on that Marconi was even lower and did not have any spike artifacts. However, I was able to see a bit of a spike when the external modulation voltage was a little bit negative.
I then messed around with some of the settings buried in the menu, I turned the external RF clock reference off on the cryo Marconi and also activated the RFDC null with the modulation BNC 50Ω terminated. After I had changed some of these things I was not quite sure if I recovered the same noise performance from the better units. Also, I noticed that the 10 kHz/V range on the cryo Marconi didn't want to lock at all, it was as if there was no actuation going on; it worked fine on settings <=4 kHz/V, just not higher, not sure what is wrong here.
We need to do some detailed measurements tomorrow at a range of different frequencies to nail down exactly what is going on here. As the VCO noise in the PLL loop is not suppressed by the loop gain, this goes strait to the bottom line of the BN spectrum. We need to know that PLL is not limited by the Marconi noise.
Measurements to do:
Also, we want to take some BN with the old Marconi swapped out. You should have all the data you need for drift of AD590 sensor traducers by now. The old TIA circuit is so badly designed that its almost certainly doing a feed forward from room temperature to can heaters. Either install the new circuit proto or turn the vacuum can thermal controls OFF completely. Just install what you have and use the secondary circuit as a your tester. But don't spend any more time making everything perfect: you are getting 1/t returns on your time on this one. You'll want to box it up and make a yellow Styrofoam insulator box to shield it more from room temp changes.
I measured transmission RIN before the beatnote measurement. Unfortunately, we can not compare with earlier intensity noise measurement I took because I didn't take transmission power measurements then.
These measurements were taken in 4 steps of frequency ranges and stitched together. See the attached notebook for further details.
I used the same measurement method as explained in (PSL:2272). Following are some experiment state measurements I made:
~ 130 MHz
PMC Reflection RFAM
(@ PMC loop RFPM frequecy)
@ 21.5 MHz
@ 14.75 MHz
Cavity Reflection RFAM
(@ PMC loop RFPM frequency)
< -77 dBm
(@ FSS loop RFPM frequency)
@ 36 MHz
@ 37 MHz
(@ 2x PMC loop RFPM frequency)
< -87 dBm
@ 43 MHz
@ 29.5 MHz
Note: I also found that half waveplate behind North FSS EOM had no marked order and was probably multi-order. I replaced it with a zero-order half waveplate and found significant improvement in RFAM at Cavity Reflection RFPD. Above mentioned numbers were taken after this change.
I'm still using the old code here as there are some unresolved questions with the new code I want to be sure about first.
It would be a good time to retake the BN + cross spectrum with RIN to see if these improvements squash the 3 kHz hump. You'll probably want to recheck the RFAM levels immediately before retaking the BN in case there has been any drift. When plotting the RIN you should include a trace that quantifies the dark noise of the PDs and the shot noise. The traces are not much use if they are limited by either of these, the elog readers would benefit from having such traces as a bench mark.
A good thing to do, as well, would be to resurrect the AEOM power controls in both paths. You can then use a swept sine to take a transfer function from intensity noise to beat note directly without just relying on the residual RIN of the laser*. This will help you model the expected real TF from intensity noise to frequency noise (for the noise budget) and help justify the design choices of the ISS (how far along is the ISS BTW?). It also lets you know the susceptibility of each path to RIN, regardless of the performance differences between the two laser. Maybe its also possible to fine tune the offsetting on the FSS PDH controls by watching the transfer function live and adjusting the DC offset to minimize Intensity->FSS->Freq Noise conversion. The offsets and gains on the FSS loop are now more or less arbitrary, this is something you can try next time you tweak up these loops.
THe AEOMs should be configured with s-polarized light (vertical) going into the modulator with a quarter-wave plate, followed by a PBS at the output. Adjust the quarter-wave plate to get yourself to 50:50 splitting, this gives you the maximum W/V slope with close to linear response. You'll need to adjust upstream powers accordingly to give you 1.5 mW at the input of the RefCavs. Be aware of how hard you are driving the modulators so that you are sure that it is in the linear regime. Terminate AEOMs when not in use.
* It would also be nice to have a tap off somewhere (<10%) to be able to sample the pre-cavity RIN. Given that any BS/ wedge you insert will misaligned the beams it will be a 0.5 day exercise to realign cavities etc, thus mid-low priority.
I think I found the culprit. the polarizer behind the EOM (PMC loop EOM) was a multi-order one and hence was extremely sensitive to temperature. I replaced it with a zero order half wavepleate and realigned the EOM to minimise the RF AM to about -70 dBm. The PMC has got misaligned in this procedure, so tomorrow I'll align it back and see if our changes made a difference.
We measured the modulation index of 0.142 rad when we installed the PMC (See PSL:2251). I checked both PMC loops, none of them are oscillating.
I think I understand now what is happening. The Amplitude modulation from EOM behind the PMC is about -21 dBm . From Evan's earlier calculations , this RF AM should be suppressed by 0.02 only since it is at 14.75 MHz. This corresponds to -34 dB and hence we are seeing a 29.5 MHz amplitude modulaion ahead of about -55 dBm. There is some mechanism which is frequency doubling this modulation and we are seeing it at 29.5 MHz after the PMC.
I think I will try reducing this RFAM with a combination of PBS and tuning both polarizer and EOM angles. But if we had an extra resonant 21.5 MHz EOM and RFPD, this problem would completely go away as PMC will be able to reduce the RFAM more effectively there.
I found this paper on OSA: Control of residual amplitude modulation in Lithium Niobate phase modulators. It suggests a control mechanism which does not require controlling the temperature. The main point in it is that if a DC offset is present in the RF signal going into the EOM, it is effectively the same as changing the temperature by some amount. So, in principle, by changing the DC bias of the RF signal with a bias-tee just before the EOM, one can minimize the RF AM modulation. The paper though doesn't suggest the feedback mechanism or what sensor would be good for this. If we think this is worth giving a shot, in my opinion, if we fork the output of EOM somehow, measure the RFAM through it and employ a feedback circuit to control the DC offset, we can actively suppress the RFAM. Just a thought at this moment.
Just after writing above, I realized people at JILA have done something similar (with more complexity though):
Reduction of residual amplitude modulation to 1 × 10-6 for frequency modulation and laser stabilization
Is this the resonant EOM or a BBEOM driven with an external circuit? The driving requirements are different, if you overdrive you'll get a bunch of higher harmonics.
Maybe check the modulation depth, make sure it isn't too excessive. Beta=0.3 should be enough. Error signal Vpp = (where P0 is the incident power, and G is the PD + mixer gain. Just make sure beta it isn't excessive in producing significant higher order components.
You want to figure out if the 29.5 MHz harmonic feature is an electrical cross coupling or optical. Check your cable routing, are you getting any cross coupling pickup from collocated coaxial lines? Pretty sure we got the mode cleaner PDH demodulation stuff right, but check mixer is right power level with 4th order LP filter + 50 ohm termination on input side of the LP filter with a RF compatible T-junction.
Also, looking back at the design documents for the PMC, it looks like the nominal design frequency considered was ~30 MHz modulation. Have a look Evan's earlier calculations, especially with respect to HOM suppression. It looks like for 30 MHz the 60 MHz harmonic is in a relatively low transmission point for HOM. If the issues are optical artifacts transmitted it might be HOM... you can always up the frequency to something closer to 30 MHz.
Take all of the above with a grain of salt. Consider how much time to sink into it based on whether you think its actually driving a noise source in the system. Eliminating this 14.75 MHz harmonic may be in the basket of diminishing returns for your time. The 36 MHz and 37 Mhz AM components are a much bigger concern for FSS related coupling of RIN into frequency noise.
I hooked up an HP8560E to RF port of the South FSS Refl RFPD. I unlocked laser from the cavity and brought it to a place which seemed far away from any mode of the cavity.
I was hoping to see a peak at 37 MHz which is PDH modulation frequency of FSS on this path. To my surprise, signal level was ~-80 dBm only at 37 MHz. On zooming out, I saw a 29.5 MHz peak instead of about ~-55dBm. @9.5 MHz is second harmonic of the modulation frequency for South PMC PDH loop. This seemed weird as sidebands of EOM before PMC should not reach after PMC. So I have taken noted some preliminary numbers for future. This isn't complete analysis:
All data was taken with a span of 50 MHz. Note how on changing the frequency offset, I got a offset point where 37 MHz Peak almost disappears but the 29.5 MHz peak is present irrespective of the frequency. Need to investigate more.
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.
Thu Jan 10 14:31:56 2019, in reply 2278
It is a resonant EOM.
I measured RIN of the two paths yesterday through taking spectrum of transmission PDs and measured cross-correlation with the Beatnote.
From the plots attached, it is clear that RIN of both paths have a peak near 3 kHz but the south path has excessive RIN in comparision to North parth and has much more coherence with BN. I'm looking into possible RF AM in south path.
Edit Wed Jan 16 14:08:03 2019 :
I forgot to convert the noise spectrum measured to laser power spectrum earlier. I am also realizing now that I should have measured the transmitted power to get the RIN. So this measurement only provides Intenisty (or Power) noise of transmitted lasers. I'm attaching the fixed plot now.
Over the break, the test of Vacuum Can Temperature Sensors transimpedance circuit was running and fb4 has logged the values. PFA time series data from fb4. See PSL:2270 for experiment details.
As seen in timeseries data, something is wrong in Ch2 data as it is fluctuating too much arbitrarily. I'll see what went worng in this particular circuit. Thankfully, I had an extra circuit on same board which is recorded in channel 3 so that we can compare the channels.
Edit: Fri Jan 11 11:24:11 2019
Added lighter plots. The plots now have mean value (averaged over 1 minute of data) with the shaded region showing one sigma uncertainty region. I've added the jupyter notebook in .zip file.
That roll up in the HF range to 3 kHz hump looks suspect.
We need to check that we're actually implementing the PLL properly and unwrapping the BN PSD properly from the actuation signal. You could end up from a result like this if the UGF was, say, ~ 1 kHz: then the PSD * (marconi slope) approximation will no longer be true and would look more like PSD * (marconi slope + 1/Mix*SR560). As demodulation for PLL frequency gives a 1/f in closed loop (from freq->V_out), this would give a roll up directly proportional to frequency around and above UGF when inverting. We should go back and check again that the transfer function measured yesterday of the PLL had a UGF of >60 kHz. You should remeasure the PLL open loop gain and post it on the elog. Make sure you use a small excitation signal and play around with the cycle averaging settings to smooth out noise for a nice clean trace. Also a schematic of exactly where signals are injected, values of gains, slopes and mixer conversion efficiencies (spec sheet value will do) and RF power from beat note detector.
You'll also way to check that you're not saturating the NF1811. You don't want weird artifacts from not being linear in response at RF... slew rate limit etc. Details of internals of NF1811 can be found in the PSL Electronics Wiki.
Also see figure 4.8 of Tara's thesis. I'm having trouble making out the colours but there is peaking there in the marconi frequency noise at around 3 kHz. This plot places the 10 kHz/V modulation slope as being clear by at least an order of magnitude. Always be suspicious. Are our macnoni's still performing? Add this to the moderate-to-low-priorities list of things to check.
The BN PSD doesn't extend high enough to compare fully to all the others but if we find that the PLL -> BN is correct then maybe this is an old problem related to excess AM from the 36 MHz and 37 MHz EOMs producting AM and PM. See PSL:2083 and related backlinks. In particular we want to know if the laser RIN has some coherence with the BN. See what Evan did in PSL:1524. Before screwing around with optimizing the AM (maybe a 1-2 day task) figure out how you can use the transmission signals to get a RIN of both cavities and make a coherence plot. This would be your smoking gun. After that maybe look into whether you should sink time into optimizing RF AM and ISS.
Checking RIN and coherence with the beat note is maybe a 1/2 day task once everything is locked up and working.
Also, put those thermal hats back on those EOMs. Its winter, have a heart.
ws1 is unable to read and write on some EPICS channels while I can see these channels in fb4 or acromag1. These channels are:
I'm not sure what is causing this. I have rebooted cromag1 several times but this problem persists. Interestingly, there are a lot of channels which are getting updated on medm screens so the origin of the problem is probably localized to a single .db file. But everything looks fine to me, at least after first few debugging trials.
Well, because of this, it is impossible almost impossible to even manually tune the beatnote frequency to the required point. I'll first fix this because it seems like an error which shouldn't be ignored. Suggestions are welcome as I am new to EPICS-Modbus-upstart-docker things and might be missing something silly.
Yesterday, I put two boards of LIGO-D1800304 with two pairs of circuits populated in each of them for testing.
As of today, I see that all sensors have reached a temperature which is within the sensing range of boards. However, I see different readings on them, probably due to different actual resistor value on each copy of circuit. The channels are being saved by fb4. I'll pull out time series data after some more time when we can safely assume that everything has thermalized. The fluctuations in the difference of these signals would tell us about environmental coupling and the board noise and precision itself.
From the review of PSL:2266 and the promises I made in PSL:2267, I think I have fixed the circuit. Corrected schematic is at DCC LIGO-D1800308-v1.
I also made a proof-of-principle circuit on a breadboard. It has only one channel (25 ) and uses different chips but same principle. Following were the replacements:
The circuit produced meaningful and predictable node voltages. So hopefully, this circuit is correct. Only remaining thing is to characterize noise and drift properties which would be done once the actual parts arrive.
I'll look into it but since the numbers work out for us for now (fortunately), I'll keep it at a lower priority. Having a good science reason will be good, I agree.
I couldn't think of a strong argument against having extra channels. Plus we don't really know what temperatures the cavities go to (and will go to with new heat shield on). So for the first version at least, I wanted to keep extra channels and decide this answer in the future.
Unfortunately, I think the present version won't really work without a lot of ugly scratches on the pcb. I messed up this one. Thanks to JLCPCB, getting boards is cheaper and faster now. So I'll get to this right away to avoid Christmas delays.
I don't know if I'm missing it, or if you've yet to add it, but can't see current excitation into the RTD. I remember you were looking into REF200 and some other voltage-> current highly stable sources (PSL:2264), that part will be key to actually getting a high precision temperature readout. I didn't understand how the op amp stage in your schematic (PSL:2264) worked; it looks like you pinned the inverting input to ground but then also connected the output pin for feedback. Doesn't really make sense to me.
Do you want something more like this: technical note. There they use the op amp to bootstrap the voltage reference so that the actual applied voltage rises to whatever is necessary to get the design current fixed through the reference resistor AND sink it through the load. The point of the that design is that the resistance of the sensor and its cabling does not affect the current: current is set only by the reference resistor. The stablity of the excitation current will hinge on the goodness of the voltage reference and that of the reference resistor.
Also, as a side note, you were proposing a 5V reference. I thought I read somewhere that the standard buried zenor reference in these types of voltage references were actually typically 7 V and the 5 V and 10 V versions some how stepped up/down using a precision resistor network buried within the chip. My understanding was that 7V references were the best because there was no additional drift. If the specs of the MAX6325 are good, then maybe its well compensated and its nothing to worry about. It might be worth checking if that series of chips has other discreet voltage options that perform better.
Its a good idea to add about 100 Ω (or more) of resistance to output of OP27s. Otherwise poor little chips are going to overdrawn in current for low impedance loads. Probably won't break them, but it will produce bogus voltages. The acromags are 10 kΩ impedance but you can never predict if someone is going to plug in a 50 Ω oscilloscope at some point. Check what max current of OP27 is and adjust so that at full range you wont be overdrawing with 50 Ω load.
RTD is pinned to ground on one side. Not sure what your intending for the wiring scheme here? 3 wires, 4 wires. Ideally you want to excite current through two wires and read back voltage drop across another two. But if you're pinning one side to ground then you've already effectively reduced it to a three wire scheme: ok but not best. I guess you want to think about how this scheme is going to minimize your uncertainty/sensitivity with respects to wiring (see maybe this). Four wires is best. Be best.
Also are we going to miss out on the excellent CMRR of the instrument amplifier if it isn't a truly differential readout on the front end of the circuit?
You've looked at a bunch of numbers for choice of RTD resistance @ 25 C. From the numbers we looked at 1 kΩ seemed like the best for order 100 µA excitation (this is the break point with Johnson noise). It might be nice to have a plot or a table that shows the tradeoff off of sensing SNR (for various noise sources) for different choices of RTD nominal resistance, i.e. 100 Ω, 1 kΩ, 5 kΩ, 10 kΩ. The excitation current and resistance determine the tradeoff points and the right choice is the one that gets below/close to the nominal input referred noise of available pre-amp stages. That would be good for framing a good science reason for choosing a particular RTD (with a particular slope).
Still not sure you need so many channels. If we already have a good idea of the operating range, then a one high precision channel will do. We are almost certainly not going to need all that dynamic range and changing resistors is easy.
The second stage of the amplifier for temperature sensor would be subtractor circuits using OP27G.
I'm attaching calculations done in the jupyter notebook as zip file.
Wed Dec 19 17:13:14 2018
Refer this only for the calculations. Use the updated schematic at DCC.
I have designed a circuit for using RTDs for sensing temperature of the cavities.
Previously REF200 has been used for driving the RTDs. It is quite noisy and we can make a better current source using a good voltage reference chip and a FET opamp. PFA circuit schematic.
Following is some comparison to highlight improvements:
* 1k Platinum RTD is assumed (link).
** 20k resistor used in the schematic is 0.01% tolerance and 0.2ppm/K TCR metal foil resistor.
I searched through various places to hunt for an instrumentation amplifier for our low noise and low-temperature drift requirements. I also checked equivalent features of instrumentation amplifiers made with various low noise opamps. See attached LISO+LTSpice analysis results. I have come to the conclusion to use AD8429BRZ for our purpose because of being single chip and low drift (AD8421BRZ is the best but it is not available until february. But I suggest future people to use AD8421BRZ). Following are some key features:
Edit Wed Dec 19 17:20:03 2018
I soldered a prototype board implementing the transimpedance circuit I, Andrew and Rana discussed earlier.
PFA the schematic and picture of the board.
Voltage rail: +- 15V
Transimpedance: Rated:16.549 kOhms (15k+1.05k+499)
Measured: 16.99 kOhms
Vol Ref; LT 1021DCS8-5 (Actual circuit would have ADR4550ARZ)
Measured voltage at Vol Ref Output: 5.003 V
Measured output at Room Temperature: 8.48 V
Temperature from the measured output: 299.005 K (25.9 )
It was certainly colder than that. I had no other good temperature reference.
Highest output on waving a hot air gun above circuit: 9.15V
Error in temperature perception from that: 358.5 mK
For measuring room temperature, I first dabbed the AD590 with little-wet tissue to cool it down. This was done to make sure no remnant heat from previous runs is remaining. Then I put the AD590 inside a shallow metal drawer opposite the soldering bench and waited for some time to let the reading settle. I assumed the metal drawer must be in equilibrium with room temperature and must have high heat capacity to work as a good room temperature bath for AD590.
When seeing the changes due to circuit temperature change, I waved a hot air gun over the circuit so that hot air blows over the circuit and not onto it. The temperature of the hot air gun was 110 with the highest speed setting. I have no exact knowledge of how much circuit temperature I increased but it got pretty hot to touch by the time I reached a ceiling in how much output value is changing (about 9.15 V)
I think I should go ahead with designing a layout of the circuit. There is only so much we can do in the design of the circuit itself. I have chosen 0.2ppm/K resistors for transimpedance to reduce our major source of drift. For voltage reference, since we are getting more precise ones in the same cost, I chose ADR4550ARZ (BRZ version on Digikey was out of stock) which has lower output voltage noise than LT1021. I have also ordered thin film resistors for the adder stage to completely eliminate the effect of drift from them.
Framebuilder has been down for months now. It looks like I've been able to get it up and going again albeit with the same issues of drifting clock from before.
I restarted the TCS lab framebuild computer (fb4) that is supposed to be recording all our PSL lab channels. It seems that the daqd process was hung on something. After poking around a bit I found that a large proportion of channels have been renamed, maybe requests to dead channels was overwhelming it. I used Craig's python channelFramebuilderConfigFileCreator.py script (see PSL:2133) to regenerate all channels into a .ini file used by cds, copied the output to them to /opt/rtcds/caltech/c4/chans/daq/C3CTN.ini and restarted.
Framebuild is now back and recording all channels (except modecleaner channels) with a UTC time that is 2h 20 m too slow. Otherwise we are now collecting data that will be useful in assesing goodness of vacuum can temperature control.
To fix the time drift issues we need to get GPS stablized timing waveform into the daq
Someone else needs to do this. Maybe a secondary project for Gupta.
I'm summarizing the analysis of Awade and Zach (40m:8125 and ATF:1752) in the context of the specific application of transimpedance amplifier for the AD590 temperature sensor.
AD590 datasheet says that it has input current noise density of without mentioning the frequency of this value or corner frequency (or any plot showing this data).
I did a liso analysis with a simple transimpedance circuit of transimpedance = 16667 Ohm and tried all the above opamps. Attached is input referred noise calculated by total output voltage noise density divided by the transfer function of the circuit.
It is clear from this analysis that we would be comfortable below with OP07, LT1012, OPA827, and OPA140. So to choose a particular opamp, we need to look into offset voltage and current drift of these opamps. The voltage offset drifts do not matter much as 1 uV/K translates to 60 uK/K of temperature readout difference per kelvin change in chip temperature. We need to achieve stability up to mK only. The current offset drift of 1pA/K translates as 1uK/K of temperature readout difference per kelvin change in chip temperature. So with given values, in my opinion, even current offset drift does not matter much. But it would be good to have low current offset and bias current features of FET inputs. So the winner is chosen as OPA827.
I'm attaching .fil and notebook file of the analysis in .zip file as well.
Edit: Wed Dec 5 15:39:29 2018
Adding one more calculation here. Assuming that the resistor used is thin film resistor with 50 ppm/K thermal drift, drift in transimpedance would be (1.6k*50e-6) Ohm/K. Then 1 K change in resistor temperature will look like:
15 mK change in perceived temperature. So this is the most important factor for us and we need to use the least possible thermal coefficient resistor available with very good insulation of the circuit. On Digikey, I'm seeing a minimum of 10ppm/K resistor for 1.65kOhm value. This should give us 3mK change per K change in resistor temperature. I'll look further if we can get even better resistors.
We have come to the conclusion that to properly tune PID, we need to accurately model a physical system that represents the cavity thermodynamics and use it to tune PID coefficients. For this, we need good temperature sensors on the cavity (not present right now) and better heat actuation with known control. Awade also mentioned that we have new gold plated heat shields ready to be installed. So we have decided to replace the heat shield and install new temperature sensors as well. Following is the plan of action for the same:
Hopefully, by the end of this work, we get better stability on beatnote frequency locking to get good spectrum reading at higher resolution from Marconi.
seems a little too much like hunt and peck. Don't you have a time domain simulation of the plant? If not, why not?
From the configuration run (see PSL:2257), I estimated some new PID coefficients. I left PID on for the long weekend with the new coefficient with the initial point about 5 MHz off from lock set point. Apparently, the system never converged (see the orange trace in attached screenshot of StripTool). It instead kept oscillating.
At this point, it seems that maybe the PID control won't work good enough. We need to keep beatnote frequency within 10kHz of setpoint to reach desired resolution range and avoid jumps in Marconi. We either need a new way of temperature control, or if PID works nearby setpoint with no hard changes, we need to reach there with almost zero slope.
This week I started working on a new method to drive the frequency to setpoint with near to zero first derivative. The purpose of this method is to reach close enough to setpoint in a calm manner so that PID can function nicely. If it works out better, it can be used as primary control near setpoint as well.
There would be three codes working together to achieve temperature driving (and/or control).
This plan is in an infant stage. We might need to change a lot of things and models depending on what data is acquired. So, for now, to reduce development time (with a possible chance of failure), I've only incorporated the DataMiner code which is on Git/cit_ctnlab/ctn_scripts/ now. I've also written a DataMinerHelper.py which spans the actuation space slowly while keeping frequency in range so that good knowledge data can be mined. These two codes are near final release.
Depending on what the knowledge data looks like, we will decide if we should go further with this plan. Until then, I'll work on noiseBudget code again.
I have reconfigured the ufc-6000 to have a sampling rate of 0.1 Hz which is minimum possible from design. I have changed ufc2.py to make sure it is set to this sampling rate everytime we read precavity beatnote frequency data.