I ceated a simple circuit that takes in 15V and outputs precisely 5V by using a 12V voltage regulator LM7812 and an AD586 that takes the output of the voltage regulator and outputs 5V (attachment 1). We plugged this into the slow channel and will leave it running for a few hours to see if we still have the fluctuations we observed earlier and also fit the noise curve. We'll also test the fast channel later as well. Attachment 2 shows the setup we have in the lab, with the red and white cable plugged into the +15V power supply and the red and black cable connected to the slow channel.
I shorted the inputs on three channels and the outputs on three channels of the Guralp box, and I did similar things with the accelerometers. I was going to move the instruments themselves back, but I didn't have time, so they are still in the box in the corner. If the setup could stay as-is for at least a few hours, that would be awesome.
Todd E. came by this morning and gave us (i) 1x new ADC card and (ii) 1x roll of 100m (2017 vintage) PCIe fiber. This afternoon, I replaced the old ADC card in the c1lsc expansion chassis, and have returned the old card to Todd. The PCIe fiber replacement is a more involved project (Steve is acquiring some protective tubing to route it from the FE in 1X6 to the expansion chassis in 1Y3), but hopefully the problem was the ADC card with red indicator light, and replacing it has solved the issue. CDS is back to what is now the nominal state (Attachment #1) and Yarm is locked for Jon to work on his IFOcoupling study. We will monitor the stability in the coming days.
(i) to replace the old generation ADC card in the expansion chassis which has a red indicator light always on and (ii) to replace the PCIe fiber (2010 make) running from the c1lsc front-end machine in 1X6 to the expansion chassis in 1Y3, as the manufacturer has suggested that pre-2012 versions of the fiber are prone to failure. We will do these opportunistically and see if there is any improvement in the situation.
Looks like the ADC was not to blame, same symptoms persist.
The PCIe fiber replacement is a more involved project (Steve is acquiring some protective tubing to route it from the FE in 1X6 to the expansion chassis in 1Y3), but hopefully the problem was the ADC card with red indicator light, and replacing it has solved the issue.
Gautam and I restarted the models on c1lsc, c1ioo, and c1sus. The LSC system is functioning again. We found that only restarting c1lsc as Rolf had recommended did actually kill the models running on the other two machines. We simply reverted the rebootC1LSC.sh script to its previous form, since that does work. I'll keep using that as required until the ongoing investigations find the source of the problem.
we did a bunch of tests to figure out the feasibility of the plan I outlined last night. Bottom line is: we appear to have a working 64 channel ADC (but with differential receiving that means 32 channels). But we need an aLIGO ADC adaptor card (I'm not sure of the DCC number but I think it is D0902006). See attached screenshot where we managed to add an ADC block to the IOP model on c1lsc, and it recognizes the additional ADC. The firmware on the (newly installed) working card is much newer than that on the existing card inside the expansion chassis (see Attachment #1).
Note that we have left the working ADC card inside the c1lsc expansion chassis. Plan is to give Rolf the faulty ADC card and at the same time ask him for a working adapter board.
Unrelated to this work: we have also scavenged 4 pcs of v2 of the differential receiving AA board from WB EE shop, along with a 1U chassis for the same. These are under my desk at the 40m for the moment. We will need to re-stuff these with appropriate OpAmps (and also maybe change some Rs and Cs) to make this board the same as v6, which is the version currently in use.
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.
I carried out the same measurements of the Moku:Go ADC and DAC noise to compare to the results from Ando Lab. Instead of a flat filter with 50dB of gain, I used the uPDH box fitted filter shape. I recorded spectral densities with an SR785; results are in Attachment 1. These measurements are consistent with those measured in Ando Lab. I included the SR785 noise floor, measured by terminating its input.
Next I tried to measure the Moku's DAC noise using its Waveform Generator and Digital Filter Box in multi-instrument mode. I generated a single-tone digital signal and passed it to an elliptic bandstop filter (fit tightly around the tone). The filtered signal was measured by the SR785. I performed this measurement with 1 kHz and 10 kHz tones [Attachement 2]. While the fundamental peak is suppressed, we still see it and its harmonics (not DAC noise). The floor of these measurements is consistent with the DAC noise reference from the first test, and we can say that the Moku:Go's DAC noise above 100 Hz is below 1 µV/rtHz.
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.
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
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.
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).
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.
[ 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:
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.
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.
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.
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.
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)
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.
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?
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?
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.
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.
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 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.
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!
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?
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.
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 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 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
[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.
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.
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:
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.