RA: I'm not sure how to interperet this; I think that the SUM channel is divided by the SUM so that this is supposed to be RIN, but not sure. Can someone please take a look into the SUS model and then explain in the elog what the SUM normalization algorithm is?
> 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.
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.
While that would be good - it doesn't address the EDCU problem at hand. After some verbal emailing, Jamie and I find that the master file in target/fb/ actually doesn't point to any of the EDCU files created by any of the FE machines. It is only using the C0EDCU.ini as well as the *_SLOW.ini files that were last edited in 2011 !!!
So....we have not been adding SLOW channels via the RCG build process for a couple years. Tomorrow morning, Jamie will edit the master file and fix this unless I get to it tonight. There a bunch of old .ini files in the daq/ dir that can be deleted too.
I took a look at the situation here so I think I have a better idea of what's going on (it's a mess, as usual):
The framebuilder looks at the "master" file
which lists a bunch of other files that contain lists of channels to acquire. It looks like there might have been some notion to just use
as the master slow channels file. Slow channels from all over the place have been added to this file, presumably by hand. Maybe the idea was to just add slow channels manually as needed, instead of recording them all by default. The full slow channels lists are in the
files, none of which are listed in the fb master file.
There are also these old slow channel files, like
There's a perplexing breakdown of channels spread out between these files and C1EDCU.ini:
controls@fb ~ 0$ grep MC3_URS /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini
controls@fb ~ 0$ grep MC3_URS /opt/rtcds/caltech/c1/chans/daq/MCS_SLOW.ini
controls@fb ~ 0$
why some of these channels are in one file and some in the other I have no idea. If the fb finds multiple of the same channel if will fail to start, so at least we've been diligent about keeping disparate lists in the different files.
So I guess the question is if we want to automatically record all slow channels by default, in which case we add in the C1EDCU_<model>.ini files, or if we want to keep just adding them in by hand, in which case we keep the status quo. In either case we should probably get rid of the *_SLOW.ini files (by maybe integrating their channels in C0EDCU.ini), since they're old and just confusing things.
In the mean time, I added C1:FEC-45_CPU_METER to C0EDCU.ini, so that we can keep track of the load there.
Atm1, The strong glitches are back.
Atm2, SUS-ETMX & Y_SENSOR_LL Damping OFF at (ref0 & ref1). damping ON (red & blue)
ETMY sus looks OK
Nice work. Congratulation
[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.
Control signal measurement of end PDH control
The Yarm ALS wasn't robust. Yesterdays night, we found that suspension kicked by something and that was the reason why the end PDH control lost lock. To make sure that the PDH loop itself is robust, I measured control signals of End PDH loops. When the gain inclease, the peak at UGF appeared and become unstable. Both arms does not seems unstable before the peaks appear.
Xarm PDH servo gain optimization
I optimized the x end PDH servo gain with measuring OLTF. Now the servo gain is 5.0. UGF is around 10 kHz and phase margin is 40 degree.
Also I measured out of loop noise. I locked the arm using IR PDH, and measure the ALS error signal. The high frequency noise become better.
I've finished setting up the fstab on Chiara and the upgrade to Ubuntu 12 seems to have gone well enough. She's fast:
but I forgot to make sure to order a dual head graphics card for it. So we'll order some dual DVI gaming card that the company recommends. Until then, its only one monitor.
Still, its ready for testing control room tools on. If everything works OK for a couple weeks, we can go to 12 on all the other ones.
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.
As you may recall, Den designed some nice seismometer stations for us with the help of Steve. The granite base was installed : elog 8461. The point of these is to have nice solid bases for our seismometers to sit on, rather than the flimsy linoleum flooring. Also, they are covered (and will be insulated) to help prevent air currents and temperature fluctuations from affecting our seismometer measurements. Even though these seismometer stations have been in place for a few months, we are not yet taking advantage of them. This is a status elog, so that we know what needs to be done.
Recently, Den finished up the design for, and Steve ordered, and we received, the small aluminum plates that go on the side of the granite slabs, so that we can feed the connectors for the seismometer through the baseplate, in an airtight way.
The current plan is to use one Guralp at each end station, and the Trillium at the vertex. As of this moment, we have 1 Guralp at ETMY, 1 Guralp at ITMX, and a Streckeisen at ETMX, and the Trillium is sitting to the south of the POX table.
Most of the work that's left to do is just to place the seismometers on the new stations, and to make cables.
I have taken an inventory of all the things that I think we need to buy (or I need to find in the lab) in order for us to finish this project up.
We need to buy a LEMO connector for the T-240 plate.
We need to buy 6 O-rings: 3 to go between each aluminum plate and the granite slabs, the other 3 between the plate and the milspec connectors for the seismometer cables.
We need to buy or confirm that we have screws to attach the plates to the granite slabs.
We need to buy or confirm that we have screws to attach the milspec connectors to the plates.
I need to confirm that I have another 37-pin dsub for the Xarm Guralp cable, and a 25-pin dsub for the Trillium.
Assuming that I am reusing the existing Yarm Guralp cable, we have all the milspec connectors necessary.
I have a 30m long spool of 19-pair cable that I will use to make the Trillium cable. I have a long cable, formerly a Streckeisen cable, that I will cut the ends off of, and make into a Guralp cable. (We had 3 of these incredibly long, maybe ~50m cables - one became the Yarm Guralp cable, one is waiting to be the new Xarm Guralp cable, and the 3rd one is connected to the Streckeisen that we still have).
Work to be done:
* Make long cables for Xarm Guralp and Vertex Trillium. Check pinouts for the milspec -> dsub connections on each cable.
* Make small cables that go inside of the granite and seismometer station. These are to connect the sensor to the aluminum plate, and then the long cables go from the plate to the readout box. Unfortunately, the holes in the granite are not large enough to pass a connector through, so these will have to be soldered in-situ.
* Plug in the Trillium readout box and confirm that it's working / makes sense.
Longer term modifications and add-ons:
* Lemo connector with wiring for temperature and pressure sensors inside the vertex station. I believe that Den was looking into what sensors we might want.
* Needle valve for slow pressure equalization on vertex station (all stations should have this, but only the Trillium plate has a hole for this).
Is there anything else that I'm forgetting?? Please reply with thoughts.
We have now watched the ETMY computer situation for a little over 150 minutes, and have seen one 'event' where the CPU time of the scy model hit 62 microseconds, and a glitch in the ETMY OSEM sensors happened at the same time. We also see no such glitches at any other time, which makes sense with our latest hypothesis, since this event was the only time that the CPU time reported being greater than 61 microseconds. (1/16384 Hz = 61.1696 microseconds).
I have now restarted the c1tst model, to see if that increases the rate of glitches (assuming that running another model heats up the whole computer a bit more, and that makes things run a little bit slower).
Wed Oct 23 21:05:28 2013
RXA: It looks like there was a real effect. Its between -2.5 and 0 on the plot below.
I've stopped the process of c1tst again to make it get better. At 9:20, I also went and opened the front rack door (the back one was already open). One reason its hot may be that the exhaust vents on the top of c1iscey are blocked by one of the custom multi-pin adaptor boxes. In the morning, we should drop the computer down by 1 or 2 notches in the rack so that it can air cool itself better. Make sure to poweroff the computer from the terminal before moving it though.
I checked the cabling somewhat. The fat grey cable which comes out of the old Sander Liu AA chassis was connected to the blue adaptor box but the strain relief screws were not being used. I tightened them (we need to buy a set of small screwdrivers for the toolboxes at each end). While doing this, the Cat6 cable in the back labeled 'c1iscey' popped out and the screen went white. This cable has a broken latch on it so it doesn't stay put - needs to be replaced too during the computer move.
c1scy has been running slow (compared to c1scx, which does basically the exact same thing *) for many moons now. We've looked at it but never been able to identify a reason why it should run slower. I suspect there may be some bios setting that's problematic.
The RCG build process is totally convoluted, and really bad at reporting errors. In fact, you need to be careful because the errors it does print are frequently totally misleading. You have to look at the error logs for the full story. The rtcds utility is ultimately just executing the "standard" build instructions. The build directory is:
The build/error logs are:
I'll add a command to rtcds to view the last logs.
(*) the phrase "basically the exact same thing" is LIGO code for "empirically not at all the same"
I noticed by eye that during one event when ETMY was getting kicked up, its CPU meter (C1:FEC-47_CPU_METER) went RED.
Thinking that this might be a clue I tried to trend this channel. Even though this channel is in the SCY EDCU file and the 'rtcds install' command claims to be 'installing C1EDCU_SCY', many of the channels named in the file are not actually showing up in ur dataviewer SLOW channels list.
I smell a cockroach in our RCG build process, but I can't find the log file for the make-install part of the build nor can I find the Makefile from which the make-install is born. Help us Jamie!
I have deleted a few filters from c1scy to see if that could reduce the CPU time and I have killed the c1tst process to see if that can cool down the entire computer. Next, we can try to open the rack doors and put a fan on there to see if we can shave a couple microseconds. I have a StripTool running on pianosa to see if we see some correlations between FEC47 and the ETMY SUS watchdog RMSs. Don't close it.
The PMC was unlocked for a little over an hour. I relocked it, and the MC locked itself. Today, it looks like PMC yaw alignment is bad, and maybe pitch isn't so good either. Transmission is 0.77
This is not really definitive. The 0.1-0.3 Hz band is not the right one to look for seismic transients - it should be the higher frequency ones.
The other test to do is to turn off the ETMY damping and then look for glitching in the sensors. And then, of course, check to see that no one has bumped the satellite box with a cart or a mop...
ETMY sensors are glitching or getting kicked up.
Atm3, There is no seismic activity here.
In 2arms + MICH configuration, residual motion of the cavity will couple with MICH signal. When cavity length change, the reflectivity of cavity also change. And that cause the phase shift in reflected light. That phase shift is detected in MICH signal. When we try to lock the DRMI + arm, that coupling will be problem for lock acquisition. For practice to estimate that coupling, I estimated the coupling between the cavity motion and the AS55Q signal.
What I did
- Measurement steps
I did the same measurement as that of this entry. For the estimation below steps are needed. The detail of each step will be written below.
--Measurement and calibration of the AS55Q error signal with MICH + 2arms locked by ALS control
--Measurement of the ALS in-loop noise and estimation of residual motion of the cavities.
--Calibration of the coupling from residual arm motion to AS55Q signal
- Calibration of the AS55Q signal
1. Sensor gain estimation
We used the same method as the previous entry,
We excited the BS at 580 Hz with a given amplitude (Vin). We enabled the notch filter at 580 Hz in the LSC MICH servo. We measured the peak height (Verr) of the AS55Q error signal. We used the actuator response (A_bs) of BS measured in this entry.
We can get the sensor gain (H) of AS55Q in unit of count/m
H = ------- -------
By this calculation H = 4.2e+07.
2. Fitting of OLTF for the MICH loop
We measured the OLTF of the MICH loop. Modelled OLTF is fitted into the measurement data. That modelled OLTF includes the actuator response of BS, the MICH servo filters, DAI,DAA,AI,AA filters, the TF of sample and hold circuit. (About DAI, DAA filters and S/H circuit please read this entry. About AI,AA filters please read this entry) Also I put time-delay into that OLTF. I estimated that time-delay and the gain of OLTF by fitting. The time delay was 311usec.
3. Estimation of the MICH free running noise
With modeled OLTF, I estimated the MICH free running noise.
Estimation of the coupling from residual cavity motion to AS55Q signal
The ALS in-loop noise data has the unit of Hz/rHz (disturbance of the cavity resonant frequency). By multiplying L_arm/f_laser we can convert the unit to m/rHz (disturbance of the cavity length) .
I used the same coupling constant between residual motion of cavity and MICH noise as this entry. For estimation of the coupling constant, we excited ETMs and measured the TF from excitation signal to AS55Q error signal. I assumed the cavity pole as 4000 Hz. The result is discussed below
ALS in-loop noise include the sensor noise. in high frequency region the in-loop noise is dominated by the sensor noise. So in this region in-loop noise does not mean actual residual motion of the cavity. And this sensor noise pushes the mirror. So we have to estimate the actual motion of the cavity by multiplying the servo transfer function of the control in this region.
I made 2 plots. Both include the MICH free running noise and estimated coupling noise from both arms. In one plot, for estimation of the coupling I multiplied only coupling constant to calibrated in-loop noise of the ALS loop. In another plot, I multiplied coupling constant and OLTF of ALS loop in order to estimate the actual motion of the cavity. If the 3 curves are coincide in first plot, that means the ALS in-loop noise is same as the residual cavity motion in that region and the MICH free running noise is dominated by coupling from residual cavity motion. If those curves are coincide in second plot, that means the ALS in-loop noise is sensor noise in that region.
Above 40 Hz, the 3 curves are totally in coincident in first plot. On the other hand in second plot the 3 curves look similar in this region. That may mean above 40 Hz the ALS noise are dominated by sensor noise and MICH free running noise is dominated by the coupling from residual cavity motion. Also in the region between 10 Hz and 40 Hz, the MICH free running noise seems to be dominated by coupling from cavity motion.
In second plot, the coupling from cavity motion is overestimated. It's possibly because of overestimation of coupling constant, but I'm not sure.
Koji mentioned that we should measure the residual motion of the cavity by using POX and POY. Now the ALS is much more stable than before, so I think we can easily do the measurement again with out of loop measurement. That will be more strait forward measurement.
Looking into control signals and error signals of the Y arm green PDH servo,
1. The saturation of feedback signal (PZT_OUT) at +/-4000 counts (less than 5V) comes from only the readout saturating. The signals looked fine on the oscilloscope.
2. We did a sine sweep at the PZT_OUT and optimized the LO frequency. The LO frequency did not need any change.
3. The error signal has some offset to it. We are not sure where this comes from.
We have been seeing that whenever green loses lock, the spot position moves down in pitch on the ETMYF camera and the GTRY camera. This led us to think about if the lock loss originated from the PDH or from the cavity.
We looked into dataviewer channels of green, IR, oplev and suspension for the following cases:
1. Green and IR PDH locked
2. Green locked and arms flashing for IR
3. Green shutter closed and IR PDH locked
4. Green shutter closed and arms flashing for IR
5. Arms flashing for IR and ETMY oplev servo turned off.
Dataviewer snapshots of glitch in all the above cases are saved in masayuki's folder users/masayuki/ALS/kicked_mirror/
In all the above cases, we could still see the glitch. We could conclude that the problem lied with the ETMY SUS.
Shown below is the dataviewer snapshot of ETMY sus and shadow sensor channels. The glitch exists even when the oplev servo is turned off pointing to problems associated with the ETMY suspension.
We got a new computer from Xi computer corp. I am currently installing Ubuntu 10.04 LTS on to it to start with and then will move on to 12 if we can figure out a way to test it besides "I guess it should work?"
Rosalba has been removed and put onto the old Jamie desk. Old Jamie desk also has a Mac Mini running on there.
At the meeting tomorrow we need to decide on a new Italian baby girl name for this new machine.
As this entry, Yarm ALS is not stable enough to lock PRMI + 2 arms. We tried to figure out what is the reason.
What we did
Check connection and alignment
1. Check the Green REFL PD.
Reflection is hitting the center of PD.
2. Check all the BNC connections
All connection are fine.
3. Check which power supply the PDH box is connected to.
PDH box is connected to 1Y4 AC power supply.
Check the control signal and error signal
4. Connected the PZT OUTMON to PC
Before the PZT output was not connected to the monitor channel. We connected that.
5. Saw the time series of the error signal and control signal (PZT output)
When the Yarm lost end PDH lock, we found that control signal kicked the PZT of end green laser. And also we saw the saturation of control signal. We are not sure where this saturation comes from.
With these check, we couldn't find any problem in connection or alignment. But the PDH control signal looks somehow strange. We tried to compare the Yarm signals with that of the Xarm, but we could not conclude anything meaningful.
We don't understand right now but we will continue to check that. We will add more details to the discussion once we have looked into the PDH box signals using oscilloscope.
The 4th week of no wet mopping of the floor and no wet wiping the vacuum envelope.
We cleaned the intakes of the south arm IFO air condition. The bottom duct have quite a bit accumulation Atm1
See wet wiped contrast on Atm2
We found 3 holes around pipes ( coming from CES ) on the east wall that has to be sealed.
After closer examination of these holes, they are sealed off well.
PMC aligned. Trans 0.78 -> 0.83
I have just turned on the PSL Innolight laser. The laser shut down with unknown reason a day ago.
Sunday evening fireworks. Manasa heard it.
PSL temperature changed
The beat note of Xarm looked somehow strange before (elog). It should be the highest when the green transmission power is highest, in other words when the end green PDH locks with a TEM00 mode. But it was not like that. When the end PDH locked with other modes (GTRX: below 0.3), the beat note was higher than TEM00 mode (GTRX: around 0.5).
We guessed that end green laser was somewhere around the point where there were 2 stable TEM00 modes . In order to move away from this unstable region of the end laser, we changed PSL temperature to obtain beat note at a different green laser frequency where we do not have any of the weird modes oscillating.
We changed the PSL temperature from 31.63 degree to 31.33 degree. We measured the in-loop noise of ALS loop and I attached it. There is not big difference in Yarm, but the Xarm in-loop noise become better in high frequency region. We think before the xend green laser was in a not-so-good state and the laser had more frequency noise then.
After change PSL temperature, Xarm ALS is so stable. Actually Xarm is being locked right now and it is locked for more than 50 minutes!!
Although the Xarm ALS is so stable, Yarm ALS is not stable right now. It lost lock by ~5min. We don't know what is the reason, so we will try to fix it tomorrow.
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 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.
I locked the PRMI, and tried to turn on the ASS, but this caused PRMI to lose lock.
Since this is similar to what happened the other night (see elog 9243, 2nd big paragraph), I looked into it a little further. I noticed that the POP QPD pitch was very close to the edge of the QPD, so I went out and (while PRMI was locked) recentered the POP QPD. After doing so, I was able to run the PRM ASS, and it worked very nicely, just as it has before. So, it looks like something drifted, such that the optimal PRM alignment caused the POP beam to not be fully on the QPD. Since the ASC loop is triggered by PRMI lock, and is constantly on, falling off the QPD causes lockloss.
While I was out there, I tweaked up the PMC pitch alignment yet again. The FSS numbers all looked reasonable, however PMC transmission was ~0.75 . I did a tiny bit of work in pitch, and now we're back to 0.83 transmission.
For PRMI + 2arm, we tried to make the ALS control noise better. As this entry we had huge 60 Hz comb noise in PDH loop of YARM.
So we tried to figure out the problem and fix it.
- What we did
We checked which power supply the staff in Y-end are connected to, and change some of them to connect to 1Y4 AC power supply from wall AC. What we changed was
1.Main end laser
3.Green REFL PD
We checked error signal of PDH control and compared before and after. The 60 Hz peak get better from -80 dBVpk to -90 dBVpk. Also I attached the plot of XARM, privious YARM (the data of Yesterday night), and current YARM ALS in-loop noises. The RMS of ALS in-loop noise of Y-arm get better by factor of 2. However, even the 60 Hz comb noise get better than before, RMS get worse by comb noise.
We would like to make these noise better at least until these noises don't affect to RMS, so we should continue to check.
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.
ETMX _OPLEV_...ERROR signals are effected by turning ON the flow bench motor at the south end
The broadband noise [~ 5-60 Hz] is much higher when the motor is running.
The flow bench was turned off.
Still to do:
* 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 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.
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.
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:
I wrote the script to scan the cavity using ALS until it finds IR resonance . This script is (script)/ALS/ALSfindIRresonance.py I attached the time series of the C1:ALS-OFFSETTER and IR transmission of XARM when the script was working.
When you start this script, it start rough scan. It steps the offset of the C1:ALS-OFFSETER with ramp time, and for each step it checks the value of C1:LSC-TR. At rough scan, one step is 0.1 count. When IR transmission become larger than threshold, this script start fine scan. In fine scan, this script steps the offset by 0.01 for the range of 2. For each step, C1:LSC_TR value is measured, and after fine scan it set the offset to the value which had the maximal C1:LSC-TR.
I put new button 'Scan %ARM' to the ALS screen. You can run this script by pushing that button.
Atm1 bandwidth 0.01 Hz ETMY plot is different from
Atm2 bandwidth 0.1 Hz normal ??????? They should be the same !!!!
We found that we need to look into the entire end PDH loop to figure out what causes the worse noise level of the Y-arm than before.(entry)
Today, I measured in-loop noise of the end PDH loop and the ALS loop with different end PDH servo gain of Y-arm to make sure the PDH servo gain change the noise level of the ALS control loop.
- What I did
Measuring the OLTF of the end PDH loop:
1. Measured the OLTF of the PDH loop with the end PDH servo gain 6 and 7.
The UGF and phase margine: 16 kHz and 53 degree(gain 7)
7.8 kHz and 86 degree(gain 6)
I couldn't measure the OLTF with higher servo gain than 7 because the loop was not stable enough. I guess that is because of the noise of the SR560, which I used for node of the excitation signal.
Calibration of the end PDH error signal
2. Locked the cavity using IR and turn on the notch filter at 580 Hz of the C1:LSC-XARM. Excited the ETMY using awg with sinusoidal signal at 580 Hz. Set the end PDH servo gain to 6 and measured error signal of the end PDH. The calibration factor of the end PDH error signal H is calculated by
H = abs(G + 1) / A * Verr / Vin
where G is the OLTF of the end PDH, A is the actuator response of the ETMY, Vin is the amplitude of the excitation signal and Verr is the error signal at 580 Hz. This H convert the error signal to the fluctuation of the cavity length, so it has the unit of V/m. We can change that unit to V/Hz by multiplying f/L, where f is the laser frequency of IR and L is the length of the arm. In this case the H convert the error signal to the fluctuation of the resonant frequency of the cavity.
The actual number was
H = 1.4e7 [V/m] (2.0e-6 [V/Hz])
In-loop noise of the end PDH loop
3. Measured the error signal of the PDH loop with the end PDH servo gain of 6.0, 7.0, 8.0 and 9.0. I calibrated these signals with above H, so these unit is Hz/rHz. I attached the result of these in-loop noise. When the end PDH servo gain is 9.0, the end PDH loop looks unstable. And 8.0 looks to be the optimal gain in terms of the in-loop noise of end PDH loop.
ALS in-loop noise:
4. Stabilized the Y-arm with ALS control loop with different end PDH servo gain, and measured in-loop noise of the ALS control loop. I attached these results and discussed about this results below.
Now we can say that too high PDH servo gain makes ALS loop very noisy. Compare to when the PDH servo gain is 7 or 8, the ALS in-loop noise is roughly 4 times higher when the PDH servo gain is 9.0, which means the PDH loop is not stable. However between 100 Hz and the end PDH in-loop noise has no big difference between when the servo gain is 6 and 9. If this high frequency noise comes from the end PDH control and this effect is linear, these noises should be same level. Also the PDH servo gain of 7.0 looks optimal gain in terms of the in-loop noise of ALS control loop, although the 8.0 has smallest end PDH in-loop noise. Actually PDH in-loop noise are smaller than ALS in-loop noise.
I'm wondering what causes the 60 Hz peak in black curve. When the gain become higher, the peak at 60 Hz looks to become larger. The UGF of the ALS loop is above 100Hz, so it's not because of that. I feel there is some hint for understanding this result in this peak.
From this observation, I could make sure that the end PDH servo gain change the ALS in-loop noise, but that effect doesn't look so simple.
By the way
We should take care about 60 Hz comb peaks. You can see huge peaks in PDH in-loop noise and also in ALS in-loop noise.
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.
I wonder what's drifting between the laser and the PMC? And why is it getting worse lately?
The PMC refl is bad in pitch today, and the transmission is only 0.76, rather than our usual 0.83ish.
I did a quick, rough tweak-up of the alignment, and now we're at 0.825 in transmission.
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).
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.
I centered the oplev of the ETMY, because I found that Yarm lost lock every 10 minutes, and the ETMY oplev was misaligned very much. I attached the 40 minutes trend of oplev and LSC-TRY. Yarm looks more stable. After centering of the oplev, the YARM looks to be more stable.
* Decide what 5 frequencies to use for excitation.
* Put the bandpass and lowpass filters into the lockin modules.
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.
We have stabilized the ALS for Y arm and concluded that although the PDH servo could be stabilized, it drifts and loses stability over a span of few hours. (See masayuki's elog today)
We wanted to follow the same systematic procedure like in the previous elog to look at the condition of the X arm as well.
In order to stabilize the green PDH servo, we held the arm using the IR PDH and aligned the end-green to the X arm.
We see 2 TEM00-like modes and one oblong TEM00+TEM01 mode that can lock to the cavity. It is not clear to me as yet as to how to differentiate between these 2 TEM-00 like modes and how we should decide between them.
One of the TEM00-like mode is strongly matched to the arm cavity. Normalized GTRX measures 0.6 counts. The other TEM00-like mode is weakly matched to the cavity. Normalized GTRX measures 0.12 counts. This might be the reason why Jenne and Masayuki were seeing a lower beat amplitude. Camera images are shown below.
On another note, we found that an oblong mode (looks like a TEM00+TEM10 mode) also locks to the cavity. The mode looks weird in that, only one half of the mode is seen moving due to seismic noise and the other part does not. I am not sure how I can describe this...so here is a 10 second video of how this mode looks like.
Our goal is to realize PRMI+one arm again. However we found that the noise level of the Y-arm is worse than before (entry).
Today we went through into the servo gains of the ALS related loops.
Step 1 to 6 is for Yarm
Alignment of the cavity and the green:
1. Locked arms using IR PDH, aligned the green beam to increase the transmission. Now the value of ALS-TRY_OUTPUT is more than 0.8.
Checking and adjustment of the end green PDH gain:
2. Measured the OLTF of green PDH loop.
3. The gain of the PDH box was 8.2. We found that the UGF was too high and the phase mergin was too low (20deg)
Therefore, the gain was reduced to the gain to 6.8. Now, the UGF and phase margin are 17.7 kHz, 41.96 degree, respectively.
Phase tracker loop:
4. Measured the OLTF of the phase tracker loop. The UGF was 2 kHz, and phase margin was 45 degree.
We found that these were already the nominal and optimized numbers.
For a reference: the filter bank C1:ALS-BEATX_FINE_PHASE has the gain of 110.
5. Disable the IR PDH lock, and stabilized Yarm by ALS. We measured the OLTF of the ALS loop (attachment 1).
The UGF and phase margin were turned out to be 125 Hz and 41 degree. respectively. This looks pretty optimal.
The ALS servo gain (the gain of the C1:ALS-YARM module) was 15.0.
6. We measured the in-loop noise of the ALS loop (C1:BEATY_FINE_PHASE_OUT_HZ) (attachment 2).
The comparison of the in-loop performance is discussed below.
After these adjustment, we found that the ALS in-loop noise of Yarm decreased in high frequency band.
(see this entry for the comparison. Sorry for my laziness! I don't have the overlaid plot)
If we believe this is true, lowering the end PDH gain improved the noise level between 100Hz to 1kHz.
This sounds weird as we decreased the PDH gain, rather than increased. We should confirm this effect by increasing the gain.
Now the in-loop RMS is started to be dominated by the peaks at 3, 16, and 24 Hz.
We should compare the current in-loop spectrum with the previous spectrum when the ALS was working fine.
By the way:
We suffered from frequent disruptions of the ALS servo during our investigation.
As we speculated that this was caused by the malfunction of the green PDH loop, we left the arm still and observed
how the green PDH lock is robust. Our discovery was that the green PDH loop had frequent interruptions (every 5~10min).
From this observation, we strongly feel that we need to look into the entire end PDH loop.
For my work designing a cost function, so that I can try out new feedback servo designs on the oplevs, I wanted to know what the dark noise of an oplev is. Since the pitch and yaw channels are divided by the sum channel, when the laser is off, the noise in the pitch and yaw channels looks much higher than it really is. So, I collected some data from the 4 individual quadrants of the ITMY oplev, when the laser was on (but damping was off), and when the laser was off. I used the values of the oplev input matrix to re-create the non-normalized pitch and yaw signals. What I see is that we have some kind of real signal below 1 kHz, but we're hitting the noise at around 1 kHz. So, we definitely don't want to use oplev error signal information above 1 kHz when designing new servos.
The last word in the title is "off". OSEM damping was on, but the oplev damping was off. These are uncalibrated, because the calibrations that we have to go from counts to microradians are for the normalized signals.