Last night Rana noticed that the overflows on the ITM and ETM coils were a crazy huge number. Today I rebooted c1dcuepics, c1iovme, c1sosvme, c1susvme1 and c1susvme2 (in that order). Rob helped me burt restore losepics and iscepics, which needs to be done whenever you reboot the epics computer.
Unfortunately this didn't help the overflow problem at all. I don't know what to do about that.
Just start by re-setting them to zero. Then you have to figure out what's causing them to saturate by watching time series and looking at spectra.
Yesterday we found that the channel C1:MDP-POS_EXC looked distorted and had what appeared to be doubled frequency componenets, in the dataviewer. This was because the dcu_rate in the file /caltech/target/fb/daqdrc was set to 16K while the adl file was set to 32K. When daqdrc was corrected it was fixed. I am going to recompile and run all these models at 16K. Once the 40 m moves over to the new front end system, we may find it advantageous to take advantage of the faster speeds, but maybe it's a good idea to get everything working at 16K first.
The MC_trans QPD Pitch and Yaw readout on the Lock_MC screen are now normalized by the trans_sum. I used the method described in my entry elog 1488.
/caltech/target/c1iool0/ioo.db now includes:
field(SCAN, ".1 second")
field(SCAN, ".1 second")
The Lock_MC screen was changed to show these new P and Y channels.
The camera wasn't working because the router has no built-in dhcp server. We had to manually start the server after rebooting the computer.
Jenne, Koji, Rana
After fixing up the Mode Cleaner a bit more (fiddling more with the MC_align sliders to get the alignment before locking, making sure that it is able to lock), we noticed that the MC Trans path could use some help. To align the MC, we put MC1 and MC3 back into the position where Rob left it on Thursday and then maximized the transmission with MC2. Then we went back and maximized with MC1/3 keeping in mind the Faraday. We got a good transmission and the X-arm had a transmission of 0.8 without us touching its alignment.
Upon looking at the AP table portion of the MC_trans path, we decided that it was all pretty bad. The light travels around the edge of the AP table, then out the corner of the table toward the PSL table. A periscope brings it down to the level of the PSL table, and then it travels through a few optics to the MC_trans QPD.
The light was clipping on the way through the periscope, and so the MC_trans QPD was totally unreliable as a method of fine-tuning the alignment of the Mode Cleaner. Ideally we'd like to be able to maximize MC_trans, and say that that's a good MC alignment, but that doesn't work when the beam is clipped.
1. The first turning mirror on the AP table after the beam comes out of the vacuum was changed from a 1" optic to a 2" optic, because the spot size is ~4-6mm. We were careful to avoid clipping the OMCT beam, by using a nifty U200 mount (C-shaped instead of ring-shaped).
2. We placed a lens with a RoC of 1m (focal length for 1064nm is ~2m), a 2" optic, between the first two mirrors, to help keep the beam small-ish when it gets to the periscope, to help avoid clipping.
3. Rana adjusted the angle of the upper periscope mirror, because even when the beam was centered on the steering mirror directly in front of the periscope and the spot was centered on the first periscope mirror, the beam wouldn't hit the bottom periscope mirror.
4. We noticed that the bottom periscope mirror was mounted much too low. It was mounted as if the optics after it were 3" high, which is true for all of the input optics on the PSL table. However, for the MC_trans stuff, all the optics are 4". We moved the periscope up one hole, which made it the correct height.
5. We removed the skinny beam tube which guided/protected the beam coming off the periscope after a steering mirror since it (a) wasn't necessary and (b) was clipping the beam. We cannot use such skinny tubes anymore Steve.
6. There was a lens just before the 2nd steering mirror on the PSL table portion, which we removed since we had placed the other lens earlier in the path. 2 lenses made the beam too skinny at the QPD.
7. After this 2nd steering mirror, there had been a pickoff, to send a bit of beam at a crazy angle over to the RFAM mon, which we removed. This results in a much brighter beam at the MC_trans QPD, and at the camera. The QPDs readouts are now a factor of ~3.5 higher than they used to be. These (especially the camera) could use some ND-filtering action.
8. The steering optic directly in front of the MC_trans QPD is a beamsplitter, and instead of dumping the light which doesn't go to the MC_trans QPD, we used this to go over to the RFAM mon (instead of the pickoff which we had removed).
9. Koji fixed up the optics directly in front of the RFAM mon, accomodating the new position of the input light (now at a much more reasonable angle, and about 15cm farther back from the PD). Note the beam dump which is preventing the cables from the FSS board from entering the beam path. This included removing an ND filter wheel, so the RFAM mon values will all be higher now. Koji also has the beam going to the PD going at a slight angle, so that the beam isn't directly reflected on itself, so that it can be dumped.
10. We aligned the beam onto the MC_trans QPD using the first steering mirror on the PSL table.
11. We also removed the giant wall of beam dumps separating the squeezing section of the table from the rest of the table.
Alberto will elog things about the RFAM mon, including different values of the PD output, etc.
Still on the to-do list:
A. Replace the second steering mirror on the AP table after the MC_trans light leaves the vacuum with a 2" optic, since the lens we placed isn't tight enough to make the spot small there yet. Us a U200A mount if possible, because they are really nice mounts.
B. Put an ND filter in front of the MC_trans camera, because the image is too bright.
C. Normalize the MC_trans QPD - the horz and vert are pretty much direct voltage readouts, with no normalization. They should be divided by the DC value. This lack of normalization results in higher sensitivity to input pointing.
D. Long term, next time someone wants to optimize the MC_trans path, move all the optics, including the MC_trans QPD and the camera closer to the periscope on the PSL table. There's no reason for the beam to be traveling nearly the full width of the PSL table when we're not manuvering around squeezing stuff.
E. Never, ever purchase these horrible U100 or U200 mounts with the full ring and the little plastic clips. They are the "AC28" version. Bad, bad, bad.
Image 1: The new setup of the AP table, Mc_trans portion.
Image 2: New setup of the MC_trans part of the PSL table.
While aligning the optics, we tried to start up the CCD. Although nothing should have changed since the last time I used it, the code claimed it could not find the camera. All the right leds are lit up. The only indication that something is awry is that the yellow led on the camera isn't blinking as it does when there is ethernet activity.
The mode cleaner seems to be locking again. I've manually unlocked it a few times in the past 20min, and most of the time it catches lock again (maybe about 80% of the time). Other times, it starts to lock in a bad mode, and can't fix itself, so I unlock it, and let it restart and it usually does fine the second time around.
I'd like it to be a little more robust, but I'm having a bit of trouble zeroing in on the optimal alignment for quickest, most durable lock aquisition of the MC. Right now I'm going to leave it for a little while to make sure it doesn't fall apart.
I am (was) able to get the mode cleaner mostly locked, but because WFS2 wasn't centered, the MC would drift, then lose lock. I recentered both the WFS (after unlocking the MC and the MZ), and am now about to commence relocking both of those.
Note to self: WFS get centered based on the direct reflection from MC1. Once the MC is close enough, the WFS are enabled, and they twiddle all 3 MC mirrors to minimize their error signal. Moral of the story: make sure the WFS are centered.
Alex has firewalled megatron. We have started a framebuilder there and added testpoints. Now it is possible to take transfer functions with the shared memory MDC+MDP sandbox system. I have also copied filters into MDC (the controller) and made a really ugly medm master screen for the system, which I will show to no one.
Friday afternoon the mode cleaner got unlocked. Then some adjustment of the MC1 bias sliders locked it again. The driftmon showed the excursion for pitch and yaw of MC1 becasue it wasn't updated after the change.
Tonight Rana found the MC unlocked and simply touched the sliders to bring the OSEMs back to the driftmon values.
MC1 Yaw remains different from the driftmon. If brught back to htat value, the MC would get unlocked.
More investigation is needed to understand why the MC lock hasn't been stable for the last few days.
The mode cleaner is still unlocked. I played with the cable at the MC2 satellite to enusre they were all plugged in.
Then I tweaked the the mirrors alignment by the sliders and eventually I could get it locked stably with 1.3 reflection. Then I rebooted C1IOO because the WFS wouldn't engage. After that the cavity wasn't locked anymore. Trying to adjust the mirrors around their position didn't restore the lock.
More work is necessary.
I'll be back on it in a while.
I put the flying-component circuit in a box; a photo is attached. I also measured the impedance; it looks exactly the same as it looked before I put the circuit in the box.
I was able to make an impedance measurement of the flying-component circuit using Koji's method for impedance measurement. I first measured the impedance of the circuit with a 10 pF capacitor in the place of the EOM (as shown in the circuit diagram). This impedance plot is attached. I then added resistance to adjust the impedance slightly, attached the circuit to a New Focus KTP 4064 EOM, and took another impedance measurement (circuit diagram and impedance plot attached). The peaks are relatively close to 50 Ohms; they are at least the same order of magnitude.
For the past couple of days I have been trying to understand and perform Koji's method for impedance measurement using the Agilent 4395A Network Analyzer (without the impedance testing kit). I have made some headway, but I don't completely understand what's going on; here's what I've done so far.
I have made several transfer function measurements using the attached physical setup (ImpedanceTestingPhysicalSetup.png), after calibrating the setup by placing a 50 Ohm resistor in the place of the Z in the diagram. The responses of the various impedances I've measured are shown in the attached plot (ImpResponses.png). However, I'm having trouble figuring out how to convert these responses to impedances, so I tried to derive the relationship between the measured transfer function and the impedance by simplifying the diagram Koji drew on the board for me (attached, ImpedanceTestingSetup.png) to the attached circuit diagram (ImpedanceTestingCktDiagram.png), and finding the expected value of VA/VR. For the circuit diagram shown, the equation should be VA/VR = 2Z/(50+Z). 50 Ohms is good to use for calibration because the expected value of the transfer function for this impedance is 1 (0 dB).
So I used this relationship to find the expected response for the various impedances, and I also calculated the impedance from the actual measured responses. I've attached a plot of the measured (red) and expected (black) response (top) and impedance (bottom) for a 1 nF capacitor (1nF.png). The expected and measured plots don't really match up very well; if I add extra inductance (7.6 nH, plots shown in blue), the two plots match up a little better, but still don't match very well. I suspect that the difference may come from the fact that for my analysis, I treated the power splitter as if it were a simple node, and I think that's probably not very accurate.
Anyway, the point of all this is to eventually measure the impedance of the circuit I created on Friday, but I don't think I can really do that until I understand what is going on a little better.
I checked the setup and found RF reflection at the load was the cause of the unreasonable response in the impedance measurement.
So, I have put a total 22dB attenuation (10+6+6 dB) between the power splitter and the load to be measured. See the picture.
This kind of attenuators, called as PADs, is generally used in order to improve the impedance matching, sacrificing the signal amplitude at the load.
Then, It looks the measurements got reasonable up to 100MHz (at least) and |Z|<1kOhm.
For the measurements, I just followed the procedure that Stephanie described.
Stephanie has measured the impedance of her resonant circuit.
As a test of the method, I measured impedances of various discrete devices. i.e. 50Ohm, 10-1000pF Cap, Inductances, circuit opened.
a) 50Ohm (marine-blue) was calibrated to be recognized as 50Ohm.
b) The mica capacitances (orange 10pF, yellow 100pF, green 1000pF) appeared as the impedances f^-1 in the low freq region. It's nice.
At high frequency, the impedances deviate from f^-1, which could be caused by the lead inductance. (Self Resonance)
So 1000pF mica is not capacitance at 50MHz already.
c) Open BNC connector (Red) looks have something like 5pF. (i.e. 300Ohm at 100MHz)
d) I could not get good measurements with the inductors as I had 200nH (and some C of ~5pF) for a Pomona clip (blue).
This is just because of my laziness such that I avoid soldering the Ls to an RF connector!
I tilted the periscope beam and aligned the MC. Now the spot at the Faraday entrance is near the center of the aperture in up/down space. The arm powers are only going up to ~0.8, though. Maybe we should try a little bit of left/right.
I looked at the IP POS spot with a viewer card, and it looked round, so no obvious egregious clipping in the Faraday. Someone might take a picture with one of the GigE camera and get us a beam profile there.
We no longer have an MC1 and MC3 camera view.
I can see a bright scatterer that can be seen from the east viewport of the BSC, but I can't tell what it is. It could be a ghost beam.
It would be nice to get an image looking into the north viewport of the IOO chamber. I can't see in there because the BS oplev table is in the way.
David and I were thinking about changing the non-polarizing beam splitter in the EUCLID setup from 50/50 to 33/66 (ref picture). It serves as a) a pickoff to sample the input power and b) a splitter to send the returning beam to a photodetector 2 (it then hits a polarizer and half of this is lost. By changing the reflectivity to 66% then less (1/3 instead of 1/2) of the power coming into it would be "lost" at the ref photodetector 1, and on the return trip less would be lost at the polarizer (1/6 instead of 1/4).
Just now found it dead. Restarted it. Is our elog backed up in the daily backups?
The construction people next door seem to be getting pretty excited about pounding things lately. At my desk the floor was shaking like a mini-earthquake, and all of the accelerometers were pretty much railed. Clara has the Guralp box out right now, so the Guralp is unplugged, but the Ranger didn't seem to be railed.
This either (a) is part of the reason the MC is being wonky lately, or (b) has nothing whatsoever to do with it. The MC watchdogs haven't been tripping all the time, so maybe this isn't a primary cause of the wonky-ness.
In looking at a many-days/months trend to see how far back this has been going, it looks like the accelerometers are hitting their rails pretty much all day every day. This may be significantly hindering Clara's Wiener filtering work. I think the gain on the accelerometer's controler panel is already set to 1, but if it's set to 10, we may want to reduce that. Alternatively, we may want to put in attenuators just as the signal is entering the PEM ADCU, to help reduce the amount of rail-hitting that's going on. I don't remember this from a couple of months ago, so this may be a problem that will go away once the construction / landscaping is done next door.
This week, Joe and I have been setting up the laser and optics. The mephisto laser is emitting a very ugly beam that we can hopefully remedy using an iris and a lens. After scanning the beam width at a few different distances from the laser, I am currently trying to determine the appropriate lenses to use.
I was in the lab last night accelerometerizing and noticed some dents on the tubes that stick out horizontally from the MC2 optical chamber (sorry, I don't know what they're called or what they do). One of them is pretty big... I don't know if this is a problem, but it probably isn't a good thing. Photos below:
This last one is a little hard to see... I was having trouble getting a good angle on it, but it's there. Not quite as significant as the first one though. (The first two pictures are of the same dent.)
Yesterday, Jay brought over the IO box for megatron, and got it working. We plan to firewall megatron this afternoon, with the help of Jay and Alex, so we can set up GDS there and play without worrying about breaking things. In the meantime, we went to Wilson House to get some breakout boards so we can take transfer functions with the 785, for an ETMX controller. We put in a sine wave, and all looks good on the auto-generated epics screens, with an "empty" system (no filters on). Next we'll load in filters and take transfer functions.
Unfortunately we promised to return the breakout boards by 1pm today. This is because, according to denizens of Wilson House, Osamu "borrowed" all their breakout boards and these were the last two! If we can't locate Osamu's cache, they expect to have more in a day or two.
Here is the transfer function of the through filter working at 16KHz sampling. It looks fine except for the fact that the dc gain is ~0.8. Koji is going to characterize the digital down sampling filter in order to try to compare with the generated code and the filter coefficients.
This morning I found the Mode Cleaner unlocked.
I check the sliders for the mirrors bias and they have not changed. Also the OSEMs readbacks show no change in the optics positions.
I don't understand what's wrong because in the previous days, in this state of alignmanet, it could lock.
I tried to tweak a little bit the periscope to check whether it was a problem of beam matching but that didn't help the cavity to lock.
I don't want to change the periscpe alignment to much becasue I believe it is still good and I suspect that there is something else going on.
Kevin Vigue, our high school summer student went through the 40m specific safety traning yesterday.
Peter and Koji,
We are constructing a setup for the new 40m CDS using Realtime Code Generator (RCG).
We are trying to put simulated suspensions and test suspension controllers on a different processors of megatron
in order to create a virtual control feedback loop. Those CDS processes are communicating
each other via a shared memory, not via a reflective memory for now.
After some struggles with tremendous helps of Alex, we succeeded to have the communication between the two processes.
Also we succeeded to make the ADC/DAC cards recognized by megatoron, using the PCI express extension card replaced by Jay.
(This card runs multi PCI-X cards on the I/O chasis.)
- Establish a firewall between the 40m network and megatron (Remember this)
- Make DTT and other tools available at megatron
- Try virtual feedback control loops and characterize the performance
- Enable reflective memory functionalities on megatron
- Construct a hybrid system by the old/new CDSs
- Controllability tests using an interferometer
Note on MATLAB/SIMULINK
o Each cdsIPC should have a correct shared memory address spaced by 8 bytes. (i.e. 0x1000, 0x1008, 0x1010, ...)
Note on MEDM
o At the initial state, garbage (e.g. NaN) can be running all around the feedback loops. They are invisible as MEDM shows them as "0.0000".
To escape from this state, we needed to disconnect all the feedback, say, by turning off the filters.
Note on I/O chasis
o We needed to pull all of the power plugs from megatron and the I/O chasis once so that we can activate
the PCI-e - PCI-X extension card. When it is succeeded, all (~30) LEDs turn to green.
I mapped out the corresponding pins on both ends of the Guralp seismometer cable. Here is the diagram:
The circular 26-pin end of the cable (that plugs into the seismometer) is labeled as above. The other end (the 39-pin end) is not physically numbered, so I just came up with a numbering system. They are both pictured on the non-cable end of the connector. The colored circles indicate the pin pairs.
FROM JENNE, 30JULY2009: the Dsub end is 37 pin, not 39.
Q. When should we use plano-convex lenses, and when should we use bi-convex?
As I had the same question from Jenne and Dmass in a month,
I just like to introduce a good summary about it.
Lens selection guide (Newport)
At a first order, they have the same function.
Abberation (= non-ideal behavior of the lens) is the matter.
ETMY oplev is still out of order. Hopefully I'll get it under control by tomorrow.
I found two ThorLabs PDA55 Si photodetectors that says detect visible light from DC to 10MHz that I'm going to use from now on. I don't know how low of a frequency they will actually be good to.
I set the MC back to its good alignment (June 21st) using this procedure. The trend of the OSEM values over the last 40 days and 40 nights is attached.
Then I aligned the periscope to that beam. This took some serious periscope knob action. Without WFS, the transmission went to 2.7 V and the reflection down to 0.6V.
Then I re-aligned the MC_REFL path as usual. The beam was far enough off that I had to also re-align onto the MC LSC PD as well as the MC REFL camera (~2 beam radii).
Beams are now close to their historical positions on Faraday and MC2. I then restored the PZT sliders to their April snapshot and the X-arm locked.
Steve - please recenter the iris which is on the periscope. It has been way off for a long time.
So it looks OK now. The main point here is that we can trust the MC OSEMs.
Afterwards I rebooted c1susvme1 and c1susvme2 because they were skewed.
I'm impressed by Rana's simple way to align the MC. IFO arms are locked or flashing. 20 days trend attached.
It is really surprising that we now have again the data from the MC OSEMs since up to two days ago the record looked corrupted (see the attachments in my entry 1774).
The reason I ended up severely misaligning the the MC is exactly that there wasn't anymore a reference position that I could go back to and I had to use the camera looking a the Faraday.
When I turned them on, the control signal in Pitch from WFS2 started going up with no stop. It was like the integrator in the loop was fed with a DC bias. The effect of that was to misalign the MC cavity from the good state in which it was with the only length control on (that is, transmission ~2.7, reflection ~ 0.4).
I don't know why that is happening. To exclude that it was due to a computer problem I first burtrestored C1IOO to July the 18th, but since that did not help, I even restarted it. Also that didn't solve the problem.
At least one problem is the mis-centering of the resonant spot on MC2, which can be viewed with the video monitors. It's very far from the center of the optic, which causes length-to-angle coupling that makes the mulitple servos which actuate on MC2 (MCL, WFS, local damping) fight each other and go unstable.
I played with the MC alignment for the beam centering. After that, I restored the alignment values.
In principle, one can select the MC2 spot as one likes, while the transmitted beam axis to the IFO is not changed
as far as you are at the best alignment. This principle is almost trivial because the beam axis matches
to the input beam axis at the best alignment.
The alignment solution is not unique for a triangle cavity if we don't fix the end spot position.
In practice, this cruising of the MC2 spot is accomplished by the following procedure:
0) Assume that you are initially at the best alignment (=max transmission).
1) Slightly tilt the MC2.
2) Adjust MC1/MC3 so that the best transmission is restored.
I started from the following initial state of the alignment sliders:
After many iterations, the spot was centered in some extent. (See the picture)
The instability looked cured somewhat.
Further adjustment caused a high freq (10Hz at the camera) instability and the IMCR shift issue.
So I returned to the last stable setting.
Of course, if you move MC1, the reflected spot got shifted.
The spot has been apparently off-centered from the IMCR camera. (up and right)
At this stage, I could not determine what is the good state.
So, I restored the alignment of the MC as it was.
But now Alberto can see which mirror do we have to move in which direction and how much.
After speaking with Rana and realizing that it would be better to use smaller inductances in the flying-component circuit (and after a lot of tinkering with the original), I rebuilt the circuit, removing all of the resistors (to simplify it) and making the necessary inductance and capacitance changes. A picture of the circuit is attached, as is a circuit diagram.
A plot of the measured and simulated transfer functions is also attached; the general shape matches between the two, and the resonant frequencies are roughly correct (they should be 11, 29.5, and 55 MHz). The gain at the 55 MHz peak is lower than the other two peaks (I'd like them all to be roughly the same). I currently have no idea what the impedance is doing, but I'm certain it is not 50 Ohms at the resonant peaks, because there are no resistors in the circuit to correct the impedance. Next, I'll have to add the resistors and see what happens.
This is a quite nice measurement. Much better than the previous one.
1) For further steps, I think now you need to connect the real EOM at the end in order to incorporate
the capacitance and the loss (=resistance) of the EOM. Then you have to measure the input impedance
of the circuit. You can measure the impedance of the device at Wilson house.
(I can come with you in order to consult with Rich, if you like)
Before that you may be able to do a preparatory measurement which can be less precise than the Wilson one,
but still useful. You can measure the transfer function of the voltage across the input of this circuit,
and can convert it to the impedance. The calibration will be needed by connecting a 50Ohm resister
on the network analyzer.
2) I wonder why the model transfer function (TF) has slow phase changes at the resonance.
Is there any implicit resistances took into account in the model?
If the circuit model is formed only by reactive devices (Cs and Ls), the whole circuit has no place to dissipate (= no loss).
This means that the impedance goes infinity and zero, at the resonance and the anti-resonance, respectively.
This leads a sharp flip of the phase at these resonances and anti-resonances.
The real circuit has small losses everywhere. So, the slow phase change is reasonable.
The last week I've started setting up the HeNe laser on the PSL table and doing some basic measurements (Beam waist, etc) with the beam scan, shown on the graph. Today I moved a few steering mirrors that steve showed me from at table on the NW corner to the PSL table. The goal setup is shown below, based on the UCSD setup. Also, I found something that confused me in the EUCLID setup, a pair of quarter wave plates in the arm of their interferometer, so I've been working out how they organized that to get the results that they did. I also finished calculating the shot noise levels in the basic and UCSD models, and those are also shown below (at 633nm, 4mw) where the two phase-shifted elements (green/red) are the UCSD outputs, in quadrature (the legend is difficult to read).
0. Probably, you are working on the SP table, not on the PSL table.
1. The profile measurement looks very nice.
2. You can simplify the optical layout if you consider the following issues
A. The matching lenses just after the laser:
You can make a collimated beam only with a single lens, instead of two.
Just put a lens of f0 with distance of f0 from the waist. (Just like Geometrical Optics to make a parallel-going beam.)
Or even you don't need any lens. In this case, whole optical setup should be smaller so that your beam
can be accomodated by the aperture of your optics. But that's adequately possible.
B. The steering mirrors after the laser:
If you have a well elevated beam from the table (3~4 inches), you can omit two steering mirrors.
If you have a laser beam whose tilte can not be corrected by the laser mount, you can add a mirror to fix it.
C. The steering mirrors in the arms:
You don't need the steering mirrors in the arms as all d.o.f. of the Michelson alignment can be adjusted
by the beamsplitter and the mirror at the reflected arm. Also The arm can be much shorter (5~6 inches?)
D. The lenses and the mirrors after the PBS:
You can put one of the lenses before the PBS, instead of two after the lens.
You can omit the mirror at the reflection side of the PBS as the PBS mount should have alignment adjustment.
The simpler, the faster and the easier to work with!
This afternoon I kept working on the alignment of the beam so that it matches at the same the PSL periscope, the Mode Cleaner and the Faraday isolator at the input of the IFO.
The camera looking at the Farady showed a beam quite low from the center of the Faraday's entrance. I wanted to move it up.
After working on the periscope alignment and on the MC mirrors, I think I managed to moved it up a bit. To know whether that was enough or not I wanted to evaluate the alignment to the X arm by checking the value of TRX.
In order for the MC to be finely matched to the input beam from the periscope, the WFS controls have to be on. Before turning them on, I centered the beam on their QPDs and run the WFS_zero_offset script.
Flashes at ETMX show at least that the beam is going through the Farady. How well, I can't tell untill the MC is under full control.
I have to leave the lab now, but I can be back tomorrow to keep working on that.
ETMY oplev is currently a work in progress. The HeNe beam is hitting the photodiode, but the spot size there is pretty much the size of the entire QPD. Thus, the ETMY oplev isn't really useful right now. I'm re-figuring things out (note to self: close to the laser, you have to use Gaussian optics...regular ray tracing doesn't really work), and hopefully will have the oplev back under control by the time Alberto is finished realigning the IFO, so this doesn't keep anyone from doing any exciting locking work.
This morning I found the elog down. I restarted it using the procedure in the wiki.
After yesterday's changes in the MC cavity state today it was necessary to optimize the alignment to the Faraday.
The way I did it was by tuning the PSL periscope in pitch and yaw trying to maximize TRX with the arm locked. After a small change in either one of the two directions I first maximized the MC transmitted power and then I ran the alignment script for the X arm.
I explored the space for both pitch and yaw and the max that I could get from TRX was 0.91. I'm not sure whether the increase in TRX is entirely due to a better alignment to the Farady rather than to a higher MC transmitted power.
Also I'm not sure I'm well interpreting the image from the camera pointing at the Farady. I guess I need someone more familiar with it to tell me if it shows any sign of clipping.
Anyway, last week, even before the MC got misaligned, TRX didn't go above 0.90. So now I wonder whether it's the MC's fault or something else's if we have that value..
Chronicles of periscope and MC alignment
Yesterday morning I started aligning the periscope but it turned out to be trickier than usual. With the ASC (Alignment Sensing Control) off and only the length controls on, the Mode Cleaner didn't lock easily, although I knew I wasn't very far from the sweet spot.
In the afternoon the struggle continued and the matching of the the beam to the MC cavity became just worse. At some point I noticed that the ASC inputs somehow had got on - although the ASC still looked disabled from the MClock MEDM main screen. So I was actually working against the Wave Front Sensors and further worsening the periscope alignment.
That hurled me to the weeds. After hours of rowing across the stormy waters of a four-dimensional universe I got to have occasional TEM00 flashes at the transmission but still, surprisingly, no MC locking. Confused, I kept tuning the periscope but that just kicked me off road again.
Then at about 7pm Koji came to my rescue and suggested a more clever and systematic way to solve the problems. He suggested to keep record of the MC mirrors alignment state and re-align the cavity to the periscope. Then we would gradually bring the cavity back to the original good position changing the periscope alignment at the same time.
That would have worked straight away, if we hadn't been fighting against a subtle and cruel enemy: the 40m computer network. But I (as John Connor), and Koji (as the Terminator) didn't pull back.
Here's a short list of the kinds of weapons that the computers threw to us:
We then proceeded with Koji's plan. In an iterative process, we aligned the MC cavity maximizing the transmission and tuned the periscope in order to match the Faraday input of the interferometer. The last thing we did it by looking at the camera pointing at the Faraday isolator.
We found that we didn't have to tune the periscope much. That means that all afternoon I didn't really go too far, but the autolocker wasn't working properly, or it wasn't working at all.
Then we ran the alignment script for the X arm but it didn't work before we aligned the steering mirrors.
Then we ran it three times but could not get more than 0.87 at TRX. That means that there we still have to work on the alignment to the Faraday. That's job for today in the trenches of the lab.
See Adhikari eLOG entry: http://nodus.ligo.caltech.edu:8080/AdhikariLab/194
I compiled and ran a simple (i.e. empty) front end controller on scipe12 at wilson house. I hooked a signal into the ADC and watched it in the auto-generated medm screens.
There were a couple of gotchas:
1. Add an entry SYS to the file /etc/rc.local, to the /etc/setup_shmem.rtl line, where the system file is SYS.mdl.
2. If necessary, do a BURT restore. Or in the case of a mockup set the BURT Restore bit (in SYS_GDS_TP.adl) to 1.
in the rack next to the printer. It sounds like a fan is hitting something.