ID |
Date |
Author |
Type |
Category |
Subject |
2210
|
Mon Nov 9 12:09:10 2009 |
Alberto | Omnistructure | Environment | BNC Cable Laid Down from South End to East VErtex |
I laid down the floor a BNC cable from the Y End table to the BNC Chamber. The cable runs next to the east wall.
I'm leaving the cable because it can turn useful in the future.
I'm tying the end of the cable to a big threaded steel rod on the side of the BS chamber.
I've also labeled as TRY |
Attachment 1: DSC_0986.JPG
|
|
2211
|
Mon Nov 9 13:17:07 2009 |
Alberto | Configuration | ABSL | NPRO on |
I turned the auxialiary NPRO for the AbsL Experiment on. Its shutter stays closed. |
2213
|
Mon Nov 9 13:26:19 2009 |
Alberto | Omnistructure | Environment | Tidying up BNC cables rack around the lab |
We have thousands of miles of BNC cables in the lab but we still don't find one when we need it. I decided to solve the problem.
This morning I tried to tidy up the several cable rack the we have in the lab.
i tried to dedicate each rack to a speecific type of cables: special cables, hand made cables, BNCs, LEMOs, etc.
In particular I tryed to concentrate BNC cable of several lengths on the rack near by the ITMX chamber.
People are invited to preserve the organization.
|
Attachment 1: DSC_0987.JPG
|
|
2214
|
Mon Nov 9 14:53:47 2009 |
Alberto | Omnistructure | Environment | Tidying up BNC cables rack around the lab |
This would be a good trial once you put the label "BNC only" on the wall.
Quote: |
We have thousands of miles of BNC cables in the lab but we still don't find one when we need it. I decided to solve the problem.
This morning I tried to tidy up the several cable rack the we have in the lab.
i tried to dedicate each rack to a speecific type of cables: special cables, hand made cables, BNCs, LEMOs, etc.
In particular I tryed to concentrate BNC cable of several lengths on the rack near by the ITMX chamber.
People are invited to preserve the organization.
|
|
2217
|
Mon Nov 9 15:11:02 2009 |
Alberto | Update | LSC | Everything put back as it was |
Quote: |
I disconnected the setup for the arm cavity TF measurement. I opened the scitation switch on the ISS medm screen. I reconnected the OMC ISS EXC cable to the breakout box on the floor.
The photodiode on the Y end is stilll connected.
Also the RFAm (whish is not disbaled anymore) still has a 50% beam splitter before it.
I'm also running the Align Full IFO script.
|
I removed the beam splitter and the PDA 255.
the beam path to the RFAM photodiode is clear again. |
2219
|
Mon Nov 9 16:32:36 2009 |
Alberto | Frogs | Environment | Shot of the white board yesterday before erasing |
Yesterday Rana and I needed some room on the white board in the Control Room. We had to erase some of the stuff present on the board despite the bif warning "Do Not Erase".
This is how it looked like before erasing.

|
Attachment 1: DSC_0980.JPG
|
|
2220
|
Mon Nov 9 18:27:30 2009 |
Alberto | Frogs | Computers | OMC DCPD Interface Box Disconnected from the power Supply |
This afternoon I inadvertently disconnected one of the power cables coming from the power supply on the floor next to the OMC cabinet and going to the DCPD Interface Box.
Rob reconnected the cable as it was before. |
2226
|
Tue Nov 10 13:02:36 2009 |
Alberto | Update | LSC | X and Y Arm Cavity Poles Measurement |
From fitting the arm cavity transfer functions I got the following values for the cavity pole frequencies.
X ARM: fp_x = (1720 +/- 70) Hz
Y ARM: fp_y = (1650 +/- 70) Hz
Attached are the plots from the fitting. |
Attachment 1: SummaryOfFits.pdf
|
|
Attachment 2: CodeAndData.tar
|
2227
|
Tue Nov 10 17:01:33 2009 |
Alberto | Configuration | IOO | c1ioovme and c1iool0 rebooted |
This afternoon, while I was trying to add the StochMon channels to the frames, I rebooted the c1ioovme and c1iool0.
I had to do it twice because of a mispelling in the C1IOO.INI file that the first time prevented the computer to restart properly.
Eventually I restored the old .ini file, as it was before the changes.
After rebooting I also burtrestored.
During the process the mode cleaner got unlocked. Later on the autoclokcer couldn't engage. I had to run the MC_down and MC_up scripts. |
2228
|
Tue Nov 10 17:49:20 2009 |
Alberto | Metaphysics | Computers | Test Point Number Mapping |
I found this interesting entry by Rana in the old (deprecated) elog : here
I wonder if Rolf has ever written the mentioned GUI that explained the rationale behind the test point number mapping.
I'm just trying to add the StochMon calibrated channels to the frames. Now I remember why I kept forgetting of doing it... |
2229
|
Tue Nov 10 19:19:57 2009 |
Alberto | Update | ABSL | Rotated polarizer on the PSL table, along the MC input pick off beam |
Aligning the beam for the PLL of the AbsL Experiement I rotated the polarizer along the path of the MC Input pick off beam (= the pick off coming from the MC periscope). |
2230
|
Tue Nov 10 19:21:53 2009 |
Alberto | Update | ABSL | PLL Alignment |
I've been trying to lock the PLL for the AbsL Experiment but I can't see the beat (between the auxiliary NPRO and the PSL).
I believe the alignment of the PLL is not good. The Farady Isolator is definitely not perfectly aligned (you can see it from the beam spot after it) but still it should be enough to see something at the PLL PD.
it's probably just that the two beams don't overlap well enough on the photodiode. I'll work on that later on.
I'm leaving the lab now. I left the auxiliary NPRO on but I closed its shutter.
All the flipping mirrors are down. |
2236
|
Wed Nov 11 12:29:44 2009 |
Alberto | Frogs | PSL | MC Locked on the wrong mode? |
This morning, after Steve pointed out that the readout RFAMPD_DC was zero, I thought of realigning the beam on the photodiode. Maybe I touched the lens or the beam splitter that send the beam on the diode when I installed an other beam splitter to make the measurement of the calibration between two ThorLabs PDA255 photodiodes.
After aligning the beam on the RFAMPD, the voltage of the DC readout was lower than it used to be (C1:IOO-RFAMPD_DC ~ 0.4 now vs. 4 as it was on November 4th).
I maximized the DC readout but the problem seems to be that the beam spot is not a round TEM00. In particular the spot looks like that of a TEM10 mode.
Since we're looking at the MC transmitted beam, is it possible that the MC is locked on the wrong mode?
Check out the attached picture. |
Attachment 1: PB110184-1.JPG
|
|
2238
|
Wed Nov 11 15:04:52 2009 |
Alberto | Update | ABSL | Working on the AP table |
I've opened the AP table and I'm working on it. |
2239
|
Wed Nov 11 16:18:57 2009 |
Alberto | Update | ABSL | Working on the AP table |
Quote: |
I've opened the AP table and I'm working on it.
|
I re-aligned the Faraday on the AP table. I also aligned the beam to the periscope on the PSL and all the other optics along the beam path. Now I have a nice NPRO beam at the PLL which overlaps with the PSL beam. The alignment has to be further improved because I see no beat yet.
I wonder if the all the tinkering on the PSL laser done recently to revive the power has changed the PSL NPRO temperature and so its frequency. That could also explain why the beat doesn't show up at the same temperature of the NPRO as I used to operate it. Although I scanned the NPRO temperature +/- 2 deg and didn't see the beat. So maybe the misalignment is the casue.
Not feeling very well right now. I need to go home for a while.
AP table closed at the moment.
NPRO shutter closed |
2249
|
Thu Nov 12 10:45:02 2009 |
Alberto | Update | PSL | Abandoned Frequency Generator |
This morning I found a frequency generator connected to something on the PSL table sitting on the blue step next to the sliding doors.
Is anyone using it? Has it been forgotten there? If that's the case, can the interested person please take care of removing it? |
2250
|
Thu Nov 12 10:45:36 2009 |
Alberto | Update | ABSL | Working on the AP table |
I've opened the AP table and I'm working on it.
Also auxiliary NPRO turned on and mechanical shutter opened. |
2252
|
Thu Nov 12 11:34:38 2009 |
Alberto | Update | ABSL | Working on the AP table |
Quote: |
Yes it did.
For long time, the crystal temperature C1:PSL-126MOPA_LTMP was 43~46deg. Now it is 34deg. Try ~10deg lower temperature.
Quote: |
I wonder if the all the tinkering on the PSL laser done recently to revive the power have changed the PSL NPRO temperature and so its frequency. That could also explain why the beat doesn't show up at the same temperature of the NPRO as I used to operate it. Although I scanned the NPRO temperature +/- 2 deg and didn't see the beat.
|
|
Beat found at 30MHz with auxiliary NPRO temperature of 37.19 degrees, vs. ~48 deg as it used to be.
The beat is small (-70dBm). PLL alignment has to be improved. |
2253
|
Thu Nov 12 12:50:35 2009 |
Alberto | Update | Computers | StochMon calibrated channels added to the data trend |
I added the StochMon calibrated channels to the data trend by including the following channel names in the C0EDCU.ini file:
[C1:IOO-RFAMPD_33MHZ_CAL]
[C1:IOO-RFAMPD_133MHZ_CAL]
[C1:IOO-RFAMPD_166MHZ_CAL]
[C1:IOO-RFAMPD_199MHZ_CAL]
Before saving the changes I committed C0EDCU.ini to the svn.
Then I restarted the frame builder so now the new channels can be monitored and trended. |
2254
|
Thu Nov 12 12:51:45 2009 |
Alberto | Update | ABSL | Working on the AP table |
Quote: |
I've opened the AP table and I'm working on it.
Also auxiliary NPRO turned on and mechanical shutter opened.
|
AP table and aux NPRO shutter just closed. |
2256
|
Thu Nov 12 16:13:05 2009 |
Alberto | Update | PSL | MC Trans Offset |
On Rana's suggestion I checked the MC transmission QPD (C1:IOO-MC_TRANS_SUM). I found that the readout is almost zero when the MC is unlocked.
I unlocked the Mode Cleaner turning off the LSC control and disabling the autolocker. The QPD reads 0.014. It seems that there is no offset.
I also checked with the IR card around the photodetector and I didn't see any stray beam. |
2257
|
Thu Nov 12 16:53:59 2009 |
Alberto | Update | ABSL | Working on the AP table |
Quote: |
Quote: |
Yes it did.
For long time, the crystal temperature C1:PSL-126MOPA_LTMP was 43~46deg. Now it is 34deg. Try ~10deg lower temperature.
Quote: |
I wonder if the all the tinkering on the PSL laser done recently to revive the power have changed the PSL NPRO temperature and so its frequency. That could also explain why the beat doesn't show up at the same temperature of the NPRO as I used to operate it. Although I scanned the NPRO temperature +/- 2 deg and didn't see the beat.
|
|
Beat found at 30MHz with auxiliary NPRO temperature of 37.19 degrees, vs. ~48 deg as it used to be.
The beat is small (-70dBm). PLL alignment has to be improved.
|
PLL alignment improved. Beat amplitude = -10dBm. Good enough.
DC readouts at the PLL photodiode:
V_NPRO = -4.44V
V_PSL = -3.76V
The NPRO beam is attenuated by a N.D.=1 attenuator just before going to the photodiode.
Something strange happened at the last. Right before -10dBm, the amplitude of the beat was about -33dBm. Then I was checking the two interfering beams with the IR card and saw that they overlapped quite well. I then turned my head back to the spectrum analyzer and suddenly the beat was at -10dBm. Not only, but a bunch of new peaks had appeared on the spectrum. Either I inadvertently hit the PD moving it to a better position or something else happened.
Like if someone was making some other modulation on the beam or the modulation depth of the PSL's sidebands had gone up. |
2261
|
Thu Nov 12 18:10:27 2009 |
Alberto | Update | ABSL | PLL Locked |
I locked the PLL and made some first measuremtns of the spectrum of the error signal. I'll post them later.
I closed the shutter of the NPRO. |
2271
|
Sun Nov 15 18:42:10 2009 |
Alberto | Update | Locking | Interferometer fully locked for 3331 seconds |
This afternoon, I tried to lock the interferometer again after a few days.
After a couple of failed attempts, and relocks of the MZ, the interferometer stayed locked continuously for about 50 minutes, with arm power of about 92.
I just wanted to check the status of the interferometer so I didn't do any particular measurement in the meantime. |
2302
|
Thu Nov 19 16:04:48 2009 |
Alberto | Configuration | elog | Elog debugging output - Down time programmed today to make changes |
We want the elog process to run in verbose mode so that we can see what's going. The idea is to track the events that trigger the elog crashes.
Following an entry on the Elog Help Forum, I added this line to the elog starting script start-elog-nodus:
./elogd -p 8080 -c /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg -D -v > elogd.log 2>&1
which replaces the old one without the part with the -v argument.
The -v argument should make the verbose output to be written into a file called elogd.log in the same directory as the elog's on Nodus.
I haven't restarted the elog yet because someone might be using it. I'm planning to do it later on today.
So be aware that:
We'll be restarting the elog today at 6.00pm PT. During this time the elog might not be accessible for a few minutes. |
2303
|
Thu Nov 19 18:49:55 2009 |
Alberto | Configuration | elog | Elog debugging output - Down time programmed today to make changes |
Quote: |
We want the elog process to run in verbose mode so that we can see what's going. The idea is to track the events that trigger the elog crashes.
Following an entry on the Elog Help Forum, I added this line to the elog starting script start-elog-nodus:
./elogd -p 8080 -c /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg -D -v > elogd.log 2>&1
which replaces the old one without the part with the -v argument.
The -v argument should make the verbose output to be written into a file called elogd.log in the same directory as the elog's on Nodus.
I haven't restarted the elog yet because someone might be using it. I'm planning to do it later on today.
So be aware that:
We'll be restarting the elog today at 6.00pm PT. During this time the elog might not be accessible for a few minutes.
|
I tried applying the changes but they didn't work. It seems that nodus doesn't like the command syntax.
I have to go through the problem...
The elog is up again. |
2308
|
Fri Nov 20 13:54:45 2009 |
Alberto | Omnistructure | Environment | New Paper and Cardboard Recycling Bins Introduced to the 40m |
The 40m produces a large amount of paper and cardboard waste. It would be worth it if we disposed those kind of garbages for recycling.
I set up two new garbage bins in the lab: one in the control rooms that adds up to the can/bottle recycling bin, and one other one in the office area, next to the printer for general paper disposal.
People in the lab are strongly invited to make use of the two new garbage bins and recycle their paper and cardboard waste.
Boxes can be larger than the garbage bin, so I'd recommend people to crash them before throwing them into the bin.


|
2321
|
Tue Nov 24 14:33:22 2009 |
Alberto | Update | ABSL | working on the AP table |
I'm working on the AP table. I also opened the auxiliary NPRO shutter. The auxiliary beam is on its path on the AP table and PSL table. |
2324
|
Tue Nov 24 19:16:02 2009 |
Alberto | Update | ABSL | working on the AP table |
Quote: |
I'm working on the AP table. I also opened the auxiliary NPRO shutter. The auxiliary beam is on its path on the AP table and PSL table.
|
Closing the AP table and the NPRO shutter now. |
2326
|
Wed Nov 25 08:43:08 2009 |
Alberto | Update | ABSL | Working on the AP table |
I'm working on the AP table. I also opened the auxiliary NPRO shutter. The auxiliary beam is on its path on the AP table and PSL table. |
2328
|
Wed Nov 25 10:20:47 2009 |
Alberto | Update | ABSL | AbsL PLL not able to lock |
Last night something happened on the beat between the PSL beam and the auxiliary NPRO beam, that spoiled the quality of the beating I had before. As a result the PLL has become unable to lock the two lasers.
The amplitude of the beat at the spectrum analyzer has gone down to -40 dBm from -10 that it was earlier. The frequency has also become more unstable so that now it can be seen writhing within tens of KHz.
Meanwhile the power of the single beams at the PLL photodiode hasn't changed, suggesting that the alignment of the two beam didn't change much.
Changes in the efficiency of the beating between the two beams are not unusual. Although that typically affects only the amplitude of the beat and wouldn't explain why also its frequency has become unstable. Tuning the alignment of the PLL optics usually brings the amplitude back, but it was uneffective today.
It looks like something changed in either one of the two beams. In particular the frequency of one of the two lasers has become less stable.
Another strange thing that I've been observing is that the amplitude of the beat goes down (several dBm) as the beat frequency is pushed below 50 MHz. Under 10 MHz it even gets to about -60 dBm.
I noticed the change yesterday evening at about 6pm, while I was taking measurements of the PLL open loop tranfer function and everything was fine. I don't know whether it is just a coincidence or it is somehow related to this, but Jenne and Sanjit had then just rebooted the frame builder. |
2329
|
Wed Nov 25 11:02:54 2009 |
Alberto | Update | ABSL | AbsL PLL not able to lock |
Quote: |
Last night something happened on the beat between the PSL beam and the auxiliary NPRO beam, that spoiled the quality of the beating I had before. As a result the PLL has become unable to lock the two lasers.
The amplitude of the beat at the spectrum analyzer has gone down to -40 dBm from -10 that it was earlier. The frequency has also become more unstable so that now it can be seen writhing within tens of KHz.
Meanwhile the power of the single beams at the PLL photodiode hasn't changed, suggesting that the alignment of the two beam didn't change much.
Changes in the efficiency of the beating between the two beams are not unusual. Although that typically affects only the amplitude of the beat and wouldn't explain why also its frequency has become unstable. Tuning the alignment of the PLL optics usually brings the amplitude back, but it was uneffective today.
It looks like something changed in either one of the two beams. In particular the frequency of one of the two lasers has become less stable.
Another strange thing that I've been observing is that the amplitude of the beat goes down (several dBm) as the beat frequency is pushed below 50 MHz. Under 10 MHz it even gets to about -60 dBm.
I noticed the change yesterday evening at about 6pm, while I was taking measurements of the PLL open loop tranfer function and everything was fine. I don't know whether it is just a coincidence or it is somehow related to this, but Jenne and Sanjit had then just rebooted the frame builder.
|
I confirm what I said earlier. The amplitude of the beat is -10 dBm at 300MHz. It goes down at lower frequencies. In particular it gets to-60 dBm below 20 MHz. For some strange reason that I couldn't explain the beating efficiency has become poorer at low frequencies. |
2334
|
Wed Nov 25 15:42:27 2009 |
Alberto | Update | ABSL | Working on the AP table |
Quote: |
I'm working on the AP table. I also opened the auxiliary NPRO shutter. The auxiliary beam is on its path on the AP table and PSL table.
|
NPRO shutter closed |
2337
|
Wed Nov 25 20:14:58 2009 |
Alberto | Update | ABSL | AbsL PLL not able to lock: problem fixed |
Quote: |
Last night something happened on the beat between the PSL beam and the auxiliary NPRO beam, that spoiled the quality of the beating I had before. As a result the PLL has become unable to lock the two lasers.
The amplitude of the beat at the spectrum analyzer has gone down to -40 dBm from -10 that it was earlier. The frequency has also become more unstable so that now it can be seen writhing within tens of KHz.
Meanwhile the power of the single beams at the PLL photodiode hasn't changed, suggesting that the alignment of the two beam didn't change much.
Changes in the efficiency of the beating between the two beams are not unusual. Although that typically affects only the amplitude of the beat and wouldn't explain why also its frequency has become unstable. Tuning the alignment of the PLL optics usually brings the amplitude back, but it was uneffective today.
It looks like something changed in either one of the two beams. In particular the frequency of one of the two lasers has become less stable.
Another strange thing that I've been observing is that the amplitude of the beat goes down (several dBm) as the beat frequency is pushed below 50 MHz. Under 10 MHz it even gets to about -60 dBm.
I noticed the change yesterday evening at about 6pm, while I was taking measurements of the PLL open loop tranfer function and everything was fine. I don't know whether it is just a coincidence or it is somehow related to this, but Jenne and Sanjit had then just rebooted the frame builder.
|
Problem found. Inspecting with Koji we found that there was a broken SMA-to-BNC connector in the BNC cable from the photodiode. |
2338
|
Wed Nov 25 20:24:49 2009 |
Alberto | Update | ABSL | PLL Open Loop Gain Measured |
I measured the open loop gain of the PLL in the AbsL experiment.
I repeated the measurement twice: one with gain knob on the universal PDH box g=3.0; the second measurement with g=6.0
The UGF were 60 KHz and 100 KHz, respectively.
That means that one turn of the knob equals to about +10 dB. |
Attachment 1: 2009-09-25_OLgain_g3png.png
|
|
Attachment 2: 2009-09-25_OLgain_g6png.png
|
|
2339
|
Wed Nov 25 20:28:17 2009 |
Alberto | Update | ABSL | Stopped working on the AbsL |
I closed the shutter of the NPRO for the night. |
2345
|
Mon Nov 30 10:28:47 2009 |
Alberto | AoG | all down cond. | sea of red |
Quote: |
Came in, found all front-ends down.
Keyed a bunch of crates, no luck:
Requesting coeff update at 0x40f220 w/size of 0x1e44
No response from EPICS
Powered off/restarted c1dcuepics. Still no luck.
Powered off megatron. Success! Ok, maybe it wasn't megatron. I also did c1susvme1 and c1susvme2 at this time.
BURT restored to Nov 26, 8:00am
But everything is still red on the C0_DAQ_RFMNETWORK.adl screen, even though the front-ends are running and synced with the LSC. I think this means the framebuilder or the DAQ controller is the one in trouble--I keyed the crates with DAQCTRL and DAQAWG a couple of times, with no luck, so it's probably fb40m. I'm leaving it this way--we can deal with it tomorrow.
|
I found the red sea when I came in this morning.
I tried several things.
- ssh into fb40m: connection refused
- telnet fb40m 8087: didn't respond
- shutdown fb40m by physically pushing the power button: it worked and the FB came back to life but still with a red light on the MEDM DAQ_DETAIL screen;
- powercycled fb40m AND C0DAQCTRL: no improvement
- shutdown fb40m, C0DAQCTRL, C1DCUEPICS and pushed the reset button on the RF network crate; then I restarted the computers in this order: fb40m, C1DCUEPICS, C0DAQCTRL: it worked: they came back to life and the lights eventually turned green on the MEDM montior screen
I'm now going to restart the single front -ends and burtgooey them if necessary. |
2346
|
Mon Nov 30 11:29:40 2009 |
Alberto | AoG | all down cond. | sea of red |
Quote: |
Quote: |
Came in, found all front-ends down.
Keyed a bunch of crates, no luck:
Requesting coeff update at 0x40f220 w/size of 0x1e44
No response from EPICS
Powered off/restarted c1dcuepics. Still no luck.
Powered off megatron. Success! Ok, maybe it wasn't megatron. I also did c1susvme1 and c1susvme2 at this time.
BURT restored to Nov 26, 8:00am
But everything is still red on the C0_DAQ_RFMNETWORK.adl screen, even though the front-ends are running and synced with the LSC. I think this means the framebuilder or the DAQ controller is the one in trouble--I keyed the crates with DAQCTRL and DAQAWG a couple of times, with no luck, so it's probably fb40m. I'm leaving it this way--we can deal with it tomorrow.
|
I found the red sea when I came in this morning.
I tried several things.
- ssh into fb40m: connection refused
- telnet fb40m 8087: didn't respond
- shutdown fb40m by physically pushing the power button: it worked and the FB came back to life but still with a red light on the MEDM DAQ_DETAIL screen;
- powercycled fb40m AND C0DAQCTRL: no improvement
- shutdown fb40m, C0DAQCTRL, C1DCUEPICS and pushed the reset button on the RF network crate; then I restarted the computers in this order: fb40m, C1DCUEPICS, C0DAQCTRL: it worked: they came back to life and the lights eventually turned green on the MEDM montior screen
I'm now going to restart the single front -ends and burtgooey them if necessary.
|
Everything is back on.
Restarted all the front ends. As usual c1susvme2 was stubborn but eventually it came up.
I burt-restored all the front-ends to Nov 26 at 8am.
The mode cleaner is locked. |
2350
|
Thu Dec 3 15:55:24 2009 |
Alberto | AoG | LSC | RF AM Stabilizer Output Power |
Today I measured the max output power at the EOM output of one of the RF AM Stabilizers that we use to control the modulation depth. I needed to know that number for the designing of the new RF system.
When the EPICS slider of the 166 MHz modulation depth is at 0 the modulation depth is max (the slider's values are reversed : 0 is max, 5 is min; it is also 0 for any value above 5, sepite it range from 0 to 10).
I measured 9.5V from the EOM output, that is 32 dBm on a 50 Ohm impedance. |
2365
|
Tue Dec 8 10:20:33 2009 |
Alberto | DAQ | Computers | Bootfest succesfully completed |
Alberto, Kiwamu, Koji,
this morning we found the RFM network and all the front-ends down.
To fix the problem, we first tried a soft strategy, that is, we tried to restart CODAQCTRL and C1DCUEPICS alone, but it didn't work.
We then went for a big bootfest. We first powered off fb40m, C1DCUEPICS, CODAQCTRL, reset the RFM Network switch. Then we rebooted them in the same order in which we turned them off.
Then we power cycled and restarted all the front-ends.
Finally we restored all the burt snapshots to Monday Dec 7th at 20:00. |
2376
|
Thu Dec 10 08:40:12 2009 |
Alberto | Update | Computers | Fronte-ends down |
I found all the front-ends, except for C1SUSVME1 and C0DCU1 down this morning. DAQAWG shows up green on the C0DAQ_DETAIL screen but it is on a "bad" satus.
I'll go for a big boot fest. |
2378
|
Thu Dec 10 08:50:33 2009 |
Alberto | Update | Computers | Fronte-ends down |
Quote: |
I found all the front-ends, except for C1SUSVME1 and C0DCU1 down this morning. DAQAWG shows up green on the C0DAQ_DETAIL screen but it is on a "bad" satus.
I'll go for a big boot fest.
|
Since I wanted to single out the faulting system when these situations occur, I tried to reboot the computers one by one.
1) I reset the RFM Network by pushing the reset button on the bypass switch on the 1Y7 rack. Then I tried to bring C1SOSVME up by power-cycling and restarting it as in the procedure in the wiki. I repeated a second time but it didn't work. At some point of the restarting process I get the error message "No response from EPICS".
2) I also tried rebooting only C1DCUEPICS but it didn't work: I kept having the same response when restarting C1SOSVME
3) I tried to reboot C0DAQCTRL and C1DCU1 by power cycling their crate; power-cycled and restarted C1SOSVME. Nada. Same response from C1SOSVME.
4) I restarted the framebuilder; power-cycled and restarted C1SOSVME. Nothing. Same response from C1SOSVME.
5) I restarted the framebuilder, then rebooted C0DAQCTRL and C1DCU, then power-cycled and restarted C1SOSVME. Niente. Same response from C1SOSVME.
Then I did the so called "Nuclear Option", the only solution that so far has proven to work in these circumstances. I executed the steps in the order they are listed, waiting for each step to be completed before passing to the next one.
0) Switch off: the frame builder, the C0DAQCTRL and C1DCU crate, C1DCUEPICS
1) turn on the frame builder
2) reset of the RFM Network switch on 1Y7 (although, it's not sure whether this step is really necessary; but it's costless)
3) turn on C1DCUEPICS
4) turn on the C0DAQCTRL and C1DCU crate
5) power-cycle and restart the single front-ends
6) burt-restore all the snapshots
When I tried to restart C1SOSVME by power-cycling it I still got the same response: "No response from EPICS". But I then reset C1SUSVME1 and C1SUSVME2 I was able to restart C1SOSVME.
It turned out that while I was checking the efficacy of the steps of the Grand Reboot to single out the crucial one, I was getting fooled by C1SOSVME's status. C1SOSVME was stuck, hanging on C1SUSVME1 and C1SUSVME2.
So the Nuclear option is still unproven as the only working procedure. It might be not necessary.
Maybe restating BOTH RFM switches, the one in 1Y7 and the one in 1Y6, would be sufficient. Or maybe just power-cycling the C0DAQCTRL and C1DCU1 is sufficient. This has to be confirmed next time we incur on the same problem. |
2384
|
Thu Dec 10 13:10:25 2009 |
Alberto | Configuration | LSC | 166 LO Disconnected |
I temporarily disconnected the Heliax cable that brings the 166MHz LO to the LSC rack.
I'm doing a couple of measurement and I'll put it back in as soon as I'm done. |
2389
|
Thu Dec 10 17:05:21 2009 |
Alberto | Configuration | LSC | 166 MHz LO SMA-to-Heliax connection repaired |
I replaced the SMA end connector for the 166 MHZ Local Oscillator signal that goes to the back of the flange in the 1Y2 rack. The connector had got damaged after it twisted when I was tigheting the N connector of the Heliax cable on the front panel. |
2393
|
Thu Dec 10 18:31:44 2009 |
Alberto | Configuration | LSC | 166 LO Disconnected |
Quote: |
I temporarily disconnected the Heliax cable that brings the 166MHz LO to the LSC rack.
I'm doing a couple of measurement and I'll put it back in as soon as I'm done.
|
These are the losses I measured on a RG-174 cable for the two frequencies that we're planning to use in the Upgrade:
@11MHz Loss=0.22dBm/meter
@55MHz Loss=0.41dBm/meter
(The cable was 2.07m long. The input signal was +10dBm and the output voltages at the oscilloscope where: Vpk-pk(11MHz)=1.90V, Vpk-pk(11MHz)=1.82V ) |
2396
|
Fri Dec 11 11:42:26 2009 |
Alberto | Configuration | LSC | 166 LO Disconnected |
Quote: |
They must not be dBm, must be dB
Quote: |
Quote: |
I temporarily disconnected the Heliax cable that brings the 166MHz LO to the LSC rack.
I'm doing a couple of measurement and I'll put it back in as soon as I'm done.
|
These are the losses I measured on a RG-174 cable for the two frequencies that we're planning to use in the Upgrade:
@11MHz Loss=0.22dBm/meter
@55MHz Loss=0.41dBm/meter
(The cable was 2.07m long. The input signal was +10dBm and the output voltages at the oscilloscope where: Vpk-pk(11MHz)=1.90V, Vpk-pk(11MHz)=1.82V )
|
|
I apologize for the lack of correctness on the units in yesterday's elog entry, but I wasn't very sharp last night.
I repeated the measurement today, this time also making sure that I had a 50ohm input impedance set in the scope. These the results for the losses.
RG-174 Cable |
0.053 dB/m @ 11MHz |
0.155 dB/m @ 55 MHz |
I also measured the losses in the Heliax cable going from the 166 MHz LO to the LSC rack:
166MHz LO Heliax |
0.378 dB @ 11MHz |
1.084 dB @ 55 MHz |
|
2397
|
Fri Dec 11 13:18:17 2009 |
Alberto | Configuration | VAC | pumpdown has started |
Quote: |
Oplev positions before and after drag wiped arm TMs as of yesterday. Slow-mode pumpdown has started with 3/4 turn opened RV1 valve at 8am today.
|
I'm leaving the lab now for less than 2 hours. I should be back in time for when the pumping is finished so that I can measure the finesse again. |
2402
|
Fri Dec 11 19:51:13 2009 |
Alberto | Configuration | LSC | 166 LO Disconnected |
Quote: |
Seems like very strange cable loss numbers. The Heliax is lossier than the RG-174? I wonder how these compare with the specs in the cable catalog?
|
In my last entry there was a typo for the measurement of the Heliax at 55 MHz. I corrected it. It was 1.084 dB instead of 1.084 dB/m.
For the Heliax I don't have the measurement of the loss per meter since I don't know the cable actual length.
Except for that, I checked the values I found on the Internet.
My measurements for the RG-174 seem comparable to the loss specified in the catalog ( here): 6.6dB in 100ft @ 55 MHz, that is 0.22 dB/m, that compare with 0.155 dB/m that I measured.
I did the measurement on a 4.33 meter long cable with SMA connectors at the ends. |
2413
|
Mon Dec 14 14:16:14 2009 |
Alberto | Update | Treasure | LOCKSTARS |
Quote: |
Good job guys. What I did was saying "I don't know", "Maybe", and "Ants...".
Now you can proceed to measurements for the visibility and the cavity pole!
Quote:
|
[Jenne, Kiwamu, Koji]
We got the IFO back up and running! After all of our aligning, we even managed to get both arms locked simultaneously.
|
|
I'm going to do it right now. |
2415
|
Mon Dec 14 19:33:04 2009 |
Alberto | Update | General | Arm Cavity Poles measured again after cleaning the optics last week |
Last week we vented and we cleaned the main optics of the arm cavities.
I measured the frequency of the cavity poles for both the arm cavities to see how they changed (see previous elog entry 2226). These the results:
fp_X = 1616 +/- 14 Hz
fp_Y = 1590 +/- 4 Hz
The error is the statistical error that I got with the Matlab NonLinearLeastSquare fitting function.
I calculated the cavity pole frequencies by measuring the transfer function between a photodiode located at the end of the arms (either X or Y) and another photodiode placed after the mode cleaner. Both diodes where Thorlabs PDA255.
(Last time, I had measured that the pair of diode had a flat calibration).
With the SR785 I measured the transfer function by exciting the OMC_ISS_EXC input cable.
For both arms I set to 1V the excitation amplitude. I repeated the measurements for different excitation amplitudes without observing any changes.
I then fitted the data with the NonLinearLeastSquare function of matlab. The script I wrote to do that is attached to this entry in a compressed file.
The files also contains the PDF with the output plots and the data from both set of measurements performed before and after the cleaning.
The data is commented in a file called measurements.log.
In the end I disabled again the test switch on the ISS MEDM screen.
I disconnected the excitation cable from the OMC_ISS_EXC input cable.
I removed the photodiode that measured the Mode Cleaner transmission from the PSL clearing the way for the beam to get back to its path to the RFAM photodiode. |
Attachment 1: XarmTF01_fit.pdf
|
|
Attachment 2: YarmTF01_fit.pdf
|
|
Attachment 3: ArmCavityFinesseMeasurment.tar.gz
|