We measured the MC coil driver noise at the output monitors of the coil driver board with an SR785 in order to further diagnose the excess IMC frequency noise.
Attachments 1 and 2 show the noise for the UL coils of MC3 and MC2 with various combinations of output filters engaged. When the 28 Hz elliptic filter is on, the analog dewhitening filter is off, and vice versa. The effect of the analog low pass filter is visible in MC3, but the effect of the digital low pass filter is swamped by the DAC noise.
We locked the arms and measured the ALS beatnote in each of these filter combinations, but which filters were on did not effect the excess IMC frequency noise. This suggests that the coil drivers are not responsible for the excess noise.
Attachment 2 shows the noise for all five coils on MC1, MC2, and MC3 as well as for ITMY, which is on a different DAC card from the MCs. All filters were on for these measurements.
Why is MC2 LR so different from the others???
The previous measurements were made from the coil driver output monitors. To investigate why the MC2 LR coil has less noise than the other coils, I also measured the noise at the output to the coils.
The circuit diagram for the coil driver board is given in D010001 and a picture of the rack is on the 40m wiki here. The coil driver boards are in the upper left quadrant of the rack. The input to the board is the column of LEMOs which are the "Coil Test In" inputs on the schematic. The output monitors are the row of LEMOs to the right of the input LEMOs and are the "FP Coil Volt Mon" outputs on the schematic. The output to the coils "Coil Out" in the schematic are carried through a DB15 connector.
The attachment shows the voltage noise for the MC2 LR coil as well as the UL coil which is similar to all of the other coils measured in the previous measurement. While the LR coil is less noisy than the UL coil as measured at the output monitor, they have the same noise spectrum as measured at the output to the coils themselves. So there must be something wrong with the buffer circuit for the MC2 LR voltage monitor, but the output to the coils themselves is the same as for the other coils.
I was preparing a short write-up / test procedure for the custom HV coil driver, when I thought of something I can't resolve. I'm probably missing some really basic physics here - but why do we not account for the shot noise from DC current flowing through the series resistor? For a 4kohm resistor, the Johnson current noise is ~2pA/rtHz. This is the target we were trying to beat with our custom designed HV bias circuit. But if there is a 1 mA DC current flowing through this resistor, the shot noise of this current is 18pA/rtHz, which is ~9 times larger than the Johnson noise of the same resistor. One could question the applicability of this formula to calculate the shot noise of a DC current through a wire-wound resistor - e.g. maybe the electron transport is not really "ballistic", and so the assumption that the electrons transported through it are independent and non-interacting isn't valid. There are some modified formulae for the shot noise through a metal resistor, which evaluates to 10pA/rtHz for the same 4kohm resistor, which is still ~5x the Johnson noise.
In the case of the HV coil driver circuit, the passive filtering stage I added at the output to filter out the excess PA95 noise unwittingly helps us - the pole at ~0.7 Hz filters the shot noise (but not the Johnson noise) such that at ~10 Hz, the Johnson noise does indeed dominate the total contribution. So, for this circuit, I think we don't have to worry about some un-budgeted noise. However, I am concerned about the fast actuation path - we were all along assuming that this path would be dominated by the Johnson noise of the 4kohm series resistor. But if we need even 1mA of current to null some DC DARM drift, then we'd have the shot noise contribution become comparable, or even dominant?
I looked through the iLIGO literature, where single-stage suspensions were being used, e.g. Rana's manifesto, but I cannot find any mention of shot noise due to DC current, so probably there is a simple explanation why - but it eludes me, at least for the moment. The iLIGO coil drivers did not have a passive filter at the output of the coil driver circuit (at least, not till this work), and there isn't any feedback gain for the DARM loop at >100 Hz (where we hope to measure squeezing) to significantly squash this noise.
Attachment #1 shows schematic topologies of the iLIGO and proposed 40m configs. It may be that I have completely misunderstood the iLIGO config and what I've drawn there is wrong. Since we are mainly interested in the noise from the resistor, I've assumed everything upstream of the final op-amp is noiseless (equivalently, we assume we can sufficiently pre-filter these noises).
Attachment #2 shows the relative magnitudes of shot noise due to a DC current, and thermal noise of the series resistor, as a function of frequency, for a few representative currents, for the slow bias path assuming a 0.7Hz corner from the 4kohm/3uF RC filter at the output of the PA95.
Some lit review suggests that it's actually pretty hard to measure shot noise in a resistor - so I'm guessing that's what it is, the mean free path of electrons is short compared to the length of the resistor such that the assumption that electrons arrive independently and randomly isn't valid. So Ohm's law dictates and that's what sets the current noise. See, for example, pg 432 of Horowitz and Hill.
In the IMC actuation chain, it looks like the MC1/MC3 de-whitening boards, and also all three MC optics' coil driver boards, are showing higher noise than expected from LISO modeling. One possible candidate is thick film resistors on the coil driver boards. The plan is to debug these further by pulling the board out of the Eurocrate and investigating on the electronics bench.
Why bother? Mainly because I want to see how good the IR ALS noise is, and currently, the PSL frequency noise is causing the measurement to be worse than references taken from previous known good times.
Sometime ago, rana suggested to me that I should do this measurement more systematically.
I've now restored all the wiring at 1X6 to their state before this work.
I wanted to investigate my coil driver noise measurement technique under more controlled circumstances, so I spent yesterday setting up various configurations on a breadboard in the control room. The overall topology was as sketched in Attachment #1 of the previous elog, except for #4 below. Summary of configurations tried (series resistance was 4.5k ohm in all cases):
Attachment #1: Picture of the breadboard setup.
Attachment #2: Noise measurements (input shorted to ground) with 1 Hz linewidth from DC to 4 kHz.
Attachment #3: Noise measurements for full SR785 span.
Attachment #4: Apparent coupling due to PSRR.
Attachment #5: Comparison of low frequency noise with and without the LM6321 part of the fast DAC path implemented.
All SR785 measurements were made with input range fixed at -42dBVpk, input AC coupled and "Floating", with a Hanning window.
Today I found one of the coil driver boards, S2100619 failed the test on CH2. There appears to be an extra phase lag after 10 kHz and some resonant-like feature at 7 kHz. This of course is very high-frequency stuff and maybe we don't care about these deviations. But it could mean something is off with the channel and could potentially lead to failure in the relevant frequency band in the future. I'll need help to debug this. Please see the attachment for details of test failure.
Good catch. It turned out that the both + and - side of the output stages for CH2 were oscillating at ~600kHz. If I use a capacitance sticks to touch arbitrarily around the components, it stops their oscillation and they stay calm.
It means that the phase margin becomes small while the circuit starts up.
I decided to increase the capacitances C6 and C20 (WIMA 150pF) to 330pF (WIMA FPK2 100V) and the oscillation was tamed. 220pF didn't stop them. After visually checked the signal behavior with an oscilloscope, the unit was passed to Anchal for the TF test.
The modification was also recorded in the DCC S2100619
Koji and I had a discussion last Friday about the suspension electronics. I think there are still a few open questions - see Attachment #1. We should probably make a decision on these soon.
Other useful links:
Looking at the signals to the test mass coils, it seems borderline to me that we will be able to acquire lock and run in a low noise configuration with the same series resistor in the coil driver circuit. The way I see it, options are:
I only looked at the ETMs for this study. The assumption is that we will have no length actuation on the ITMs, only local damping and Oplev loops (and maybe some ASC actuation?), which can be sufficiently low-pass filtered such that even with coil de-whitening, we won't have any range issues.
Attachment #1 shows the time-domain traces of the coil driver signals as we transition from POX/POY lock to the ALS lock. There are some transients, but I think we will be able to hold the lock even with a 5 kohm resistor (~twice what is on ETMX right now). From just these numbers, it would seem we can even go up to 10 kohms right away and still be able to acquire lock, especially if we re-design the digital feedback loop to have better low-pass filtering of the high-frequency ALS noise, see the next attachment.
Attachment #2 shows the f-domain picture, once the arm lengths are fully under ALS control (~25 seconds onwards in Attachment #1). The RMS is dominated by high frequency ALS length loop noise, which we can possibly improve with better design of the digital control loop.
Finally, Attachment #3 shows the situation once DARM control has been transitioned over to AS55_Q. Note that the vertex DoFs are still under 3f control, so there is the possibility that we can make this even lower noise. However, one thing that is not factored in here is that we will have to de-whiten these signals to low-pass filter the DAC noise (unless there is some demonstrated clever technique with noise-mons or something to subtract the DAC noise digitally). Nevertheless, it seems like we can run safely with 5 kohms on each ETM coil and still only use ~2000 cts RMS, which is ~1/10th the DAC range (to allow for dealing with spurious transients etc).
Looking at signals to the ETMs from the current lock acquisition sequence, the RMS current to a single coil is approximately _____ (to be filled in later).
To re-cap, every time I tried to do this in the last month or so, the optic would get kicked around. I suspected that the main cause was the insufficient low-pass filtering on the Oplev loops, which was causing the DAC rms to rail when the whitening was turned on.
I had tried some loop-tweaking by hand of the OL loops without much success last week - today I had a little more success. The existing OL loops are comprised of the following:
THe elliptic low pass was too shallow. For a first pass at loop shaping today, I checked if the resonant gain filter had any effect on the transmitted power RMS profile - turns out it had negligible effect. So I disabled this filter, replaced the elliptic low pass with a 5th order ELP with 2dB passband ripple and 80dB stopband attenuation. I also adjusted the overall loop gain to have an upper UGF for the OL loops around 2Hz. Looking at the spectrum of one coil output in this configuration (ITMY UL), I determined that the DAC rms was no longer in danger of railing.
However, I was still unable to smoothly engage the de-whitening. The optic again kept getting kicked around each time I tried. So I tried engaging the de-whitening on the ITM with just the local damping loop on, but with the arm locked. This transition was successful, but not smooth. Looking at the transmon spot on the camera, every time I engage the whitening, the spot gets a sizeable kick (I will post a video shortly). In my ~10 trials this afternoon, the arm is able to stay locked when turning the whitening on, but always loses lock when turning the whitening off.
The issue here is certainly not the DAC rms railing. I had a brief discussion with Gabriele just now about this, and he suggested checking for some electronic voltage offset between the two paths (de-whitening engaged and bypassed). I also wonder if this has something to do with some latency between the actual analog switching of paths (done by a slow machine) and the fast computation by the real time model? To be investigated.
GV 170628 11pm: I guess this isn't a viable explanation as the de-whitening switching is handled by the one of the BIO cards which is also handled by the fast FEs, so there isn't any question of latency.
With the Oplev loops disengaged, the initial kick given to the optic when engaging the whitening settles down in about a second. Once the ITM was stable again, I was able to turn on both Oplev loops without any problems. I did not investigate the new Oplev loop shape in detail, but compared to the original loop shape, there wasn't a significant difference in the TRY spectrum in this configuration (plot to follow). This remains to be done in a systematic manner.
Plots to support all of this to follow later in the evening.
Attachment #1: Video of ETMY transmission CCD while engaging whitening. I confirmed that this "glitch" happens while engaging the whitening on the UL channel. This is reminiscent of the Satellite Box glitches seen recently. In that case, the problem was resolved by replacing the high-current buffer in the offending channel. Perhaps something similar is the problem here?
Attachment #2: Summary of the ITMY UL coil output spectra under various conditions.
Our design kits are full again. They are waiting for a new brilliant PD design.
To obtain a colored version with good contrast of the grayscale image of scattering of light by dust particles on the surface of test mass, got using GigE camera. The original and colored images are attached here.
I want to make changes to c1rfm. Found uncommited changes to it from Sept 27. Since we recompiled it since then it should be safe to commit them, so I did. See svn log for details.
I used a Eurocard extension board to peek at the inputs and outputs of each of the gain-ladder AD829s on input B of the CM board in the +31dB configuration with the input terminated. (i.e with the following stages active in this order: +16dB, +8dB, +4dB, +2dB, +1dB).
The voltages I observed imply that the +8dB stage has an input voltage offset of -2mV, whereas all the other positive gain stages show around +-0.5mV. This could explain the shift observed at the +15->+16 transition. (However, since both input channels show a jump here, maybe its something more systemic about the board...)
In any case, it should be simple enough to swap out a new AD829 in place of U9B and see if it improves things, before getting too deep into the muck. (In principle, the AD829 has offset nulling pins, but I'm not sure how to do it in a non-hacky way since the board doesn't have any pads for it.)
I replaced some of the AD829s with other AD829s, but the offset situation didn't improve.
However, I figured that we don't really need the ~100MHZ bandwidth of the AD829, since the IMC loop limits us to a ~10kHz CARM bandwidth. Also, since we don't routinely use IN2 for anything, I felt free to try something else.
Specifically, I replaced all of the positive gain AD829s in the input 2 gain ladder with OP27s (U8B->U12B on D1500308), which should have input offset voltages ~30x lower than the AD829s.
Here is a comparison of the outputs these configurations perform, normalized to the output at the +0dB gain setting - where all of the op amps in the gain ladder are bypassed.
So, most of the transitions now result in an output offset change of less than 0.5mV, which is nice.
The exception seems to be where the +8dB stage is switched in or out. I may try replacing this one, as these transitions cause a lock loss now when trying to lock the arm with high bandwidth using POY.
I realized I totally forgot to post this last week, but I prototyped the comparator and boost triggering portion of the ISS, at least in part. Below is a schematic that shows the prototype circuit I made. Note that it includes ports for the oscilloscope channels that appear in the second image included. Essentially, I was able to verify that the output from the LT1016, as it's currently constructed in the ISS schematic, would be sufficient logic to switch the MAX333a.
Below, we can first see that the comparator is switching its output as desired. When the DC level of the input drops below a certain threshold (~1.6 V) the output of the comparator switches on to ~4 V. When the DC level of the input goes back up above the upper threshold (~3.2 V), the comparator switches off to ~0.3 V. The exact values of the threshold voltages can be determined/tuned at a later date, but this is the basic behavior that the comparator circuit will have.
To detect whether or not the MAX333a was switching properly, I connected the common terminal of one of the switches to a +5 V supply, and looked at the voltage coming off both the 'open' and 'closed' terminals of said SPDT switch. We can see that with Logic 0 (comparator output ~0.3 V) Channel 4 exhibits a ~5 V signal, just as we would expect from the above schematic. With Logic 1 (comparator output ~4 V), Channel 3 exhibits the characteristic 5 V signal.
Comparison between Hamamatsu S3399 and Perkin Elmer FFD-100
These are the candidates for the BB PD for the green beat detection as well as aLIGO BB PD for 532nm/1064nm.
FFD-100 seems the good candidate.
Basic difference between S3399 and FFD-100
- S3399 Si PIN diode: 3mm dia., max bias = 30V, Cd=20pF
- FFD-100 Si PIN diode: 2.5mm dia., max bias = 100V, Cd=7pF
The circuit at the page 1 was used for the amplifier.
- FFD-100 showed 5dB (= x1.8) larger responsivity for 1064nm compared with S3399. (Plot not shown. Confirmed on the analyzer.)
- -3dB BW: S3399 180MHz, FFD-100 250MHz for 100V_bias. For 30V bias, they are similar.
I made some progress in modeling MICH loop.
Putting all the LSC and SUS filters together with the MICH Finesse model I constructed an OLTF model and plot it with the measurement done by Paco and Yuta in this elog (attachment 1).
There are 2 unknown numbers that I had to adjust in order to fit the model with the measurement:
1. The SUS damping loop gain (found to be ~ 2.22), which seems to vary wildly from SUS to SUS.
2. The coil driver gain (found to be 45), which I should measure.
I find coil_driver_gain*SUS_damping_filter_gain by increasing it until the SUS damping loop becomes unstable.
The coil driver gain I find by making the measurement and model overlap.
However, there is one outstanding discrepancy between the measurement and the model: Paco and Yuta measure the MICH calibration to be 1.3e9 cts/m while my model shows it to be 1.3e10 cts/m, an order of magnitude larger.
The model can be summarized with these lines of code (I assume that the product of the ADCs(DACs) and and whitening(dewhitening) filters is unity):
BS2AS55 = TFs["AS_f2"]["BS"]
PD_responsivity = 1e3*0.8 #V/W
ADC_TF = 3276.8 #cts/V
demod_gain = 6.77 #According to https://wiki-40m.ligo.caltech.edu/Electronics/LSC_demoddulators
whitening_gain = 10**(24/20) #24 dB
BS2MICH = BS2AS55*PD_responsivity*demod_gain*whitening_gain*ADC_TF
DAC_TF = 6.285e-4 #V/cts, elog 16161
coil_TF = 0.016 #Newton/Ampere per coil, elog 15846
coil_R = 20e3 #Ohm
actuation_TF = DAC_TF*coil_TF/coil_R
OLTF = (BS2MICH*MICH_ctrl_cmplx*-6*0.5 + OSEM_filters_cmplx*OSEM_TF*2.22)*coil_filters_cmplx*actuation_TF*SUS_cmplx*45
I should write down what I didn't include for completeness:
1. AA filters
2. AS55 input 60Hz comb filter
3. Violin filters
After discussing with Paco, we agreed that the discrepancy in the MICH calibration might come from the IQ mixing angle which for the IFO is not optimized, while in Finesse is set such that all the amplitude is in one quadrature.
I'm curious why the actual OLTF included the 60Hz comb...? It is undesirable to have such structure in the OLTF around the UGF as it can cause servo instability.
And if you remove them, you don't need to model them :-)
RFM reads are slow. Rolf has said it should take 2-3 microseconds per read.
c1sus is taking about 7 microseconds per read, twice as slow as Rolf's claim.
The RFM card is in the IO chassis, and is sharing the PCIe bus with 4 ADC cards, 3 DAC cards, 4 BO cards, and a BIO card. Its possible this crowded bus is causing the reads to take even longer.
Compare read times between the c1sus computer, which has its RFM card in the IO chassis, to c1ioo, which has its RFM card in the computer.
No RFM reads: 8 microseconds
3 RFM reads: 20 microseconds (~4 per read)
6 RFM reads: 32 microseconds (~4 per read)
No RFM read: 25 microseconds (bigger model)
1 RFM read: 33 microseconds (~8 per read)
3 RFM read: 45 microseconds (~7 per read)
6 RFM read: Over 62 microseconds, doesn't run.
It looks like moving the RFM card may help by about a factor of 2 in read speed, although its still not quite what Alex and Rolf claim it should be.
The c1mcs and c1ioo models have been reverted to their normal operations.
The values obtained from both analytical and finesse solution is given in the above table along with the corresponding percentage errors.finesse1.pdf
The parameters used for this calculation are listed below.
The cavity scan data obtained from Finesse is also attached here.
Hmm? What is the definition of the percentage error? I don't obtain these numbers from the given values.
And how was the finesse value obtained from the simulation result? Then what is the frequency resolution used in Finesse simulation?
The percentage error which I found out =[(analytical value - finesse value)/analytical value]*100
But inorder to find the finesse value, I just used curser to get the central frequency of each peak and by substracting one from the other I found TMS and FSR.
The resolution was 6500 Hz. Thus, it seems that this method is not actually reliable. I am trying to find the central frequency of each mode with the help of lorentzian fits. I am attaching a fit which I did today. I have plotted its residual graph also.
I am uploading 4 python scripts to the github.
1. Analytical Solution
2. Finesse model- cavity scan
3. Finesse model- fitting
4. Finesse model- residual
Hmm? What is the definition of the percentage error? I don't obtain these numbers from the given values.
And how was the finesse value obtained from the simulation result? Then what is the frequency resolution used in Finesse simulation?
> The percentage error which I found out =[(analytical value - finesse value)/analytical value]*100
Yes, I this does not give us 0.70%
(3.893408 - 3.8863685)/3.893408 *100 = 0.18%
But any way, go for the fitting.
Oopss !! I made a mistake while taking the values from my notes. Sorry.
Over the past 36 hours, I've run full-fledged FDAs on KALLO.
The transfer functions for translational drives and responses are neatly described by the attached transfer function "matrix."
1) Extend the 3x3 analysis to include tilts and rotations in a 6x6 analysis.
2) Figure out how to do the same types of tests for phase instead of displacement.
Please edit this same entry throughout the day for the shutdown elogging.
I took a screenshot of C0VAC_MONITOR.adl to ensure that all pnematic valves are in closed positions:
The status message says "All pnematic valves closed" and the latest error message is about "V7 closed, N2 < 6.50e+01".
I found out that there was no autoburt happening for c1vac channels. I created an autoBurt.req file for the vac.db file and saved one snapshot. I also added the path of this file in autoburt/.requestfilelist . Let's see if autoburting starts by that for this file as well.
With this, I think we can safely shutdown acromag chassis. Hopefully, the relays are configured such that the valves are nominally closed in absence of a control signal. After the chassis is shut down, wwe can shutdown C1VAC by:
At the 1x8 rack, the following were switched off on their respective front panels:
PTP2 & PTP3 Controller
MKS Gauge controller
PRP Gauge Controller
G2P316a & b Controllers
Serial Device Server
Powered off from back of unit:
TP2 and 3 controllers were unplugged from respective power strips (labeled C2 and C3)
C1vac and the laptop at the workstation were shut down
Manual Gate valve was closed
All steps taken have been recorded here:
All spare channels on the PSL acromag chassis are connected with ~12in of spare wiring for future use.
I have finished drawing the circuit diagrams for the quad photodiode boxes. Here are copies of the circuit diagram.
There are three main operation circuits in the quad photdiode box: a summing circuit (summing the contributions from the four inputs),
a Y output circuit (taking the difference between the input sums 3+2 and 1+4), and an X output circuit (taking the difference between the
input sums 3+4 and 1+2). I will complete an mini report on my examination and conclusions of the QPD circuit for the suspension wiki tomorrow.
Single layer of stack successfully modeled in COMSOL. I'm working on trying to add Viton springs now and extend it to a full stack. Having some difficulty with finding consistent parameters to work with.
The ALS error (i.e. phase tracker output) is linear everywhere, but noisy.
The 1/sqrt(TR) is linear and less noisy but is not linear at around the resonance and has no sign.
The PDH signal is linear and further less noisy but the linear range is limited.
Why don't we combine all of these to produce a composite error signal that is linear everywhere and less-noisy at the redsonance?
This concept was confirmed by a simple mathematica calculation:
The following plot shows the raw signals with arbitorary normalizations
1) ALS: (Blue)
2) 1/SQRT(TR): (Purple)
3) PDH: (Yellow)
4) Transmission (Green)
The following plot shows the preprocessed signals for composition
1) ALS: no preprocess (Blue)
2) 1/SQRT(TR): multiply sign(PDH) (Purple)
3) PDH: linarization with the transmission (If TR<0.1, use 0.1 for the normalization). (Yellow)
4) Transmittion (Green)
The composite error signal
1) Use ALS at TR<0.03. Use 1/SQRT(TR)*sign(PDH)*(1-TR) + PDH*TR at TR>0.03
2) Transmittion (Purple)
Very nice error signal. Still, I think we need to take into account the frequency shape of the transfer function TR -> CARM.
True. But we first want to realize this for a single arm, then move onto the two arms case.
At this point we'll need to incorporate frequency dependence.
Using Koji's mathematica notebook, and Nic's python work, I set out to run a time domain simulation of the error signal, with band-limited white noise added in.
Basically, I sweep the displacement of the cavity (with no noise), and pass it to the analytical formulae with the coefficients Koji used, with some noise added in. I also included some 1/0 protection for the linearized PDH signal. I ran a sweep, and then compared it to an ALS sweep that Jenne ran on Monday; reconstructing what the CESAR signal would have looked like in the sweep.
The noise amounts were totally made up.
They matched up very well, qualitatively! [Since the real sweep was done by a (relatively) noisy ALS, the lower noise of the real pdh signal was obscured.]
Given this good match, we were motivated to start trying to implement it on Monday.
At this point, since we've gotten it working on the actual IFO, I don't plan on doing much more with this simulation right now, but it may come in handy in the future...
Extending the previous model, I've closed a rudimentary CESAR loop in simulink. Error signals with varying noise levels are combined to bring a "cavity" to lock.
There are many things that are flat out arbitrary at this point, but it qualitatively works. The main components of this model are:
And it can lock!
Right now, all of the functions and noise levels are similar to the previous simulation, and therefore don't tell us anything about anything real...
However, at this point, I can tune the parameters and noise levels to make it more like our interferometer, and thus maybe actually useful.
The LSC model was modified for CESAR.
A block called ALSX_COMBINE was made in the LSC block. This block receives the signals for ALS (Phase Tracker output), TRX_SQRTINV, TRX, POX11 (Unnormalized POX11I).
It spits out the composite ALS signal.
Inside of the block we have several components:
1) a group of components for sign(x) function. We use the PDH signal to produce the sign for the transmission signal.
2) Hard triggering between ALS and TR/PDH signals. An epics channel "THRESH" is used to determine how much transmission
we should have to turn on the TR/PDH signals.
3) Blending of the TR and PDH. Currently we are using a confined TR between 0 and 1 using a saturation module. When the TR is 0, we use the 1/SQRT(TR) signal for the control,
When the TR is 1, we use the PDH signal for the control.
4) Finally the three processed signals are combined into a single signal by an adder.
It is important to make a consideration on the offsets. We want all of ALS, 1/SQRT(TR), and PDH to have zero crossing at the resonance.
ALS tends to have arbitorary offset. So we decided to use two offsets. One is before the CESAR block and in the ALS path.
The other is after the CESAR block. Right now we are using the XARM servo offset for the latter purpose.
We run the resonance search script to find the first offset. Once this is set, we never touch this offset until the lock is lost.
Then for the further scanning of the arm length, we uused the offset in the XARM servo filter module.
After making the CDS modification, CESAR was tested with ALS.
First of all, we run CESAR with threshold of 10. This means that the error signal always used ALS.
The ALS was scanned over the resonance. The plot of the scan can be found in EricQ's elog.
At each point of the scan, the arm stability is limited by the ALS.
Using this scan data, we could adjust the gains for the TR and PDH signals. Once the gains were adjusted
the threshold was lowered to 0.25. This activates dynamic signal blending.
ALS was stabilized with XARM FM1/2/3/5/6/7/9. The resonance was scanned. No glitch was observed.
This is some level of success already.
Next step was to fully hand off the control to PDH. But this was not successfull. Everytime the gain for the TR was
reduced to zero, the lock was lost. When the TR is removed from the control, the raw PDH signal is used fot the control
without normalization. Without turning on FM4, we lose 60dB of DC gain. Therefore the residual motion may have been
too big for the linear range of the PDH signal. This could be mitigated by the normalization of the PDH signal by the TR.
Today we modified the CESAR block.
- Now the sign(X) function is in a block.
- We decided to use the linearization of the PDH.
- By adding the offset to the TR signal used for the switching between TR and PDH, we can force pure 1/sqrt(TR) or pure PDH to control the cavity.
[Nic, Jenne, EricQ, and Koji]
We have used CESAR successfully to bring the Xarm into resonance. We start with the ALS signal, then as we approach resonance, the error signal is automatically transitioned to 1/sqrt(TRX), and ramped from there to POX, which we use as the PDH signal.
In the first plot, we have several spectra of the CESAR output signal (which is the error signal for the Xarm), at different arm resonance conditions. Dark blue is the signal when we are locked with the ALS beatnote, far from IR resonance. Gold is when we are starting to see IR resonance (arm buildup of about 0.03 or more), and we are using the 1/sqrt(TRX) signal for locking. Cyan is after we have achieved resonance, and are using only the POX PDH signal. Purple is the same condition as cyan, except that we have also engaged the low frequency boosts (FM 2, 3, 4) in the locking servo. FM4 is only usable once you are at IR resonance, and locked using the PDH signal. We see in the plot that our high frequency noise (and total RMS) decreases with each stage of CESAR (ALS, 1/sqrt(TR) and PDH).
To actually achieve the gold noise level of 1/sqrt(TR), we first had to increase the analog gain by swapping out a resistor on the whitening board.
The other plots attached are time series data. For the python plots (last 2), the error signals are calibrated to nanometers, but the dark blue, which is the transmitted power of the cavity, is left in normalized power units (where 1 is full IR resonance).
In the scan from off resonance to on resonance, around the 58 second mark, we see a glitch when we engage FM4, the strong low frequency boosts. Around the 75 second mark we turned off any contribution from 1/sqrt(TR), so the noise decreases once we are on pure PDH signal.
In the scan through the resonance, we see a little more clearly the glitch that happens when we switch from ALS to IR signals, around the 7 and 12 second marks.
We want to make some changes, so that the transition from ALS to IR signals is more smooth, and not a discrete switch.
As Koji suggested in his email this afternoon, we looked at how much actuator range is required for various forms of arm locking: (1) "regular" PDH lock aquisition, (2) ALS lock acquisition, (3) CESAR cooling.
To start, I looked at the spectra and time series data of the control signal (XARM_OUT) for several locking situations. Happily, when the arm is at the half fringe, where we expect the 1/sqrt(TRX) signal to be the most sensitive (versus the same signal at other arm powers), we see that it is in fact more quiet than even the PDH signal. Of course, we can't ever use this signal once the arm is at resonance, so we haven't discovered anything new here.
EricQ then made some violin plots with the time series data from these situations, and we determined that a limit of ~400 counts encompasses most of the steady-state peak-to-peak output from locking on the PDH signal.
[ericq: What's being plotted here are "kernel density estimates" of the time series data of XARM_OUT when locked on these signals. The extent of the line goes to the furthest outlier, while the dashed and dotted lines indicate the median and quartiles, respectively]
I tried acquiring ALS and transitioning to final PDH signals with different limiters set in the Xarm servo. I discovered that it's not too hard to do with a limit of 400 counts, but that below ~350 counts, I can't keep the ALS locked for long enough to find the IR resonance. Here's a plot of acquiring ALS lock, scanning for the resonance, and then using CESAR to transition to PDH, with the limit of 400 counts in place, and then a lockloss at the end. Even though I'm hitting the rails pretty consistently, until I transition to the more quiet signals, I don't ever lose lock (until, at the end, I started pushing other buttons...).
After that, I tried acquiring lock using our "regular" PDH method, and found that it wasn't too hard to capture lock with a limit of 400, but with limits below that I can't hold the lock through the boosts turning on.
Finally, I took spectra of the XARM_OUT control signal while locked using ALS only, but with different limiter values. Interestingly, I see much higher noise between 30-300 Hz with the limiter engaged, but the high frequency noise goes down. Since the high frequency is dominating the RMS, we see that the RMS value is actually decreasing a bit (although not much).
We have not made any changes to the LSC model, so there is still no smoothing between the ALS and IR signals. That is still on the to-do list. I started modifying things to be compatible with CARM rather than a single arm, but that's more of a daytime-y task, so that version of the c1lsc model is saved under a different name, and the model that is currently compiled and running is reverted as the "c1lsc.mdl" file.
Asymptotic cooling of the mirror motion with CESAR was tested.
With ALS and the full control bandwidth (UGF 80-100Hz), the actuator amplitude of 8000cnt_pp is required.
Varying control bandwidth depending on the noise level of the signal, the arm was brought to the final configuration with the actuator amplitude of 800cnt_pp.