Give us a lockloss or other kind of time series plot so we can bask in the glory.
Look upon this three second lock, ye Mighty, and rejoice!
I hope the grappa was already cold, and ready to drink!
To get a better look at how to do fast ALS, I took some "Plant TF" measurements of the X arm.
Specifically, in single arm POX lock and the both Y TMs misaligned, I used the SR785 to inject into EXC B of the common mode board with the CM fast output gain and IMC IN2 gain both at 0dB, and looked at the transfer function of that excitation into the analog ALSX I and AS55 Q out-of-loop signals. (ALSX I tuned to a zero crossing via the delay line box as usual.)
My expectation was to see them only differ by the IR single arm cavity pole, which should be around 8-9kHz ( FSR/450 = 3.9MHz/450 ~ 8.6kHz). The green cavity pole at ~18k shouldn't show up since we're not touching the green light, and the IMC pole at ~3.8kHz shouldn't show up since this is well within the IMC loop bandwidth and we're actuating on its error point.
Instead, I see them differ by a double pole at 4.3kHz. (or zero, if you look at it the reciprocal way). Vectfit actually fits them as a slightly complex pair, with a Q of 0.53/ I imagine that the wiggles are due to the digital control loop.
My question is: why is there a double zero here? Where has my reasoning led me astray?
ALS is the comparison of the PSL laser freq vs the end laser freq that is locked to the arm cavity resonant freq
On the other hand, the AS55 PDH is the comparison of the PSL laser freq after the IMC vs the arm cavity resonant freq. Here the PDH signal involves the arm cavity pole.
In total you observe the difference by the IMC cav pole + the arm cav pole.
Ah, I understand it now! Since the additive offset path keeps the post-cavity frequency TF flat, the pre-cavity frequency must grow above the cavity pole, which is why ALS sees a zero.
Ok, so this means we want to apply two lowpasses to the ALS signal for use as fast CARM control, if we want it to be capable of scalar blending with REFL11: one at ~120Hz to imitate the CARM coupled cavity pole present in REFL11, and one at ~3.8kHz to undo the "IMC cavity zero" present in ALS.
At this point, I'm starting to prefer an active circuit to do this lowpassing; using LISO to check designs for two cascaded passive LPFs it looks like the ALS signal would have to be attenuated by a factor of ~20 at DC if we don't use resistors smaller than 1k, given the low input impedence of the CM board.
Despite our best efforts, the grappa remains out of reach: the DRFPMI was not locked tonight.
We spent a fair amount of time with the AUX X laser, as it was glitching madly again.
DRMI was finicky until I found some more reliable triggering settings; namely aquiring with AS110Q, but after that transitioning the trigger to the same POP22+POPDC combo as PRCL and MICH. With this in place, the DRMI lock seems really indefinite no matter what CARM seems to do; or at least, I always lost lock due to CARM shenanigans after this.
The most frustrating part was the fact that I just couldn't cross over the AO path stably. It never "clicked" into high circulating power as it normally does (either in PRFPMI, or how it was last week). Various crossover filters and tweaks were attempted to no avail. Morning traffic starts soon, so we're calling it a night.
I've made a cascaded passive 2-pole pomona box for fast ALS use, using LISO to check that it'll give the right shape when hooked up to the CM board's input stage.
First stage is a 133Ohm + 10uF cap for ~120Hz LP, second is 1.15kOhm + 47nF cap for ~3.8kHz LP. The DC gain is ~0.75, which is much better than what I was doing before. The second stage would normally make a 2.9kHz LPF on its own, but the loading of the input stage moves the corner up.
It seems the 133 Ohm resistor is a reasonable load on the output AD829 of the ALS demod board (short-circuit output current of 32mA and a series output resistor of 499Ohm). To be able to use the digitized ALSX I and the lowpassed analog version simultaneously, I had to buffer the signal with a SR560 before the pomona box, otherwise the signals looked distorted. This isn't a good long-term solution. Maybe I can used the further-buffered differential output to drive the LPF+CM board.
The LISO files used to model the filter and CM board input stage, and fit the pole frequencies are attached.
I made some attempts to get the AO path going today, but I suspect this daytime noise is just too much; the PC drive seems too irritable
For real this time.
Fast ALS was still a problem tonight. I don't think high frequency ALS noise saturating the PC drive is the issue; I put two 10k poles before the CM board (shooting for just 2-3kHz bandwidth), and the PC drive levels would be stable and low up until the lockloss, which was always conincident with a step in the AO gain.
After working with that for a few hours, we turned back to our more standard locking attempts. First, we dither aligned the PRMI, and then centered the REFL beam on REFL11. It's hard to say for certain, but we may have been a little close to the edge of the PD. The only other thing that differed from Monday's attempts was using 6dB less AO gain when trying the up the overall gain.
The script now reliably breaks through to stable high powers, we had a handful of pure-RF locks tonight. The digital DARM gain needs tuning, and the CARM bandwidth still isn't at its final state, but these are very tractable. Off the top of my head, the way forward now includes:
Unrelated: I feel that the PRC angular FF may have deteriorated a bit. I'm leaving the PRC locked on carrier to collect data for wiener filter recalculation.
in addition to Koji's words I feel like we should also thank those who made small but positive contributions. Its hard not to notice that this locking only happened after the new StripTool PEM colors were implemented...
From the times series plot I guess that the fuzz of the in-loop DARM is 1 pm RMS (based on memory). This means that the ALS was holding the DARM at 10 pm from the RF resonances.
There is no significant shift in the DRMI error signals, so new weird CARM effect. Would be interesting to see what the 1f signals do in the last 60 seconds before RF lock.
For documentation, perhaps Gautam can post the loop gain measurements of the 5 loops on top of the Bode plots of the loop models.
Here is a longer lock, about 100 seconds RF only, from later that same night. The in-loop CARM and DARM error signals have the order of magnitude of 1nm per count.
From ~-150 to -103, we were fine tuning the ALS offsets to try and get close to the real CARM/DARM zero points then blending the RF CARM signal.
At -100, the CARM bandwidth increases to a few kHz and stabilizes the arm powers. By -81, the error signals are all RF. At -70, I turned on the transmon QPD servos, which brought the power up a bit.
If I recall correctly, lock was lost because I put waaaay too big of an excitation on DARM with the goal of running its UGF servo for a bit. The number I entered was appropriate for ALS, but most certainly too huge for AS55...
Last Friday, I installed some RF couplers on the green BBPDs' outputs, and sent them over to Gautam's frequency divider module. At first I tried 20dB couplers, but it seemed like not enough power was reaching the dividers to produce a good output. I could only find one 10dB coupler, and I stuck that on the X BBPD. With that, I could see some real signals come into the digital system.
I don't think it should be a problem to leave the couplers there during other activities.
For CARM and DARM, the A channels are used for the ALS signals, whereas the B channels are used for blending the RF signals.
For the DRMI, the A channels are used for the 1F signals, whereas the B channels are used for the 3F signals. The settings for transitioning to 1F after locking the DRFPMI have not yet been determined.
These settings are currently saved in the DRMI configurator, but the demod angles are set for DRFPMI lock, so the settings don't reliably work for misaligned arms.
The REFL33 element in SRCL_B is to reduce the PRCL coupling, was found empirically by tuning the relative gains with the arms misaligned and looking at excitation line heights. The offsets were found by locking the DRMI on 1F signals with arms misaligned, and taking the average value of these 3F error signals.
The CARM and DARM ALS settings are largely scripted by scripts/ALS/Transition_IR_ALS.py, which takes you from arms POX/POY locked to CARM and DARM ALS locked. The DRMI settings are usually restored from the IFO_CONFIGURE screen.
When arms are POX/POY locked, and the green beatnotes are appropriately configured, calling scripts/DRFPMI/carm_cm_up.sh initiates the following sequence of events:
When CARM and DARM are buzzing around true zero, powers maximized:
This is as far as we've taken the DRFPMI so far, but the CARM bandwidth is still only at a few kHz. Based on PRFPMI locking, the next steps will be:
I found (an old) 10 dB coupler in the RF component shelves near MC2 - it has BNC connectors and not SMA connectors, but I thought it would be worth it to switch out the 20dB coupler currently on the X green beat PD on the PSL table with it. I used some BNC to SMA adaptors for this purpose. It appears that the coupler works, because I am now able to register an input signal on the X arm channel of the digital frequency counter (i.e. the coupled output from the green beat PD). I thought it may be useful to have this in place and do an IR transmissions arm scan using ALS for the X arm as well, in order to compare the results with those discussed here. However, the beat note amplitude on the analyzer in the control room looks noticeably lower - I am not sure if the coupler is responsible for this or if it has to do with the problems we have been having with the X end laser (the green transmission doesn't look glitchy on striptool though, and the transmission itself is ~0.45). In any case, we could always remove the coupler if this is hindering locking efforts tonight.
A handful of DRFPMI locks tonight, longest one was ~7 minutes.
EPICS/network latency has been a huge pain tonight. The locking script may hang between commands at an unstable place, or fail to execute commands altogether because it can't find the EPICS channel. This prevented or broke a number of locks.
I made some CARM OLG and crossover measurements, and found the AO gain for the right crossover freq (~100Hz) to be ~8dB different than what's in the PRFPMI script, which is weird. Right now, the CARM bandwidth / ability to turn on boosts is limited by the gain peaking in the IMC CLG due to the high-ish PC/PZT crossover frequency we're using.
Gautam turned on some sensing excitations during the last couple of locks, but they weren't on for very long before the lock loss. Hopefully I can pull out at least some angles from the data.
I'm also more convinced that the PRC angular FF needs retuning; there is more residual motion on the cameras than I'm used to seeing. I've taken more data that I'll use to recalculate a wiener filter tomorrow.
The PMC, ALSX beat and ITMX oplev all needed a reasonable pitch realignment tonight.
The length of DRFPMI lock did not increase much tonight, but we got a ~80 second sensing matrix measurement, and got the CARM bandwidth up to 10k with two boosts on.
NB: I did not measure the CARM loop gain at its excitation frequency, so the plotted sensing element is supressed by the CARM loop. However, this is still useful for gauging the size of the PRCL signal vs. the residual CARM fluctuations. The excitations are fairly closely spaced between 309 and 316 Hz.
For comparison, I'm also re-plotting the DRMI sensing measurement from a few weeks back taken at CARM offset of -4. We can see some change in the PRCL sensing, likely due to the CARM-coupled path. MICH/PRCL sadly looks pretty degenerate, but REFL55 looks more reasonable.
I think the main limitation tonight was SRC stability. Even before bringing CARM to zero offset, we would see occasional sharp dives in AS110 power. One lockloss happened soon after such an occurance, but I checked the values, and it was not sufficient to trigger the Schmitt trigger down; instead it may have been a real optical loss of signal. The SRCL OLTF looks sensible.
Tonight was kind of a wash.
We spent some time retaking single arm scans with Gautam's frequency counting code to confirm the linewidths he measured before his most recent round of code improvements. During this, ETMX was being its old fussy self, costing us gentle realignment time. For the time being, we started actuating on ITMX for single arm locks. Also, out of superstition, I changed the static position offset that had been at +1k for the last N months to -1k.
ETMX broke us out of a few DRFPMI lock trials as well, as did poor SRM alignment. I finally set up dither alignement settings for SRM in DRMI though, which helped (even in the arms-held-off-resonance situation). I still prefer doing the PRM/BS dither alignment in a carrier PRMI lock, because I think the SNR should be better than DRMI.
We know that the ETMX excursions can happen without length drive exciting them, but also that length drives certainly can excite them. For future locks, I'm going to try out avoiding ETMX drive altogether; the sites use a single ETM for their DARM actuation and let the CARM loop take care of the resultant cross coupling, so hopefully we can do the same without angering the mode cleaner.
Anyways, we didn't really ever make it far enough to do anything interested with the DRFPMI tonight
While the ETMx issues are being investigated - with Eric's help, I took some data from arm scans of the Y arm through ~2FSRs using ALS. I've also collected the data from the frequency counter readout during these scans but since they were done rather fast (over 60seconds), I am not sure how accurate this data will be. The idea however is to use the frequency readout from the phase tracker - this has to be linearized though, which I will do during the daytime tomorrow. The plan is to use our GPS timing unit to synchronize the following chain :
GPS timing unit 1PPS out --> FS725 Rb Clock 1PPS in (I recovered one which was borrowed from the 40m some time ago from the ATF lab yesterday evening, waiting for it to lock to the Rb clock now)
FS725 Rb Clock 10 MHz out --> Fluke 6061A 10MHz reference in
FS725 Rb Clock 10 MHz out-->agilent network analyzer 10MHz reference in (for measurement of the frequency of the signal output from the Fluke RF signal generator independent of its front panel display)
Then I plan to look at the phase tracker output as a function of the driving frequency (which will also be measured, offline, using the digital frequency counter setup) over a range of 20 MHz - 50 MHz in steps of 1 MHz. Results to follow.
Earlier tonight, Eric and I tweaked the PMC alignment (the mode cleaner was not staying locked for more than a couple of minutes, for almost an hour).
I performed a preliminary calibration of the X and Y phase trackers, and found that the slopes of a linear fit of phase tracker output as a function of driven frequency (as measured with digital frequency counter) are 0.7886 +/- 0.0016 and 0.9630 +/- 0.0012 respectively (see Attachments #1 and #2). Based on this, the EPICS calibration constants have been updated. The data used for calibration has also been uploaded (Attachment #4).
I found that by adopting the approach I suggested as a fix in elog 11736, and setting a gate time of 1second, I could eliminate the systematic bias in measured frequency I had been seeing, the origin of which is also discussed in elog 11736. This was verified by using a digital oscillator to supply the input to the frequency counting block, and verifying that I could recover the driving frequency without any systematic bias. Therefore, I used this as a measure of the driving frequency independent of the front panel display of the Fluke 6061A.
The actual calibration was done as follows:
Y-arm transmission scan
I used the information from Attachment #2 to calibrate the X-axis of the Y-arm transmission data I collected on Wednesday evening. Looking at the beat frequency on the analyzer in the control room, between 24 and 47 MHz (green beat frequency, within the range the calibration was done over), we saw three IR resonances. I've marked these peaks, and also the 11MHz sideband resonances, in Attachment #3. It remains to fit the various peaks. I did a quick calculation of the FSR, and the number I got using these 3 peaks is 3.9703 +/- 0.0049 MHz. This value is ~23 kHz greater than that reported in elog 9804, but the error is also ~4 times greater (6 IR resonances were scanned in elog 9804) so I think these measurements are consistent.
I had brought an FS725 Rubidium clock back from W Bridge - the idea was to hook this up to the GPS 1PPS output, and use the 10MHz output from the FS725 as the reference for the fluke 6061A. However, the FS725 has not locked to the Rb frequency even though it has been left powered on for ~2days now. Do I have to do something else to get it to lock? The manual says that it should lock within 7 minutes of being powered on. Once this is locked, I can repeat the calibration with an 'absolute' frequency source...
I fitted the data obtained with the FSR and linewidth measurements and I've got FSR and finesse of y-arm by fitting.
The fitted data and the fitting results are attached.
FSR = 3.9704 MHz (ave. of two FSRs, 3.9727 MHz and 3.9681 MHz)
finesse = 401 +/- 11
estimated loss = 1812 (+456 / - 431) ppm
I found peaks from the data and fitted each peak by Lorentzian, automatically with Python (the sourse code I used is attached).
3 parameters of Lorentzian for each peak and their fitting errors are attached.
Then, using 3 peaks of carrier resonance, I calculated FSR, finesse, and loss.
The error of finesse came from that of linewidth.
When calculating the loss, I used the value of 1.384 % for transmission of ITMY.
Since the finesse is mostly determined by the transmission of ITM, the relative error of loss estimation is larger (about 25 % ) though the relative error of finesse is about 3 %. Therefor we have to find the reason why each estimated linewidth varies that largely, and measure finesse more accurately.
I'd like to add a few calculation results, mode matching ratio for Y arm and modulation depth.
Here I assumed peaks marked in the bottom figure shown in elog 11738 as resonances of carrier and modulated sidebands and others as resonances of HOM.
- mode matching ratio = 94.92 +/- 0.19 % WRONG
How I calculated: for each peak of carrier, you can find 6 peaks of HOM resonaces. Then I calculated the sum of the hight of 6 peaks divided by the hight of carrier resonance peak, and took average of this values for 3 resonance peaks of carrier.
- modulation depth = 0.390 +/- 0.062 WRONG
How I calculated: I took average of the hight of 6 peaks of modulated sideband resonance, and normalized it with the hight of peaks of carrier resonance. Using the relation 'normalized hight' = (J_1(m)/J_0(m))^2, I got modulation depth, m.
- modulation depth = 0.390 +/- 0.062
There are two modulation frequencies that make it to the arm cavities, at ~11MHz and ~55MHz. Each of these will have their own modulation depth indepedent of each other. Bundling them together into one number doesn't tell us what's really going on.
As an update to Yutaro's earlier post - I've done an independent study of this data, doing the fitting with MATLAB, and trying to estimate (i) the FSR, (ii) the mode matching efficienct, and (iii) the modulation depths at 11MHz and 55MHz.
The values I've obtained are as follows:
FSR = 3.9704 MHz +/- 17 kHz
Mode matching efficiency = 92.59 % (TEM00 = 1, TEM10 = 0.0325, TEM20 = 0.0475)
Modulation depth at 11MHz = 0.179
Modulation depth at 55MHz = 0.131
Misc Remarks and Conclusions:
After thinking about the interpretation of the various peaks seen in the scan through 2 FSRs, I have revised the information presented in the previous elog. Yutaro pointed out that the modulation frequency isn't exactly 11MHz, but according to this elog, is 11.066209 MHz. So instead of using mod(11e6,FSR), I really should have been using mod(11.066209,FSR) and mod(5*11.066209,FSR) to locate the positions of the 11MHz and 55MHz sidebands relative to the carrier resonances. With this correction, the 'unknown' peaks identified in Attachment #1 in elog 11743 are in fact the 55MHz sideband resonances.
However, this means that the peaks which were previously identified as 55MHz sideband resonances have to be interpreted now - I'm having trouble identifying these. If we assume that the types of peaks present in the scan are 11 MHz sideband, 55MHz sideband, and the TEM00, TEM10, TEM20, TEM30, and TEM40 mode resonances, then the peaks marked in grey in Attachment #1 to this elog can be interpreted as TEM30 (right of a carrier resonance) and TEM40 (left of a carrier resonance) mode resonances - however, the fitted center frequencies differ from the expected center frequencies (determined using the same method as elog 469) by ~3% (for TEM30) and ~20% (for TEM40) - therefore I am skeptical about these peaks, particularly the 4th HOM resonances. In any case, they are the smallest of all the peaks, and any correction due to them will be small.
The updated modulation depths are as follows (computed using the same method as described in elog 11743, the updated plot showing the ratio of bessel functions as a function of the modulation depth is Attachment #2 in this elog):
@11.066209 MHz ---- 0.179
@5*11.066209 MHz --- 0.226
These numbers are now reasonably consistent with those reported in elog10211.
As for the mode-matching efficiency, the overall number is almost unchanged if I assume the TEM30 peaks are accurately interpreted: 92.11%. But the dominant HOM contribution comes from the first HOM resonance: (TEM00 = 1, TEM20 = 0.0325, TEM10 = 0.0475, TEM30 = 0.0056). These numbers may change slightly if the 4th HOM resonances are also correctly identified.
ETMx is still not well behaved and the mode cleaner isnt too happy either, so I think we will save the measurement of the round trip arm loss for daytime tomorrow.
There are two modulation frequencies that make it to the arm cavities, at ~11MHz and ~55MHz. Each of these will have their own modulation depth indepedent of each other. Bundling them together into one number doesn't tell us what's really going on.
I'm sorry. I misunderstood two things when writing elog 11741: the number of modulation frequencies, and how to distinguish modulation peaks and HOM peaks.
Now, I report about interpretation of the peaks marked in grey in Attachment #1 in elog 11745.
The peaks marked in grey are interpreted as 3rd and 4th HOM resonance, if we assume that the radius of curvature of ETMY is slightly different from measured value. (measured: 57.6 m --> assumed: 59.3 m)
What I have done:
I plotted the differences in frequency between HOM peaks and 00 mode peaks (see Attachment #1) vs. expected orders of modes. The plot is shown in Attachement #2.
By fitting these data points, I calculated most likely value of gradient of this plot. This value corresponds: g_ITMYg_ETMY=0.3781. However, measured data of the radii of curvature suggests that g_ITMYg_ETMY=0.358. Assuming that this disagreement comes from the difference between measured and real values of ROC of ETMY (ITM is almost flat so that change of ROC of ITM doesn't have significant effect on g_ITMg_ETM), ROC of ETMY should be 59.3 m, different from measured value 57.6 m.
What I'd like to know:
-- Is such disagreement of ROC usual? Could it happen?
-- Are there any other possible explanations for this disagreement (or interpretations of the peaks marked in grey)?
What is the uncertainty of your RoC estimation?
One measurement of the ETMY ROC was 57.6m, but we trust another measured value of 60.26m than the other.
The value is always dependent on the spotposition on the mirror and how the ROC is calculated from the mirror phase map (e.g. spotsize, averaging method).
So I don't think this is a huge deviation from the spec.
FYI: I've also reported the similar mod depths of
in ELOG11036 with a different kind of measurement method.
The uncertainty came from the residual of linear fitting and based on my estimation,
ROC_ETMY = 59.3 +/- 0.1 m.
And I attach the updated figure of the fitting (with residual zoomed up).
Data points in the lower are (intentionally) slightly shifted horizontally to make it easy for us to see them.
It is hard, I think, to estimate the error of each data point, but I used 17 kHz for the errors of all data points; 17 kHz is the error of FSR estimation of this measurement, and since FSR is the distance between two carrier peaks we can consider that HOM distances, which are the distance between carrier peaks and HOM peaks, have similar order errors comared with that of FSR.
Having obtained a working FS725 Rubidium standard and syncing it to out GPS timing unit, I wanted to have one more pass at calibrating the phase tracker output, with the RF signal generator calibrated relative to an 'absolute' source. I also extended the range of frequencies swept over to 15MHz to 110MHz. We found that the phase tracker output appears linear over the entire range scanned, but taking a closer look at the residuals suggested some quadratic structure. Restricting the fitted range to [31MHz 89MHz] yields the following calibration constants for the X and Y arm respectively: 0.9904 +/- 0.0008 and 0.9984 +/- 0.0005. This suggests that out previous calibration was pretty accurate, and that it is valid over a wider range of frequencies, so we could plausibly fit in more FSRs in future scans if necessary. I have not updated these values on the EPICS screens (though judging by how close they are to 1, I wonder if this is even necessary)...
The principle change in the setup compared to that used to collect the data presented in elog 11738 was the addition of the FS725 rubidium standard. As detailed here, I synced the Rubidium standard to our GPS timing unit (this took a while - the manual suggests it should only take minutes, but it took about 10 hours - the two photos in Attachment #1 show the status of the front panel before and after it synced to the external 1PPS input). I then took 10 MHz outputs from the FS725, and ran one to the Fluke 6061A, and the other to the AG4395A. The Fluke 6061 A has a small switch at the back which has to be set to "EXT" in order for it to use the external reference (it has now been returned to the "INT" state). We then connected the output of the signal generator via a 3-way minicircuits splitter to the AG4395A, and the two beat channels.
I cleared the phase history on the MEDM screen, and set the phase tracker UGF. We then swept through frequencies from 15MHz to 110MHz (using the AG4395 to verify the frequency at each step). I used the following command to record the average value (over 10 seconds) and the standard deviation: z avg 10 -s C1:ALS-BEATX_FINE_PHASE_OUT_HZ >> 20151113_PT_X.dat and so on.. The amplitude of the signal generated (i.e. before the splitter) was -18dBm (chosen such that the Q outputs of either phase tracker was between 1000 and 3000), while the gains were ~100 (X) and 50 (Y). I then downloaded the data and fitted it.
The output of the phase tracker looks roughly linear over the entire range of frequencies scanned - but looking at the residuals, one could say there was some quadratic structure to it (see residual plots in Attachment #2). By looking at the shapes of the residuals, I judged that if we fit in the range [31MHz 89MHz] (for both X and Y), we should see negligible structure in the residuals. Attachment #3 contains the fits and residuals for these fits. One could argue that there is still some structure in the residuals, but is markedly less than over the entire range, and, I think, small enough to be neglected. The calibration constants quoted at the beginning of the elog are from the fits over this range. In principle, we could always break this down into smaller pieces and do a linear fit over that range. But this should allow us to scan through >5 FSRs.
Since the beat signal also goes to the frequency counter via the couplers, I was also collecting the readouts of the frequency counter. Attachment #5 contains the data collected. It is interesting to note that the FCs fail at ~101 MHz (corresponding to ~6146 Hz after the dividers).
Also, we had taken another dataset last night, but found that there was an anomalous kink in the X phase tracker output at (coincidentally?) 89 MHz (I've attached the data in Attachment #6). I'm not sure why this happened, but this is what led me to take another dataset earlier today (Attachment #4).
Summary of Attachments:
I followed a slightly different fitting approach to Yutaro's in an attempt to determine the g-factor of the Y arm cavity (details of which are below), from which I determined the FSR to be 3.932 +/- 0.005 MHz (which would mean the cavity length is 38.12 +/- 0.05 m) and the RoC of ETMY to be 60.5 +/- 0.2 m. This is roughly consistent (within 2 error bars) of the ATF measurement of the RoC of ETMY quoted here.
I set up the problem as follows: we have a bunch of peaks that have been identified as TEM00, TEM10... etc, and from the fitting, we have a bunch of central frequencies for the Lorentzian shapes. The equation governing the spacing of the HOM's from the TEM00 peaks is:
The main differences in my approach are the following:
The frequency source was fixed. The IMC LO level was adjusted.
IMC is locked => OLTF measured UGF 144kHz PM 30deg.
The trouble we had: the 29.5 MHz source had an output of 6 dBm instead of 13 dBm.
The cause of the issue: A short cable inside had its shield cut and had no connection of the return.
- The frequency source box was dismantled.
- The power supply voltages of +28 and +18 were provided from bench supplies.
- The 29.5 MHz output of 5~6 dBm was confirmed on the work bench.
- The 11 MHz OCXO out (unused) had an output of 13 dBm.
- Once the lid was opened, it was immediately found that the output cable for the 29.5 MHz source had a sharp cut of the shield (Attachment1).
- OK. This cable was replaced. The output of 13 dBm was recovered.
- But wait. Why is the decoupling capacitor on the 29.5 MHz OCXO bulging? The polarity of the electrolytic capacitor was wrong!
- OK. This capacitor was replaced. It was 100 uF 35 V but now it is 100 uF 50 V.
- I further found some cables which had flaky shields. Some of them were twisted. When the panel cable s connected, the feedthroughs were rotated. This twists internally connected cables. Solder balls were added to the connector to reinforce the cable end.
- When the box was dismantled, it was already noticed that some of the plastic screws to mount the internal copper heat sinks for ZHL-2's were broken.
They seemed to be degraded because of the silicone grease. I didn't try to replace all as it was expected to take too much time, so only the broken screws
were replaced with steel screws with shoulder washers at the both side of the box.
- After confirming the circuit diagram, the box was returned to the rack. The 29.5 MHz output of 13 dBm there was confirmed.
Gautam couldn't observe a Y green beatnote earlier, so we checked things out, fixed things up, and performance is back to nominal based on past references.
Sorry, I completely forgot to turn the Marconi on...
I misaligned ITMX. The oplev servo for ITMX is now turned off. You can restore ITMX alignment by running "restore".
I measured round trip loss of Y arm. The alignment of relevant mirrors was set ideal with dithering (no offset).
round trip loss of Y arm: 166.2 +/- 9.3 ppm
(In the error, only statistic error is included.)
How I measured it:
I compared the power of light reflected by Y arm (measured at AS) when the arm was locked (P_L) and when ETMY was misaligned (P_M). P_L and P_M can be described as
The reason why P_L takes this form is: (1-alpha)*4T_ITM/(T_tot)^2 is intracavity power and then product of intracavity power and loss describes the power of light that is not reflected back. Here, alpha is power ratio of light that does not resonate in the arm (power of mismatched mode and modulated sideband), and T_tot is T_ITM+T_loss. Transmissivity of ETM is included in T_loss. I assumed alpha = 7%(mode mismatch) + 2 % (modulation) (elog 11745)
After some calculation we get
Here, higher order terms of T_ITM and (T_loss/T_ITM) are ignored. Then we get
Using this formula, I calculated T_loss. P_L and P_M were measured 100 times (each measurement consisted of 1.5 sec ave.) each and I took average of them. T_ETM =13.7 ppm is used.
-- This value is not so different from the value ericq reported in July (elog 10248).
-- This method of measuring arm loss is NOT sensitive to T_ITM. In contrast, the method in which loss is obtained from finesse (for example, elog 11740) is sensitive to T_ITM.
In the method I'm now reporting,
but in the method with finesse,
In the latter case, if relative error of T_ITM is 10%, error of T_loss would be 1000 ppm.
So it would be better to use power of reflected light when you want to measure arm loss.
We disconnected the cable that was connected to CH5 of the whitening filter in 1Y2, then connected POYDC cable to there (CH5). This channel is where POYDC used to connect.
Then we turned on the whitening filter for POYDC (C1:LSC-POYDC FM1) and changed the gain of analog whitening filter for POYDC from 0 dB to 39 dB (C1:LSC-POYDC_WhiteGain).
I slightly changed the orientation of a few mirrors on AS table that are used to make the AS light get into PDs, in order to confirm that the strange behavior of ASDC (I will report later) is not caused by clipping related to these mirrors or miscentering on PDs.
Then output level of ASDC, AS55, and AS165 could have changed.
So take care of this possible change when you do something related to them. But the relative change of them would be at most several %, I think.
I noticed that ASDC level changes depending on the angle of ITMY when trying to take some data for loss map of YARM. We finally found that ASDC level behaves strangely when the angle of ITMY in yaw direction is varied, as you can see in Attachment 1. Now, AS port recieved only the reflection of ITMY.
NOTE: This behavior indicates that angular motion could couple to length signal in AS port.
Koji suggested that this behavior might be caused by interference at SR2 or SR3 between main path light and the light reflected by the AR surface. By rough estimation, we confirmed that this scenario would be possible. So it would be better to measure AR reflection of the same mirror to ones used for SR2 and SR3 in term of incident angle.
Ed by KA: This senario could be true if the AR reflection of teh G&H mirrors have several % due to large angle of incidence. But then we still need think about the overlap between the ghost beam and the main beam. It's not so trivial.
Due to the strange behavior (elog 11815) of ASDC level, we checked if it is possible to use POYDC instead of ASDC to measure the power of reflected light of YARM. Attached below is the spectrum of them when the arm is locked. This spectrum shows that it is not bad to use POYDC, in terms of noise. The spectrum of them when ETMY is misaligned looked similar.
So I am going to use POYDC instead of ASDC to measure arm loss of YARM.
Ed by KA:
The spectra of POYDC and ASDC were measured. We foudn that they have coherence at around 1Hz (good).
It told us that POYDC is about 1/50 smaller than ASDC. Therefore in the attached plot, POYDC x50 is shown.
That's the meaning of the vertical axis unit "ASDC".
Uploaded on T1000461 too.
Tonight I measured "loss map" of ETMY. The method to calculate round trip loss is same as written in elog 11810, except that I used POYDC instead of ASDC this time.
How I changed beam spot on ETMY is: elog 11779.
I measured round trip loss for 5 x 5 points. The result is below.
494.9 +/- 7.6 356.8 +/- 6.0 253.9 +/- 7.9 250.3 +/- 8.2 290.6 +/- 5.1
215.7 +/- 4.8 225.6 +/- 5.7 235.1 +/- 7.0 284.4 +/- 5.4 294.7 +/- 4.5
205.2 +/- 6.0 227.9 +/- 5.8 229.4 +/- 7.2 280.5 +/- 6.3 320.9 +/- 4.3
227.9 +/- 5.7 230.5 +/- 5.5 262.1 +/- 5.9 315.3 +/- 4.7 346.8 +/- 4.2
239.7 +/- 4.5 260.7 +/- 5.3 281.2 +/- 5.8 333.7 +/- 5.0 373.8 +/- 4.9
The correspondence between the loss shown above and the beam spot on ETMY is shown in the following figure. In the figure, "downward" and "left" indicate direction of shift of the beam spot when you watch it via the camera (ex. 494.9 ppm corresponds to the lowest and rightest point).
Edited below on 28th Nov.
To shift the beam spot on ETMY, I added offset in YARM dither loop. The offset was [-30,-15,0,15,30]x[-10,-5,0,5,10] for pitch and yaw, respectively. How I calibrated the beam spot is basically based on elog 11779, but I multiplied 5.3922 for vertical direction and 4.6205 for horizontal direction which I had obtained by caliblation of oplev (elog 11785).
Edited above on 28 th Nov.
I will report the detail later.
Here, I upload data I took last night, including the power of reflected power (locked/misaligned) and transmitted power for each point (attachement 1).
And I would like to write about possible reason why the loss I measured with POYDC and the loss I measured with ASDC are different by about 60 - 70 ppm (elog 11810 and 11818). The conclusion I have reached is:
It could be due to the strange bahavior of ASDC level.
This difference corresponds to the error of ~2% in the value of P_L/P_M. As reported in elog 11815, ASDC level changes when angle of the light reflected by ITMY changes, and 2% change of ASDC level corresponds to 10 urad change of the angle of the light according to my rough estimation with the figure shown in elog 11815 and attachment 2. This means that 2% error in P_L/P_M could occur if the angle of the light incident to YARM and that of resonant light in YARM differ by 10 urad. Since the waist width of the beam is ~3 mm, with the 10 urad difference, the ratio of the power of TEM10 mode is , where . This value is reasonable; in elog 11743 Gautam reported that the ratio of the power of TEM10 was ~ 0.03, from the result of cavity scan. Therefore it is possible that the angle of the light incident to YARM and that of resonant light in YARM differ by 10 urad and this difference causes the error of ~2% in P_L/P_M, which could exlain the 60 - 70 ppm difference.
I found that TRY level degraded and the beam shape seen with CCD camera at AS port was splitted when the beam spot on ETMY was not close to the center. This was because dither started not working well. I suspect so because in such a case TRY level went up when I did iteration with TT1 and TT2 after freezing dither. Splitted beam shape indicates that incident light did not match well with the cavity mode.
TRY level for each point was this:
[[ 0.6573 0.8301 0.8983 0.8684 0.6773 ]
[ 0.7555 0.8904 0.9394 0.8521 0.6779 ]
[ 0.6844 0.8438 0.9318 0.8834 0.6593 ]
[ 0.7429 0.8688 0.9254 0.8427 0.6474 ]
[ 0.7034 0.8447 0.8834 0.8147 0.6966 ]]
In the worst case, TRY level was 70 % of the maximum level. Assuming that this degrade was totally due to the mode mismatch, this corresponds to ~50 urad difference between the angle of incident light and resonant lighe in the arm (see elog 11819).
I need some more hints to understand the improvement, although its generally good to re-build it considering the sad state of the assembly/installation that you found.
I see that the current design brings the 11 MHz signal to -2 dBm before intering the first ZHL-2+, but since that has a NF of 9 dB, that seems to only degrade the phase noise to -2 - (-174 +9) = -163 dBc. That seems OK since we only need -160 dBc from this system. Probably the AM noise is worse than this already (we should remember to hook up a simple AM stabilizer in 2016, as well as the ISS).
What else are the main features of this improvement? I can reward a good summary with some Wagonga.
I'm not claiming we need to modify the frequency source immediately as we are not limited by the oscillator amplitude or phase noise.
I just wanted to note something in mind before it goes away quickly.
Alberto's T1000461 tells us that the oscillator and phase noise are degraded by factor of ~3 and ~5 due to the RF chanin.
My diagram is possible removal of up-down situation of the chain.
Maybe more direct improvement would be:
- Removal of two amplifiers out of four. The heat condition of the box is touch thought it is not critical.
- The modification will allow us to have a spare 11MHz channel at 1X2 rack that would be useful for 3f modulation.