Following the method in Peter's Elog,
I edited c1psl.db to include the following:
I restarted c1psl (had to go hit the physical reset button since it didn't come back after telnet-ing and "reboot"ing) to make this take effect.
Next step is to tell the PMC screen to look at this _LOCALC rather than _LODET, and the screen will be calibrated into dBm.
Right now, the screen is as it always has been, because after relooking at the calibration, I no longer believe it. This calibration claimes -19dBm for an LOmon value of 0.1200, when I actually measured +16dBm for this LOmon value. So I've screwed something up in doing my MatLAB calibration. I'll fix it tomorrow, and put in the correct calibration before I change the PMC screen.
RefCav, PMC, MC are all back and locked after my shenanigans.
I edited c1psl.db to include the following:
As it turns out, I apparently can't tell X from Y when fitting a function in a rush. The real calibration stuff which is now in c1psl.db is:
I restarted c1psl (again, had to go hit the physical reset button since it didn't come back after a telnet-reboot) to have it take in the changes. The psl.db file that was in place before yesterday (before I touched it) is saved as psl.db.15Apr2009 just in case.
I edited the PMC EPICS screen to have the LO mon look at C1:PSL-PMC_LOCALC, which is the calibrated channel in dBm. I also stuck a little label on the screen saying what units it's in, because everyone likes to know what units they're looking at.
The new Level 13 mixer on the PMC servo board is installed (minicircuits SRA-3MH). Since the RF output of the LO board was ~16dBm, I put a 3dB attenuator between the LO board and the LO input on the servo board. Since the previous cable was *just* the right length, this required adding a tiny bit of cable. I found a very short cable, which worked out nicely, and didin't leave bunches of extra cable between the two boards. One of these days if I have time (i.e. if it is necessary), I'll make a new cable for this purpose, so that we don't have 2 cables daisy-chained.
A note on the Mixer-replacement: The mixer on the PMC servo board is soldered in a set of 8 through-holes, not stuck in a socket. So I had to desolder the old Level 23 Mixer (minicircuits RAY-3) which was a total pain. Unfortunately, in this process, I lifted one of the pads off the back side of the board. Once the old mixer was removed, it became clear that the pin for the pad I had lifted was shorted via a trace on the front side of the board to the pin directly across from it. So when installing the new mixer, I did my best to get some solder into the through-hole for the lifted-pad-pin, and then tied it using a jumper wire to the pin that it's shorted to on the front of the board. You can't see the trace that shorts the two pins because it's underneath the mixer, when the mixer is installed. (Sidenote: after talking with Rana, this should be okie-dokie, especially if these are ground pins).
The PMC and MC locked nice and happily after I replaced the board and turned all the HV supplies back on, so I call this a success!
I also measured the OLG of the PMC servo after today's adventures in mixer-land. I get a UGF of 1.4kHz, with 66 degrees of phase margin. The method for this is in elog 924.
I checked the phase slider setting of the PMC phase screen by putting 30kHz at 100mV into the Ext DC input of the servo board, and looking at the 30kHz peak output of the Mixer Out. I fiddled with the phase slider, and chose the value for which the 30kHz peak was maximized. The phase slider is now set to 5.0V.
The MOPA is taking the long weekend off.
Steve went out to wipe off the condensation inside the MOPA and found beads of water inside the NPRO box, perilously close to the PCB board. He then measured the water temperature at the chiller head, which is 6C. We decided to "reboot" the MOPA/chiller combo, on the off chance that would get things synced up. Upon turning off the MOPA, the neslab chiller display immediately started displaying the correct temperature--about 6C. The 22C number must come from the MOPA controller. We thus tentatively narrowed down the possible space of problems to: broken MOPA controller and/or clog in the cooling line going to the power amplifier. We decided to leave the MOPA off for the weekend, and start plumbing on Tuesday. It is of course possible that the controller is the problem, but we think leaving the laser off over the weekend is the best course of action.
steve, rob, alberto
Steve installed two rotary flow meters into the MOPA chiller system--one at the chiller flow output and one in the NPRO cooling line. After some hijinks, we discovered that the long, insulated chiller lines have the same labels at each end. This means that if you match up the labels at the chiller end, at the MOPA end you need switch labels: out goes to in and vice-versa. This means that, indubitably, we have at some point had the flow going backwards through the MOPA, though I'm not sure if that would make much of a difference.
Steve also installed a new needle valve in the NPRO cooling line, which works as expected as confirmed by the flow meter.
We also re-discovered that the 40m procedures manual contains an error. To turn on the chiller in the MOPA start-up process, you have to press ON, then RS-232, then ENTER. The proc man says ON, RS-232, RUN/STOP.
The laser power is at 1.5W and climbing.
The chiller HT alarm started blinking, as the water temperature had reached 40 degrees C, and was still rising. We turned off the MOPA and the chiller. Maybe we need to open the needle valve a bit more? Or maybe the flow needs to be reversed? The labels on the MOPA are backwards?
The chiller appears to be broken. We currently have it on, with both the SENSOR and RS-232 unplugged. It's running, circulating water, and the COOL led is illuminated. But the temperature is not going down. The exhaust out the back is not particularly warm. We think this means the refrigeration unit has broken, or the chiller computer is not communicating with the refrigerator/heat exchanger. Regardless, we may need a new chiller and a new laser.
steve, alberto, rob
After some futzing around with the chiller, we have come to the tentative conclusion that the refrigeration unit is not working. Steve called facilities to try to get them to recharge the refrigerant (R-404a) tomorrow, and we're also calling around for a spare chiller somewhere in the project (without luck so far).
The repair man thinks it's a bad start capacitor, which is 240uF at 120V. Steve has ordered a new one which should be here tomorrow, and with luck we'll have lasing by tomorrow afternoon.
I drained the water and removed side covers from the Neslab RTE 140 refrigerated water cooler unit this morning. The hoses to the laser were disconnected.
This abled you to see the little window of refregerant R404A was free of bubles, meaning: no recharge was needed.
The circulator bath was refilled with 7 liters of Arrowhead distilled water and the unit was turned on.
The water temp was kept 20.00+- .05C without any load. Finally the AC-repair man Paul showed up.
He measured the R404A level to be as specified: 23-24 PSI on the suction side and 310 PSI on the discharge side.
The unit was working fine. Paul found an intermittently functioning starting capacitor on the compressor that was removed.
The 240 micro Farad 120VAC cap will arrive tomorrow
Steve, Rob and Alberto
Starting capacitor 216 miroFarad was installed on the compressor. Water lines were connected to the MOPA as corrected, so the flow meter readings are logical.
Now IN means flowing water in the direction of black arrow on the hose.
We struggled with the Neslab presetting: temp, bauds rate and other unknowns till Rob found the M6000 manual on Peter king's website.
Alberto realized that the chiller temp had to be reset to 20C on water chiller.
I put 1mg of Chloramin T into the water to restrict the growth of algae in the bath.
The NPRO heat sink was around ~20C without flow meter wheel rotation and the PA body ~25C by touch of a finger
I just opened up the needle valve a litle bit so the flow meter wheel would started rotating slowly.
That small glitch at the end of this 3 hrs plot shows this adjustment.
I'm setting SLOWDC to about -5.
I had to edit FSSSlowServo because it had hard limits on SLOWDC at (-5 and 5). It now goes from -10 to 10.
I locked to PSL loops, then tweaked the alignment of the MC to get it to lock.
I first steering MC1 until all the McWFS quads were saturated. This got the MC locking in a 01 mode. So I steered MC1 a little more till it was 00. Then I steered MC2 to increase the power a little bit. After that, I just enabled the MC autolocker.
The laser power seems to have become more stable after fixing the laser chiller. The power is lower than it used to be (MOPA amplitude 2.5 versus 2.7) but, as shown in the attchement, it became more steady.
Some thoughts on what happened with the MOPA cooling.
Some unknown thing happened to precipitate the initial needle valve jiggle, which unleashed a torrent of flow through the NPRO. This flow was made possible by the fact that the cooling lines are labeled confusingly, and so flow was going backwards through the needle valve, which was thus powerless to restrict it. The NPRO got extremely cold, and most of the chiller's cooling power was being used to unnecessarily cool the NPRO. So, the PA was not getting cooled enough. At this, point, reversing the flow probably would have solved everything. Instead, we turned off the chiller and thus discovered the flaky start-motor capacitor.
Now we have much more information, flow meters in the NPRO and main cooling lines, a brand-new, functioning needle valve, a better understanding of the chiller/MOPA settings necessary for operation, and the knowledge of what happens when you install a needle valve backwards.
The Neslab chiller is working well. It's temp display shows 20.0 C rock solid. Flow meter rotating at 13.5Hz at the out put of the chiller.
The MOPA temp was measured with a hand held thermocouple . The PA was 34 C and 29 C at NPRO heat sink.
The NPRO flow meter was not rotating at this time. There was just trickeling water flow though the meter.
I closed the needle valve this point. It needed 8 turns clockwise. This drives head temp to 19.9 C
Than I opened the needle valve 9 turns and the flow meter wheel was rotaing at ~ 1 Hz
We gained a little power. Can you explain this?
The PMC alarm was on this morning. It was relocked at lower HV
The FSS_RMTEMP jumped 0.5 C so The PZT was compensating for it.
Today I tuned the periscope on the PSL table to align the beam to the Mode Cleaner. With the Wave Front Sensor control off, I minimized the reflection from the MC and maximized the transmission. While doing that I also checked that the transmitted beam after the MC didn't lose the alignment with the interferometer's main Faraday isolator.
In this way, I've got a reflection, as read from the MC_REFLPD_MC, of about 0.6. Then I centered the WFS on the AS table. After that the WFS alignment control brought the reflection to 0.25 and a nice centered bull-eye spot showed on the monitor.
Trying to track the MC positions back for a few days, it seems that the data hasn't been recorded properly for a while. Something happened yesterday after my boot fest and then the record got restored. Attached here are the readbacks showing the event for MC1.
Is anything wrong with the data record?
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.
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..
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.
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.
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.
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.
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.
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.
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.
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 installed an improvised version of PSL output beam iris at the output periscope last week.
Stephanie has needed the doors to the PSL open all day, and still has them open, so I just turned the HEPAs on high.
We aligned both the reference cavity and the PMC, each by looking at their Trans PD on Davaviewer, and adjusting the two steering mirrors to maximize the transmission power. We got a pretty good amount of improvement for the ref cav, but since the PMC hasn't decayed a whole lot, we got a much smaller amount of improvement.
I turned the HEPAs back down to ~50.
After Alberto and I worked on aligning the reference cavity, Rob asked the important and useful question: what is the visibility of the reference cavity. This helps tell us if we're optimally aligned or not even close.
I did a scan of the ref cav temperature, using /scripts/PSL/FSS/SLOWscan, but there seems to be no real signal is C1:PSL-FSS_RFPDDC. As shown in Alberto's 200-day plot, it does change sometimes, but if you zoom in on the flat parts, it seems like it's not really reading anything meaningful. I did a cursory check-out of it, but I'm not 100% sure where to go from here: There are (as with all of these gold-box PDs) 3 outputs: a ribbon cable (for ADC purposes I think), an SMA for the RF signal, and a BNC for the DC signal. The photodiode is clearly working, since if you stick the Lollypop in front of the PD, the cavity unlocks. I plugged a 'scope into the DC BNC, and it also behaves as expected: block the beam and the signal goes down; unblock the beam and the signal goes up. Something of note is that this readout gives a positive voltage, which decreases when the beam is blocked. However, looking at the dataviewer channel, nothing at all seems to happen when the beam is blocked/unblocked. So the problem lies somewhere in the get-signal-to-DAQ path. I unplugged and replugged in the ribbon cable, and the value at which the channel has been stuck changed. Many days ago, the value was -0.5, for the last few days it's been -1.5, and after my unplug/replug, it's now back to ~ -0.5 . The other day Alberto mentioned, and made the point again today that it's a little weird that the PD reads out a negative voltage. Hmm.
we have a tester cable, but you don't want it. Instead the problem is probably at the cross-connect. The D-cable goes to a cross-connect and you can probe there with a voltmeter. If the signal is good there, trace it to the ADC. Also trend for several years to see when this happened - Yoichi may know the history better.
Also, we still need to complete the FSS RFPD task list from last year.
For some reason a few minutes ago the FB DAQ crashed and I had to restarted.
I called in the reinforcements today. Ben came over and we looked all around at all of the cross-connects and cables relating to the FSS. Everything looks pretty much okey-dokey, except that we still weren't getting signal in the DataViewer channels. Finally we looked at the psl.db file, which indicates that the C1:PSL-FSS_RFPDDC channel looks at channel 21 of the ADC cross connect thing. We followed the cable which was plugged into this, and it led to a cable which was disconnected, but laying right next to the Ref Cav refl PD. We plugged this into the DC out SMA connection of the photodiode (which had not been connected to anything), and suddenly everything was mostly golden again in dataviewer land. RFPDDC_F now has a signal, but RFPDDC is still flat.
Even though this seems to be working now, it's still not perfect. Rob suggested that instead of having this SMA cable going from the photodiode's DC out, we should take the signal from the ribbon cable. So I'm going to figure out which pin of the D-connector is the DC out, and take that from the cross connect to the ADC cross connect. This will help avoid some persnickity ground loops.
I have added/modified SMOO settings to all of the records in psl.db appropriately. Changes checked in to SVN.
As a reminder, you should check in to the SVN all changes you make to any of the .db files or any of the .ini files in chans.
The offending beam dump has been removed, and the PMC relocked.
Maybe it was Russell Crowe
I think the MZ pzt is broken/failing. I'm not sure how else to explain this behavior.
The first bit of the time series is a triangle wave into the DC offset (output) field, over approximately the whole range (0-250V). You can see the fringe visbility is quite small. The triangle wave is stopped, and I then maxed out the offset slider to get to the "high" power point from the triangle wave sweep. Then for a little while with the PZT is held still, and the power still increases. The MZ is then locked, and you can see the PZT voltage stay about the same but the power continues to rise over the next ~10 minutes or so.
This plot answers the previous question, and raises a new one--what the heck is MZTRANSPD? I'd guess the pins are unconnected--it's just floating, and somehow picking up the MZ_PZT signal.