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.
Eventually the instability in the Y end PDH servo turned out to be some kind of an alignment issue.
After carefully realigning the green beam to the Y arm, the UGF of the ALS loop became able to be at more than 50 Hz.
With this UGF it became able to suppress the arm motion to the ADC noise level (few 100 pm in rms).
Now I am scanning the arm length to look for a TEM00 resonance.
I have noticed that the spatial fringe pattern of the reflected green light was very sensitive to the pitch motion of ETMY when the green light was locked to the Y arm.
So I realigned the last two launching mirrors to minimize the reflected light. Indeed the misalignment was mainly in the pitch direction.
I basically translated the beam upward by a couple of mm or so.
The amount of the DC reflection is about 2.4 V when it is unlocked and it is now 0.77 mV when the green light is locked.
I guess this could be one of the reasons of the unstable behavior in the Y end PDH lock (#6071). (But still it doesn't fully explain the instability).
One of the crucial and currently limiting calibration errors is in the ALS beat. We think a major driver of calibration uncertainty may be the DFD TF calibration since it depends on the RF beat power.
The RF beat power as monitored by C1:ALS-BEATY_RF_POW shows relative fluctuations of 0.02% at the 16 Hz sampling rate (actually 0.09% rms from Attachment #1) once the single arm and YAUX laser are both locked. This sounds ok, but that's just a statistical estimate. The beat frequency changes every time we break and reacquire the lock, making the BEAT PD frequency response and DFD overall calibration change their nominal TF. This changes can be significantly larger than 0.02% (e.g 4.9% = observed change in the RF power after breaking and reacquiring the YAUX lock this morning). This is far more significant than the contribution from the RIN on the two lasers.
This kind of systematic error could be addressed by either/all:
Last year, I worked on the ALS delay line electronics, thinking that we were in danger of saturation. The analysis was incorrect. I find that for RF signal levels between -10 dBm and +15 dBm, assuming 3dB insertion loss due to components and 5 dB conversion loss in the mixer, there is no danger of saturation in the I/F part of the circuit.
The key is that the MOSFET mixer used in the demodulation circuit drives an I/F current and not voltage. The I-to-V conversion is done by a transimpedance amplifier and not a voltage amplifier. The confusion arose from interpreting the gain of the first stage of the I/F amplifier as 1 kohm/10 ohm = 100. The real figures of merit we have to look at are the current through, and voltage across, the transimpedance resistor. So I think we should revert to the old setup. This analysis is consistent with an actual test I did on the board, details of which may be found here.
We may still benefit from some whitening of the signal before digitization between 10-100 Hz, need to check what is an appropriate place in the signal chain to put in some whitening, there are some constraints to the circuit topology because of the MOSFET mixer.
One part of the circuit topology I'm still confused by is the choice of impedance-matching transformer at the RF-input of this demod board - why is a 75 ohm part used instead of a 50 ohm part? Isn't this going to actually result in an impedance mismatch given our RG405 cabling?
Update: Having pulled out the board, it looks like the input transformer is an ADT-1-1, and NOT an ADT1-1WT as labelled on the schematic. The former is indeed a 50ohm part. So it makes sense to me now.
Since we have the NF1611 fiber coupled PDs, I'm going to try reviving the X arm ALS to check out what the noise is after bypassing the suspect Menlo PDs we were using thus far. My re-analysis can be found in the attached zip of my ipynb (in PDF form).
The restoration of the delay-line electronics is complete. The chassis has not been re-installed yet, I will put it back in tomorrow. I think the calculations and measurements are in good agreement.
Apart from restoring the transimpedance of the I/F amplifier, I also had to replace the two differential-sending AD8672s in the RF Log detector circuit for both LO and RF paths in the ALS-X board. I performed the same tests as I did the last time on the electronics bench, results will be uploaded to the DCC page for the 40m version of the board. I think the board is performing as advertised, although there is some variation in the noise of the two pairs of I/Q readouts. Sticking with the notation of the HP Application Note for delay line frequency discriminators, here are some numebrs for our delay line system:
In conclusion: the ALS noise is very likely limited by ADC noise (~1 Hz/rtHz frequency noise for 5uV/rtHz ADC noise). We need some whitening. Why whiten the demodulated signal instead of directly incorporating the whitening into the I/F amplifier input stage? Because I couldn't find a design that satisfies all the following criteria (this was why my previous design was flawed):
So Rich suggested separating the transimpedance and whitening operations. The output noise of the differential outputs of the demodulator unit is <100 nV/rtHz at 100 Hz, so we should be able to saturate that noise level with a whitening unit whose input referred noise level is < 100 nV/rtHz. I'm going to see if there are any aLIGO whitening board spares - the existing whitening boards are not a good candidate I think because of the large DC signal level.
This Hanford alog may be of relevance as we are using the aLIGO AA chassis for the IR ALS channels. We aren't expecting any large amplitude high frequency signals for this application, but putting this here in case it's useful someday.
This test was done, and I determine the frequency discriminant to be (for an RF signal level of ~2 dBm).
Attachment #1: Measured and predicted value of the DFD discriminant for a few RF signal levels.
Attachment #2: Measured noise spectrum in the 1Y2 (LSC) electronics rack, calibrated to Hz/rtHz using the discriminant from Attachment #1.
I'm still waiting on some parts for the new BeatMouth before giving the whole system a whirl. In the meantime, I'll work on the EX and EY green setups, to try and improve the mode-matching and better characterize the expected suppressed frequency noise of the end NPROs - the goal here is to rule out the excess low-frequency noise that was seen in the ALS signals coming from unsuppressed frequency noise.
Attachment #1 shows the schematic of the test setup. Signal generator (Marconi) was used to supply the RF input. We observed the IF output in the following three test conditions.
I wrote the down script for ALS. This script is (script)/ALS/ALSdown.py When this script is running, it watches the feedback signal of the ALS control loop so as to shut down the servo immediately when the suspension is kicked.
When the value of C1:ALS-X(Y)ARM_OUT becomes larger than the threshold (right now it is 4500 counts), it changes the servo gain to 0, turns off all filters except for FM5 (the filter for phase compensation), resets the history of the phase tracker of each arm and prints the time on window when the suspension kicked
I put the switch on the C1ALS screen, and if you push this switch the window will open (like when you turn on the c1ass script) and the script start to run. For stopping this script, you have to close that window or press Ctrl + C on that window. This is little bit inconvenient, but we will make autolocker script for ALS and this downscript will be included that script soon. So I think it is enough to protect the suspensions right now.
I modified the ALS down script. When the value of C1:ALS-X(Y)ARM_OUT becomes larger than the threshold, it turn off the output ON/OFF switch immediately. That is because the ALS servo has ramp time. When script changes the gain to 0, it takes some seconds. That is not good for suspensions.
After changing servo gain to 0 and turning off the filters, the script waits ramp time and turn on the servo output switch.
We installed some rails to mount the 2U chassis containing ~100m of delay line cabling, and the 1U chassis containing the FET demodulators for the ALS signals in the LSC rack. This has made it MUCH easier for a single person to work there and remove/reinstall these chassis. The delay line box has 100m of cable inside it, and so was rather heavy (~8kg) - previously, it was being supported only by a pair of brackets on the front, so the new arrangement is much more robust. Steve is looking into acquiring plastic spacers of the appropriate width, so that we can secure the units to the rack using usual rack mount screws (but the material of the newly installed rails and the screw heads holding them in place necessitate this plastic spacer).
Delay line box has been re-installed, demodulator chassis has been removed by me for characterization. Steve will put up photos once the units are re-installed.
For this work, I had to disconnect a bunch of cabling, but only those connected to ALS. All cables were labelled, and I will re-connect them once I am done with the demod chassis.
Anyways I think this is a big improvement from what was the situation before, and I am moving on to debugging the ALS electronics.
We think we got to the bottom of this issue today. The RF signal level going into the demod board is too high. This electronics chain needs some careful gain reallocation.
I was demonstrating to Koji a strange feature I had noticed in the ALS control, whereby when applying a CARM offset to detune the arms, the two arms seemed to respond differently (based on the transmission levels). This kind of CARM-->DARM coupling seemed strange to me. Anyway, I also noticed that the EPICS indicators on the ALS MEDM screen suggested ADC saturations were going on. I had never really looked at the fast time series of the inputs to the phase tracker servos, but these showed saturating behavior on ndscope traces. I went to the LSC rack and measured these on a scope, indeed, they were ~20V pp.
The output of the BeatMouth PDs are going to a ZHL-3A amplifier - we should consider replacing these with lower gain amplifiers, e.g. the Teledyne AP1053. This is relegated to a daytime task.
Other findings tonight:
While working on the PSL table, I somehow put the IMC FSS into a bad state, reminiscent of this behavior. Seems like this is linked to some flaky connection on the PSL table. One candidate is the unstable attachment of the Pomona box between the NPRO PZT and the FSS output - we should install a short BNC cable between these to avoid the lever arm situation we have right now.
Leaving a note on the ALS feedback before I forget:
The MC2 suspension needs to have an input for the ALS feedback in the realtime model like ETMs.
I added an ALS feedback path on the MC2 suspension and this path will enable us to stabilise the MC length using the ALS scheme.
We tried several times tonight to engage the Fool path with the PRFPMI. No success.
First, we locked the arms on ALS, in CARM/DARM mode, and measured the cancellation ability, to make sure that the filter shape and gain was set correctly. For the PRFPMI, it was okay using the same shape as the single arm case, but the gain was +20.0. There might be a bit more cancellation to be gained if we adjust the shape at the ~1dB level, but we're already able to get 20dB of cancellation, so we decided that would be enough to give things a try. To get this much cancellation, we set the phase tracker loops to both have 2kHz UGFs, almost exactly. We should implement a UGF servo, or the amplitude method version of that as Koji suggested ages ago, so that the phase tracker is always at the same place.
I don't think that REFL 11 is seeing as much CARM as I expect. We ended up switching over to linearized REFL55 for our attempts. When we're close to zero CARM offset, the arms are constantly flashing through resonance, and we get the loud buzzing. REFL11 doesn't seem to see any of this, even though we should be close enough to see some PDH action. REFL55 does change as we get closer to resonance, so I think it's seeing some real CARM stuff.
We tried engaging the Fool, but I don't think it did anything too useful. We need to make an estimate of what we expect our gain of the REFL loop to be - or at least the sign.
The PRMI is still not stable enough. It keeps falling out of lock when we get to high-ish arm powers. Not good. More brain power tomorrow on the modulation cancellation issue.
Perhaps if things are stable at moderate arm powers, we can use an excitation to line up the ALS vs. REFL error signals, and then watch the noises of them change as we move around in CARM offset. This should tell us when the linearized REFL signal is quiet enough that it's worth triggering and trying to transfer over.
The last lockloss tonight, there was something funny going on, that we can't explain. Even though both arms were locked on the CARM/DARM combined ALS signals, beatx doesn't see the giant oscillation that causes carm to lose lock until much later. Fool was trying to do something, but that should affect both als individal signals in the same way. Mystery.
The ALS fool scheme is now diagrammed up in OmniGraffle, including its new official icon. The mathematica notebook has not yet been updated.
EDIT, JCD, 17Feb2015: Updated cartoon and calculation: http://22.214.171.124:8080/40m/11043
I re-did the Mathematica notebook according to the most current diagram (note to daytime self: attach .nb file!!!), and found that the denominator has changed, such that plugging in the new D=-A_refl*P_als*S_als gives the same
full-system closed loop gain of
where is the open loop gain, and the * indicates either the REFL or ALS portions of the system.
I have also plotted some things with Matlab, although I'm a little confused, and my daytime self needs to spend some more time thinking about this.
In the actuators (both for REFL and ALS), I include a pendulum, the digital anti-imaging filters that let us go from the 16kHz model to the 64kHz IOP and the analog anti-imaging filters after the DAC. Note to self: still need to include violin filters here.
For the servo gains, I copy the filters that we are using from Foton, and give them the same overall gain multiplier that is in the filter bank. For the ALS going through the CARM filter bank, this is FMs 1, 2, 3, 5, 6 with a gain of 15. For the RF (actually, POY here) going through the MC filter bank, this is FMs 4, 5, 7 with a gain of 0.08.
For the plants of each system, since this is still single arm lock, I just include a cavity pole (80kHz for ALS, 18kHz for REFL).
In the sensors (both for REFL and ALS), I include the analog anti-aliasing as well as the digital anti-aliasing to allow us to go from the 64kHz IOP to the 16kHz front end system. For the ALS I also include in the sensor the closed loop response of the phase tracker loop (H/(1-H), where H is the open loop gain of the phase tracker). For both sensors, I also include a semi-arbitrary number to make the full single-loop open loop gain have a UGF of 200Hz. In the ALS sensor, I also include a minus sign to make the full open loop gain have the correct phase.
Here I plot the open loop gains of the individual single loops, as well as the open loop gain of the full system (Hals + Hrefl - Hals*Hrefl). I feel like I must be missing a minus sign in my ALS loop, but I don't know where, and my nighttime brain doesn't want to just throw in minus signs without knowing why. That will affect how the final ALSfool (blue trace) looks, so maybe it's not really as crazy as it looks right now.
Also, I was trying to explain to myself why we are getting the shape that we are in our measurements of the cancellation (http://nodus.ligo.caltech.edu:8080/40m/11041). But, I can't. Below are the plots of the transfer functions from either point 9 or 10 (before or after the G_refl) to point 5, which is the ALS error point. The measurement in elog 11041 should correspond to the blue trace here. For these traces, the decoupling is set to just (-A_refl), although there aren't any noticeable changes in the shape if I just set D=0. If we start with the assumption that D=0, the shape and magnitude are basically identical to this plot, and then as we make D=-A_refl P_als S_als, the transfer functions both go to zero.
So. Why is it that with no decoupling, the transfer function from 10 to 5 is tiny? Why do the shapes plotted below look nothing at all like the measured cancellation shape? Daytime brain needs to think some more.
Here is an updated cartoon, with the ALS sensor explicitly shown as the beatbox times the closed loop response of the phase tracker servo.
The most important transfer functions are written on the diagram. Others can be extracted from the attached Mathematica file (which corresponds to this diagram).
I have measured very, very carefully the transfer function from pushing on MC2 to the Yarm ALS beatnote. In the newest loop diagram in http://nodus.ligo.caltech.edu:8080/40m/11030, this is pushing at point 10 and sensing at point 4.
Since it's a bunch of different transfer functions (to get the high coherence that we need for good cancellation to be possible), I attach my Matlab figure that includes only the useful data points. I put a coherence cutoff of 0.99, so that (assuming the fit were perfect, which it won't be), we would be able to get a maximum cancellation of a factor of 100.
This plot also includes the vectfit to the data, which you can see is pretty good, although I need to separately plot the residuals (since the magnitude data is so small, the residuals for the mag don't show up in the auto plot that vectfit gives).
If you recall from http://nodus.ligo.caltech.edu:8080/40m/11020, we are expecting this transfer function to consist of the suspension actuator (pendulum with complex pole pair around 1Hz), the ALS plant (single pole at 80kHz) and the ALS sensor shape (the phase tracker is an integrator, with a boost consisting of a zero at 666Hz and a pole at 55Hz). That expected transfer function does not multiply up to give me this wonky shape. Brain power is needed here.
Just in case you were wondering if this depends on the actuator used (ETM vs MC2), or IFO configuration (single arm vs. PRFPMI), it doesn't. The only discrepancy between these transfer functions is the expected sign flip between the MC2 and ETMY actuators. So, they're all pretty consistent.
Before locking the PRFPMI, I copied the boost filter (666:55) from the YARM ALS over to Xarm ALS, so now both arms have the same boost.
Things to do for ALSfool:
Wonkey shape: Looks like a loop supression. Your http://nodus.ligo.caltech.edu:8080/40m/11016 also suggests it too, doesn't it?
Dang it, yes. You're right. I should have caught that.
Since Dcpl and Srefl are both zero during the measurement (since it was an ALS lock), this is actually
So, I need to remove the effect of the ALS closed loop, to get the actual quantity I was looking for.
I discussed with Yuta about the ALS servo and phase tracker and found that there was a lot of information lying around from last year but there aren't any clear elogs on how to enable ALS and obtain IR resonance.
Guide to enabling the ALS servo and find IR resonance:
The steps will explain in detail how to ressurrect the ALS servo for green X-arm and find IR resonance using ALS. The medm screens are very confusing right now.
(i) Finding the beat note
1. Get the IR to flash in TEM00 for the arm and lock it by enabling LSC (Locking the arm to IR keeps the arm cavity mirrors stable so that you can scan the temperature of the X-end laser to find the beat note).
2. Steer the X-green into the arm cavity such that the arm cavity locks in TEM00 for green as well. At this point you should also have the X-green reaching the PSL table.
3. Align the PSL doubled green (PSL-green) and the X-green in near-field (at the camera) and far-field (letting the beams to propagate beyond the Green-TRX PD).
4. Check cabling of the RF beat PD.
5. Change the X-laser temperature by sweeping the offset (C1: ALS-SLOW_SERVO2_OFFSET) in steps of 10.
6. Find the beat note and tune the alignment at the beat PD to maximize the beatnote amplitude. Disable LSC for X arm.
(ii) The GREEN HORNET explained
'Input signal conditioning' block takes I and Q signals after the delay frequency discriminator (DFD) in the beat box and these signals pass through C1ALS_BEATX_FINE filter banks. The output signal then enters the phase rotation matrix of the phase tracker. The phase tracker gives 'PHASE_OUT' which is the error signal that is fed to the ETM servo filter module (DOF filters) through the 'Input matrix' in the medm.
An offset can also be fed to the phase tracker which will scan the beat frequency (used to find IR resonance).
1. easyALS.py - This runs from 'ON plus' or 'ON minus' buttons in the C1ALS_COMPACT.
The script clears history of 'fine_phase' filter module and increases gain of the servo in steps ('ON plus' for positive gain and 'ON minus' for negative gain).
2. findIRresonance.py - This runs from 'IRres' button in the C1ALS_COMPACT.
It adds offset to the phase tracker in steps which scans the beat frequency to find IR resonance.
P.S. Check the scripts before enabling the servo so that the right filter modules are being turned ON. Using the wrong set of filter modules can kick the ETM.
X arm ALS progress:
I found the beat note and got ALS to work reasonably for the Xarm without kicking the ETM. I did this by manually toggling buttons and changing gains. The scripts need editing.
Modify the scripts to work as we want them to.
The ALS medm is SSSOOOO confusing. It definitely needs to be fixed (remove all unwanted parts of the screen that existed 'pre-phase tracker').
Find IR resonance.
As I was trying to solve the 2 arm ALS problem, I found the Y arm ALS not so stable AGAIN :( . I measured the in-loop noise of the X arm as ~400Hz/rtHz (60 picometers).
I went ahead and checked the out of loop noise of the ALS and found there is some high frequency noise creeping in above 20Hz for the Y arm ALS (blue curve). I checked the UGFs and phase margins of the phase tracker loops and found they were good (UGF above 1.4KHz and phase margins between 40 and 60 degrees).
So the suspect now is the PDH servo loop of both the arms which has to be checked.
Attached is the out-of loop noise plots of X and Y arm ALS.
Not sure why, but Rana and I didn't see the super high Xarm noise with ALS that we reported last night (elog 10382).
The in-loop ALS noise seems fine. The out of loop measurement while the ALS is locked is a little tricky, since ALS hold the arms within the POX/POY linear ranges.
Here is the in-loop noise:
The ALS system is iffy tonight.
After putting the cable back to the RF spectrum analyzer (it had been taken to test the frequency counter setup, and not put back), I had a good Yarm beatnote, but again this evening the Xarm beatnote is small. I touched up the PSL table alignment (very, very little needed, but it did double my peak height). I *think* that this is happening because we haven't settled into a good IFO alignment place, so the arm pointing keeps changing very slightly, which means that the PSL ALS alignment needs touching. Anyhow, even after alignment the Xarm beatnote is only -36 dBm at 81 MHz. It should be at least -25 dBm or so, although I haven't seen it any larger than about -35 dBm since the IFO beam was lost last Friday.
I am not able to hold ALS lock long enough to scan the arms and find the IR resonances. The only optics that I am actuating on this evening are the 2 ETMs. When I lose lock and look at the watchdogs, the ETMs are the only optics that have largeish numbers, which comes from the ALS lockloss. So, I don't think I am suffering from the ITM suspension kicks tonight. Rather, I think that it's that the ALS system isn't tuned up nicely.
I think that it is past time we tuned up and checked out the ALS PDH setup. Q: Can you please measure the loop TFs for both of the ALS PDH boxes tomorrow? At the very least we want to know what we're working with.
Evan: What is the status with the ISS?
I am going to try tomorrow to look at the suspensions, and see if I can track anything down. I feel like I see the kicks more often when the arms are locked, i.e. we are sending an LSC signal to them. The LSC POS signal is a factor of a few hundred larger than the damping SUSPOS signal is. Are we saturating something somewhere? Why is this a new thing? We certainly do see kicks when the LSC is not engaged, so this may not be the right path, but it is something concrete to look at.
The Xarm ALS has been a little funky today.
First, the green and the arm-axis would not stay co-aligned. I'm not sure which was moving (although neither ITMX nor ETMX seemed to be moving very much according to their oplevs and OSEMs). I went to the Xend table and jiggled the mounts for the steering optics, in case one was loose or something. None were. However, the transmission quit jumping around by a factor of 2 after that. The beatnote alignment on the PSL table was also bad, so I tweaked that alignment up for the Xarm. There were some not connected cables and fibers blocking the access to the X beatnote area, so those are up on top of the PSL table.
Anyhow, I haven't locked the individual arms, but I cannot hold the lock with CARM/DARM. The CARM output keeps hitting the threshold for the locking watchdog, which turns off the lock. Obviously I could just increase this threshold, but the right thing to do is figure out why the Xarm ALS is so noisy today, and why it wants to output such a large control signal to maintain the lock.
[Jenne, Koji, Manasa, EricQ]
Today we successfully locked the ALS using the LSC system, with filters that are good for both the IR PDH and the ALS locking. We tried PRFPMI, but were unable to hold PRMI lock while the arms were held with ALS. We combined the ALS signals into common and differential signals, and successfully transitioned over to a combined set of 1/sqrt(TRANS) signals for the common mode part of the lock (differential stayed with ALS).
Locking the ALS using filters in the LSC system that are also good for IR PDH
The biggest difference between the ALS and LSC filters were the ones used for lock aquisition. At Koji's suggestion, I made FM5 of the LSC servos (for X and Y arms) the filter needed for ALS locking. Then, I made FM4 into a combination of old LSC FM4 and FM5, as well as an inverse of the new FM5, so that when both FM4 and FM5 are engaged, the servo shape is the same as the old LSC. I left the other LSC filters where they were. I replaced the FM1 +6dB with the combined integrators (really, just gentle DC boosts) for the ALS, since we were never using this +6dB filter module. The LSC resonant gain filter for the bounce mode also included a resgain for 18.5 Hz. I don't know what that was for, and it was eating into phase that I needed, so I removed it.
The other filter that changed significantly was the Boost filter. The ALS system had been using more DC gain than the LSC had. However, the current ALS boost filter (in FM10 of the old ALS servos) was eating too much phase near my UGF. So, I scooted the whole boost filter to lower frequencies, to give myself some extra phase margin. The boost was set to "zero history", "zero crossing", with 0.01 tolerance and an 8 second timeout. Setting it to zero crossing with a low tolerance, rather than just ramping it on, was the key to engaging the boost.
I had to be so careful about phase margin, since I lost ~15 degrees of phase at 200 Hz from the lag of going through the RFM network. This was pretty frustrating, but I don't have a better plan yet, save moving the c1als model and ADC to the SUS machine, which has Dolphin access to the LSC. I may back off my safety margin, and give myself some gain in the boost back at 10Hz, since we are now seeing too much noise at 10Hz in the closed-loop spectra. I also "cheated" and lowered my UGF from the ~150Hz it used to be in the ALS model, to 100Hz, where I was closer to the top of the new phase bubble.
With the new filter situation, I was able to lock the Xarm (the one I was using for design work) with both IR and ALS. To lock IR, the "restore" script still works. For the ALS, we should put in a separate "restore" script into the IFO_CONFIGURE screen.
The ALS locking procedure is as follows:
* Prepare ALS and green locking. Green locked to 00 mode, alignment all nice, etc, etc. Beatnote within 100MHz on spectrum analyzer. If doing both arms, try to get beatnotes on opposite sides of PSL, to keep crossbeatnotes at higher frequencies, and out of the way.
* Turn on Watch script.
* Set LSC parameters (this is where a new restore script will come in handy):
* Zeros in RFPD columns of input matrix (i.e. POX and POY).
* Ones in AUX input matrix elements.
* Zeros in power normalization matrix rows for arms.
* All FM triggers for arms set to "Man" for manual.
* Override main trigger, so that signals are always going through to the servo.
* Only FM5 engaged in arm servo.
* Gain of servo set to zero, output on, then engage main LSC master switch. ETM output on.
* Clear history in phase tracker.
* Check sign of gain using + or - 0.1 in the servo. You'll know if you got it wrong (the ETM will be kicked, and the beatnote will fly around). If you didn't get it wrong, you probably got it right.
* Increase gain to about 12 (with correct sign).
* Engage FM1 (gentle DC boost), FM6,7,8 (resonant gains for stack, bounce, roll)
* Wait a few seconds for filters to settle, then engage FM9 (boost).
* Run find IR resonance script.
* Move off resonance by ~36 counts (12 times the +3 script). This number comes from trying to be completely off the IR resonance, even when the PRMI was locked.
* Do whatever locking (ex. PRMI) you set out to do.
After locking both arms with ALS using the LSC system, we attempted to lock the PRMI. We were able to lock PRMI on REFL55 I&Q, REFL33 I&Q, and REFL55 I&AS55Q before the arms were locked, so we were hoping that we wouldn't have too much trouble.
We found the IR resonance for both arms, then moved off resonance. Then, restored the PRM. For REFL55, Koji coarsely turned the REFL 55 demod phase from 16 degrees to 87, while we were locked on the carrier. After this, I stepped farther and farther from the IR resonance, since at first I found that our transmitted powers were something like 4, rather than almost zero, so the demod phase may not be totally correct.
We were having trouble, so we locked the PRMI on carrier using REFL55 I and AS55 Q, with 1's in both elements in the input matrix. MICH gain was about -10, PRCL +0.010. We used this time to tweak up the alignment of the PRMI. At some point, Koji tweaked the REFL33 demod phase from 124 to 134 degrees. Then we switched back to sideband locking. After some trials with REFL55 I&Q, and REFL55/AS55, we went to REFL33 I&Q. REFL33I->PRCL was 1.556 in the input matrix, and REFL33Q->MICH was -0.487. No other elements in the input matrix. MICH gain was reduced to -6, PRCL gain to -0.020. MICH FMs 3,6,9 triggered, PRCL FMs 2,3,6,8,9 triggered. We were able to keep short locks on the order of ~10 seconds, but not longer. We played with every parameter we could think of (alignment being good is one of the most important!), but were not able to keep better lock. The POP spot is moving around a lot, so the PRCL ASC needs to be examined, hopefully tomorrow.
We started losing the Xarm lock fairly regularly, I'm not sure why, but the Yarm was locked for almost 2 hours straight, held off resonance with ALS!
ALS Common and Differential, transition to IR control
We set PRMI aside for the rest of the night, and looked at using ALS to control the arms in common and differential modes.
Regular ALS locking procedures were used (see above), with the exception of the AUX input matrix:
Since the beatnotes were on opposite sides of the PSL frequency, the common and differential modes look opposite of what you'd expect.
We then used the regular find IR resonance scripts running simultaneously, which worked really well to find both arms' IR resonance points.
I put a 1 count offset in the Xarm servo (which was our proxy for common mode), although in retrospect this should have been +0.5 in ALSX, and -0.5 in ALSY, so that our signals going through the input matrix were at their zero crossings. Anyhow, this offset put us at about half fringe on both arms (transmissions were about 0.6).
Koji set the offsets in the 1/sqrt(trans) filter banks before the input matrix so that they would have zero crossings at this point (avg the IN1, put negative of that value into the offset).
We then stepped the input matrix values until our common mode (Xarm) row was:
We left the differential (YARM) row alone, so that the ALS system would still be controlling the differential degree of freedom. The values and sign for the 1/sqrt(trans) signals came from a transfer function of dividing the spectra of each error signal and noting the relative gain and sign.
After we swapped the error signals, we realized that we had to remove the offset from the XARM servo, which is why we should have put the offsets elsewhere in the first place.
Then, Koji took a spectrum, which is attached to this entry. We note that the ALS signals are strongly correlated, and mostly common.
To Do List
Going forward, we need to figure out what is going on with the PRMI, and why we're having trouble keeping lock.
We need to redo the PRCL ASC servo, with the anti-oplev trick that Rana mentioned a week or two ago.
We need to investigate the degeneracy of REFL165, now that Q's simulation doesn't justify / explain it.
I'm really excited, so I'm posting this, even though I'm still working:
I currently have ALS locked using the LSC system, and have (by hand, coarsely) found IR resonance! Hooray!
I looked at my error signals, as well as LSC-XARM_IN1 with dataviewer, and noticed that the XARM_IN1 signal was crazy when I was using the ALS signal as the error. I soon realized that this is because there was a non-zero element in the power normalization matrix, and I'm overriding the trigger. So, I was trying to divide by zero, and was getting crazy numbers. After zeroing the power normalization matrix element for the Xarm, the XARM_IN1 signal matched the ALSX_OUT, and I was easily able to acquire lock.
I had already re-transferred over the ALS versions of the filters, so that's what I'm using right now. Next up (on a 5 minute time-scale) is trying to acquire lock using the regular LSC filters.
Oh, also, something I hadn't thought of before dinner: I am setting the offset of the ALSX filter bank such that the output is centered around zero, so that I can lock, since these are not AC coupled servos.
Great. I indeed disabled all of the triggers and the normalization during my trial but in vain.
So I'm curious this is actually because of the filter shape or not.
I am also not able to lock the ALS using the 'regular' LSC filters. To figure out what filters were doing what, I made several comparison plots from Foton.
The first one is the progression of ALS locking, using the filters from ALS-XARM. FM5 is always engaged, then FMs 2, 3, 6, 7, and 8, and finally FM 10 (the low frequency boost) is engaged.
The next plot is a comparison between the ALS version of the filters, and the LSC-XARM equivalents.
Finally, just so I remember which LSC filters do what, I made an equivalent of the first plot, but for the LSC filters.
When I try to lock the Xarm ALS using the regular LSC filters, I'm getting an oscillation somewhere, that grows and eventually knocks me out of lock. It looks from dataviewer to be in the ~few Hz range, but it's hard to see it in DTT, since I don't stay locked all that long once the oscillation starts. (If I catch it, I can back off the gain and turn off the servo without losing lock, but if I don't turn off the servo, I inevitably push the ETM too hard and lose green lock to the arm.) I tried engaging the 3.2 Hz resonant gain filter, and it just makes things oscillate sooner, so that's not a solution with the current filter designs.
Also, I'm not able to lock the IR using the ALS version of the XARM filters. I'll have to meditate more on the situation, but the filters seem to be different enough that there's no crossover at this point.
No more progress tonight. I am still unable to lock the ALS using the regular LSC filters. I went back to putting the ALS filters into the LSC filter banks, and locked both arms with ALS, and found their IR resonances. I then held them off resonance, and tried to lock PRMI with REFL 55 I&Q, with no success. Just before locking the arms, I had redone the whole IFO alignment (lock arms in IR, ASS, lock and align MICH, lock and align PRMI), and the PRMI was flashing very nicely. I'm not sure why I wasn't able to catch lock, except that perhaps 3 or 6 ALS offset counts isn't far enough away from the IR resonance to make the 1f signals happy. The MC lost lock, which I then took as a sign that it's time to go home. (I was hoping to do a quick PRMI + 2arms, and see that we don't lose PRMI lock. I was going to catch lock with REFL55, then transition to REFL33, although if I had thought about it before the MC lost lock, I would have tried just catching lock with REFL33).
I restored the regular LSC filters for the X and Y arms, and locked the arms in IR just to make sure it's all honkey-dory. Which, it's not quite. I don't know why, but right now, neither arm wants its boost (FM9) enabled. It's part of the restore script that FM9 is triggered along with the rest of the filters, but even if I turn on the filters manually, I can turn on all but FM9, and then when I turn on the boost, the arm falls out of lock. Same behavior for both arms. Anyhow, they lock, and they seem okay modulo the boost not being able to engage.
Renaming of the c1gcv model earlier (elog 7011) had left white boxes in most of the ALS medm screens.
Channels names were corrected. No more white boxes.
I am working on the basic ALS servo model. The simulink model for the same is attached. The loop is not yet complete (I'm still debugging it) ; but this is just an update of where I am right now.
Attached is the simulink and matlab file.
Last night, as well as tonight, the ALS seems not quite as robust as it was earlier in the week.
I have just taken noise spectra, and ALS is definitely more noisy than usual.
These plots are with the arms held in CARM and DARM mode, with servo gains of 8. I was seeing the beginnings of gain peaking at a gain of 10, so I turned it back to 8. Our ALS in-loop RMS is usually something like a few hundred Hz, but I'm seeing over 1kHz, so I have a factor of 4 or 5 too much noise. Why?!?!?
I have noticed that ALS noise has been at 1KHz rms since LSC arm lock servos have been used to lock arms using ALS error signals. May be this has not been given much attention.
But looking more closely at the ALS noise (better dtt resolution for noise power spectrum) , there seems to be too much noise suppression at <1Hz and not much happening at around 10Hz.
Attachment 1 (data files at /users/manasa/data/140421/)
So I made a bunch of transfer function measurements for ALS and phase tracker servo. Koji will be using these and redesigning the servo filters so that we can get more suppression at 10Hz.
Other than this I also found that the Y arm showed more high frequency noise as compared to the X arm. (Edit by manasa: Thinking back now, this could be related to the onset of 60Hz noise at the Y end elog 9838. But still has to be looked at after fixing TRY)
Tip: Once the arms are ALS locked, enabling the SLOW_SERVO helps hold the lock stably.
P.S. I realigned the Y green to the arm and brought GTRY to 0.93
Find out what makes Y arm in-loop noise at high frequency higher than X arm.
Before starting to move things around the PSL table, I measured the ALS out of loop noise for reference. The noise spectrum showed excess noise around 30Hz. The traces in blue were taken before I went in and those in red were taken after my work.
I also looked at the power spectrum of LSC-TRY_OUT to see if the noise is from the IR lock itself and there was nothing suspicious with it.
Since the green transmission was 50% lower than the usual, I touched the steering mirrors for green at the Y end table to get a better transmission and beat signal. The noise still hasn't disappeared.
I am not sure if this could be from our neigbors who have been running rock experiments since morning. We should check back to see if this noise disappears once they shut down.
DTT xml files are available in directory /users/manasa/data/150109/
I found out an error I did in copying some control model values from Kiwamu's matlab code. On fixing those, we get a considerably reduced amount of total noise. However, there was still an unstable region around the unity gain frequency because of a very small phase margin. Attachment 3 shows the noise budget, ALS open-loop transfer function, and AUX PDH open-loop transfer function with ALS disengaged. Attachment 4 is the yaml file containing all required zpk values for the control model used. Note that the noise budget shows out-of-loop residual arm length fluctuations with respect to PSL frequency. The RMS curve on this plot is integrated for the shown frequency region.
Adding two more poles at 100 Hz in the ALS digital filter seems to work in making the ALS loop stable everywhere and additionally provides a steeper roll-off after 100 Hz. Attachment 1 shows the noise budget, ALS open-loop transfer function, and AUX PDH open-loop transfer function with ALS disengaged. Attachment 2 is the yaml file containing all required zpk values for the control model used. Note that the noise budget shows out-of-loop residual arm length fluctuations with respect to PSL frequency. The RMS curve on this plot is integrated for the shown frequency region.
But is it really more stable?
For that, we'll have to take present noise source estimates but Gautum vaguely confirmed that this looked more realistic now 'shape-wise'. If I remember correctly, he mentioned that we currently can achieve 8 pm of residual rms motion in the arm cavity with respect to the PSL frequency. So we might be overestimating our loop's capability or underestimating some noise source. More feedback on this welcome and required.
The code used to calculate the transfer functions and plot them is in the repo 40m/ALS/noiseBudget
Attachment 5 here shows a block diagram for the control loop model used. Output port 'Res_Disp' is used for referring all the noise sources at the residual arm length fluctuation in the noise budget. The open-loop transfer function for ALS is calculated by -(ALS_DAC->ALS_Out1 / ALS_DAC->ALS_Out2) (removing the -1 negative feedback by putting in the negative sign.) While the AUX PDH open-loop transfer function is calculated by python controls package with simple series cascading of all the loop elements.
I think the digital loop in the ALS budget is too optimistic. You have to include all the digital delays and anti-aliasing filters to get the real response.
aslo, I recommend grabbing some of the actual spectra from the in-lock times with nds and using the calibrated spectra as inputs to this mode. Although we don't have good models of the stack, you can sort of infer it by using the calibrated seismometer data and the calibrated MC_F or MC_L channels (for IMC) or XARM/YARM signals for those.
This is not a reply to comments given to the last post; Still working on incorporating those suggestions.
Rana suggested looking first at what needs to be suppressed and then create a filter suited for the noise from scratch. So I discarded all earlier poles and zeros and just kept the resonant gains in the digital filter. With that, I found that all we need is three poles at 1 Hz and a gain of 8.1e5 gives the lowest RMS noise value I could get.
Now there can be some practical reasons unknown to me because of which this filter is not possible, but I just wanted to put it here as I'll add the actual noise spectra into this model now.
This ALS loop is not stable. Its one of those traps that comes from using only the Bode plot to estimate the loop stability. You have to also look at the time domain response - you can look at my feedback lecture for the SURF students for some functions.
Yes, that loop was unstable. I started using the time domain response to check for the stability of loops now. I have been able to improve the filter slightly with more suppression below 20 Hz but still poor phase margin as before. This removes the lower frequency region bump due to seismic noise. The RMS noise improved only slightly with the bump near UGF still the main contributor to the noise.
For inclusion of real spectra, time delays and the anti-aliasing filters, I still need some more information.
Related Elog post with more details: 40m/15587
Koji recommended that I can add whitening filters to suppress ADC noise easily. I added a filter before ADC in ALS loop with 4 zeros at 1.5 Hz and 4 poles at 100 Hz and added a reversed filter in the digital filter of ALS. This did not change the performance of the loop but significantly reduced the contribution of ADC noise above 1 Hz. One can see ALS_controls.yaml for the filter description. Please let me know if this does not make sense or there is something that I have overlooked.
Now, the dominant noise source is DFD noise below 100 Hz and green laser frequency noise above that. For DFD noise, I used data dating back to Kiwamu's paper. The noise contribution from DFD in the model is lower than the latest measured ALS noise budget post on elog. I'll look further into design details and noise of DFD.
Code, data, and schematics
I used D1400293 to get the latest logged details about the universal PDH box used to lock the green laser at X end. The uPDH_X_boost.fil file present there was used to obtain the control model for this box. See attachment one for the code used. Since there is a variable gain stage in the box, I tuned the gain of the filter model F_AUX in ALS_controls.yml to get the maximum phase margin in the PDH lock of the green laser. Unity gain frequency of 8.3 kHz can be achieved in this loop and as Gautam pointed out earlier, it can't be increased much further without changes in the box.
The ALS control model remains stable with a reduction in total estimate noise because of the above update. There are few things to change though:
For all the loops where we drive the NPRO PZT, there is some notch/resonance feature due to the PZT mechanical resonance. In the IMC loop this limits the PZT/EOM crossove to be less than 25 kHz. I don't have a model for this, btu it should be included.
If you hunt through the elogs, people have measured the TF of ALS NPRO PZT to phase/frequency. Probably there's also a measured ALS PDH loop somewhere that you could use to verify your model.
The only two PZT Phase modulation transfer function measurements I could find are 40m/15206 and 40m/12077. Both these measurements were made to find a good modulation frequency and do not go below 50 kHz. So I don't think these will help us. We'll have to do a frequency transfer function measurement at lower frequencies.
I'm still looking for ALS PDH loop measurements to verify the model. I found this 40m/15059 but it is only near the UGF. The UGF measured here though looks very similar to the model prediction. A bit older measurement in 2017 was this 40m/13238 where I assume by ALS OLTF gautum meant the green laser PDH OLTF. It had similar UGF but the model I have has more phase lag, probably because of a 31.5 kHz pole which comes at U7 through the input low pass coupling through R28, C20 and R29 (See D1400293)
If the green laser is not being used, can I go and take some of these measurements myself?
There was some UNELOGGED work at EX today. The DFD outputs were also hijacked for loss measurement. Unclear who the culprit was, but there is now a broad noise bump centered around ~180 Hz in the ALS X noise curve, which certainly wasn't there yesterday. Maybe let's keep the few working systems working, it is annoying to have to deal with these auxiliary issues every night. I'll push ahead with locking, hopefully the ALS noise is "good enough".
I re-checked the ALS noise in the following configurations:
The RMS noise sensed by POX/POY is ~20pm, which is somewhat higher than the best I've seen (maybe the arms are moving more at the time of measurement or the AUX PDH loops need a bit of touching up). But the orange traces in the top row of Attachment #1 are already ~x2 better than the equivalent traces from when we were using the green beams to make the beats. So it's hard to explain the 0-300 fluctuations in the arm powers when the CARM offset is reduced to 0 - i.e. the ALS noise is becoming worse as I reduce the CARM offset (= have more circulating power compared to the conditions of this test). I assume the transmission is Lorentzian, in which case even if we have 5x the CARM linewidth worth of ALS noise, we should see the arm power fluctuate between ~10 and 300.
* I notice that a big jump in the RMS sensed by POX/POY comes from the 24 Hz peak, which is presumably the Roll mode coupling to length - maybe a ResG can make the situation better. The high frequency noise can also be probably rolled off better.
Koji mentioned to me (and elogged) that he was unsuccessful locking the ALS using the LSC servos. He suggested I look into this.
So, rather than just looking at the transfer function between POX or POY and the green beatnotes at a single frequency, I did a whole transfer function. The point was to see if the TF is flat, and if we get any significant phase lag in the transfer from c1als to c1lsc. (c1als is running on the IOO machine, so an RFM connection is involved in getting it over to the LSC machine.)
In the first figure, I have plotted POX vs. Beatnote_PHASE_OUT (ALS error signal, still in the c1als model), and POX vs. ALSX_IN1 (the ALS error signal, after transfer over to the c1lsc model). You can see that we have a little phase lead in the blue transfer function, and fairly significant phase lag in the red (red is after transfer over to the lsc model). In the grand scheme of things, the magnitude is fairly flat, however that is not perfectly true - the peaks seen near 50 Hz and 300Hz are repeatable. The relative phase lag between the "BEATX" version of the signal in the ALS model, and the "ALSX" version of the signal in the LSC model is 15 degrees at 200 Hz, which corresponds to 33 usec.
The second figure is the same as the first, except for the Yarm. The relative phase lag between the ALS version of the error signal and the LSC version is 16 degrees at 200 Hz, which is about 35 usec.
As a side note, before trying any ALS locking, I took a spectrum of the beatnote (in the ALS model) while the arms were locked with IR:
To check things, I made sure that I could lock the Xarm ALS using the old ALS system - I was able to do so. (Has someone put the "watch" script as a constantly-on thing? It's kind of nice not to have to turn it on, although we'll need to change it to turn off the LSC versions of the servos eventually).
Then, I tried locking the Xarm using the LSC system (using only FM5 of the regular LSC-XARM filter bank). Like Koji, I was not able to acquire lock. As a next step, I copied all of the LSC-XARM filters into an empty filter module, LSC-XXXDC (the first one on the list underneath LSC-XARM), and copied over the ALS Xarm filters to the LSC Xarm filter bank. I then tried to acquire lock, but am unable to get it to stay. Using the ALS system, when you put in a small gain, the beatnote starts to settle down, and as you increase the gain, the beatnote stops moving (as seen on the spectrum analyzer) almost completely. However, using the LSC system, the beatnote never really stops moving or settles down. And if I increase the gain, I push the ETM hard enough that I lose green lock. I have put the regular LSC filters back for now.
Here is a plot from Foton comparing the FM5 filter modules from the LSC-XARM (regular IR locking) and the ALS-XARM servo. They are pretty different, and have 10 degrees of phase difference at 200 Hz, because 2 of the 3 poles are complex in the LSC version, while the ALS version is just a single real pole.
Anyhow, I am declaring it to be dinnertime, and I plan to return in a few hours. Since I put the regular LSC filters back (since I'm going to have to realign after dinner anyway), the IFO should be in its nominal state if anyone wants to come in and play with it.
Hmm. Wierd. Can you look at the TFs between ETMX-EXC and the error signals so that we can identify which one has these structures.