Here's an updated X ARM ALS noise budget.
I attempted a single arm actuation calibration using IR beatnote (in the directions of soCal idea for DARM calibration)
Rana suggested in today's meeting to put in a notch filter in the XARM IR PDH loop to avoid suppressing the excitation line. We tried this today first with just one notch at 1069 Hz and then with an additional notch at 619 Hz and sent two simultaneous excitations.
We attempted to simulate "oscillator based realtime calibration noise monitoring" in offline analysis with python. This helped us in finding about a factor of sqrt(2) that we were missing earlier in 16171. we measured C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ when X-ARM was locked to main laser and Xend green laser was locked to XARM. An excitation signal of amplitude 600 was setn at 619 hz at C1:ITMX_LSC_EXC.
We got a value of . The calibration factor in use is from nm/cts from 13984.
Next steps could be to budget this noise while we setup some way of having this calibration factor generated in realitime using oscillators on a FE model. Calibrating actuation of a single optic in a single arm is easy, so this is a good test setup for getting a noise budget of this calibration method.
We did a quick check to make sure there is no saturation in the C1:SUS-ITMX_LSC_EXC analog path. For this, we looked at the SOS driver output monitors from the 1X4 chassis near MC2 on a scope. We found that even with 600 x 10 = 6000 counts of our 619 Hz excitation these outputs in particular are not saturating (highest mon signal was UL coil with 5.2 Vpp). In comparison, the calibration trials we have done before had 600 counts of amplitude, so we can safely increase our oscillator strength by that much
Things that remain to be investigated -->
I did this analysis again by just doing demodulation go 5s time segments of the 60s excitation signal. The major difference is that I was not summing up the sine-cosine multiplied signals, so the error associated was a lot more. If I simply multpy the whole beatnote signal with digital LO created at excitation frequency, divide it up in 12 segments of 5 s each, sum them up individually, then take the mean and standard deviation, I get the answer as:
as opposed to that was calculated using MICH signal earlier by gautum in 13984.
Attachment 1 shows the scatter plot for the complex calibration factors found for the 12 segments.
My aim in the previous post was however to get a time series of the complex calibration factor from which I can take a noise spectral density measurement of the calibration. I'll still look into how I can do that. I'll have to add a low pass filter to integrate the signal. Then the noise spectrum up to the low pass pole frequency would be available. But what would this noise spectrum really mean? I still have to think a bit about it. I'll put another post soon.
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 replaced a shutter driver for GRY since it stopped working this morning.
We replaced it with a free driver which was sitting on the ITMY table.
The reverse polarity issue of C1:AUX-GREEN_Y_Shutter was fixed by switching one of the switches of the driver from N.O. to N.C.
Also, "Toggle" button was added to IFO_ALIGN.adl so that we can toggle shutters easily to find TEM00. It runs /home/controls/Git/40m/scripts/ALS/ShutterToggler.py.
The green Y shutter now works but in reverese, meaning that sending 1 to C1:AUX-GREEN_Y_Shutter closes the shutter and vice versa. This needs to be fixed.
We took the long BNC cable that ran from ETMX to ETMY and ran it from ETMX into the control room instead. This way Cici and Deeksha can send small voltage signals to the AUX PZT and read back using the beatnote pickoff that is usually connected to the spectrum analyzer.
I took ~ 7 minutes of XALS beatnote data with the XAUX laser locked to the XARM cavity, and the XARM locked to PSL to develop an allan deviation estimator. The resulting timeseries for the channel C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ (decimated timeseries in Attachment #1) was turned into an allan variance using the "overlapped variable tau estimator":
Where represents the k-th data point in the raw timeseries, and are the variable integration intervals under which two point variances are computed (the allan variance is a special case of M-point variance, where M=2). Then, the allan deviation is just the square root of that. Attachment #2 shows the fractional deviation (normalized by the mean beat frequency ~ 3 MHz for this measurement) for 100 integration times spanning the full duration (~ 7 min = 420 s).
The code used for this lives in Git/40m/labutils/measuremens/ALS/
If this estimate is any good, wherever the fractional beatnote deviation reaches a minimum value can be used as a proxy for the longest averaging time that give a statistical increase in SNR. After this timescale, the frequency comparison is usually taken over by "environmental instabilities" which I don't think I can comment further on. In our particular estimate, the 100 second integration gives a fractional deviation of ~ 0.44 %, or absolute deviation of 12.925 kHz.
what's the reasoning behind using df/f_beat instead of df/f_laser ?
I took ~ 7 minutes of XALS beatnote data with the XAUX laser locked to the XARM cavity, and the XARM locked to PSL to develop an allan deviation estimator.
I guess it didn't make sense since f_beat can be arbitrarily moved, but the beat is taken around the PSL freq ~ 281.73 THz. Attachment #1 shows the overlapping tau allan deviation for the exact same dataset but using the python package allantools, where this time I used the PSL freq as the base frequency. This time, I can see the minimum fractional deviation of 1.33e-13 happening at ~ 20 seconds.
The allan variance is related to the beatnote spectral density as a mean-square integral (the deviation is then like the rms) with a sinc window.
In the morning I took some time to align the AUX beams in the XEND table. Later in the afternoon, I did the same on the YEND table. I then locked the AUX beams to the arm cavities while they were stabilized using POX/POY and turned off the PSL hepa off temporarily (this should be turned on after today's work).
After checking the the temperature slider sign on the spectrum analyzer of the control room I took some out-of-loop measurements of both ALS beatnotes (Attachment #1) by running diaggui /users/Templates/ALS/ALS_outOfLoop_Ref_DQ.xml and by comparing them against their old references (red vs magenta and blue vs cyan); it seems that YAUX is not doing too bad, but XAUX has increased residual noise around and above 100 Hz; perhaps as a result of the ongoing ALS SURF loop investigations? It does look like the OLTF UGF has dropped by half from ~ 11 kHz to ~ 5.5 kHz.
Anyways let this be a reference measurement for current locking tasks, as well as for ongoing SURF projects.
[Paco, Deeksha, rana]
Quick elog for this evening:
The PZT sweeps that we've been making to characterize the ALS-X laser should probably be discarded - the DFD was not setup correctly for this during the past few months.
Since the DFD only had a peak-peak range of ~5 MHz, whenever the beat frequency drifts out of the linear range (~2-3 MHz), the data would have an arbitrary gain. Since the drift was actually more like 50 MHz, it meant that the different parts of a single sweep could have some arbitrary gain and sign !!! This is not a good way to measure things.
I used an ezcaservo to keep the beat frequency fixed. The attacehed screenshot shows the command line. We read back the unwrapped beat frequency from the phase tracker, and feedback on the PSL's NPRO temperature. During this the lasers were not locked to any cavities (shutters closed, but servos not disabled).
For the purposes of this measurement, I reduced the CAL factor in the phase tracker screen so that the reported FINE_PHASE_OUT is actually in kHz, rather than Hz on this plot. So the green plot is moving by 10's of MHz. When the servo is engaged, you can see the SLOWDC doing some action. We think the calibration of that channel is ~1 GHz/V, so 0.1 SLOWDC Volts should be ~100 MHz. I think there's a factor of 2 missing here, but its close.
As you can see in the top plot, even with the frequency stabilized by this slow feedback (-1000 to -600 seconds), the I & Q outputs are going through multiple cycles, and so they are unusable for even a non serious measurement.
The only way forward is to use less of a delay in the DFD: I think Anchal has been busily installing this shorter cable (hopefully, its ~3-5 m long so that the linear range is more. I think a 10 m cable is too long.), and the sweeps taken later today should be more useful.
I laid down another temporary cable from Xend to 1Y2 (LSC rack) for also measuring the Q output of the DFD box. Then to get a quick measurement of these long cable delays, we used Moku:GO in oscillator mode, sent 100 ns pulses at a 100 kHz rate from one end, and measured the difference between reflected pulses to get an estimate of time delay. The other end of long cables was shorted and left open for 2 sets of measurements.
I-Mon Cable delay: (955+/- 6) ns / 2 = 477 +/- 3 ns
Q-Mon Cable delay: (535 +/- 6) ns / 2 = 267 +/- 3 ns
Note: We were underestimating the delay in I-Mon cable by about a factor of 2.
I also took the opportunity to take a delay time measurement of DFD delayline. Since both ends of cable were present locally, it made more sense to simply take a transfer function to get a clean delay measurement. This measurement resulted with value of 197.7 +/- 0.1 ns. See attached plot. Data and analysis here.
[Paco, Anchal, Radhika]
We tried to debug why the XARM green laser isn't catching lock with the arm cavity. First I tried to improve alignment:
- Aligned the arm cavity axes by maximizing IR transmission.
- Adjusted M1 and M2 steering mirrors to align the X green beam into the arm. GTRX reached ~0.3.
- At the vertex table, I adjusted the lens in the GTRX path to focus the beam onto the DCPD. This increased GTRX to ~0.7.
- Visually I confirmed that TEM00 of the green laser was flashing in the arm cavity, fairly centered. But it was not catching lock.
We suspected the XARM AUX PZT might be damaged/unresponsive. Paco, Anchal, and I fed several frequency signals to the PZT and looked for a peak in the AUX-PSL beatnote spectra at the expected frequency. We confirmed that the X-arm AUX PZT is responsive up to 12 kHz (limited by ADC samping rate). We have no reason to suspect the PZT wouldn't be responsive at the PDH modulation frequency of 231 kHz.
- Investigate PDH servo box / error signal.
I tested the mixer by feeding it a 300 kHz signal sourced from a Moku:Go. I kept the LO input the same - 231.25 kHz from the signal generator. The mixer output was a ~70 kHz waveform as expected, so demodulation is not the issue in green locking.
Next I'll align the arm cavities with IR and check to see if the green REFL signal looks as expected. If not, we'll have to invesitage the REFL PD. If the signal looks fine, and we now know it's being properly demodulated, the issue must lie further downstream.
I've disabled the alarm for PEM_count_half, using the mask in the 40m.alhConfig file. We can't do anything about it, and it's just annoying.
I turned the StripTool and ALARMS and BLRMS back on on op540m. Looks like it has been rebooted 5 days ago and no one turned these back on. Also, there was a bunch of junk strewn around its keyboard which I restrained myself from throwing in the trash.
The BLRMS trends should be active now.
A small rat / large mouse just ran through the control room. Ugh.
Fire alarm went off several minutes ago. Talked to security and they said there was no fire. It beeped twice again just now. No one has been working on the IFO today.
The fire alarm came on around 15:05 for about 2-3 minutes. We all left the lab and counted heads. I called Paul Mackel x2646 (cell 626/ 890- 3259) at Fire Protection Services. He said that this alarm test was planned and we should of got an email notice. Perhaps I missed that notes.
It is posted at the 40m wiki with Gautam' help. Printed copies posted around doors also.
There was an alarm sound from the Smart-UPS 2200 sitting under the workstation. I see that the 'replace battery' light is red, and this elog tells me that these batteries are replaced every ~1-4 years; the last replacement was march 2016. Holding down the 'test' button for 2-3 seconds results in the alarm sound and does not clear the replace battery indicator.
In the revival of the experiement length measurement for the recycling cavities, I turned the auxiliary NPRO back on. The shutter is closed.
I also recollected all the equipment of the experiment after that during the summer it had been scattered around the lab to be used for other purposes (Joe and Zach's cameras and Stephanie and Koji's work with the new EOM).
I'm working on the PSL table to set up the PLL setup for the AbsL experiment.
I turned the auxialiary NPRO for the AbsL Experiment on. Its shutter stays closed.
Aligning the beam for the PLL of the AbsL Experiement I rotated the polarizer along the path of the MC Input pick off beam (= the pick off coming from the MC periscope).
I've been trying to lock the PLL for the AbsL Experiment but I can't see the beat (between the auxiliary NPRO and the PSL).
I believe the alignment of the PLL is not good. The Farady Isolator is definitely not perfectly aligned (you can see it from the beam spot after it) but still it should be enough to see something at the PLL PD.
it's probably just that the two beams don't overlap well enough on the photodiode. I'll work on that later on.
I'm leaving the lab now. I left the auxiliary NPRO on but I closed its shutter.
All the flipping mirrors are down.
I've opened the AP table and I'm working on it.
I re-aligned the Faraday on the AP table. I also aligned the beam to the periscope on the PSL and all the other optics along the beam path. Now I have a nice NPRO beam at the PLL which overlaps with the PSL beam. The alignment has to be further improved because I see no beat yet.
I wonder if the all the tinkering on the PSL laser done recently to revive the power has changed the PSL NPRO temperature and so its frequency. That could also explain why the beat doesn't show up at the same temperature of the NPRO as I used to operate it. Although I scanned the NPRO temperature +/- 2 deg and didn't see the beat. So maybe the misalignment is the casue.
Not feeling very well right now. I need to go home for a while.
AP table closed at the moment.
NPRO shutter closed
I re-aligned the Faraday on the AP table. I also aligned the beam to the periscope on the PSL and all the other optics along the beam path. Now I have a nice NPRO beam at the PLL which overlaps with the PSL beam. The alignment has to be further improved becasue I see no beat yet.
I wonder if the all the tinkering on the PSL laser done recently to revive the power have changed the PSL NPRO temperature and so its frequency. That could also explain why the beat doesn't show up at the same temperature of the NPRO as I used to operate it. Although I scanned the NPRO temperature +/- 2 deg and didn't see the beat. So maybe the misalignment is the casue.
We definitely changed the PSL NPRO temp while fiddling around, trying to increase the laser power. I think it's noted in the elog both times that it's happened in the last few months (once when Rana, Koji and I worked on it, and then again when it was just Koji), but we opened up the side of the MOPA box so that we could get at (and change) the potentiometer which adjusts the NPRO temp. So you may have to search around for a while.
Yes it did.
For long time, the crystal temperature C1:PSL-126MOPA_LTMP was 43~46deg. Now it is 34deg. Try ~10deg lower temperature.
I wonder if the all the tinkering on the PSL laser done recently to revive the power have changed the PSL NPRO temperature and so its frequency. That could also explain why the beat doesn't show up at the same temperature of the NPRO as I used to operate it. Although I scanned the NPRO temperature +/- 2 deg and didn't see the beat.
Also auxiliary NPRO turned on and mechanical shutter opened.
Beat found at 30MHz with auxiliary NPRO temperature of 37.19 degrees, vs. ~48 deg as it used to be.
The beat is small (-70dBm). PLL alignment has to be improved.
PLL alignment improved. Beat amplitude = -10dBm. Good enough.
DC readouts at the PLL photodiode:
V_NPRO = -4.44V
V_PSL = -3.76V
The NPRO beam is attenuated by a N.D.=1 attenuator just before going to the photodiode.
Something strange happened at the last. Right before -10dBm, the amplitude of the beat was about -33dBm. Then I was checking the two interfering beams with the IR card and saw that they overlapped quite well. I then turned my head back to the spectrum analyzer and suddenly the beat was at -10dBm. Not only, but a bunch of new peaks had appeared on the spectrum. Either I inadvertently hit the PD moving it to a better position or something else happened.
Like if someone was making some other modulation on the beam or the modulation depth of the PSL's sidebands had gone up.
I locked the PLL and made some first measuremtns of the spectrum of the error signal. I'll post them later.
I closed the shutter of the NPRO.
I'm working on the AP table. I also opened the auxiliary NPRO shutter. The auxiliary beam is on its path on the AP table and PSL table.
Closing the AP table and the NPRO shutter now.
Last night something happened on the beat between the PSL beam and the auxiliary NPRO beam, that spoiled the quality of the beating I had before. As a result the PLL has become unable to lock the two lasers.
The amplitude of the beat at the spectrum analyzer has gone down to -40 dBm from -10 that it was earlier. The frequency has also become more unstable so that now it can be seen writhing within tens of KHz.
Meanwhile the power of the single beams at the PLL photodiode hasn't changed, suggesting that the alignment of the two beam didn't change much.
Changes in the efficiency of the beating between the two beams are not unusual. Although that typically affects only the amplitude of the beat and wouldn't explain why also its frequency has become unstable. Tuning the alignment of the PLL optics usually brings the amplitude back, but it was uneffective today.
It looks like something changed in either one of the two beams. In particular the frequency of one of the two lasers has become less stable.
Another strange thing that I've been observing is that the amplitude of the beat goes down (several dBm) as the beat frequency is pushed below 50 MHz. Under 10 MHz it even gets to about -60 dBm.
I noticed the change yesterday evening at about 6pm, while I was taking measurements of the PLL open loop tranfer function and everything was fine. I don't know whether it is just a coincidence or it is somehow related to this, but Jenne and Sanjit had then just rebooted the frame builder.
I confirm what I said earlier. The amplitude of the beat is -10 dBm at 300MHz. It goes down at lower frequencies. In particular it gets to-60 dBm below 20 MHz. For some strange reason that I couldn't explain the beating efficiency has become poorer at low frequencies.
NPRO shutter closed
Problem found. Inspecting with Koji we found that there was a broken SMA-to-BNC connector in the BNC cable from the photodiode.
I measured the open loop gain of the PLL in the AbsL experiment.
I repeated the measurement twice: one with gain knob on the universal PDH box g=3.0; the second measurement with g=6.0
The UGF were 60 KHz and 100 KHz, respectively.
That means that one turn of the knob equals to about +10 dB.
I closed the shutter of the NPRO for the night.