The new PRM ASC design
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000
zero: f: 0.5Hz q: 1 / 4Hz, q: 2 / f: 1Hz, q: 3
pole: f: 2Hz q: 3 / f: 2.7Hz, q: 2 / f: 1Hz, q: 15
FM9: (HF Roll-off)
pole: f: 40Hz q: 1/Sqrt(2) (2nd order butterworth)
Servo gain: -0.023
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000
zero: f: 0.5Hz q: 1 / 4Hz, q: 2 / f: 1.5Hz, q: 10
pole: f: 1.02Hz q: 10 / f: 3Hz, q: 5 / f: 2Hz, q: 6
FM9: (HF Roll-off)
pole: f: 40Hz q: 1/sqrt(2)
Servo gain: -0.027
The loop gains were adjusted to have the UGFs of 10Hz. The measured openloop transfer functions were compared with the model.
The transfer functions for yaw are well matched. However, the pitch ones don't. It seems that the pitch loop has extra low pass
which I can't locate. The possibility is the analog electronics of the pitch loop.
The effect of the control between 0.3Hz to 3Hz are well represented by the model. The attachment 2 shows the free running
angle fluctuation, the ones with the control engaged, and the estimated spectra. Indeed, the estimated spectra well represent
the measured angular spectra.
The other day, Jenne and I were comparing my MIST simulation to her Optickle simulation for the CARM transfer functions I posted some days ago. She told me that the arms are not exactly where they should be for the whole "PRC length tuning to account for sideband reflection phase off resonant cavity" deal.
Specifically, as in the wiki (but with newer modulation frequencies), I calculated the ideal arm length to be 37.795 m some time ago, when doing PRC length simulations, and Jenne has told me that the X arm is more like 37.6m, and Y is 37.9. So, I updated my simulations, and found the following:
This does weird things to the f2 sideband buildup on resonance in the PRFPMI configuration:
(POP is way huger than than the TR's, because the POP pd's are artificially "inside" the cavity, whereas TRX/Y is actually transmitted through an ETM)
This is not necessarily directly something to worry about, but I think the following may be. It looks like this arm length mismatch actually causes the PRCL demodulation phase in REFL 165 to change dramatically with the CARM offset. (REFL33 seems fine, though. 5 degrees causes less than a 1% effective gain change.)
My simulations don't include any signal recycling yet, so I don't have anything to show if there is a similar effect for SRCL, but it wouldn't surprise me...
In today's ISC call, Kiwamu was comparing two ways to approach resonance:
D-type might be interesting to check out, since things change a little less dramatically when you reduce the DARM offset. Maybe this makes signal hopping easier? Signal recycling may complicate things, though.
So, I've simulated CARM and DARM offset effects on CARM and DARM signals. (As with the previous plots, this is for the PRFPMI configuration.) From moving both offsets around, it looks like the resonance peak is about 5x wider in DARM than in CARM, so I simulated a 50pm offset range for CARM and a 250pm offset range for DARM.
Here are some CARM signal transfer functions subject to CARM offsets in the top plot, and DARM offsets in the bottom plot.
It's looks like the DARM offset changes cause much less dramatic changes in the CARM plant features. It's conceivable that this would make CARM locking easier.
Here are some DARM plant transfer functions.
In these plots, I did something kind of artificial: when we move the CARM offset, it changes the proper demodulation phase to get DARM in the Q of the AS 1F RFPDS. So, at each CARM offset, I re-phased the AS 1F demodulators, to show the total DARM information available at the AS RFPDs at each offset, rather than what one would actually see in them with a static demod phase.
I've also turned on the MC2 TRANS path to gather some data over the weekend on how well or bad it works. Please turn it off on Monday.
MC2_TRANS path in WFS servo turned OFF.
The MC had not been stable lately with WFS drifting constantly. I checked the servo and found that the MC_TRANS path was still running. It turned out that the autolocker script enables the TRANS path in the locking process. I have turned the MC_TRANS path servo inputs OFF and now it is no more a part of the WFS servo.
P.S. Jenne fixed the PMC alignment mostly in pitch to bring it up to 0.81 from 0.77. But the temperature fluctuations have still not got us to the sweet spot for optimum PMC trans.
To check the basolute frequency stability of the old monochrome HP 8591E RF Spectrum analyzer that we're using for the ALS beat readout, I hooked its 10 MHz reference output (from its rear panel) into the A channel of the SRS SR620 frequency counter. The SR620 is locked to the FS 720 Rubidium clock via the 10 MHz connections in their rear panels.
So, we can assume that this is a good absolute readout. It reads 9.999860.7 +/- 0.3 Hz. So its 139.1-139.4 Hz lower than 10 MHz. The +/- 0.3 is just a slow drift that I see over the course of 10 minutes.
So, let's say that the analyzer is low by 10 ppm, so the arm length estimates are short by ~0.4 mm. A negligible correction, so there's no need to use atomic clocks to measure our arm lengths.
We turned on the MC2_TRANS paths for both PIT/YAW tonight.
I turned off the BLP200 and turned on the RLP7 (RLP always are better than BLP). G_PIT = -0.111, G_YAW = 0.111. On Monday, let's let Steve look at the trends and determine if this centering servo is bad or good.
I should've included this in my Thursday night ELOG... That evening, I aligned the mode cleaner with reasonable MC1/3 spot positions, and the MC2 spots very close to centered, and recentered the WFS and MC2 Trans QPDs. The mode cleaner held up very well over the course of that evening, even when actuating CARM on MC2 with WFS engaged (which previously wasn't very stable when the WFS weren't well aligned).
The MC was showing slow but periodic alignment drifts and eventually unlocked around noon. I looked up the alignment trend (Attach: 2 day trend)
MC_TRANS_PIT_ERR and MC_TRANS_Y_ERR show that the MC_TRANS servo slowly drifted the IMC alignment causing it to lose lock from time to time (mostly in yaw).
To confirm that the drift was NOT due to off-centering in the MC2_TRANS QPD, I turned off the WFS servo, moved MC2 to recenter the trans beam on the QPD, and re-enabled WFS servo.
MC_TRANS path in WFS is still left enabled.
This is a 4-day trend. I don't see any difference here which is significant. My guess is that the MC_TRANS servo gain is so low that its not really doing anything.
I'll turn it on periodically this week and then on Monday people can look at the trend again to see if they can identify when the servo is ON and when its OFF.
During a lull in Koji vs. The Arm, I switched on the MC2_TRANSQPD feedback path to check out its UGF. In the past months, when its been on, it has had a gain of ~0.03 - 0.1.
Today, I found that with the gain turned up to 11, it has a ~1 minute step response time (as you see in the above Strip chart). So its had a UGF of ~2 hours or so during the times when we thought it might be doing bad or good or magic.
I leave it on now to see if it behaves well over the next days. Let's see if Steve thinks its good or not based on his trend monitoring.
** also touched up the PMC pointing (using the PMC REFL image / please never align the beam into the PMC without this camera image)
After Jamie fixed the third party repo issue with Ottavia, he was able to upgrade it to Ubuntu 12.04 Precise Pangolin. But its network stopped working.
I tried to fix its issues by ifconfig and GUI, but what it really wanted was for me to put the network cable back into its eth0 slot. The eth1 network card appears not be working anymore.
All seems fine now. Next I will mount the shared user disk from linux1 and put in a .bashrc.
Last night after checking cabling and turning on ISS, we tried several times to handoff to REFL_DC but it didn't work at all.
We want there to be ~16000 cts of signal per quadrant on the optical levers. I think that most of the QPDs have been modified to have 100k transimpedance resistors.
From the attached 90 day trend, you can see that the ETMX, BS, PRM, and SRM are really low. We should figure out if we need to change the lasers or if the coating reflectivities are just low.
Steve, can you please measure the laser powers with a power meter and then reply to this entry?
Another possibility is that we are just picking a dim beam and a brighter one is available.
Still no success tonight
For some reason or another, I decided that we should see if the optical lever servos were injecting too much noise into the test masses. The ITMs are much worse than the ETMs and I am afeared that they might be making the main noise for our arms in the 20-40 Hz region. Jenne is checking up on these feedback loops to see what's up.
To estimate the actuator gains of the mirrors, I turned on 1 count drives from LSC/CAL oscillators into the LSC drives of each test mass at the frequencies shown in the plot with the resulting peaks showing up in in POX/Y with the single arm locks in red. I will leave these going permanently, but with 0.1 count ampltiudes; we need to make it so in the scripts.
We need to go back and have a look at all of our optical lever control filters, and make sure they make sense.
In particular, we should have a look at the ITMs, since they have a huge amount of motion around 10Hz.
Notes: ETMX shouldn't have that lower notch. The bounce mode Qs should be lowered.
I'm in the process of filling this table
I should replace ETMX He/Ne laser
I took loop measurements of ETMX pit and yaw, and set the upper UGF to be ~6Hz for both. This required a pitch gain of 25, and a yaw gain of 16.
The spectra look similar to what they were before Steve did the swap.
I believe that the Xend aux laser was turned off earlier today, for Steve's work swapping out the oplev. When I went down there, the red "off" LED was illuminated, and the LCD screen was showing something. I pushed the green "on" button, and I immediately got green.
Also, I saw that the 24Hz roll mode was very rung up on ETMX. I looked at the FM5 "bounce roll" filter, and it had some old values, 12Hz and 18Hz for the resonant gains. All other optics have the proper 16Hz and 24Hz frequencies. I copied the BS oplev bounce roll filter over to ETMX pit and yaw (both were wrong), and loaded them in. The mode is starting to ring down.
ETMX oplev qpd gain has to be increased.
Atm3, Oplev sum read 12,000 counts when the qpd was disconnected ?
Dark qpd was zero and normal He/Ne incident on qpd was 1,730 counts.
This QPD circuit (D980325-C1 ) uses the nice OP497 Quad FET opamp as the transimpedance amplifier. It has a low enough current noise, such that we can increase the resistors (R1-4) up to 100k and still be Johnson noise limited. We should also make sure that the compensation caps (C3-6) are ~2.2 nF so as to not destabilize the opamp. f_low = 1/2/pi/R/C = 730 Hz.
I will do the swap later today unless someone else gets to it first. (note: check for oscillations w/ fast scope probe after installing)
I did these modification tonight. The slideshow of some images is attached. Instead of 100k, I used 97.6k thin film, since this seemed like an oddball size that doesn't get used otherwise. I forgot to measure the dark noise of the quadrants before doing the swap, but comparing the pit/yaw/sum before/after the swap shows that the signal is basically unchanged (since pit/yaw is normalized by SUM), but that the noise is lower by a factor of a few above 100 Hz due to being above ADC noise now. Previously, it was bottoming out at ~10 prad/rHz. Since the signal is unchanged, I guess that the calibration and therefore the loop gain should not have changed either...
And the sum went up by almost 10x as expected from the resistor change.
My SURF week-1 work...
To measure the transimpedence of the Broadband photodiode (D1002969-v8), using a New focus photodiode (1611) as reference. The amplitude modulated Jenne Laser (1.2mW) was used.
The steps involved in getting the transimpedence are as follows:
1) Frequency sweep range: 1MHz to 200 MHz.
2) Number of Points sampled in the range: 201
3) Type of sweep: Logarithmic
The Plots of transimpedence obtained are attached (results.pdf) . The results obtained for BBPD is consistent with the ones obtained before, but the same method and code gives a different transimpedence for 1611.
The transimpedence of NF 1611 was obtained to be around 4-5 V/A which is very much off-track compared to the one given in the datasheet (elog: 2906).
The transimpedence of Broadband photodiode (D1002969-v8) was around 1200 - 1300 V/A for most of the range, but the value started falling as the frequency approached 100 MHz. This result is consistent with DCC document: T1100467-v2.
How is the modulation depth assumed in the calculation?
If you don't know the modulation depth, you can't calibrate the transimpedance of each PD individually.
A recap of the ringdown measurements made at the 40m in mid 2012, the hardware that was installed for the same and results from the measurements.
A trans PD was installed (elog 7122).
This PD does not exist in the trans path anymore.
The polarity in the MC servo was flipped with the MC WFS disabled and the PD trans signal was used to look at the cavity ringdown.
Ringdown time = 13 us
Cavity finesse from the measurement = 453 (inconsistent with actual finesse).
Attachment: Ringdown measurement and fits
The AOM was installed before the PMC. The AOM was driven by the driver installed on the PSL table. (RF power ~1.5W @ 80MHz @1.0V modulation input). An RF switch was installed to control the AOM driver input. ZASWA-2-50DR+ was installed.
Note: The AOM was used by the ISS crew after this. So the RF switch has been removed and the AOM is no more a part of the ringdown setup.
No measurements were made as we could not obtain relevant TTL signals to control the switch remotely.
To do this better:
1) Just step the analog input to the AOM (i.e. no RF switch) and measure the PMC trans output with a fast DC coupled PD. IMC should be unlocked and disable during this part. We want the PMC ringdown to be faster than 1 us.
2) Re-install a fast PD in the MC trans path without disrupting the existing MC trans QPD setup.
3) Measure IMC ringdown and fit the data to find the cavity losses.
4) Think about how to use the Isogai, et. al (2013) technique to better measure the losses, taking into account the mirror transmissions.
Attached is the weekly work plan / equipment requirement / lab expert's presence needed for the upcoming week.
The frequency counter (FC) takes in an analog RF input(signal) and outputs the frequency of the signal(Ranging from 1 MHz- 6000 MHz) in the digital domain (into a processor). The FC samples the data with a given sample rate( user defined) which ranges from 0.1 s to 1 s(faced problems in fixing this initially). For data acquisition, we have been using a Raspberry Pi(as a processor) which is connected to the martian network and can communicate with the computers inside the 40m. The ultimate challenge which I faced( and been knocking my head off from past two-three weeks) is the synchronization of clocks between the Raspberry Pi and the FC i.e the clock which the FC uses to sample and dump data( every 'x' s) and the clock inside the raspberry pi( used in the loop to wait for a particular amount of time the frequency counter takes to dump successive data).
Psuedo Code(code attached):
open device : FC via USB-HID;
open device : ADC via I2C;
always(for t= recording time):
read data from ADC(external clock);
if pos edge detected:
read data from FC and store it in a register;
else read data from ADC;
write data stored in the register to a file( can be an Epics channel or a text file);
The attached are the plots showing the time between samples for a large number of samples taken for different sampling times of the FC. The percentage error is the percentage of standard error in the timing between two samples for the data for the entire measurement. It can be inferred that this error has been cut down to the order of ms.
To do next:
Looks good. Now you have the internal timer to verify the external clock.
If you can realize the constant rate sampling without employing the external clock, that's quite handy.
The attached are the PSD plots with improved FC timing(with the same code as in http://nodus.ligo.caltech.edu:8080/40m/10151). More plots(Phase and PSD) to follow.
New script called scripts/ALS/findRedResonance.py finds the IR resonance in less than 20 seconds.
The above is the gist of what goes on, but there were several issues to overcome to get the code to run.
From the last plot:
- Subtracting the offset of 0.0095, the modulation depth were estimated to be 0.20 for 11MHz, 0.25 for 55MHz
- Carrier TEM00 1.0, 1st order 0.01, 2nd order 0.05, 3rd order 0.002, 4th order 0.004
==> mode matching ~93%, dominat higher order is the 2nd order (5%).
Eric: now we have the number for the mode matching. How much did the cavity round-trip loss be using this number?
AOM removed from the beampath and PMC relocked.
1. Measured the initial power after PMC as 1.30W and reduced it down to 130mW.
2. Checked the power in the AOM zero order transmission before touching it. For 0-1V modulation input, the power dropped from 125uW to 98.3uW.
3. Steered the mirror right before the AOM to increase AOM zero order transmission and then carefully moved the AOM around to obtain maximum power attenuation. I repeated this a few times and the maximum attenuation that I could obtain was 125uW to 89.2uW (~30% attenuation).
Although this is not the right way to align the AOM, we do not have much options with the current setup as there is not enough separation between the zero order and first order beams and the AOM is on a fixed rigid mount.
4. I tried to dump the first order beam from the AOM and it wasn't satisfactory as well. There is barely any separation between the zero order and first order beams.
1. SInce the alignment to the PMC was disturbed by moving the AOM and the steering mirror in front of it, the PMC alignment was lost.
2. I could not relock the PMC at low power or high power. Rana had to come to rescue and fixed the alignment so that we could see flashes of PMC on the trans camera (This was done by aligning refl beam to the PMC REFL PD while giving a triangular ramp to the PMC PZT voltage).
Also I should not have tried to lock the PMC at high power as I could have been steering the beam at high power to the edges of the PMC mirrors that way and burning stuff easily.
3. Before fine tuning the alignment, I decided to remove the AOM from the beam path as there needs some work done on it to make it useful.
4. I removed the AOM from the beam path and relocked the PMC.
5. PMC is relocked with 0.79 counts in TRANS and I measured the power after PMC 1.30W
Attachment: picture showing AOM removed from the beampath.
To estimate the transfer function and the noise in the FC that is a part of the FOL-PID loop.
The setup used for the measurements is described in my previous elogs.
The input modulation signal and the FC output were recorded simultaneously for a certain period of time and the phase and gain are estimated from the data.
Analysis(Data and code attached):
The recordings must contain equal number of data points(around 6000 data points in my measurements) for analysis.
The steps I followed to generate these plots are:
Phase(system) =Phase(FC Signal) - Phase(Input Signal)
From the plots its can be inferred that :the delay of the FC is almost 0 until the modulation of 0.1 Hz. Then there are phase shifts of +/- 180 degrees showing that the system has multiple poles and zeroes(will be estimated after I have phase plots at few more carrier frequencies).
To Do Next:
Phase plots for varying carrier frequencies and different sampling times.
Installation of FC inside the 40m.
If I assume 1sample delay for 0.1s sampling rate, the delay is Exp[-I 2 pi f T], where T is the sampling period.
This means that you expect only 36 deg phase delay at 1Hz. In reality, it's 90deg. Huge!
Also there are suspicious zeros at ~1.6Hz and ~3Hz. This may suggest that the freq counter is doing some
internal averaging like a moving average.
It would be interesting to apply a theoretical curve on the plot. It's an intellectual puzzle.
Rack 1Y2, I took transfer function measurements for each of the following demodulator boards: REFL11, REFL33, REFL55, REFL165, AS55, POP22, POX11 and POY11.
What I did:
1) Removed the wire at PD Input to demodulator board.
2) Put the MOD output from network analyzer into PD input of board.
3) Ran a sweep from 100kHz to 100MHz.
4) Measured the transfer function between PD RF MON and PD Input. (The PD RF MON signal came out of the RF multiplexer, so the mux is included as well )
5) Put the original wire back at PD Input.
The plots clearly show an attenuation of 20dB (factor of 10) for all the demodulator boards. This explains why my transimpedance measurements are off by 10 times.
Note: for REFL 165, there was an extra 100MHz high pass filter installed at PD Input. I did not remove this and made my measurements along with this.
a) Modify the PDFR system to calibrate out this attenuation.
b) Measure the transfer function between the input and output of RF mux, so that we can have just the transfer function between PD input an PD RF MON (for documentation's sake)
Thanks Koji , for your hint for the brain teasing puzzle. I was looking into Filters that are usually used in devices like counters, DSO and other scopes. I found that , to improve the quality of the measurement one of the best approach is averaging. I looked deeper into averaging and found out this:
There are two general use-cases for averaging . The first, successive sample averaging, takes a single acquisition and averages between its samples. The second, successive capture averaging, combines the corresponding samples of multiple captures to create a single capture. Successive sample averaging is also called boxcar filtering or moving average filtering. In an implementation of this type of averaging each output sample represents the average value of M consecutive input samples. This type of averaging removes noise (one of the reasons the noise level was not bad: http://nodus.ligo.caltech.edu:8080/40m/10151) by decreasing the device's bandwidth(could be one of the reasons why the FC operates in 4 different frequency ranges). It applies an LPF function with a 3dB point approximated by 0.433 * s / M, where M is the number of samples to be averaged, and s is the sample rate in samples per second.
Now I tried verifying the 3 dB points in the gain plots I generated :
For 1 s Sampling time : the 3 dB point for such a Boxcar filter should be at 0.433* 1/M. If we assume that it averages for 2 samples, M=2 which gives the 3dB point at 0.288 Hz but occurs somewhere between 0.3 and 0.4 Hz. (http://nodus.ligo.caltech.edu:8080/40m/140619_120548/GainVsFreq.png)
For 0.1s Sampling time: the 3dB point should be at 2.17 Hz and in reality is 2.5 Hz(http://nodus.ligo.caltech.edu:8080/40m/140701_211904/gain.png).
Also, This type of filter will have very sharp nulls at frequencies corresponding to signals whose periods are integer sub-multiples of M/s. As seen my previous plots (http://nodus.ligo.caltech.edu:8080/40m/10118 , http://nodus.ligo.caltech.edu:8080/40m/10070) there are sharp nulls at frequencies
0.4 Hz for 1S sampling time and
at 1.5 Hz,3 Hz for 0.1 S sampling time as correctly predicted.
The moving average filter is L-sample moving average FIR, with the frequency response as: H(ω) = (1/L) (1 − e− jω L)/(1 − e− jω)..
There is an overall delay of (M - 1)/2 samples from such a length-M causal FIR filter.
The expected bode plots for such a filter with L= 5 is attached(attachment 2).
The expected bode plots for such a filter with L= 4 is attached and compared with the measured.
RXA: When comparing two things, please put them onto the same plot so that they can be compared.
Using these numbers for both arms (Modulation takes away .2*.25 = 5% power, mode matching takes away 7% after that), I get the following from my data from March:
Xarm loss is 561.19 +/- 14.57 ppm
Yarm loss is 130.67 +/- 18.97 ppm
Obviously, the Xarm number looks very fishy, but its behavior was qualitatively very different when I took the data. ASDC would change from ~0.298 to ~0.306 when the Yarm was locked vs. misaligned, whereas the xarm numbers were .240 to .275.
In any case, I'll do the measurement again tomorrow, being careful with offsets and alignment; it won't take too long.
I repeated the exact steps above and made sure everything was back where it should be after I was done.
Reason I had to retake the measurements:
My script for acquiring data from the AG4395A network analyzer was such that it first acquired the magnitude data from channel 1 and then recorded phase data from channel 2 without holding its trace. Hence the phase and magnitude data were not exactly in sync with each other. So, when I tried to fit the data to a model using vector fitting, I ended up with very bad results.
I have now changed every single script relating to the network analyzer to just get the real and imaginary data in one go and then calculate the phase using this data.
The fitting process is now in progress and results will be up shortly.
The goal of the measurements we made ( my previous 3 elogs) was to characterize the laser frequency thermal actuator that is a part of the FOL- PID loop.
For this we made indirect TF measurements for the thermal actuator by looking at the PZT response by 1)arm cavity( ETM ,ITM) displacement and 2) temperature offset excitation. The goal was to do something like getting G1=TF3/TF1 and G2=TF3/TF2 and ultimately dividing G2/G1 to get TF2/TF1 with correct calibration. The final TFs obtained are the X and Y arm TFs for Laser frequency response vs temperature offset in(HZ/count). The calculations in detail are:
Obtained G1 = PZT response/ Temperature Offset (count/count): (in detail here )
Obtained G2 = PZT response/ X and Y arm displacement( count/ count) : (in detail here)
Calibrated G2 to count/m ( in detail here)
Divided G2/G1 to get X and Y arm displacement/ Temperature Offset( m/ count) to get G3
Did these calculations:
dL/ L = dF /F
F = c/lambda ;Lambda = 532 nm ; L =
X arm length = 37.79 +/- 0.05 m
Y arm length = 37.81 +/- 0.01 m
TF: Laser Freq/ Temperature Offset = G3 *F/L (HZ/Count)
The calibration coefficients for the ends are :
X End: [23.04 +/- 0.23 ]* 10^3 (HZ/Count)
Y End: [18.71 +/- 0.2 ]* 10^3 (HZ/Count)
For the TFs of the temperature actuator on laser frequency I used ITMs for both the arms. The bode plots for the calibrated( HZ/Temp Count) are attached.
For the X-Arm Thermal Actuator, I calculated the TFs at two different frequency ranges and combined the results where the coherence is high(>0.7). At 1 Hz the coherence was not as good as the other frequencies(due to the suspension resonance at 0.977 Hz).
The poles and zeroes are estimated after fitting this data using Matlab vectfit tool.The graphs showing fit and measured values are attached.
Y arm Thermal Actuator:
5th order TF fitted:
z1 = -0.9799;
z2 = 2.1655;
z3 = -2.9746- i * 3.7697
z4 = -2.9746+ i * 3.7697
z5 = 95.7703 + 0.0000i
p1 = -0.0985- i* -0.0845
p2 = -0.0985+ i* -0.0845
p3 = -0.6673- i* -0.7084
p4 = -0.6673+ i* -0.7084
p5 = -8.7979.
X-arm Thermal Actuator:
Gain = 20
z2 = -18.2774
z3 = -16.6167
z4 = -1.2486
z5 = 28.1080
p1 = -0.1311 - 0.1287i
p2 = -0.1311 + 0.1287i
p3 = -8.3797 + 0.0000i
p4 = -4.0588 - 7.5613i
p5 = -4.0588 + 7.5613i
I will use get the poles and zeroes from these fitted bode plots and use it to build the PID loop.
Koji asked me to get the calibration of the PZT counts to Volts for the the X and Y ends. Yesterday, I went inside the lab and took some measurements from the digital readout of the PZT by giving in a DC offset(-5 to +5 volts) to PZT_Out and read out from these channels:
For X-end: C1:ALS-X-SLOW_SERVO1_IN1
For Y-end: C1:ALS-Y-SLOW_SERVO1_IN1
Since a 20dB attenuator was placed in the path of X-arm readout while taking the Transfer functions(Detail), I did the calibration measurements without removing it from the path. However, for the Y arm there was no attenuator in the readout path.
The obtained calibration values are :
X- arm PZT : [146.3 +/- 2.37 ] counts/Volt
Y- arm PZT : [ 755.1 +/- 3.6] counts/Volt
The attached are the fit and data plots for the above calibration.
1) Don't be brainless. Redo the fitting of the Y arm. Obviously the fit is not good.
2) How can you explain the value from the ADC bit and range?
e.g. +/-10V range 16bit ADC => 2^16/20 = 3276.8 count/V
The PZT seems to saturate at around +/- 3500 counts. So for the Y arm, I excluded the saturated points and fitted the data points again.
As for the calibration number, we expect the 3276.8 count/V for +/- 10 V range of a 16 bit ADC but the number is ~800 count/V. I couldn't figure out a reason why the number is so different.
The new calibration values are :
X- arm PZT : [146.3 +/- 2.37 ] counts/Volt (with a 20 dB attenuator included in the path)
Y- arm PZT : [ 797 +/- 3.6] counts/Volt
I will get the calibration in MHz/V of PZT actuation and check whether these numbers make any sense.
To make MC auto locker running correctly, mcdown and mcup were revised
I tried it by unlocking MC several times. It seems OK. Let's see how it works.
Nominal gains for locking (to be taken care by mcdown)
was 16 and is 19 now.
was 9 and is 9 now too.
was missing and now +13
was +23.5 and is now +20.0
Nominal gains for operation ( to be taken care by mcup.
was 19 and is 19 now too.
was 25 and now uses ezcastep (ezcastep C1:IOO-MC_VCO_GAIN=9 +1,16 -s 0.1)
ezcawrite C1:PSL-FSS_MGAIN `ezcaread -n C1:PSL-STAT_FSS_NOM_C_GAIN`
ezcawrite C1:PSL-FSS_FASTGAIN `ezcaread -n C1:PSL-STAT_FSS_NOM_F_GAIN`
C1:PSL-STAT_FSS_NOM_C_GAIN` is +18
C1:PSL-STAT_FSS_NOM_F_GAIN` is +20
- Put the circuit diagram of the sum amp on/in the circuit enclosure and associate it with an elog [done].
- Update the circuit diagram of the pomona box [done]
It seems that the MC auto locker and the FSSSlow PID servo survived a night.
PC Drive is still angry occasionally. We want to know what this is.
- FSS Box has the output range of +/-10V
- Thorlabs HV amp MDT694 accepts 0V ~ +10V
- This circuit add an offset of +5V while the main signal is attenuated by a factor of 2. The offset voltage is produced from the voltage reference IC AD586.
- In addition, a summing node and voltage monitors before and after the summing node are provided. They are useful to test the crossover frequency of the fast/PC loops.
- The output noise level at 10kHz was ~60 nV/rtHz. The transfer function of the circuit was measured and flat up to 100kHz. The phase delay is negligible at 10kHz and less than 3deg at 100kHz
- Although the schematic was drawn in Altium, the board is a universal 1U eurocard and all wires were hand soldered.
Reasoning to choose the current parameters:
FSS Common: 18dB
FSS Fast: 20dB
Openloop transfer function of the IMC loop with the nominal gain setting. The UGF is 176kHz and the phase margin is 48 deg.
This is about 3 time more bandwidth than the previous setting. (Good)
It is visible that the TF has sharp roll off around 1MHz. I wonder if this comes from the demodboard LPF and/or the PMC cav pole.
In fact, according to Manasa, the PMC has the ringdown of 164.6ns which corresponds to the cavity pole of 967kHz. So this must
be there in the OLTF.
From the plot, the order of the low pass is about 5. Subtracting the slope by the cavity pole, the order is four. If I look at the TF of the minicircuits
LPFs (this entry), the phase delay of the filter at 1/10 of the cut off freq is ~30deg. And the order of the filters are maybe 6th elliptic?
So it's not yet clear if the LPF is causing a significant phase delay at 180kHz.
More significantly, the gain margin at ~1MHz is way too small. This is causing a big servo bump at that frequency as seen in Attachment 2.
In total, my recommendation is to move the LPF freq up by x2 or x3, and give a mild LPF above 500kHz.
This requires some modeling as well as try and error.
This figure is to explain how the common FSS gain was set. By increasing the gain, the UGF is increased and we can enjoy more supression (from red to purple).
The more gain, however, the more servo bump we observe above the UGF. The gain was chosen so that the total PC feedback does not exceed 3V.
This figure explains how the fast FSS gain (namely crossover frequency between fast and PC) was set. When the fast is low (red) the phase margin between two loops
are plenty and therefore the openloop TF is smooth. But the PC's frequency domain is large and has to work more (in rms). As the fast gain is increased, the actuation
by the PC is offloaded to the fast PZT (that's good). But eventually the phase margin is not enough and the dip start to show up (purple). This dip cause worse closed loop TF,
as seen in Attachment 4, or even an instability of the loop eventually. So the fast gain was set somewhere in between (green).