Here is the Yuta's Alignment Scheme from elog 17056 with these slight adjustments:
Current alignment scheme:
Current alignment scheme I figured out is the following.
- Check Y green. If it is transmitted at good spot on GTRY camera, Yarm is OK. If not, tweak ITMY/ETMY. alignment.
- Mis-align AS4, align TT1, TT2, LO1 to have BHDC_A_OUT of ~115 and BHDC_B_OUT of ~95.
- Align PR3, PR2 to maximize TRY_OUT to ~1.0
- Tweak ITMY/ETMY if the beam spot on them are not good.
- Align BS, ITMX to have good MICH fringe and TRX_OUT to ~1.0.
- Tweak ITMX/ETMX if the beam spot on them are not good.
- Misalign ETMY, ETMX, ITMY to have LO-ITMX fringe in BHD DCPDs. From Sitemap --> BHD --> Homodyne Phase Ctrl --> LO_PHASE --> Turn ON LO Phase Servo (This will lock LO and ITMX fringe) --> align AS beam with SR2 and AS4 differentially, with ratio of AS4/SR2=3.6 for YAW, with ratio of AS4/SR2= 4.5 for PITCH to have BHDC_A_OUT ~ 50.
- Restore ITMY alignment, and lock MICH.
Some ideas Koji suggested:
For the second idea, it is convenient to be able to control the arms in the XARM/YARM basis as opposed to the CARM/DARM basis as we usually do when going through the locking sequence. After some fiddling, I am able to reliably execute this transition, and achieve a state where the FP arm cavities are resonant for the IR with the ALS beat note frequency being the error signal being used. Some important differences:
I took a look at the TRX/TRY RIN reported in the single arm POX/POY lock, and compared the performance of the two available PDs at each of the two ends. Attachment #1 shows the results. Some remarks:
Main goals tonight were:
we decided to give the PRFPMI lock a go early-ish. Summary of findings today eve:
The ALS--> IR CARM handoff is the problematic step. In the past, getting over this hump has just required some systematic loop TF measurements / gain slider readjustments. We will do this in the next few days. I don't think the ALS noise is any higher than it used to be, and I could do the direct handoff as recently as March, so probably something minor has changed.
Could not load filters into the C1:SUS-ETMX_LOCKIN1_SIG filter bank.
Apparently the filter bank name was too long. I'm not sure why this isn't caught by the real time code generator, I'm planning on asking Alex and Rolf about it today.
Reduce the name of the components. Basically LOCKIN1 needs to become something like LOCK1 or LIN1.
In related news, it looks like the initial filters are hard coded to be 2048 Hz. Given that they start out empty they won't cause things to break immediately, and if you're editing the file you can update the rate as you add the filter. I'll also bring this up with Alex and Rolf and see if the RCG can't be more intelligent about its filter generation.
Each morning now, I am going to try to align both arms and lock. Along with that, sometime at towards the end of each week, we should align the OpLevs. This is a good habit that should be practiced more often, not only by me. As for the Y Arm, Yehonathan and I had to adjust the gain to 0.15 in order to stabilize the lock.
I was going to try some locking, but things are a little too noisy.
Just so Kiwamu knows what I did today, in case he comes back....
I ran LSCoffsets, and aligned both X and Y arms and saved their positions, and aligned MICH, and saved the BS position.
I'll play with it more later, when there aren't trucks driving around outside that I can hear / feel in the control room.
After giving up on locking, the MC is getting unlocked every now and again (2 times so far in the last few minutes) from transient seismic stuff.
I finally managed to get long stretches of PRMI lock, up to many minutes. The lock is not yest very stable, it seems to me that we are limited by some yaw oscillation that I could not trace down. The oscillation is very well visible on POP.
Presently, PRCL is controlled with REFL55_I, while MICH is controlled with AS55_Q. This configuration is maybe not optimal from the point of view of phase noise couplings, but at least it works quite well. I believe that the limit on the length of locks is given by the angular oscillation. I attach to this entry few plots showing some of the lock stretches. The alignment is not optimal, as visible from a quite large TEM01 mode at the dark port.
Here are the parameters I used:
MICH gain -10 PRCL gain -0.1
Normalization of both error signal on POP22_I with factor 0.004
Triggering on POP22: in at 100, out at 20 for both MICH and PRCL.
POP55 demodulation phase -9
MICH and PRCL control signal limits at 2000 counts
There is a high frequency (628 Hz) oscillation going on when locked (very annoying on the speakers...), but reducing the gain made the lock less stable. I could go down to MICH=-1.5 and PRCL=-0.02, still being able to acquire the lock. But the oscillation was still there. I suspect that it is not due to the loops, but maybe some resonance of the suspension or payload (violin mode?). There is still some room for fine tuning...
Lock is acquired without problems and maintained for minutes.
Have a nice week-end!
Our first move has to be fixing the whitening switching for REFL55. That's the configuration we need to start and then move onto REFL165 to get to FPPRMI.
I put a notch in FM10 for both MICH and PRCL at 628Hz, to try to prevent us from exciting the mode that Gabriele saw on Friday. Since those filter banks were all full, I have removed an ELP50 (ellip("LowPass",4,1,40,50)). I write it down here, so we can put it back if so desired.
Thursday morning I found the control room emergency exit not locked.
Please check the doors when leaving the lab , specially when you are the last one out.
Which 1f signals are you going to use? PRCL has sign flipping at the carrier critical coupling. So if the IFO is close to that condition, 1f PRCL suffers from the sign flipping or large gain variation.
For these initial attempts, I was just trying to transition MICH to REFL55Q. I agree, the PRCL situation may be more complicated.
Here, I provide some details of the sequence. Obviously, I am presenting one of the quickest transitions to the fully locked state, I don't claim that every attempt is so smooth. But it is pretty cool that the whole thing can be done in ~3 minutes.
See Attachment #1 for the labels.
This particular lock held for ~20 minutes so I could run some loop characterization measurements etc.
I am struggling to explain:
I see. At the 40m, we have the direct transition from ALS to RF. But it's hard to compare them as the storage time is very different.
Provided the IMC is cooperative, the input pointing isn't drifting, and the RF offsets aren't jumping around too much, the locking sequence is now pretty robust.
Most of the analysis uses data between the GPS times 1274418176 and 1274419654 that are recorded to frames.
I tried locking single arm this morning, but I was unable to because the triggers were set to lock strictly to MICH. Anchal explained this to me and helped me out. I figured this information would be useful and should be logged somewhere. In red, this is accessed through the IFO --> Configure. Choosing X Arm and Y Arm will change the triggers on the C1LSC page for the single arm locking (In the Black Box.)
Here is a lock loss from around 11 PM tonight. Might be due to poor PRC signals.
This is with arm powers of ~6-10. You can see that with such a large MICH offset, POP22 signal has gone done to zero. Perhaps this is why the optical gain for PRCL has also dropped by a factor of 30 .
This seems untenable . We must try this whole thing with less MICH offset so that we can have a reasonable PRCL signal.
Between the 40m meeting, and chatting with Gabriele, there was lots of talking yesterday about our 40m Lock Acquisition game plan.
From those talks, here is my current understanding of the plan, in a Ward-style cartoon:
(This is a 2 page document - description of steps is on 2nd page)
If you look closely, you will notice that there are several places that I have used "?" rather than numbers, to indicate what RFPD signal we should be using. To fill these in, I need to look at some more simulations, and think more carefully about what signals exist at what ports, and what SNR we have at each of those ports.
Also, while the overall scale of the arm power plot is correct, the power level at each step is totally arbitrary right now, and should just be taken to mean places (in time) where the CARM offset is reduced a little more.
There are several things at this point that we know we need to look into:
* POP 22/110 PD and filtering electronics should be switched to a broadband PD, rather than the Thorlabs PD + Miniciruits filters. (Hardware)
* Whitening for the transmission QPDs needs to be thought about more carefully. (Calculation, then hardware)
* Chose a good SNR REFL DC signal, which may or may not be from the PD we are currently using (I think it's the DC of REFL11, but I'll have to check). (Calculation)
* For DRMI locking, what is the size of the SRCL error signal at AS55, AS165, and the REFL ports? Do we need to lock with AS port, and then switch over to a REFL 3f port, to make acquisition easier? (Simulation)
* Similarly, I want to make the equivalent of Figure 3 of T1000294, with our 40m parameters. (Simulation)
* To set the phase of AS110, simulate the demod phase of AS110 in both DRMI and SRMI cases. If no (significant) change, maybe we can set the phase in the real system by misaligning the PRM, and watching the SRMI flash. (Simulation)
* Simulate an arm sweep, up to many orders of the sidebands, to see how close to the carrier resonance any sideband resonances might be. If something like the 4th order sideband resonates, and then beats with a 1st order sideband, is that signal big enough to disturb our 3f locking of the PRMI / DRMI? We want to be holding the arms off resonance with ALS closer to the carrier than any "important" sideband resonances (where the definition of "important" is still undetermined). (Simulation)
* Check if we can hand DARM from the DC transmission signals to the final RF signal while we still have a large CARM offset. Is there a point where the CARM offset is too large, and we must be still using the DC signals? (Simulation)
* At what arm power level can we transition from ALS to IR DC transmission signals for the individual arms? (Simulation)
* Still need to finish calculating what could be causing our big arm power fluctuations (Test mass angular motion? PRM angular motion? ALS noise?) (Calculation)
Replys, and comments are welcome, particularly to help me understand where I may have (likely did) go wrong in drawing my cartoon.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "en_US.ISO8859-1",
LC_MONETARY = "en_US.ISO8859-1",
LC_CTYPE = "en_US.ISO8859-1",
LC_COLLATE = "en_US.ISO8859-1",
LC_MESSAGES = "C",
LC_NUMERIC = "en_US.ISO8859-1",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
We found that the caput commands were taking much longer to execute on megatron than on pianosa (for example). Suspecting that this had something to do with the fact that megatron was using EPICS binaries from the shared NFS drive which were compiled for a much older OS, I installed the latest stable release of EPICS on megatron. The new caput commands execute much faster. I also added the local EPICS directory to the head of the $PATH variable used by the MC autolocker and FSS Slow scripts, so that they use the new caput command. But mcup is still slow - maybe my new path definition isn't picked up and it is still using the NFS binaries? To be looked into...
There were a bunch of medm processes stalled on megatron (connected with screenshot taking). To see if they were interfering with the other scripts, I killed all of the medm processes, and commented out the line in the crontab that runs the screenshots every 10 mins. Let's see if this improves stability.
Koji has provided a 2TB USB3 external hard drive that will get daily backups of chiara:/home/cds, the idea being that if the internal HD at /dev/sdb1 fails, we can physically open the external up, and swap the hard drive into chiara.
We're running an rsync job on it right now, which should be done in a few hours. (USB3 is fast!)
I've also written a backup script at scripts/backup/rsync_chiara.backup which keeps its books in scripts/backup/rsync_chiara.backup.log
I'm adding a entry to the root crontab on chiara to execute the script every day at 7am.
I had some syntax errors in the script that prevented the script from doing the right thing. The backup is now up to date, and the cronjob should work.
I'll bring a file binder "40m wiring diagram" to home at the next chance.
There is another one on the shelf in the control room.
(I thought I put it in my bag, but it looks like that I left it somewhere around the fax area)
Larry and Nicolas
Larry's transfer function measurements suddenly started returning 0dB 0degrees when before there was some fake filter in the C1:ALS-OFFSETTER2 filter bank.
We looked in the filter bank and his filter was gone. So I created a new filter called LARRYP in FM2. We also disabled the output so he could drive the filter bank and test his TF code.
I tried to figure out why offline LMS filter subtract seismic noise much better from MC_F then the Wiener filter. I did the calculations twice - with my codes and with Matlab in-build functions, the results are the same. So this is not a code error.
The coherence between GUR 1, 2 and MC_F is still poor. Wiener filter is linear and its performance is confined to the frequency ranges where we see coherence. Lms filter is non-linear and it may be possible to subtract the noise even if non-linear effects are present in the system.
I've checked seismometer readout box again. I've soldered 50 Ohms to plus and minus inputs to VERT 1,2 N/S 1,2, E/W 1,2 - GUR 1 and 2 use these channels. Then I put the box back and connected it to the ADC.
The plot shows that the readout box noise is below the ADC noise. It is possible that amplifiers introduce non-linear effects. To check this I plotted the coherence between OSEM sensors and GUR1X signal:
The coherence between OSEM sensors and GUR1X is pretty good, so may be witness path is not responsible for low coherence at 0.1 - 0.5 Hz between MC_F and GUR 1,2. IT seems that MC_F is bad at low frequencies. I terminated the input to the Channel 1 of the Pentek Generic board, where MC_F is plugged in.
ADC is also good. Something else is wrong.
We opened up the little Thorlabs battery operated PD to see what was inside. Rana took some pictures, and I drew a schematic (attached). It's just a diode, biased with a battery (albeit a crazy 22.5V battery).
Comment by KA: PD is Hamamatsu S1223-01 Si PIN diode.
What a crazy battery. The main point is that it looks like this can be used for reasonable purposes: uses a load resistor on the BNC connector and you can use some pre-amp (e.g. Busby box or SR560) to have a low noise PD readout. You can also use the SR560 in its A-B mode as an 'opamp'. Ground the A input and the use a pole at 1 Hz and make the Output go into the B input through some large series resistor. The BNC from the PD gets Teed into the B input as well.
Then this becomes a transimpedance circuit readout of the diode, using the current noise of the SR560 as the limit.
I need to figure this out before it's worth trying any acrobatic AO path turn-on scenarios.
Also this evening, I went to the Yend and did another tweak-up of the green beam alignment.
Never mind. This is just the low pass filter that Den put in to try to deal with the moving cavity pole.
Before I realized this, just in case it was a computer quirk, Koji and I rebooted the end station front end machines. This had no effect other than to keep me searching and measuring until I figured it out. If I turn off the low pass, the phase pops back up to very close to the reference. The low pass currently comes on automatically as part of the carm_cm_up script.
Here are some tests we should script.
Checking the Acromag DAC calibration is more complicated I think. There are measurements of the actuator calibration in units of nm/ct for the fast DACs. But these are only valid above the pendulum resonance frequency and I'm not sure we can synchronously drive a 10 Hz sine wave using the EPICs channels. The current test which drives the PIT/YAW DoFs with a DC misalingment and measures the response in the PDmon channels is a bit ad hoc in the way we set the "expected" response which is the PASS/FAIL criterion for the test. Moreover, the cross-coupling between the PDmon channels may be quite high. Needs some thought...
I'd like to get a concrete list of measurements written down, so that it's clear what needs to be done before I graduate.
Are there things that I'm missing? I've never had an IFO to characterize before.
While meditating on other things, I have noticed / found the following today:
YARM ASS works okay. Yesterday I measured the sensing matrix for the ASS for both arms (although I forgot to copy one of the matrix elements to my text file for Xarm - needs remeasuring). I put the Yarm matrix in (after appropriate inversion, only non-zero pitch-to-pitch, yaw-to-yaw elements). I turned on the Yarm ASS, and the yaw converged pretty quickly (couple of minutes), with gains of -1 in the servos, overall gain of anywhere between 0.005 and 0.010. The pitch took much longer, and I had to 'pause' several times by turning off the overall gain for the yarm ass when the MC lost lock (which has happened several times tonight - unknown cause). Eventually, the pitch settled out, and quit changing, but the lockin outputs weren't zero, even though the error signal for the servos were almost zero (gains for the pitch servos were -0.5, overall gain ~0.005 was better than 0.01 - higher gain caused oscillations in the lockin outputs). I think this means that I need to remeasure the yarm pitch ass matrix. It's still much, much faster to just turn on the dithers, watch the striptool of the lockin outputs, and align the cavity by hand.
I think the ETMX Trans camera view is clipped a little bit. I went down there, and it doesn't seem to be on the last optic before the camera, and moving the spot on the camera doesn't change the shape of the image, so I don't think it's on the camera. We should look into this, since it's either clipping on the BS that separates some camera beam from the TRX beam, or TRX is getting a clipped beam too. If the clipping is any earlier in the Trans path, the Trans QPD could also have some clipping. This requires investigation. The xarm trigger needs to be reset/disabled so we don't lose lock every time we block the TRX beam (as was happening to me).
XARM really doesn't like to relock unless the POX whitening is turned off. Good flashes, doesn't really catch (10+ min waiting (while working on Yarm stuff) ). After turning off the whitening, it catches almost immediately. Even though it's on the to-do list to rethink the tuning of our whitening, we should probably implement the whitening triggering now anyway. It'll make things easier.
The double integrator that Rana implemented in the X and Y arm servo filters last week take 8 seconds to turn off (due to Foton settings), so even though they are triggered to turn off immediately upon lockloss, they sit around and integrate for 8 seconds, so have huge signals. If the cavity flashes and the locking trigger engages during that 8 seconds, we send a huge kick to the ETMs. I'm modeling the response of the filters to an impulse and noise, particularly in the case of ramping on the double integrators. The problem is that a flat filter has 0deg phase, but the double integrator has 180deg phase at low frequencies, so there's some weird sign flipping that can happen as we ramp - this is part of what I'm modeling.
MC is losing lock unusually often tonight. Everything on the servo board screen looks normal (which is good since that's all set by the autolocker). I just disabled the test exc in, but that's been left enabled for a while now, and it hasn't (I think?) been a problem since there shouldn't be anything connected to the board there. PMC transmission is a little low, 0.816, and FSS is starting to get near -1 on the slow actuator adjust, but we've seen locking of the PMC problems around -1.5 or -2 of the FSS, and the adjust value was at -0.8 earlier tonight and we still had MC locking problems. I have had the seismic channels open on Dataviewer for the last several hours, and I'm not seeing any spikes in any of the Guralp channels which correspond to the times that the MC loses lock. BLRMS don't seem particularly high, so MC lockloss cause is still a mystery for today.
The ETMX monitor selector on the VIDEO screen seems not to be switching the actual camera that's shown on the monitor. Using the script command itself works, so my screen is wrong.
nodus was rebooted by Alex at Fri Aug 14 13:53. I launched elogd.
./elogd -p 8080 -c /export/elog/elog-2.7.5/elogd.cfg -D
It looks like Alex also rebooted all of the control room computers. Or something. The alarm handler and strip tool aren't running.....after I fix susvme2 (which was down when I got in earlier today), I'll figure out how to restart those.
Alex switched the mount point for /cvs/cds on Linux1 to the 1.5 TB RAID array after he finished copying the data from old drives. This required a reboot of linux1, with all the resulting /cvs/cds mount points on the other computers becoming stale. Easiest way to fix that he found was to do a reboot of all the control room machines. In addition, a reboot fest should probably happen in the near futuer for all the front end machines since they will also have stale mount points as well from linux1.
The 1.5 TB RAID array mount is now mounted on /home of linux1, which was the old mount point of the ~300 GB drive. The old drive is now at /oldhome on linux1.
Because I keep taking a long time to search for these, since I can't remember the keywords in the different entries, here are the links:
elog 3759 : Green X end aux laser temperature setting vs. PSL laser temperature setting
elog 4439 : Green Y end aux laser temperature setting vs. PSL laser temperature setting
More words: beat note, doubling, second harmonic.
T_Xend = 8.31 + 0.9293*T_PSL
T_Yend = 6.9825 + 0.87326*T_PSL
Also, C1:GCY-SLOW_SERVO2_OFFSET was 29725 (twenty nine thousand seven hundred twenty five) cts when we sat down to start today.
C1:GCX-SLOW_SERVO2_OFFSET was 80 (eighty) cts when we sat down to start today. Why the offsets are so different, I don't know. But I was able to find the X green beatnote with this small number offset, so it is approximately correct.
I set the limitters of the MC WFS servos not to inject the feedback more than 2000.
The residual of the WFS shakes the MC SUSs at every lock loss.
I re-measured the power levels today.
We have ~205mW out of the NPRO, and ~190mW after the Faraday. It doesn't look like the situation is going to improve dramatically. I'm going to work on a revised layout with the Innolight as soon as I've profiled the beam from it, and hopefully, by Monday, we can decide that we are going ahead with using the Innolight.
Lightwave NPRO information:
Serial Number: 337
Manufactured: December 1998!!
Details of checks performed:
Koji tuned the parameters on the laser controller and we observed the following:
Ericq has begun the characterization of the repaired Innolight. We checked that it outputs 1W of power. We will now have to perform the following measurements:
All of these will have to be done before installing this laser at the endtable.
I believe the consensus as of now is to go ahead with carrying out the above measurements. Meanwhile, we will keep the Lightwave NPRO on and see if there is some miraculous improvement. So the decision as to whether to use the Innolight is deferred for a day or two.
I attempted to measure the frequency noise of the extra Lightwave NPRO we have that is currently sitting on the PSL table. I did the following:
I've turned the Lightwave NPRO back to standby for now, in anticipation of further trials later today. I've also restored the IMC.
After adjusting the alignment of the two beams onto the PD, I managed to recover a stronger beatnote of ~ -10dBm. I managed to take some measurements with the PLL locked, and will put up a more detailed post later in the evening. I turned the IMC autolocker off, turned the 11MHz Marconi output off, and closed the PSL shutter for the duration of my work, but have reverted these to their nominal state now. The are a few extra cables running from the PSL table to the area near the IOO rack where I was doing the measurements from, I've left these as is for now in case I need to take some more data later in the evening...