We have looked at a few things that do and don't affect the out of loop noise of the ALS X beat, and found that cavity alignment and beatnote RF frequency had the strongest effects.
Possible causes of noise:
1. Air currents from A/C or flowbench. No effect.
* When table lid is on, turning on and off the flow bench air did not qualitatively change the out of loop beatnote time series signal.
2. Scattered light from other beams hitting green PDH PD. No effect.
* There are a few spots of green light that are hitting the case of the PDH photodiode, but when I put an iris in place to block those spots, there was no change in the beatnote spectra. This makes sense to me since none of those spots were close to hitting the diode itself.
* Rana did notice that the beam was not well centered on the PD, so he steered the beam onto the center of the diode. Also, the PD is now tilted a little bit so that the reflection from the diode doesn't go back into the beam path. Neither of these things had an effect that we noticed in the beatnote noise.
3. Oplev laser light getting to PDH PD. Not tested.
* We don't see any red light over by the PDH PD, so we did not try turning off the oplev's laser to see if that had an effect, but we suspect that it is not the cause of our noise.
4. Clipping of main IR / green beam on Xend table. Not tested.
* We should still go have a look at this, but we no longer think that this is the main cause of the elevated noise.
5. Scattered light all over Xend table. Not tested.
* We should still work on dumping extraneous beams on the table, but we do not think that this is the main cause of the elevated noise.
* Rana took some photos so that we can see how truely bad the situation is.
6. Amplitude modulation dip in NPRO. Not tested.
* It is probably still a good idea to check this, in case the dip in the amplitude modulation has changed over the year or two since it was last measured, but we also don't think that this is the main problem.
7. Check PDH servo. Not done.
* I think this is still on Q's long-term todo list, but we should give the PDH servos a once-over.
8. Arm cavity longitudinal motion. No effect.
* While the Xarm was locked with IR, we put a line at 1.7 Hz with 325 counts into the ITMX position. To keep lock, the ETM had to move as well. When we turned on this line (and increased its amplitude up to the final value of 325 cts), we did not see any qualitative change in the beatnote time series noise.
9. Arm cavity alignment. Significant DC effect.
* When the alignment of one of the arm cavity mirrors is changed, the DC value of the beatnote signal changes.
* ITMX moved in yaw, we see a 7kHz/15urad DC shift in the BEATX_FINE_PHASE_OUT_HZ time series.
* ETMX moved in yaw, we see an 8kHz/5.5urad DC shift in the time series. We aren't sure why this is about a factor of 3 times larger effect (same shift for smaller misalignment) than the ITM.
* We want to do a Yuta-style analysis to see what the angle to length coupling looks like, so that we can measure the angular motion of our cavity mirrors and put the expected noise into our ALS noise budget. Perhaps this will help us understand the low frequency difference between our in-loop beatnote error signal and our in-loop PDH error signals (red vs. maroon on the ALS noise budget posted above Pianosa).
* I've asked Manasa to take some transfer functions in the morning, so that we can start to have an idea of what is going on with this.
10. Beatnote RF frequency. Significant broadband effect.
* We have found that when the Xarm beatnote is at low RF frequencies, the noise is high, and when the beatnote is at high RF frequencies, the noise is low!
* Low RF freqs are below about 40 MHz, while high RF freqs are above about 90 MHz. This has not been tested for the Yarm. Also, these are for the case of "temp slider up, beatnote up". I have not checked if the same is true for the other side of the PSL frequency, although I don't have reason to believe that it would be.
* Maybe we are saturating some amplifiers? We need to check this out. One thought that Den mentioned was the harmonics, and that perhaps they are causing trouble in the electronics.
* Den is going to think about implementing a frequency divider so that we can directly digitize the beatnote signal.
* Here are spectra for different cases:
* And here is a spectrogram showing us going back and forth between the high and low noise states:
* A: First noticing that noise is good when RF frequency is high.
* B: Not locked on TEM00 mode, so extra noisy. Disregard.
* C: Bad noise time. Xbeat was 21 MHz (dark purple on DTT spectrum above), Ybeat was 118 MHz (sea green on DTT spectrum above).
* D: Good noise time. Xbeat was 89 MHz (light purple on DTT plot), Ybeat was still 118MHz (turquoise on DTT plot).
* E: Bad noise time. Xbeat was 37.5 MHz, Ybeat was still 118 MHz.
* F: Good noise time. Xbeat was 113 MHz, Ybeat was still 118 MHz.
Attached is the measurement of the transfer function from ITMX oplev error in yaw to the ALSX error signal.
The arm was locked to the IR using POX and the green beat frequency (between X arm trans in green and PSL green) in this case was 27MHz.
The transfer function looks mostly flat between 1Hz - 30Hz at 700-800 Hz/urad. The DC shift that Jenne measured from the time series is ~500 Hz/urad.
So far I have not been able to measure the TF below 1Hz without the arm losing its lock. Updates will follow.
Data xml file can be found in /users/manasa/data/140521/
Below are the transfer functions measured between the angular (pit, yaw) motion of X arm mirrors and the ALSX error signal. The measurements were again made for 1Hz-30Hz.
The transfer functions are mostly flat.
ITMX P - 200-300 Hz/urad (beat freq = 45 MHz)
ITMX Y - 700-800 Hz/urad (beat freq = 27MHz)
ETMX P - 500-600 Hz/urad (beat freq = 56 MHz)
ETMX Y - 1000-2000 Hz/urad (beat freq = 62.5MHz)
Data xml files can be found in /users/manasa/data/140521/
I saw big misalignment on the GTRX camera, I went to the PSL table and aligned the beat beams.
I disconnected the RF out of the X beat PD and connect an oscilloscope.
The beat amplitude was 15mVpp at the beginning and is 60mVpp right now.
I checked the alignment on this RF PD and the DC PD as well as the spot on the CCD.
The RF cable was connected again.
Jenne and I ran the ALS and scanned the arm cavity. We had the impression that the noise level of the ALS improved,
but I don't have correctly calibrated measurement. Let's do it tomorrow in the day time.
The Yarm beat alignment look awful. We should align this too.
The X and Y arms were locked successfully using ALS and the arms could be scanned and held to support IR resonance.
The same procedure as in elog 9219 was followed. In-loop noise was measured to be between 200-300 Hz rms for the lock.
ALS settings for the lock
X arm : FM 2, 3, 5, 6, 7, 8, 10 Gain = 11.0
Y arm : FM 2, 3, 5, 6, 7, 8, 10 Gain = 10.0
Nice restoration. We eventually want to make transition of the servo part from ALS to LSC model for the further handing off to the other signals.
Please proceed to it.
Nic, Jenne, EricQ, and Koji should describe the demonstartion of CESAR achieved tonight.
Q and I have started to use the ALS slow servo for the end aux lasers while locking the arms using ALS. The servo prevents us from hitting the limits of the PZT range for the end lasers and a better PDH locking.
But keeping the servo ON causes the slow output to drift away making it hard to find the beat note everytime the arm loses lock. The extensive beat note search following the unlock can be avoided by clearing history of the slow servo.
Q and I have started to...
I've not updated the MEDM screens to reflect the two new paths yet, but will do so soon. It also remains to install appropriate filters for the servo path that takes the frequency readout as the input.
A few more related changes:
Here is our first attempt at a single-arm noise budget for ALS.
Attachment 1 shows the loop diagram we used to calculate the contribution of different noises.
Attachment 2 shows the measured noise at C1:ALS-BEATX_PHASE_FINE_OUT_HZ when XARM was locked to the main laser and Xend Green laser was locked to XARM.
Here's an updated X ARM ALS noise budget.
[Meenakshi, Gautam, Shruti]
- We initially aligned the arm cavities to get the green lasers locked to them. For the X arm cavity, we tweaked the ITMX and ETMX pitch and yaw and toggled the X green shutter until we saw something like a TEM00 mode on the monitor and a reasonable transmitted power.
- With the LSC servo enabled, the IR light also became resonant with the cavities.
- Then we measured the noise in different configurations. Attachment 1 shows the the ALS OOL (in the IR beat signal) noise with the arms locked inidividually via PDH.
The script for plotting the ALS beat frequency noise is:
Even though we were not able to lock the the IR beat (by enabling LSC) during the day possibly because of increased seismic activity, we tried to the measure the ALS beat frequency noise by changing the PDH side-band frequency to different values.
I tried choosing values that corresponded to the peaks in the PM/AM as found in elog:15206 but for some reason unknown to us the cavity did not lock between 700-800 kHz.
The three attachments have data for different sideband frequencies:
Attachment 1: 819.472 kHz (peak in PM/AM, measured around noon)
Attachment 2: 225.642 kHz (peak in PM/AM, measured earlier in the morning)
Attachment 3: 693.500 kHz (not a peak in PM/AM)
We don't think these plots mean much and will do the measurement at some quieter time more systematically.
While doing the experiment, the ITMY pitch actuation was changed from -2.302 to -2.3172V because it locked better.
The ITMX, ETMX alignment was also tweaked to try to lock with different sideband frequencies and then restored to the values that were found earlier in the morning.
Unlikely, the alignment was probably just not good. I restored the alignment and now the arms can be locked to IR frequency.
Even though we were not able to lock the the IR beat (by enabling LSC) during the day possibly because of increased seismic activity
We proceeded with the trying to measure the ALS out-of-loop noise of the X arm when the X arm cavity is green-locked using different PDH sideband frequencies.
Before doing the experiment, Koji helped us with getting the arm cavities locked in IR using LSC (length) and ASC (angular).
With the arms locked in IR and green, we repeated the same measurements as before at different sideband frequencies (Refer Attachment 1 - label in Hz). We did not optimize the phase nor did we look at the PDH error signal today which is possibvly why we did not see an improvement in the noise. We will look into this possibly tomorrow.
Could you please put physical units on the Y-axis and also put labels in the legend which give a physical description of what each trace is?
It would also be good to a separate plot which has the IR locking signal and the green locking signal along with this out of loop noise, all in the same units so that w can see what the ratio is.
In order to adjust the relative phase for PDH locking, we used the Siglent SDG 1032X function generator which has two outputs whose relative phase can be adjusted.
This Siglent function generator was borrowed from Yehonathan's setup near the PSL table and can be found at the X end disconnected from our setup after our use.
Initially, we used the Siglent at 231.250 kHz and 5 Vpp from each output with zero relative phase to lock the green arm cavity. By moving the phase at intervals of 5deg and looking at the PDH error signals when the cavity was unlocked we concluded that 0deg probably looked like it had the largest linear region (~1.9 V on the yaxis. Refer elog 15218 for more information) as expected.
Then we tried the same for 225.642 kHz, 5 Vpp, and found the optimal demod phase to be -55deg, with linear region of ~3 V (Ref. Attachment 2). A 'bad' frequency 180 kHz was optimized to 10deg and linear region of ~1.5 V.
The error signals at higher frequencies appeared to be quite low (not sure why at the moment) and tuning the phase did not seem to help this much.
For the noise measurement, the IFO arms were locked to IR and green, but even after optimizing the transmission with dither, we couldn't achieve best locking (green transmission was around ~0.2). Further, the IMC went out of lock during the experiment after which Koji helped us by adjusting the gains a locking point of the PMC servo. Attachment 1 contains some noise curves for the 3 frequencies with a reference from an earlier 'good' time.
to make the comparisons meaningfully
one needs to correct for the feedback changes
Attachment #1 shows a first look at the IR ALS noise after my re-coupling of the IR light into the fiber at EY.
CDS model changes:
In preparation for resuming IFO locking activities, I measured the ALS noise with the arm lengths locked to IR, AUX laser frequencies locked to the arm lengths. Looks promising (y-axis units are Hz/rtHz).
Attachment #1 shows the results of my measurements tonight (SR785 data in Attachment #2). Both loops have a UGF of ~10kHz, with ~55 degrees of phase margin.
Excitation was injected via SR560 at the PDH error point, amplitude was 35mV. According to the LED indicators on these boxes, the low frequency boost stages were ON. Gain knob of the X end PDH box was at 6.5, that of the Y end PDH box was at 4.9. I need to check the schematics to interpret these numbers. GV Edit: According to this elog, these numbers mean that the overall gain of the X end PDH box is approx. 25dB, while that of the Y end PDH box is approx. 15dB. I believe the Y end Lightwave NPRO has an actuator discriminant ~5MHz/V, while the X end Innolight is more like 1MHz/V.
Not sure what to make of the X PDH loop measurement being so much noisier than the Y end, I need to think about this.
More detailed analysis to follow.
I am now going to measure the OLTFs of both green PDH loops to check that the overall loop gain is okay, and also check the measurement against EricQ's LISO model of the (modified) AUX green PDH servos. Results to follow.
Didn't someone look at what the OLG req. should be for these servos at some point? I wonder if we can make a parallel digital path that we switch on after green lock. Then we could make this a simple 1/f box and just add in the digital path (take analog control signal into ADC, filter, and then sum into the control point further down the path to the laser) for the low frequency boost.
I calibrated the ALS-OFFSETTER output.
I measured the FSR of cavity in unit of counts. That was 395 counts. Our cavity FSR is 3.8 MHz, so 1 count of the OFFSETTER output is 9.7 kHz.
I calibrated the ALS-OFFSETTER output.
I measured the FSR of cavity in unit of counts. That was 395 counts. Our cavity FSR is 3.8 MHz, so 1 count of the OFFSETTER output is 9.7 kHz.
Really? What cavity length did you use in the calculation?
I'm playing around with the lastest ALS fool feedforward on the Yarm, and I like what I'm seeing.
First, I verified that I could reproduce the TF shapes in ELOG 11041, which I was able to do with a gain of +9.3 and FMs 5 and 6 in the FF module.
Then, I locked the arm on ALS with full bandwidth, and on POY with the settings currently used the MC module, and took their spectra as references. (I put an excitation on the arm at 443Hz to line them up to the same arbitrary units.)
Then, with ALS at its usual 100Hz UGF and boosts on, the Fool path on, and the MC FM set to trigger on/off at 0.8/0.5, I slowly brought ALS towards zero offset and saw it pop right into resonance. I then manually triggered the PDH boosts.
Here are some spectra, showing that, with the Fool path on:
Once the PDH loop is running, the ALS loop can be switched out at the CARM FM output without much of an effect beyond a small kick.
However, looking at the loop shapes, maybe I got lucky here. I took the usual injection TFs at the MC FM, the CARM FM, and at ETMY, to get the overall OLG; all of them have >0.9 coherence pretty much everywhere except the first two points.
As desired, the PDH loop looks pretty normal.
I have no intuition about how the fooled CARM loop should look, since this is even more complicated than a two-loop system.
I don't currently know what is causing the odd feature in the overall at ~50Hz, and it spooked me out when I saw the multiple UGF crossings. The only thing I could think of happening there is the pole in the ALS phase tracker boost. I turned it off, and remeasured; the feature persists...
To wrap it up, here's something I think is pretty cool. Here's what happens when I give ETMY a 1000 count position step impulse (no ramp). [Here, CARM is on ALS with G=12, but only FM5 on]
Although the arm was controlled with IR before the kick, ALS maintained control. As soon as ALS brought the arm back towards resonance, the PDH loop picked it right back up.
Some random notes:
DTT data is attached, in case it's useful to anyone!
Koji raised a good question about the step response I wrote about. Namely, if the UGF of the ALS servo is around 100Hz, we would expect it to settle with a characteristic time on the order of tens of milliseconds, not seconds, as was seen in the plot I posted.
I claim that the reason for the slow response was the fact that the feedforward FM stayed on after the kick, despite the MC filter bank being triggered off. Since it has filters that look like a oscillator at 1Hz, the ringdown or exponential decay of this filter's output in response to the large impulsive output of the PDH control signal just before being triggered down would slowly push the ALS error signal around through the feedforward path.
Given this reasoning, this should be helped by adding output triggering to the FF filter that uses the MC trigger matrix row, as I wanted to do anyways. I have now added this into the LSC model (as well as DQ at 2kHz for the MC_CTRL_FF_OUT), and the impulse response is indeed much quicker.
In the following plot, I hit ETMY with a five sample, 5000 amplitude, impulse (rather than a step, as I did yesterday). The system comes back to PDH lock after ~40ms.
The cancellation went from ~10 dB to ~30 dB. This seems good enough. The new filter 'Comp1' is just constructed by eye. We then had to tune the filter module gain to a few %. Seems good enough for now, but we should really try to understand what it is and why it is the way that it is. In the above plot, the ORANGE trace is the old cancellation and the GREEN one is the new one. The filter TF is attached below - its not special, we made it by presing buttons in FOTON until the TF matched the measured TF of ALSY/LSC-MC_CTRL_FF_OUT.
Koji had suggested that I sync up the two function generators to ensure that they have the same base frequency and so that crosstalk will actually appear at the expected frequency. After syncing up the two function generators, I drove the following frequencies through each cable:
X: 29.537 MHz Y: 29.5372 MHz
X: 29.545 MHz Y: 29.5452 MHz
Each time, the difference between the frequencies was 200 Hz, so if there was crosstalk, a spike should appear in the PSDs at 200 Hz when frequencies are being driven through both cables simulataneously, but not when just one is on. We very clearly see a spike at 200 Hz in both the X arm and the Y arm with the conductive SMAs, indicating crosstalk. For the front panel with isolated SMAs, we see a spike at 200 Hz when both frequencies are on, but it is much less pronounced than with the conductive SMAs. It seems as though there will be crosstalk using either panel, just less with the isolated SMAs.
I tested both of the front panels (conductive and isolated SMAs) with the ALS Delay Line Box by driving extremely close frequencies through the cables. By doing this, we would expect that a spike would show up in the PSD if there was crosstalk between the cables.
In the plots below, for the conductive panel, the frequencies used were
X Arm: 22.329 MHz Y Arm: 22.3291 MHz
For the isolated panel, the frequencies were
X Arm: 22.294 MHz Y Arm: 22.2943 MHz
This gives a difference of 100 Hz for the conductive panel and 300 Hz for the isolated panel. Focusing on these areas of the PSD, it can be seen that in the Y Arm cable there is a very clear spike within 30 Hz of these differences when frequencies are being driven through both cables as opposed to the signal being in only the Y Arm. In the X Arms, the noise in general is higher when both cables are on, but there is no distinct spike at the expected frequencies. This indicates that some sort of crosstalk is probably happening due to the strong spikes in the Y Arm cables.
The front panels for the ALS delay line box came in last week. Some of the holes for the screws were slightly misaligned, so I filed those and everything is now put together. I just need to test both front panels to determine if the SMAs should be isolated or not.
Koji had also suggested making the holes in the front and back panel conical recesses so that flat head screws could be used and would counteract the anodization of the panel and avoid the SMAs being isolated. I think if we did that then conductivity would be ensured throughout the panel and also through the rest of the box. I also think one way we could test this before drilling conical recesses would be to test both front panels now, as one has isolated SMAs and one has conductive SMAs. If the anodization of the panel isolated the SMA regardless, we could potentially figure this out by testing both panels. But, would it also be that it is possible that the isolation of the SMA itself does not matter and so this test would tell us nothing? Is there a better way to test if the SMAs are being isolated or not? Or would this be more time consuming than just drilling conical recesses as a preventative measure?
We've been having trouble tuning the ALS DIFF matrix. Trying to see if the MC2 EXC can be cancelled in ALS DARM by adjusting the relative gains in ALSX and ALSY Phase Tracker outputs.
There's a bunch of intermittent behavior. Between different ALS locks, we get more or less cancellation. We were checking this by driving MC2 at ~100-400 Hz and checking the ALS response (with the ALS loops closed). We noticed that the X and Y readbacks were different by ~5-10 degrees and that we could not cancel this MC2 signal in DARM by more than a factor of 4-5 or so. In the middle of this, we had one lock loss and it came back up with 100x cancellation?
Attached is a PDF showing a swept sine measurement of the ALSX, ALSY, and DARM signals. You can see that there is some phase shift between the two repsonses leading to imperfect cancellation. Any ideas? Whitening filters? HOM resonance? Alignment?
Here are my thoughts on calibration errors. This applies to the single arm actuation calibration, but may easily be extended to calibrate the DARM residual noise for example.
According to the math in this post, there are four parameters whose estimates build the total calibration uncertainty: arm length, wavelength, loop gain, and beatnote fluctuation. Below is a table for how each is measured, what the sources of statistical versus systematic error are, how large each relative contribution roughly is, and how we may improve on them.
The arm length has been estimated before by locking the arm with the ALS beat, scanning the arm length and looking at the IR resonances. From the statistical uncertainty standpoint the limit seems to be number of measurable FSRs. Using these numbers, the statistical uncertainty comes to ~ 0.6%. Other attempts claim to have improved on this by almost an order of magnitude giving ~ 0.02%. Simply scanning over more FSRs should improve this as the usual square root number of measurements statistical error reduction.
Systematic error comes from the frequency referenced on this measurement (the Marconi 11 MHz sideband oscillator), nonlinearities in the mostly linear scan (e.g. POS to PIT coupling). I think it's safe to neglect frequency offsets > 1 Hz because of the Rb clock reference and the Marconi's own calibration. I'm not sure about the POS to PIT coupling magnitude and whether F2A filters are helping here, but offset scan nonlinearities should distort the FSR nonuniformly and this error may have sneaked into the statistical estimate above. From the posts referenced above, the scan result seems extremely linear, but repeating the measurement and plotting the residuals may give an accurate estimate of the nonlinearity. I think either of the systematic errors discussed here should be below or around the ppm (0.0001%) level, but this should be confirmed.
If we use the NPRO specification Mephisto's wavelength is 1064 nm and there is no statistical error.
If on the other hand we do iodine absorption spectroscopy, we may be able to see ~ 4 lines throughout the 30 GHz tuning range of the NPRO. Fun fact: 30 GHz correspond to 1 cm-1 (inverse centimeter). Assuming we can scan our laser with a 0.01 cm-1 resolution, it may be possible to estimate the absolute wavelength to 10 better than any line center. The ATLAS of iodine spectroscopy gives strong absorption lines around 532 nm to 0.001 cm-1, or 0.00001% accuracy. A simple Doppler broadened absorption should improve this further.
If we use the NPRO specification the systematic error comes from the number of known significant figures ~ 0.047 %. A slightly better estimate comes from the Prometheus model with a frequency doubled output hitting near the P 83(33-0) line of iodine, at 18787.814 cm-1. This gives a nominal wavelength of 532.259 nm, or 1064.518 nm on the seed. Because the tuning range is 30 GHz, our systematic error may be +0.03 nm - 0.07 nm from 1064.52 nm. Taking the median of 0.05 nm, the relative systematic error from the Nd:YAG specification is 46.9 ppm = 0.0047%.
If on the other hand we do iodine spectroscopy, the systematic error will be dominated by the residual shifts on the iodine vapor, which are negligibly small compared to the Doppler broadened lines. They might add sub-ppm uncertainty to the absolute calibration.
The error in estimating beatnote fluctuations is statistically dominated if our beat detection is shot noise limited for example. Other stationary noises with power law spectra decaying faster than 1/f are subject to this effect. The allan deviation discriminates the timescales at which our measurement is dominated by statistical error. Currently our calibration lines have SNR of 10 to 100. Averaging seems to be limited to ~ 100 second timescales, so the statistical error on these measurements is ~ 0.1 to 1.0 %.
As suggested in the above, the allan deviation discriminates the statistical dominated timescales for this measurement. There is a correspondence between noise spectra and allan deviation, so we should be able to point out what noises contribute to systematic drift in our ALS noise budget.
Also from B&P, we should estimate how biased our TF is. This depends on delays, bandwidths, measurement device noises, etc. Furthermore, the analog electronics in the AUX servo should drift, but we neglect this contribution for now. A simple bias estimate (eq 9.75) tells us that the coherence is biased by the number of averages such that in our estimate above the unbiased coherence is roughly 0.897. This means our systematic contribution from TF bias is ~ 0.17 %.
We should remember that in the case of loop gain, the total error (systematic + statistical) gets an extra suppression factor of the order of the loop gain itself. Radhika's resonant digital gain filters should easily allocate 40 dB (or ~ 100) on every calibration line such that our total calibration error drops to the 0.1% level.
The IFO is being uncooperative tonight, and I have an early morning meeting, so I'm calling it a night.
Koji's filter module changes have been propagated from the Xarm to the Yarm, to CARM and to DARM. (Actually, Q overwrote the changes to Xarm on Sunday accidentally, so first he reverted those for us, and then we propagated the changes).
Today, with careful measuring, we find that for X and Y arms individually locked with the ALS, we want the gains to be +17 for the Yarm, and -17 for the Xarm (with the beatnote up-is-up convention). This puts the UGFs at 150 Hz.
We then switched over to CARM and DARM locking. We guessed that the gains should be a factor of 2 lower since we're pushing on both ETMs for DARM, and the MC2 actuator is roughly the same strength as the sum of the ETMs. In the end, after measuring the CARM and DARM loops, we find that the gains should be +7.5 for CARM, and +8.0 for DARM to set the UGFs at 150 Hz. The servo is a little bit delicate, so having too low of gain is not okay.
For some reason, we seem to be utilizing more actuator range with the new setup, so the limiters in the filter banks have been set to 11,000 (previously were 8,000), and the ALS watch script (ALSdown.py) threshold has been increased to 10,000 (previously 7,000).
When finding the IR resonances with the new scheme, we are having trouble holding lock throughout the scan. I have set the tramp for the coarse part of the scan to be 0.05 seconds (previously 0.01 seconds), which is an increase of a factor of 5 in the ramp time. This helps, but may still not be enough, since we don't always hold lock until both IR resonances are found.
Probably the most annoying thing from tonight is the fact that ETMY keeps drifting off, particularly in yaw, when locked. I don't have an explanation of why this is happening, but you can watch it happen sometimes, and the lock will be lost shortly thereafter. Definitely when we lose lock and the ETM gets kicked, it is far enough away in yaw alignment that I have to completely redo the Yarm alignment. This happens whether or not the ETMY oplevs are on.
To summarize, 3 scripts have been modified:
(1) ALSdown - threshold increased (Modification from last week - turns off the slow temp servos for the end lasers, clears histories)
(2) ALSfindIRresonance - increase ramp time
(3) Lock_ALS_CARMandDARM - final gain values set to 7.5 for CARM and 8 for DARM, no filters come on until gains all the way up, turns on new set of Koji filters. (Modification from last week - turns on the slow temperature servos for the end lasers)
ALS common locked by actuating on MC2 and ALS Differential locked by actuating on ETMX and ETMY (Stable lock acquired for over an hour).
Common and Differential offsets were swept to obtain IR resonance in both the arms (arms stayed on resonance for over 15 minutes).
1. Configured LSC settings to allow locking using ALS error signals.
2. Locked common and differential using ALS error signals
XARM 1 -1
YARM 1 1
X arm servo settings:
FIlters: FM1, FM5, FM6, FM7, FM9
Gain = -8.0
Y arm servo settings:
Filters: FM1, FM5, FM6, FM7, FM9
Gain = +8.0
ETMX 1 0
ETMY 0 1
3. Transitioned CARM control output to actuate on MC2 instead of ETMX
SUS-MC2_LSC servo gain = 1.0
The transition was done in very small steps : actuating on MC2 in -0.01 steps at the outmatrix upto -1.0 while reducing the ETMX actuation to 0 simultaneously.
DARM still stayed locked only with actuation on ETMY.
4. Transitioned DARM control to ETMX and ETMY.
Used ezcastep to step up DARM control (Y arm output) actuation on ETMX and step down the actuation on ETMY.
Final output matrix
ETMX 0 -0.5
ETMY 0 0.5
MC2 -1.0 0
Noise plot in attachment.
5. Finding arm resonance
Used ezcastep to gradually build up offsets in CARM (LSC-XARM_OFS) to find IR resoance in one arm (Y arm).
Introducing a small (order of 0.5) DARM offset (LSC-YARM_OFS) shifted the Y arm off-resonance.
Used CARM offset to get back the Y arm to resonance.
Changing CARM and DARM offsets alternately while tracking the Y arm resonance got us to a point where we had both the arms resonating for IR.
6. At this point the MC decided to give up and we lost lock.
1. We found that the WFS2 YAW output filterbank had the output switched OFF (probably accidentally by one of us). This was reenabled. Please be careful while manually turning ON and OFF the MC WFS servos.
It was known that the Y end ALS PZTs are not working. But Anchal reported in the meeting that the X end PZTs are not working too.
We went down to the X arm in the afternoon and checked the status. The HV (KEPCO) was off from the mechanical switch. I don't know this KEPCO has the function to shutdown the switch at the power glitch or not.
But anyway the power switch was engaged. We also saw a large amount of misalignment of the X end green. The alignment was manually adjusted. Anchal was able to reach ~0.4 Green TRX, but no more. He claimed that it was ~0.8.
We tried to tweak the SHG temp from 36.4. We found that the TRX had the (local) maximum of ~0.48 at 37.1 degC. This is the new setpoint right now.
We locked the XARM and YARM with using ALS control loop and we succeeded to lock stably both arms. The performance of the ALS was tested with a measurement of the calibrated error signal. (attachment 1)
- red and blue : the in-loop noise of ALS of each arm.
- green and purple:Stability of the beat-note frequency with the MC and the arm freely running.
In the high frequency region, YARM has larger noise than XARM, and these noises were not there in previous measurements by Koji and Manasa (elog8865). You can see that in both of in-loop noise and free running noise. These noises may be caused by the Green PDH servo or hte phase tracker servo or any other electrical staff. We will start noise budget of these servo.
At higher frequency than UGF of ASL control loop, the loop does not suppress the noises at all, but the inloop and free running noise are not equivalent. I have no idea about that so far.
What was the beat freq for each arm?
The HF noise level depends on the frequency of the beat note.
As the BBPD has the freq dependent noise level. (See this entry)
What was the beat freq for each arm?
The HF noise level depends on the frequency of the beat note.
As the BBPD has the freq dependent noise level. (See this entry)
I'm not sure about the actual number of the beat frequency, but the beat frequency was almost same in both arms. And I took this measurement sometimes with slightly different beat frequency but the noise level didn't change so much.
I updated the mime.local.conf file for the AIC Wiki so as to allow attachments with the .txz format. THis should be persistent over upgrades, since its a local file.
[ Yuki, Gautam ]
I improved Anti-Imaging board (D000186-Rev.D), which will be put between DAC port and PZT driver board.
It had notches at f = 16.6 kHz and 32.7 kHz, you can see them in the plot attached. So I replaced some resistors as follows:
Then the notch moved to 65.9 kHz (> sampling frequency of DAC = 64 kHz, good!).
(The plot enlarged around the notch frequency and the plot of all channels will be posted later.)
All electronics and optics seem to be ready.
I made a cable which connects DAC port (40 pins) and AI board (25 pins). I will check if it works.
Tomorrow I will change setup for improvement of AUX Y-end green locking. Any optics for IR will not be moved in my design, so this work doesn't affect Y-arm locking with main beam.
While doing this work, I will do:
When signals are transmitted between the models running at different rates, no AI or AA filters are automatically applied. We need to fix our models.
I tried shifting the notch frequencies on the D000186-revision D board given to me by Koji. The existing notches were at ~16 kHz and ~32 kHz. I shifted these to notches at ~64 kHz and ~128 kHz by effecting the following changes (see schematic for component numbering) on Channel 8 of the board-I decided to check things out on one channel before implementing changes en masse:
=> New notches should be at 66.3 kHz and 131.7 kHz.
I then measured the frequency response of the modified channel using the SR785, and compared it to the response I had measured before switching out the resistors. The SR785 only goes up to 102 kHz, so I cannot verify the 128 kHz notch at this point. The position of the 64 kHz notch looks alright though. I think I will go ahead and switch out the remaining resistors in the evening.
Note 1: These plots are just raw data from the SR785, I have not tried to do any sort of fitting to poles and zeros. I will do this at some point.
Note 2: All these smts were taken from Downs. Todd helped me locate the non-standard value resistors. I also got a plastic 25-pin D-sub backshells (the spares are in the rack), with which I have fashioned the required custom ribbon cables (40 pin IDC to 25 pin D-sub with twisted ribbon wire, and a short, 10pin IDC to 10pin IDC with straight ribbon wire).
I carried some further modifications and tests to the AI Board. Details and observations here:
I think the board is okay to be used now.
We checked back in time to see how the BS and PRM OSEM slow channels are zero. It was clear that they became zero when we worked on this issue on June 17th, Thursday. So we simply went back and power cycled the c1susaux acromag chassis. After that, we had to log in to c1susaux computer and run
sudo /sbin/ifdown eth1
sudo /sbin/ifup eth1
This restarted the ethernet port acromag chassis is connected to. This solved this issue and we were able to see all the slow channels in BS and PRM.
But then, we noticed that the OPLEV of ITMX is unable to read the position of the beam on the QPD at all. No light was reaching the QPD. We went in, opened the ITMX table cover and confirmed that the return OPLEV beam is way off and is not even hitting one of the steering mirrors that brings it to the QPD. We switched off the OPLEV contribution to the damping.
We did burt restore to 16th June morning using
burtwb -f /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2021/Jun/16/06:19/c1susaux.snap -l /tmp/controls_1210622_095432_0.write.log -o /tmp/controls_1210622_095432_0.nowrite.snap -v
This did not solve the issue.
Then we noticed that the OSEM signals from ITMX were saturated in opposite directions for Left and Right OSEMs. The Left OSEM fast channels are saturated to 1.918 um for UL and 1.399 um for LL, while both right OSEM channels are bottomed to 0 um. On the other hand, the acromag slow PD monitors are showing 0 on the right channels but 1097 cts on UL PDMon and 802 cts in LL PD Mon. We actually went in and checked the DC voltages from the PD input monitor LEMO ports on the ITMX dewhitening board D000210-A1 and measured non-zero voltages across all the channels. Following is a summary:
We even took out the 4-pin LEMO outputs from the dewhitening boards that go to the anti-aliasing chassis and checked the voltages. They are same as the input voltages as expected. So the dewhitening board is doing its job fine and the OSEMs are doing their jobs fine.
It is weird that both the ADC and the acromags are reading these values wrong. We believe this is causing a big yaw offset in the ITMX control signal causing the ITMX to turn enough make OPLEV go out of range. We checked the CDS FE status (attachment 1). Other than c1rfm showing a yellow bar (bit 2 = GE FANUC RFM card 0) in RT Net Status, nothing else seems wrong in c1sus computer. c1sus FE model is running fine. c1x02 (the lower level model) does show a red bar in TIM which suggests some timing issue. This is present in c1x04 too.
Currently, the ITMX coil outputs are disabled as we can't trust the OSEM channels. We're investigating more why any of this is happening. Any input is welcome.
After sliding the alignment bias around and browsing through elog while searching for "stuck" we concluded the ITMX osems needed to be freed. To do this, the procedure is to slide the alignment bias back and forth ("shaking") and then as the OSEMs start to vary, enable the damping. We did just this, and then restored the alignment bias sliders slowly into their original positions. Attachment 1 shows the ITMX OSEM sensor input monitors throughout this procedure.
At the end, since MC has trouble catching lock after opening PSL shutter, I tried running burt restore the ioo to 2021/Jun/17/06:19/c1iooepics.snap but the problem persists
C1:PEM-SEIS_EX_TEMP2_MON gives us t
C1:PEM-SEIS_EX_TEMP2_CTRL can provide
End X configuration
sudo systemctl restart modbusIOC.service
$ rtcds build-install c1scx
$ rtcds build-install c1asx
$ rtcds build-install c1x01
Hardware check again
C1:PEM-SEIS_EX_TEMP2_CTRL gave +
We needed two additional ADC channels for the seismometer setup, to read out the temperature of the seismometer can/enclosure, and another for the ambient temperature near the can. Koji let me know that there are two EPICS ADC channels, C1:X01-MADC0_EPICS_CH29 and C1:X01-MADC0_EPICS_CH30 that are currently unused. These are also conveniently CH 6 and 7 on the ADC board referred to in the previous post.
Andrei and I laid out a couple of new BNC cables from the 1x9 rack to the seismometer, along the older cables. The image below shows the current configuration of the ADC -
The cable labelled EX-SEIS ... is for the temperature of the seismometer connected to CH 5, SEIS_AMB_TEMP is for the ambient temp connected to CH 6, and SEIS_CAN_TEMP is for the can temp connected to CH 7.
All three channels yield a count number on caget-ing, so I had to calibrate these too. The calibration is given by voltage = [ -3.0593-4 * (counts) - 0.00367 ] V and I obtained this by reading values for three positive voltages.
Recently some people are interested in ADC/DAC noise of Moku:GO. I measured them, and found that ADC noise is much larger than expected (quantization error).
I used "PID Controller" module for the measurement of ADC/DAC noise.
I set up the module as follows:
I took data by data logger DL-750 and calculated PSDs by myself. Measured DAC noise is shown in Fig.1.
Fig.1 : DAC noise of Moku:GO
I modeled the noise spectrum by:
I took data by data logger DL-750 and calculated PSDs by myself. Measured ADC noise is shown in Fig.2.
I modeled the noise spectrum by:
I estimated quantization error of ADC/DAC. Specification of the inputs/outputs are as follows:
From these specifications, the estimated quantization noise is . I plotted measured noise and this estimation noise in Fig.3.
Comparing with this value,
There is a measured data about ADC noise of Moku:Lab at here. Comparing with this, ADC noise of Moku:GO has a stranger shape than that of Moku:Lab.
If we are using Moku:GO and worried about sensitivities, we should insert some whitening filter before the input of Moku:GO.