I fixed the XARM and YARM real time calibration servo.
I also change the C1CAL_MICH_A servo. Now the actuator response and the suspension TF are combined together and that filter name is BS_act. C1CAL_XARM_A and C1CAL_YARM_A have same kind of filters, ETMX_act and ETMY_act.
There are AI filter in each A servo and inv_AA, inv_DAA filters in CINV servo, but it's doesn't work correctly yet.
These aren't servos. What he means is that he's changed some filters in the real time calibration screens so as to make the actuation and sensing parts more accurate, but the inversion of the AA filters is not accurate yet.
In moving now to full IFO locking, there are a number of sub-states to diagnose:
Which to do first and in what order?
I vote on PRMI+1arm -> PRFPMI
The attached plot shows the spectra of all the REFL signals with the PRMI SB lock.
We excited the ITMY_LSC with 3000 counts. We used the Masayuki calibration of ITMY (5 nm / count * (1/f^2)) to estimate this peak in the REFL spectra.
To correctly scale the REFL spectra we account for the fact that the DTT BW was "0.187 Hz" and we turn off the "Bin" radio box before measuring the peak height with the cursor.
Since the ITMY motion is 3000 * 5e-9 / (580.1 Hz)^2 = 44.6 pm_peak, we want the DTT spectrum of the REFL spectra to report that too.
i.e. to convert from peak height to meters_peak, we use this formula:
meters_peak = peak_height * sqrt(BW) * sqrt(2)
I *think* that since the line shows up in multiple bins of the PSD, we should probably integrate a ~0.5 Hz band around the peak, but not sure. Need to check calibration by examining the time series, but this is pretty close.
Mystery: why are the REFL_I 3f signals nearly as good in SNR as the 1f signals? The modelling shows that the optical gain should be ~30-100x less. Can it be that our 1f electronics are that bad?
Bonus: notice how we have cleverly used the comb of bounce frequencies around the calibration line to determine that REFL11 is clipping!
First up for me this evening was getting the PRMI locked.
I used the IFO configure screen to lock the X and Y arms, then aligned them using the ASS scripts. Then used the IFO config screen to restore the Michelson, and did some fine tune tweaking of the BS alignment by looking at the AS camera. Then, I restored the PRMI from the IFO config screen, tweaked the PRM a little bit in yaw, and was able to get a lock using REFL 165 I&Q for ~25 minutes before I got bored and unlocked things. I used the ASS for the PRM to align the PRM, then turned off the ASS. POP110 and POP22 both drifted down, but by a small amount, and at the end (when I turned the ASS back on for PRM), they picked back up to about their original levels.
(Note to self: to get it to print both plots, chose custom paper size, make it 14.5 by 11. Don't ask why, just do it, because it works. Also, in PNG device properties, increase the compression to 9.)
After I played with the PRMI, I started looking at the ALS system.
I had both arms locked on IR using the regular LSC system (so POX and POY for the error signals). Then I opened up the green shutters, and got both arms locked on green (so the green lasers were just following the arms...no digital ALS business). I went out to the PSL table and tweaked up the alignment of the green beams (didn't need much at all, just an itsy bitsy bit in yaw, mostly). I saw a very strong peak for the Yarm vs. PSL (around -19dBm), and there was a harmonic of that beat. Opening and closing the Xarm green shutter had no effect on these peaks, so there wasn't any kind of X-Y cross beat sneaking around that I could see. That's really as far as I got - I think (but haven't checked) that Manasa may have removed the power splitter / combiner, so that the RF analyzer is only looking at the Y beat PD (she mentioned earlier today that she was going to give that a try to narrow things down).
After that, Rana and I went back to the PRMI for some noise stuff, and worked on the PMC. See those separate elogs for info on those activites.
Someone left the arms aligned, and the LSC engaged, so the arms have been locked almost continuously for several days hours. The trend below is for 4 days hours. What is most impressive to me is that we don't see a big degredation in the transmitted power over this time.
EDIT: Okay, I got excited without paying attention to units. It was only several hours, which is not too unusual. Although the lack of transmission degredation is still unusual. However, this may be due to improved oplevs? I'm not sure why, but we're not seeing (at least in this plot) the degredation to ~0.7 after an hour or so.
Something is really excellent with the alignment today, or something has changed with the POP path / electronics. While usually we see ~120 counts on POP22_I and ~175 counts on POP110_I (cf elog 9193), today I have ~175 counts on POP22_I and ~265 counts on POP110_I.
I have resaved the PRMI locking settings in the IFO Config screen. Nothing has changed, except that I have put a 1e-4 into the PRCL matrix elements for REFL11I, REFL33I and REFL55I. So, PRMI still locks on REFL165 I&Q, but the other 3 REFL diodes' whitening gets triggered when the cavity is locked. I think this will help the LSC sensing matrix measurements, which I'm going to test out now.
I discovered that I was not getting enough SNR on all the refl RFPDs when I actuated using the Sensing Matrix script. The problem was that the ITMs have actuation constants that are a factor of 5 lower than the PRM. So, I need to push on the ITMs (for MICH) about 5 times as hard as I push on the PRM (for PRCL). I have modified the sensing matrix scripts to allow different actuation amplitudes for each degree of freedom. If I watch the REFL PD spectra while the script is running, I see that I now have some actual SNR (as in, more than 1, which is what the SNR was for some diodes previously).
A consequence of this is that the script to analyze past data will no longer work on sensing matrix data taken before this afternoon. On the other hand, that data isn't very useful, since there was no SNR.
Rana and I noticed last week that it looked like the REFL11 beam was clipping. This afternoon, I locked the PRMI with REFL 165 I&Q, and checked the REFL 11 path. The beam looks fine through all of the optics going to the diode, so I just realigned the beam onto the diode using the itty bitty steering mirror. I have not yet checked the change (hopefully improvement) in the REFL11 spectrum.
I have modified the LSC model (the currently-running model is checked into the svn), but it is not compiling for me. So, if you need to make changes to it, be careful, and probably save my version off to the side, and checkout the latest svn version. (I don't foresee anyone needing to modify this model any time soon though).
The change that I'm trying to make is adding several more lockin setups, so that we can measure the sensing matrix elements for several degrees of freedom simultaneously.
Right now, the error that I'm getting is the frustrating "something isn't connected" error, even though if you look in the model, the part that it mentions is fully connected. Usually the solution to this is to disconnect and reconnect everything, so I'll work on that after I return to the lab in a bit.
The modifications to the LSC model are now complete, and the new model has been compiled, installed, and is running. The sensing matrix lockins are all in the c1cal model. Masayuki is locking right now, so so far, things appear to be back to normal.
The longer version of the story, with all the detours and hiccups:
After several tries of deleting the GoTo and From flags / tags in the lockin area of the LSC model, and continually getting the "something is not connected" errors, I gave up and just drew several long lines. So, in the new Sensing Matrix block (which is actually in c1cal, not c1lsc, but that's a story for the next paragraph), we should eventually make things back to the more clean flags situation, but for right now, it's working, with lots of lines everywhere. I've tried to be very organized and clear about what lines go where, so that it's easy to see what's going on.
I eventually was able to compile c1lsc, and then installed it, and restarted the model. Adding in 5x the lockin modules (we had 27, but now we have 5x27, so that we can look at the sensing matrix elements for every degree of freedom, and every photodiode, all at the same time) was too much for the poor lsc cpu. I was consistently getting over 70usec per cycle, and was hitting a max of 77usec for the lsc cpu. Both of those numbers are greater than the allowed 60usec. So, I made the decision to put the whole sensing matrix / lockin stuff into the calibration model. This means that I have 27+5 more IPC signals than I used to, but so far things seem to be okay (no rigorous testing yet). (27 to send the 27 PD inputs over to the cal model, and another 5 to send the oscillator "clocks" from the cal model to the lsc model.) The lsc model is now running faster than before (because there were 27 lockin modules in the model), at 24-28 usec, and the cal model is running at 39usec.
All seemed well and good, both the lsc and cal models compiled, but the lsc burt restore wasn't working. Restarting the model did not successfully do a burt restore, and when I tried several different .snap files from today, and other times this month using burtgooey, I kept getting "NOT OK", and numbers weren't being restored into the epics channels. A very few settings were restored, but most were not. I ended up copying a .snap file from a few hours ago into a separate directory, then went in and by-hand removed all the lines referring to now non-existant lockin channels. Burtgooey still told me "NOT OK", but settings seem to be restored, so I think it's okay. I have not confirmed each and every one of the 10,000+ channels to ensure that the number is the same as the one in the .snap file, but as I glance around in the LSC screen and its dependants, all the numbers and buttons look about right.
After all this stuff, Masayuki is locking both arms simultaneously in IR, as he prepares to test some new ALS scripts, so things seem okay for now.
After finishing up working on the models for today, I made corresponding screens.
The new Sensing Matrix (and lockin) overview screen is accessible from the sitemap: LSC -> Sensing Matrix.
From there, you have the oscillators, input matrices (one per degree of freedom), output matrix, and the lockin modules themselves. You can either look at several PDs for one degree of freedom (ex. there is a screen for all the AS RFPDs, demodulated for the DARM oscillation), or all the degrees of freedom for a single PD (ex. how are all the degrees of freedom seen in AS55Q?). The LSC screen has been updated to match - now you see 5 oscillator readbacks, and a larger output matrix. There is a button for the Sensing Matrix overview screen, and if you click on the cartoons of the oscillators, it'll take you to the oscillators screen.
Still to do:
* Decide what 5 frequencies to use for excitation.
* Put the bandpass and lowpass filters into the lockin modules.
* Put matching notch filters into each LSC servo.
* Re-write the sensing matrix scripts.
* Put a little more stuff into the front end so that we get total mag and phase of the sensing matrix element, not just uncalibrated lockin outputs.
I worked on some of these "to-do" things today for the new sensing matrix setup. I chose several frequencies around 90 Hz for my measurements. This was an area (while PRMI was locked with REFL 165 I&Q, and all 4 REFL PDs had their whitening on) there was a pretty wide clean space in the noise spectrum.
I put bandpass filters into the _SIG banks of the lockin modules, and lowpass filters into the _I banks. However, when I loaded the new filter coefficients, it looks like not all of them are showing up in the screens. I'm a little confused as to why. They are still there if I close and re-open Foton, so I think I really put them in.
Also, I don't think that I'm successfully getting any signal from the LSC model into the new lockin modules on the CAL model. I'm not sure if this is to do with the fact that I added 32 more IPC connections the other day. I've emailed Jamie to ask whether or not we may have hit some limit.
I also tried testing out a small bit of c-code for the calibration of the lockin outputs. It seems as though I cannot do an arctangent in the front end. When I compile the c1tst model, and start it up, if I have an "atan2" in the code, it tells me "No Sync". However, if I remove that line of c-code, the model compiles fine (which it did in the case with the arctan), and the model runs just fine (which it doesn't with the arctan). My backup plan is to include a Taylor expansion for the arctangent in some c-code.
I think that we always drive above the UGF for sensing matrix measurements since we like to put notches in the servo. In principle, we could drive within the control band and then take out the effect by measuring the control signal and undoing the gain in the digital filters. But that seems pretty complicated for any MIMO system.
Hmmmm, yup. I forgot to pay attention to what the UGFs of our LSC loops are when I was picking a low-noise region. Since they're (currently, at least) around 100Hz, I want to find a frequency in the few hundred Hz region. Masayuki has the IFO right now for ALS diagnostics, so I'll pick new frequencies later. If we decide to omit the bandpass filters, it's even easier to change frequencies on the fly (although we'll always still have to make the servo notch filters match).
After staring and thinking, I remembered that there is a limit to the number of characters that a channel name can have. So, I removed the "_LOCKIN" part of the names, and recompiled, and everything seems to work. I modified the screens that I had made, and they show all the appropriate things now.
The symptoms were that the numbers in the filter banks (for example, INMON) were white with the usual black background. The numbers are supposed to be green with a black background. After I recompiled, all the numbers were green.
This also means I need to re-put in the low pass filters.
PRCL Open Loop Transfer Function. PRMI locked on REFL 165 I&Q, Xarm held on IR resonance using ALS, ETMY misaligned:
MICH Open Loop Transfer Function. PRMI locked on REFL 165 I&Q, Xarm held on IR resonance using ALS, ETMY misaligned:
Time series data during our PRMI + 2 arm attempt:
its time to get the CM servo hardware turned back on. We're going to want to switch it on when we're about ~1/50th of the way up the CARM fringe.
A good way to re-commission it is to lock it to the single arm, using a Pomona box filter to move the arm pole down to the coupled cavity pole frequency.
I worked today some more on the new Sensing Matrix situation. I have added stuff to the CAL model, so that the sensing matrix elements come out calibrated to W/m, with phase in degrees. The idea is that we can see time series of the calibrated lockin outputs, so that we have minimal post-processing to do, since these are things that will be interesting to look at live.
The first step is to go from I and Q to magnitude and phase. Each "sensor" (ex. REFL55Q) is demodulated with a lockin part, which outputs sub I and Q channels (so, something like REFL55Q_I and REFL55Q_Q). We are only interested in the _I component of the lockin. But, REFL55I also has a _I and _Q. Again, we only take the _I part. Now, we have REFL55I_I and REFL55Q_I. We call these the I and Q components of the sensors (this is exactly what we normally call them, but it can get confusing since the lockins also have _I and _Q before we discard the _Q part). Now, we want to take these I and Q components, and transform them to a magnitude and phase. After we do that, we want to calibrate the magnitude to "Watts per meter" from "counts sensed per counts driven". I also converted the phase to degrees, since that's the unit we usually use when talking about the sensing matrices.
To go from the I and Q components to Mag and Phase, I wrote a little block of c-code, which is in /opt/rtcds/caltech/c1/userapps/release/isc/c1/src/MagPhaseFromIQ.c . Since we can't use the arctan function, I approximated it using equation 17 from Full Quadrant Approximations for the Arctangent Function [Tips and Tricks] from IEEE. (I used x -> y/x in equation 17, so that I had a 2D situation). I also have an "if / else if" cascade to determine what quadrant I'm in. Since the formula in the paper is from [0,pi/2), I just needed to add pi, subtract the answer from pi, or negate the answer to get to the other quadrants. Also, note that they are using a "normalized" arctan function, so equation 17 is really from [0,1), and you have to remember to multiply by pi/2 on your own.
To get from drive counts to drive meters, I put in an EPICS variable for the optic's actuation constant (ex, PRM's constant can be found in elog 8255). Right now, we have to transfer the oscillation frequency from the oscillator part's _FREQ variable to a new EPICS variable, but Zach and Joe just today made a new oscillator part that makes it easier to access the frequency and amplitude of the drive within the front end. See LLO aLog 9139 for details on this new part. I had trouble compiling with their new part, but once I get that figured out, I won't need to do this transfer of information. Anyhow, the drive calibration is (optic actuation constant)/[(drive frequency)^2].
Then the total calibration of the magnitude is Mag in cts/m = 2 * mag / [(drive amplitude) * (drive calibration)] . The factor of 2 comes from the fact that the lockin output is a factor of 2 smaller than the true sensing matrix element. The lower case "mag" in the formula is the output of the c-code.
After this, there is yet another EPICS variable, to hold the calibration for the photodiode, to get from counts sensed to Watts of power at the actual port. By "actual port", I mean the true IFO port, taking into account any optical elements between the port and the photodiode, like beam splitters and dumps, or loss from the imperfect reverse isolation of the input Faraday.
The code all compiles and runs fine, although I haven't done any explicit testing yet.
Still to-do for Sensing Matrix:
* Find all of the numbers for all of the EPICS variables. In particular, I need to get the ratio of the power hitting each photodiode to the power at that port.
* Write a script to do a burt-restore with all the correct settings, and turn on the dither lines.
* Put the lowpass filters back in the demodulators, now that they have new (shorter) names.
* Try it, and compare with the optickle model, and previous measurements.
* Copy Anamaria's script to look at the error statistics for my measurements.
Koji reminded me that we should also save the data from the PRMI+Xarm, just in case we want to look at it later.
Here is the time series, in which you can see us finding the Xarm IR resonance, moving the arm off resonance, locking PRMI, and bringing the arm back into resonance. At the very end, the arm is still held on resonance, but I had disabled the LSC locking, so we see very large flashes at TRX (of order 40, rather than 1).
The data is in the same folder as the 2arm data: /users/jenne/PRCL/PRMI_Xarm_ALS_16Oct2013/
The text files have been differentiated, so that the 2arm data has "_2arms" at the end of the filename, while the Xarm data had "_Xarm" appended to the filename. Since we left the cavities locked for many minutes (during which transfer functions were taken), the data set for the PRMI+Xarm is very long.
I locked PRMI, and (after fixing the POP QPD situation, noted in elog 9249) took power spectra of all the REFL RFPDs. It looks like the area above 500 Hz is pretty clean and flat for all the signals, so I'm going to use 560Hz, 562Hz, 564Hz, 566Hz and 568Hz for my 5 sensing matrix frequencies.
Also, I'm not sure what is going on with REFL11, but there's a weird dip between 630 Hz and 660 Hz in both I and Q. I recentered this guy not too long ago (elog 9218), but it clearly needs some more looking-at.
While Manasa, Jenne, and Masayuki are working on the preparing the interferometer, I write the elog for them.
- 6PM-ish: X and Y arms were was locked. They were aligned with ASS.
- PRMI was locked. The PRM was aligned with ASS.
- Jenne went into the lab and aligned the PRM ASC QPD.
- Jenne also aligned all of the oplev spots except for the SRM.
- 6:40PM Then, Manasa and Masayuki checked the out-of-loop stability of the arms.
The X and Y arms have the rms of 2.2kHz and 600Hz, respectively.
The X arm is significantly worse than the Y arm.
Masayuki saved the plot somewhere in his directory.
- 7:20PM X beat: 41.2MHz, Y beat: 14.8MHz
- 7:22PM PRMI locked POP110 115-120
- 7:30PM Lost lock of everything. Start over. Taking the arm alignment.
- 7:45PM start the 2nd trial. PRMI+one arm ready.
- 8:00PM explosion! Lost lock.
- 8:30PM The Xarm ALS is not stable anymore. It loses the control in ~10sec.
We are investigating the out-of-loop stability of the Yarm ALS.
(i.e. Look at the beat note error signal while locking the Yarm with the IR PDH)
I have modified the Sensing Matrix I,Q to Mag, Phase library part in the new sensing matrix system.
I had forgotten that in the c-code, I convert from radians to degrees, and so was doing the conversion again in the model. As it turns out, this gives you a nonsense number. I removed the multiplication by 180/pi in the model, and just use the output of the c-code, which is already in degrees.
I also put in some "choice" blocks just before the divisions in the calibration section of this library part. If it's about to divide by zero, divide by one instead.
The last modification so far today was adding the _PHASE_DEG and _MAG_WPERM (watts per meter) channels to a DAQ channels block, so that they are saved.
The RCG was very unhappy with me having 2 channels, with no data rate after them (doing this is supposed to imply that both should be saved at the default data rate), however after I put in "2048", it was happy. The symptom was a little tricky: The channel names in Dataviewer showed up red, even though the model compiles and runs. An indicator that you have a problem is a note in the model's "GDS" screen (the details screen that you can click to from the CDS front end overview screen). The channel name is "C1:FEC-50_MSGDAQ" (where the number 50 is specific to the c1cal model). After restarting the model, but before restarting the framebuilder's daqd process, this channel said "Error reading DAQ file!", rather than the date and time of the last successful read. At this point, before restarting the daqd process on the framebuilder, all of the fb statuses are green and good. However, after restarting the daqd process on the framebuilder, I got status "0x2000". Anyhow, after trying many different things, I determined that I could have 1 channel, without a specified rate, but if I wanted more than one channel, I needed to specify the rate for both.
[Masayuki, Jenne, Rana]
We have, for the past hour and a few minutes, had PRMI + 2 arms locked. Yup, that's right, we did it! (We never gave control of the arms to the IR LSC system, so it's kind of cheating, but it was still cool.)
A little after midnight, we felt that the Yarm was behaving well enough that we could give PRMI + 2 arms a try. So we did. Probably around 1am-ish, or maybe a little bit before, we had the system locked.
How did we do it?
* Locked arms in IR to help find green beatnotes.
* Misalign ETMs, lock and align PRMI.
* Misalign PRM.
* Restore ETMs, find arm resonances, then step away (I did +3 counts, which is 29 kHz).
* Restore PRM, lock PRMI.
* Brought Xarm back close to resonance using ALS (-3 counts). It seems like this may not actually have gotten us back to perfect resonance, but that actually made bringing in the other arm easier.
* Brought Yarm back close to resonance using ALS (-3 counts).
* Turned on Sensing Matrix notches and oscillators (10,000 counts for MICH, actuating on BS and PRM at 562.01 Hz, 200 counts for PRCL actuating on PRM at 564.01 Hz).
* Stepped arms back and forth to see how things responded.
During this process, particularly during the various arm steps, the PRMI lost lock many times. However, the ALS system never lost lock for either arm, for an hour and a half or so. Good work, ALS team!! The PRMI would reaquire lock (sometimes we'd have to undo whatever arm step we just took, to get farther away from resonance) without any intervention. It seemed that as we came closer to full arm resonance, we were never able to hold PRMI locked. This is what is instigating some of our investigations for tomorrow.
Also, Rana reported to me that he turned the c1tst model back off, and opened the door(s?) to the ETMY rack to allow more air flow sometime before midnight, which seems to have reduced the rate of the CPU going over 61 microseconds, as well as reduced the number of times the ETMY suspension glitches. We definitely need to make some changes so that we're not so close to the edge. This may have been one of the big things that allowed our success tonight.
The transmission PDs at the ends of the arms are saturating around 50 counts (they have gains of 2e-3 so that they are roughly normalized to 1 being the max power in a single arm). We need to commission the end transmission QPDs.
All of the signals looked a little ratty, and we heard lots of noise - Rana suggests that we recommission our CARM servo.
ALS beat info: [Xarm 40.9 MHz, -11.4 dB], [Yarm 50.5 MHz, -17.7 dB]
Things to look at tomorrow:
Data! I should be able to extract sensing matrix information, even though my sensing matrix software isn't totally ready yet. I know what the oscillators were doing, and I can look at the PD error signals. We also save the Offsetter numbers, so I can kind of tell what the PRMI+arms situation was.
Can we tell by looking at the end laser PZT feedback signals whether we're making our arms longer or shorter? So that we can tell if we're putting on DARM or CARM offsets.
Spectrum and time series of REFL 165 (our PRMI LSC locking PD) to see if we're saturating while we bring the arms into resonance. Basically, does anything bad happen, particularly since the PD is not a resonant PD, so there are some 1f signals floating around in addition to the 3f signals. We want to put in a directional coupler after the PD, before the demod board, and send that signal to a spectrum analyzer and a 'scope. Hopefully we can use the power of the internet to not need to sit in the IFO room saving data as we move the arms around. Do we need to put bandpass filters on the PD signal before it goes to the demod board?
Optickle model of 1f vs. 3f signals in the different ports, as the CARM offset is reduced.
Violin notches for the arms - should be put into ALS and LSC models. It looks like the modes are around 631 Hz, but we should check.
Hardware for end low gain transmission QPDs.
Software (schmidt triggering) for end transmission QPDs.
Modifying / preparing a matrix in the ALS system so that we can give CARM and DARM offsets conveniently.
Nice work. Congratulation
Just in case people were confused, although the PRMI + 2 ALS arms were controlled, we weren't able to bring them in to resonance. They were in some unknown off-resonant state.
We can try to calculate the expected recycling gain (ignoring losses in the PRM) following section F.2.1 of my Manifesto:
T_PRM = 5.6%, R_ARMS ~ 98%, G_PRC ~38.
So the full TRX/TRY powers should be G_PRC/T_PRM = 690.
In our stable configuration, we were sitting at TRX/Y powers of ~5-10. Once in awhile we could get a state where the power was saturating the detectors at ~50 and possibly would have gone up to 100, but it was all oscillation at that point. (we've got to find and notch the ETM violin mode frequencies in the ALS feedback servos.
As we move in towards resonance, we have to now consider all of complications of handing off to various error signals and CARM optical spring compensation and RF saturation that have been discussed in Rob's thesis and Lisa's lock acquisition modeling.
> all of complications of handing off
- ALS error signals transfered to the LSC input matrix.
- Handing off from the ALS to the 1/sqrt(TRX)+offset signal
- Handing off to the RF signal
- And, of course, CM servo.
I have modified the ETM suspension models to include a schmidt triggering block, so that we can choose between using the high gain low power Thorlabs PD and the low gain high power QPD.
The Thorlabs high gain PD signal is used as the signal to trigger on, so we need to put appropriate thresholds in.
If things are "triggered", that will imply that the Thorlabs PD is seeing a lot of power, so we should be using the QPD SUM channel instead. There is a "choice" block after the trigger block, to do this switching.
Since the LSC model will only see the output of this choice block, the gain that is currently in C1:LSC-TR[X or Y]_GAIN should be moved to the end SUS model. We also need to find the correct gain for the QPD sum channels so that they are also normalized to "1" for single arm full power so that we can smoothly go between the 2 diodes.
Rana has promised to make screens, and write scripts for the switching stuff.
As Jenne's Elog we want to see Spectrum and time series of REFL 165 (our PRMI LSC locking PD) to see if the signal is saturated while bring the arms into resonance.
I started to connect the spectrum analyser and the 'scope to REFL165 output.
Directional coupler (Mini=-circuits ZMDC-10-2 ZMDC-20-3) was connected just before the dimod boad input. The main output of coupler is plugged into demod board's input.The other output of the coupler is connected to AG4395A using BNC cable.
The spectrum analyser output can be read using netgpibdata in control room. The IP address is 192.168.113.108 and the GPIB address is 17. For this I dissconected the network hub from another AG4395A, which is at the front of 1X2 lack.
I didn't connected the 300 MHz 'scope right now, but tomorrow it will be connected using power splitter and also be able to get data by internet. For connect 'scope to network, I disconected the network hub from SR785.
We were locking the PRMI, but it is very rumbly today. I reduced the MICH servo gain from -0.8 to -0.4 , and things seem to be better. Now my MICH UGF is about 60Hz.
I measured the spectrum of the REFL165 output using AG4395A. As this entry we put the directional coupler between REFL165 output and demod board input, so I measure the signal from the coupler during the PRMI was locked.
After measure REFL165, I also measured REFL55 output in order to make sure that the signal is not smaller than noise because of coupler. I terminated the couple output of coupler on the REFL165, and take signal from REFL55 output port directly. Both plots seems same except for around the resonant frequency of each PDs. From this plot we cannot say that the coupler reduce signal to spectrum analyser too much.
After this measurement I reconnected the REFL165 to analyser and reconnected the REFL55 output to demod board.
As Jenne's Elog we want to see Spectrum and time series of REFL 165 (our PRMI LSC locking PD) to see if the signal is saturated while bring the arms into resonance.
I started to connect the spectrum analyser and the 'scope to REFL165 output.
We changed the Directional coupler from ZMDC-20-3 to ZMDC-20-5-S+ because that coupler seemed to introduce some high frequency noise.
I connected the 'scope between REFL165 output and demod board input. I split the signal from coupler using the splitter (Mini-Circuits ZFSC-2-5). One signal is going to 'scope CH1 and the other is going to spectrum analyzer. I connected the 'scope to 40MARS. The IP adress is 192.168.113.25. I connected that by cabling from 1X2.
The command to get the data from spectrum analyzer right now
From command line, put ./netgpibdata -i 192.168.113.108 -d AG4395A -a 17 -f meas01
(EDIT JCD: You must first be in the correct folder: /opt/rtcds/caltech/c1/scripts/general/netgpibdata/)
(EDIT JCD again: "meas01" in the command line instruction will be the name of the filename. Also, the output file meas01.dat has a comment in the first line that must be deleted before you can plot the data. This sucks, and we should write a script to strip that line, then make nice plots.)
Please take notice that although IP address of AG4395A is same as written in the help of netgpibdata, the GPIB address is not same. It's 17.
How to use 'scope from control room.
Open the browser. Put the IP adress of 'scope (192.168.113.25) into adrress bar of the browser. If it's on the network, below screen will open.
You can control 'scope, get the data, and so on from control room.
Please take notice that Google Chrome cannot connect the 'scope. So you have to use the Firefox or other browser.
As we are meditating on things to look at for PRMI + 2 arms, Rana brought up the question of the demod board situation.
We then found this table on the wiki (LSC demod boards) that indicates that all of the demod boards were originally given lowpass filters, no matter the demodulation frequency. Back in September, I switched out the low pass filter for a bandpass filter in POP110, and put in the same bandpass when putting together AS110 (elog 9100). So, the 11MHz diodes are probably okay with lowpasses, and the 110 diodes are okay, but we need to think about all the other ones.
We should probably do a first guess by putting in a bandpass filter, but then simulate and measure to figure out what our requirements are for attenuation at the non-demodulation frequencies for each board.
The SXBPs from Minicircuits look pretty good, but there are lots of options on their website.
For tonight, Rana has put a coax 100 MHz highpass filter on the input to the REFL165 demod board.
This of course changes our demod phase. Rana plotted a 4th order elliptic filter in Matlab, and from the plot determined that we should expect around 60 degrees of difference in our phase.
To actually set the phase, I locked PRMI on AS55Q and REFL33I (MICH gain = -8.0, PRCL gain = +0.05, with 1's in the matrix elements). I then turned on the PRCL oscillation notch (564 Hz), and turned on the sensing matrix's drive at that frequency, and looked at the spectrum of REFL165.
The previous REFL165 demod phase was 96 degrees, so I was looking around either 36 degrees or 156 degrees. The phase that minimized the peak in the Q signal while driving PRCL was 37.5 degrees. Good work Matlab/Rana.
I then looked at the transfer functions between REFL33 and AS55 and REFL165, to see if there were any sign flips that happened. There were not. As expected, it was just a little extra phase delay.
I was able to lock PRMI with REFL 165 again after this phasing, and I am now taking transfer functions of the MICH and PRCL loops to make sure that we have the gains about right.
I am now taking transfer functions of the MICH and PRCL loops to make sure that we have the gains about right.
I have set the PRCL UGF to be about 180Hz, and the MICH UGF to be about 70 Hz.
This is with locking on REFL165 I&Q, with MICH gain of -2.0 and PRCL gain of 0.70 .
The PRCL loop only has about 30 degrees of phase margin, and is not near the top of its phase bubble. During the day, I need to look at why we don't have more phase near 200 Hz.
I worked on the script SPAG4395A.py tonight with Masayuki's help. This sets up the parameters on the Agilent 4395A and then acquires the spectrum data. It had a couple of bugs before: no matter what channel you requested, you always got channel R. It also would disobey any requests to reduce the attenuation and left the Auto Atten ON. The version now in the SVN allows you to choose the channel and the attenuation.
It then makes this plot using matplotlib. The attached image is from the REFL165 pickoff at a time tonight when the arm powers were ~5-10. I have converted the spectrum from RF electrical Watts into Volts (V = 50*sqrt(W)). To go from the analyzer input to the demod board input we should scale this spectrum by a factor of ~15 (to account for the 20 dB from the coupler and the 3 dB of the splitter and a little more for losses). On the oscilloscope we see Vpp ~5 mV, so that's ~75 mVpp at the output of the BBPD which we're using for REFL165. Perhaps we can handle another factor of ~2-3 ? I'm not sure what we have in terms of linearity measurements on this thing.
EDIT: Evan is right, its V = sqrt(50*W), not V = 50*sqrt(W). ignore y-axis above
Masayuki was able to hold both arms off-resonance with ALS long enough for me to lock the PRMI (arms still held off resonance), and take a set of transfer functions.
MICH gain is still -2.0, PRCL gain is still 0.070, which, with the ETMs misaligned, gave me UGFs of 70 for MICH and 180 for PRCL.
Now, however, with the ETMs aligned, but arms held off resonance with ALS, the UGFs have been lowered by a factor of 2 in frequency! What is doing this?? MICH is now 40 Hz, and PRCL is now 80 Hz.
We measured the MICH and PRCL loops for several arm powers, and there was no change, at least until the arms were both resonating with powers of ~4 .
After misaligning the ETMs, I remeasured the loops, and the UGFs went back up to where they started.
I simulated how the 3f signal is affected by the resonance condition of the arms.
To keep it simple, I only simulated a double cavity. The attached plot shows the result. In x there is the arm cavity detuning from resonance (in log scale to show what happens close to the 0 value). In the y axis there is the PRC detuning. So every vertical slice of the upper plot gives a PDH signal for a given arm detuning. The bottom plot shows the power build up inside the arm, which is dominated by the carrier.
The 3f signal is not perturbed in any significant way by the arm resonance condition. This is good and what we expected.
However, in this simulation I had to ensure that the 1f sidebands are not perfectly anti-resonant inside the arms. They are indeed quite far away from resonance. If the modulation frequency is chosen in order to make the 1f sidebands exactly ant-resonant, the 2f will be resonant. This screws up the signal: REFL_3f is made of two contributions of equal amplitude, one on the PRC sidebands resonance and the other on the PRC carrier resonance. When the arm tuning goes to zero, these two cancels out and there is no more PDH...
However, this is a limit case, since the frequency show match perfectly. If the modulation frequency is few arm line widths away from perfect anti-resonance, we have no problem.
Yes, the resonance of the 2nd-order sidebands to the IFO screws up the 3f scheme.
2f (~22MHz) and 10f (~110MHz) are at x 5.6 and x 27.9 FSR from the carrier, so that's not the case.
Could we also see how much gain fluctuation of the 3f signals we would experience when the arm comes into the resonance?
From the simulation there is no visible change in the gain.
5:31pm - This is still a work in progress, but I'm going to submit so that I save my writing so far. I think I'm done writing now.
First, a transcription of some of the notes that I took last Tuesday night, then a few looks at the data, and finally some thoughts on things to investigate.
MICH and PRCL Transfer Functions while arms brought in to resonance (both arms locked to ALS beatnotes):
This is summarized in elog 9317, which I made as we were finishing up Tuesday night. Here's the full story though. Note that I didn't save the data for these, I just took notes (and screenshots for the 1st TF).
POP22I was ~140 counts, POP110I was ~100 counts.
MICH gain = -2.0, PRCL gain = 0.070.
First TF (used as reference for 2-10), PRMI locked on REFL165, Xarm transmission = 0.03, Yarm transmission = 0.05 (both arms off resonance). MICH UGF~40Hz, PRCL UGF~80Hz.
2: X=off-res (xarm not moved), Y=0.13, no change in TF
3: X=off-res (xarm not moved), Y=0.35, no change in TF
4: X=off-res (xarm not moved), Y=0.60, MICH high freq gain went up a little, otherwise no change (no change in either UGF)
5: X=off-res (xarm not moved), Y=0.95, same as TF#4.
6: X=0.20, Y=1.10 (yarm not moved), same as TF#4
7: X=0.40, Y=1.30 (yarm not moved), same as TF#4
8: X=0.70, Y=1.55 (yarm not moved), same as TF#4
9: X=1.40, Y=2.20 (yarm not moved), same as TF#4
10: X=4.0, Y=4.0 (yarm not moved), PRCL UGF is 10Hz higher than TF#4, MICH UGF is 20Hz lower than TF#4.
11: (No TF taken), Xarm and Yarm transmission both around 20! To get this, MICH FMs that were triggered, are no longer triggered to turn on. Also, MICH gain was lowered to -0.15 and PRCL gain was increased to 0.1
12: (No TF taken), Xarm and Yarm transmissions both around 40! The peaks could be higher, but we don't have the QPD ready yet.
After that, we started moving away from resonance, but we didn't take any more transfer functions.
OpLev spectra for different arm resonance values:
We were concerned that the ETMs and ITMs might be moving more, when the arms are resonating high power, due to some optical spring / radiation pressure effects, so I took spectra of oplevs at various arm transmissions.
I titled the first file "no lock", and unfortunately I don't remember what wasn't locked. I think, however, that nothing at all was locked. No PRMI, no arm ALS, no nothing. Anyhow, here's the spectrum:
I have a measurement when the Yarm's transmission was 1, and the Xarm's transmission was 1.75. This was a PRMI lock, with ALS holding the arms partially on resonance:
Next up, I have a measurement when Yarm was 0.8, Xarm was 2. Again, PRMI with the arms held by ALS:
And finally, a measurement when Xarm was 5, Yarm was 4:
Just so we have a "real" reference, I have just now taken a set of oplev spectra, with the ITMs, ETMs and PRM restored, but I shut the PSL shutter, so there was no light flashing around pushing on things. I noticed, when taking this data, that if the PSL shutter was open, so the PRFPMI is flashing (but LSC is off), the PRM oplev looks much like the original "no Lock" spectra, but when I closed the shutter, the oplev looks like the others. So, perhaps when we're getting to really high powers, the PRM is getting pushed around a bit?
Conclusions from OpLev Spectra: At least up to these resonances (which is, admittedly, not that much), I do not see any difference in the oplev spectra at the different buildup power levels. What I need to do is make sure to take oplev spectra next time we do the PRMI+2arms test when the arms are resonating a lot.
Time series while bringing arms into resonance:
I had wondered if, since the POP 22 and 110 values looked so shakey, we were increasing the PRCL RIN while we brought the arms into resonance. You can see in the above time series that that's not true. The left side of the plot is PRMI locked, arms held out of resonance using ALS. First the Yarm is brought close to resonance, then the Xarm follows. The RIN of the arms is maybe increasing a little bit as we get closer to resonance, but not by that much. But there seems to be no correlation between arm power and RIN of the power recycling cavity.
Alternatively, here is some time series when the arm powers got pretty high:
Possible Saturation of Signals:
One possibility for our locklosses of PRMI is that some signal somewhere is saturating, so here are some plots showing that that's not true for the error and control signals for the PRMI:
Here, for the exact same time, is a set of time series for every optic except the SRM. We can see that none of the signals are saturating, and I don't see any big differences for the ITMs or ETMs in the times that the PRMI is locked with high arm powers (center of the x-axis on the plot) and times that the PRMI is not locked, so we don't have high arm powers (edges of the plot - first half second, and last full second). You can definitely see that the PRM moves much more when the PRMI is locked though, in both pitch and yaw.
DCPD signals at the same time:
NB: These latest 3 plots were created with the getdata script, with arguments "-s 1067163405 -d 7". It may be a good idea to take some spectra starting at, say 1067163406, 1 second in, and going for ~2 seconds. (It turns out that this is kind of a pain, and I can't convince DTT to give me a sensible spectrum of very short duration....we'll just need to do this live next time around).
Things to think about and investigate:
Why are we losing lock?
On paper, is the (will the) optical spring a problem once we get high resonance in the arms?
Spectra of oplevs when we're resonating high arm power.
What is the coupling between 110MHz and 165MHz on the REFL165 PD? Do we need a stronger bandpass?
Why are things so shakey when the arm power builds up?
Why do PRCL and MICH have different UGFs when the arms are controlled by ALS vs. ETMs misaligned?
Does QPD for arm transmissions switching work? Can we then start using TRX and TRY for control?
What is the meaning of the similar features in both transmission signals, and the power recycling cavity? Power fluctuation in the PRC due to PRM motion?
Gabriele and I talked for a while on Wednesday afternoon about ideas for transitioning to IR control, from ALS.
I think one of the baseline ideas was to use the sqrt(transmission) as an error signal. Gabriele pointed out to me that to have a linear signal, really what we need is sqrt( [max transmission] - [current transmission] ), and this requires good knowledge of the maximum transmission that we expect. However, we can't really measure this max transmission, since we aren't yet able to hold the arms that close to resonance. If we get this number wrong, the error signal close to the resonance won't be very good.
Gabriele suggested maybe using just the raw transmission signal. When we're near the half-resonance point, the transmission gives us an approximately linear signal, although it becomes totally non-linear as we get close to resonance. Using this technique, however, requires lowering the finesse of PRCL by putting in a medium-large MICH offset, so that the PRC is lossy. This lowering of the PRC finesse prevents the coupled-cavity linewidth of the arm to get too tiny. Apparently this trick was very handy for Virgo when locking the PRFPMI, but it's not so clear that it will work for the DRFPMI, because the signal recycling cavity complicates things.
I need to look at, and meditate over, some Optickle simulations before I say much else about this stuff.
You have the data. Why don't you just calculate 1/SQRT(TRX)?
...yeah, you can calculate it but of course you don't have no any reference for the true displacement...
I made some small edits to the LSC screen.
* When I added columns for the new AS110 PD, I had forgotten to make the Trigger matrix and Power Normalization matrix icons on the screen bigger, so we weren't seeing the last 2 columns in the overview screen.
* I added "show if not zero" oscillator icons to the Sensing Matrix part of the LSC overview screen, so that it's easier at a glance to see that there is an oscillator on.
The idea of introducing a large MICH offset to reduce the PRC finesse might help us to get rid of the transmitted power signal. We might be able to increase enough the line width of the double cavity to make it larger than the ASL length fluctuations. Then we can switch from ASL to the IR demodulated signal without transitioning through the power signal.
I think Steve is trying to align the end transmission QPDs, since the arms are locked nicely right now. I noticed that the QPDX pitch and yaw signals were digital zeros. A quick look determined that the QPDX matrix to go from 4 quadrants to 3 degrees of freedom had been filled in for the POS row, but not pitch and yaw. So, I copied the QPDY matrix over to QPDX (so the ordering of the rows and columns is assumed to be the same).
Hopefully this will get us close to centered, but I suppose we ought to check really which quadrant is which, by shining a laser pointer at each quad at each end.