40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 39 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  14565   Wed Apr 24 11:22:59 2019 awadeBureaucracyEquipment loanBorrowed Zurich HF2LI Lock in Amplifer to QIL

Borrowed Zurich HF2LI Lock in Amplifer to QIL lab Wed Apr 24 11:25:11 2019.

  14616   Fri May 17 10:12:07 2019 AnjaliSummaryEquipment loanBorrowed component

I borrowed one Marconi (2023 B) from 40 m lab to QIL lab.

  14618   Fri May 17 16:07:25 2019 gautamSummaryEquipment loanBorrowed component

ZHL-3A (2 units) —-> QIL

Quote:

I borrowed one Marconi (2023 B) from 40 m lab to QIL lab.

  17233   Mon Nov 7 12:37:26 2022 KojiUpdateGeneralBorrowed the fiber tester for the OMC lab

I am borrowing the fiber illuminator / fiber tester / VisiFault for the OMC lab. It has been stored in the top drawer at the center work bench.

==> Returned

  5054   Thu Jul 28 16:10:34 2011 kiwamuUpdateLSCBoth arm locked

[Nicole / Jamie / Rana / Kiwamu]

  The X arm and Y arm have been locked.

The settings for the locking were stored on the usual IFO_CONFIGURE scripts, so anybody can lock the arms.

In addition to that Nicole, Jamie and Rana re-centered the beam spot on the ETMY_TRANS camera and the TRY PD.

The next step is to activate the C1ASS servo and align the both arms and beam axis.

 

 

Xarm locking notes:

* Changed TRX gain from -1 to -0.02. Without this 50x reduction the arm power was not normalized.

* Had to fix trigger matrix to use TRX for XARM and TRY for YARM. Before it was crazy and senseless.

* Lots of PZT alignment. It was off by lots.

* Yarm trans beam was clipping on the steering mirrors. Re-aligned. Needs to be iterated again. Be careful when bumping around the ETMY table.

* YARM gain was set to -2 instead of -0.2. Because the gain was too high the alignment didn't work right.

ALWAYS HAVE an OPEN DATAVIEWER with the standard ARM channels going when doing ANY INTERFEROMETER WORK.

THIS IS THE LAW.

  9199   Thu Oct 3 22:14:06 2013 MasayukiUpdateGreen LockingBoth arms ALS stabilized for IR resonance

[Manasa, Masayuki]

We succeeded in stabilizing both the arms using ALS and get IR to resonate at the sametime.

Measurement

At each step we measured the _PHASE_OUT_Hz calibrated error signals for  Y in this configuration so as to get the in-loop noise of ALS control of YARM

1. we stabilized YARM off IR resonance by using ALS, misaligned ETMX, closed XARM green shutter. That means no IR flashing and no green in XARM.

2. we aligned the ETMX with XARM green shutter closed.

3. we opened the green shutter and locked the green laser with PDH to the XARM.

4. we stabilized the XARM using ALS and off resonance for IR.

5.We brought the XARM to IR resonance with YARM stabilized off IR resonance.

6. we brought the YARM to IR resonance

Beat frequencies when both the arms were stabilized and had IR resonating :
X arm beat frequency = 73.2 MHz; Y arm beat frequency = 26.6 MHz.

Attachment

1.the ALS in-loop noise in X and Y arms with IR off resonance and resonating.

2.the ALS in-loop noise in Y arm in each step from 1 to 6.(will follow soon)

Discussion

The Y arm ALS in-loop noise doesn't seem to be different in any of the configurations in step 1 to 6. This seems to mean that the ALS of the two arms are decoupled.

Actually we are not sure what changed from the last few days (when we were seeing some sort of coupling between the ALS of X and Y arm) except for YARM green PDH servo gain changed (see this entry),

  16888   Fri Jun 3 15:22:51 2022 yutaUpdateLSCBoth arms locked with POY/POX, IR beam centered on TMs with ASS

[JC, Paco, Yuta]

We locked both Y and X arms with POY11 and POX11.
RFM fix (40m/16887) enabled us to use triggering using C1:LSC-TRY/X_OUT.
IR beam is now centered on TMs using ASS (for Yarm, ASS loops cannot be closed fully, so did it manually).

What we did:
 - Aligned both arms so that the beams are roughly centered at TMs using cameras.
 - Yarm lock was easy, but Xarm lock required gain tuning. Somehow, Xarm required x3 higher gain as follows, although the amplitude of POX11_I_ERR seems to be almost the same as POY11_I_ERR. I suspect it is something to do with power normalization matrix (TRX flashing is almost a double of TRY flashing).

C1:LSC-YARM_GAIN = 0.01
C1:LSC-XARM_GAIN = 0.03

 - Run ASS for Yarm. ASS loops cannot be closed fully using default feedback parameters. I guess this is because ITMY ULCOIL is not working (40m/16873). ASS demodulated signals were manually zero-ed by manually aligning ETMY, ITMY and PR3 (and some TT1 and TT2), except for demodulated signals related to ITMY. Beam on ITMY was centered just by using our eyes.
 - Run ASS for Xarm. It seemed to work well.
 - After this, TRX and TRY were as follows and beam positions on TMs were as attached.

C1:LSC-TRX_OUT ~0.95
C1:LSC-TRY_OUT ~ 0.58

(TRX is somehow lower than what we had yesterday... 40m/16886; TRX and TRY photodiode alignment was checked, but seems to be OK.)

 - Centered TMs and BS oplevs.

Next:
 - POX and POY demodulation phases are not fully optimized. Needs re-tuning.
 - Tweak GRX and GRY injection (restore GRY PZTs?)
 - Install ETMXT camera (if it is easy)
 - MICH locking
 - RTS model for BHD needs to be updated

  11018   Thu Feb 12 23:40:12 2015 ranaUpdateIOOBounce / Roll stopband filters added to MC ASC filter banks

The filters were already in the damping loops but missing the MC WFS path. I checked that these accurately cover the peaks at 16.5 Hz and 23.90 and 24.06 Hz.

  10930   Thu Jan 22 15:35:41 2015 diegoUpdateSUSBounce/Roll Measurements

I measured the bounce/roll frequencies for all the optics, and updated the Mechanical Resonances wiki page accordingly.

I put the DTT templates I used in the /users/Templates/DTT_BounceRoll folder; I wrote a python script which takes the exported ASCII data from such templates and does all the rest; the only tricky part is to remember to export the channel data in the order "UL UR LL" for each optic; the ordering of the optics in a single template export is not important, as long as you remember it...

Anyhow, the script is documented and the only things that may need to be modified are:

  • lines 21, 22: the "starting points" FREQ_B and FREQ_R (to accomodate noisy or bad data, as ETMX was for the Roll part in both the measurements I took);
  • line 72: the parameters of the slepian window used to average the data: the first one is the most important and indicates how much averaging will happen; more averaging means less noise but broader and lower peaks, which shouldn't be a big issue since we care only about the peak position, not its amplitude; however, if the peak is already shallow, too much averaging will make things worse instead of better;
  • lines 110, 118: the initial guess for the fit parameters;

The script is in scripts/SUS/BR_freq_finder.py and in the SVN. I attach the plots I made with this method.

  16652   Wed Feb 9 11:56:24 2022 AnchalUpdateGeneralBringing back CDS

[Anchal, Paco]

Bringing back CDS took a lot of work yesterday. I'm gonna try to summarize the main points here.


mx_start_stop

For some reason, fb1 was not able to mount mx devices automatically on system boot. This was an issue I earlier faced in fb1(clone) too. The fix to this problem is to run the script:

controls@fb1:/opt/mx/sbin/mx_start_stop start

To make this persistent, I've configured a daemon (/etc/systemd/system/mx_start_stop.service) in fb1 to run once on system boot and mount the mx devices as mentioned above. We did not see this issue of later reboots yesterday.


gpstime

Next was the issue of gpstime module out of date on fb1. This issue is also known in the past and requires us to do the following:

controls@fb1:~ 0$ sudo modprobe -r gpstime
controls@fb1:~ 1$ sudo modprobe gpstime

Again, to make this persistent, I've configured a daemon (/etc/systemd/system/re-add-gpstime.service) in fb1 to run the above commands once on system boot. This corrected gpstime automatically and we did not face these problems again.


time synchornization

Later we found that fb1-FE computers, ntp time synchronization was not working and the main reason was that fb1 was unable to access internet. As a rule of thumb, it is always a good idea to try pinging www.google.com on fb1 to ensure that it is connected to internet. The issue had to do with fb1 not being able to find any namespace server. We fixed this issue by reloading bind9 service on chiara a couple of times. We're not really sure why it wasn't working.

~>sudo service bind9 stop
~>sudo service bind9 start
~>sudo service bind9 status
* bind9 is running

After the above, we saw that fb1 ntp server is working fine. You see following output on fb1 when that is the case:

controls@fb1:~ 0$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-table-moral.bnr 110.142.180.39   2 u  399  512  377  195.034  -14.618   0.122
*server1.quickdr .GPS.            1 u   67   64  377  130.483   -1.621   1.077
+ntp2.tecnico.ul 56.99.239.27     2 u  473  512  377  184.648   -0.775   2.231
+schattenbahnhof 129.69.1.153     2 u  365  512  377  144.848    3.841   1.092
 192.168.123.255 .BCST.          16 u    -   64    0    0.000    0.000   0.000

On the FE models, timedatectl should show that NTP synchronized feild is yes. That wasn't happening even after us restarting the systemd-timesyncd service. After this, I just tried restarting all FE computers and it started working.


CDS

We had removed all db9 enabling plugs on the new SOSs beforehand to keep coils off just in case CDS does not come back online properly.

Everything in CDS loaded properly except the c1oaf model which kepy showing 0x2bad status. This meant that some IPC flags are red on c1sus, c1mcs and c1lsc as well. But everything else is green. See attachment 1. I then burtrestroed everything in the /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2022/Feb/4/12:19 directory. This includes the snapshot of c1vac as well that I added on autoburt that day. All burt restore statuses were green OK. I think we are in good state now to start watchdogs on the new SOSs and put back the db9 enabling plugs.


Future work:

When somebody gets time, we should make cutom service files in fb1:/etc/systemd/system/ symbolic links to a repo directory and version control these important services. We should also make sure that their dependencies and startup order is correctly configured. I might have done a half-assed job there since I recently learned how to make unit files. We should do the same on nodus and chiara too. Our hope is that on one glorious day, the lab can be restarted without spending more than 20 min on booting up the computers and network.

 

  16653   Wed Feb 9 13:55:05 2022 KojiUpdateGeneralBringing back CDS

Great recovery work and cleaning of the rebooting process.

I'm just curious: Did you observe that the c1sus2 cards have different numbering order than the previous along with the power outage/cycling?

  2708   Wed Mar 24 12:38:17 2010 HartmutConfigurationGreen LockingBroadband PD for green PLL

Modified one of the PD assemblies carrying a large SI-Diode (~10mm diameter).

Removed elements used for resonant operation and changed PD readout to transimpedance

configuration. The opamp is a CLC409 with 240 Ohm feedback (i.e. transimpedance) resistor.

To prevent noise peaking at very high frequencies and get some decoupling of the PD,

I added a small series resistor in line with the PD and the inverting opamp input.

It was chosen as 13 Ohm, and still allows for operation up to ~100MHz.

Perhaps it could be smaller, but much more bandwith seems not possible with this opamp anyway.

Changes are marked in the schematic, and I list affected components here.

(Numbers refer to version 'PD327.SCH' from 30-April-1997):

-removed L4

-connected L3 (now open pad) via 100 Ohm to RF opamp output. This restores the DC sognal output.

-removed c17

-connected pin 3 of opamp via 25 Ohm to GND

-connected kathode of PD via 13 Ohm to pin 2 of opamp

-removed L6, C26, L5, C18, and C27

-shorted C27 pad to get signal to the RF output

 

Measured the optical TF with the test laser setup.

(Note that this is at 1064nm, although the PD is meant to work with green light at 532nm!)

Essentially it looks usable out to 100MHz, where the gain dropped only by about

6dB compared to 10MHz.

Beyond 100MHz the TF falls pretty steeply then, probably dominated by the opamp.

 

The maximal bias used is -150V.

If the bias is 'reduced' from -150V to -50V, the response goes down by 4dB at 10MHz and

by 9dB at 100MHz.

 The average output was 30mV at the RF output, corresponding to 60mV at the opamp output (50Ohm divider chain).

With 240 Ohm transimpedance this yields 250µA photo-current used for these transfer functions.

SiAmpl.png

 

SiPhase.png

 

 

  5470   Mon Sep 19 21:19:25 2011 KatrinUpdateGreen LockingBroadband photodiode characterization

Another Hamasutu S3399 photodiode was tested with the electronic circuit as described in LIGO-D-1002969-v.

RF transimpedance is 1k although the DC transimpedance is 2k.

The noise level is 25pA/sqrt(Hz) which corresponds to a dark current of 1.9mA or 1.7mA in the independent measurement.

At all frequencies the noise is larger compared to Koji's measurement (see labbook page 4778).

 


In file idet_S3399.pdf the first point is not within its error bars on the fitted curved. This point corresponds to the dark noise measurement

I made this measurement again. Now it is on the fitted curve. In the previous measurement I pushed the save button a bit too early. The

averaging process has not been ready while I pushed the 'save'  button.

Dark current is 1.05mA and noise is lower than in the previous measurement.

New file are the XXX_v2.pdf files

current_noise_S3399_v2.pdf

 idet_S3399_v2.pdf

 


 idet_S3399.pdf

 current_noise_S3399.pdf

S3399_response.pdf

  878   Mon Aug 25 12:13:49 2008 JenneUpdatePSLBroken PMC Servo Board
I broke the PMC servo board (on accident).

I was trying to measure the resistance of the extra resistor that someone put between the board and the HV OUT connector, since this is part of an RC filter (where C is the capacitance of the PZT on the PMC) that I need to know the values of as part of my mission to make a 14.6kHz notch for the PMC body mode. The resistance is 63.6k. I had to pull the board to get in to measure this resistance.

This resistor between the board and the center pin of the panel-mount HV OUT connector made a rigid connection between the board and the panel. When I was putting the board back in, I must have strained this connection enough that it broke. We don't have any of the same kind of resistor here at the 40m, so I'm waiting until after lunch to go to Wilson house and see if they've got any. The IFO is down until I get this sorted out.
  5299   Wed Aug 24 17:05:11 2011 JenneUpdateSUSBroken UL magnet on ITMX

Quote:

The ITMX tower was shipped into the Bob's clean room to put the magnet back on. 

 Repair work is delayed.  I need the "pickle pickers" that hold the magnet+dumbbell in the gluing fixture, for gluing them to the optic.  Here at the 40m we have a full set of SOS gluing supplies, except for pickle pickers.  We had borrowed Betsy's from Hanford for about a year, but a few months ago I returned all of the supplies we had borrowed.  Betsy said she would find them in her lab, and overnight them to us.  Since the problem occurred so late in the day, they won't get shipped until tomorrow (Thursday), and won't arrive until Friday.

I also can't find our magnet-to-dumbbell gluing fixture, so I asked her to send us her one of those, as well. 

I have 2 options for fixing ITMX.  I'll write down the pros and cons for each, and we can make a decision over the next ~36 hours.

OPTIONS:

(#1) Remove dumbbell from optic.  Reglue magnet to dumbbell. Reglue magnet+dumbbell to optic.

(#2) Carefully clean dumbbell and magnet, without breaking dumbbell off of optic.  Glue magnet to dumbbell.

PROS:

(#1) Guarantee that magnet and dumbbell are axially aligned.

(#2) Takes only 1 day of glue curing time.

CONS:

(#1) Takes 2 days of glue curing time. (one for magnet to dumbbell, one for set to optic.)

(#2) Could have slight mismatch in axis of dumbbell and magnet.  Could accidentally drop a bit of acetone onto dumbbell-to-optic glue, which forces us into option 1, since this might destroy the integrity of the glue joint (this would take only the 2 days already required for option 1, it wouldn't force us to take 2+1=3 days).

  5302   Thu Aug 25 15:20:03 2011 JenneUpdateSUSBroken UL magnet on ITMX

Dmass just reminded me that the usual procedure is to bake the optics after the last gluing, before putting them into the chambers.  Does anyone have opinions on this? 

On the one hand, it's probably safer to do a vacuum bake, just to be sure.  On the other hand, even if we could use one of the ovens immediately, it's a 48 hour bake, plus cool down time.  But they're working on aLIGO cables, and might not have an oven for us for a while.  Thoughts?

  5305   Thu Aug 25 17:57:35 2011 SureshUpdateSUSBroken UL magnet on ITMX

Quote:

Dmass just reminded me that the usual procedure is to bake the optics after the last gluing, before putting them into the chambers.  Does anyone have opinions on this? 

On the one hand, it's probably safer to do a vacuum bake, just to be sure.  On the other hand, even if we could use one of the ovens immediately, it's a 48 hour bake, plus cool down time.  But they're working on aLIGO cables, and might not have an oven for us for a while.  Thoughts?

I think we should follow the established procedure in full, even though it will cost us a few more days.  I dont think we should consider the vacuum bake as something "optional".  If the glue has any volatile components they could be deposited on the optic resulting in a change in the coating and consequently optical loss in the arm cavity.

 

 

  5306   Fri Aug 26 07:53:59 2011 steveUpdateSUSBroken UL magnet on ITMX

Quote:

Dmass just reminded me that the usual procedure is to bake the optics after the last gluing, before putting them into the chambers.  Does anyone have opinions on this? 

On the one hand, it's probably safer to do a vacuum bake, just to be sure.  On the other hand, even if we could use one of the ovens immediately, it's a 48 hour bake, plus cool down time.  But they're working on aLIGO cables, and might not have an oven for us for a while.  Thoughts?

 Follow full procedure for full strength, minimum risk

  11242   Fri Apr 24 01:16:30 2015 JenneUpdateASCBroken Xass?

I ran the "off" script for the Xarm ASS, followed by the "on" script, and now the Xarm ASS doesn't work.  Usually we just run the freeze/unfreeze, but I ran the off/on scripts one time. 

Koji, if you have some time tomorrow, can you please look at it?  I am sorry to ask, but it would be very helpful if I could keep working on other things while the ASS is taken care of.

Steve, can you please find a cable that goes from the LSC rack to the IOO rack (1Y2 to 1X2), or lay a new one?  It must be one single long cable, without barrels sticking it together.  This will help me actuate on the Marconi using the LSC rack's DAC. 

Thank you!!

  11248   Sat Apr 25 03:32:45 2015 KojiUpdateASCBroken Xass?

I spent a day to fix the XARM ASS, but no real result. If the input of the 6th DOF servo is turned off, the other error signals are happy
to be squished to around their zeros. So this gives us some sort of alignment control. But obviously a particular combination of the
misalignment is left uncontrolled.

This 6th DOF uses BS to minimize the dither in ITMX yaw. I tired to use the other actuators but failed to have linear coupling between
the actuator and the sensor.


During the investigation, I compared TRX/TRY power spectra. TRX had a bump at 30Hz. Further investigation revealed that the POX/POY
had a big bump in the error signals. The POX/POY error signals between 10-100Hz were coherent. This means that this is coming from
the frequency noise stabilized with the MC. (Is this frequency noise level reasonable?)

The mysterious discovery was that the bump in the transmission exist only in TRX. How did the residual frequency noise cause
the intensity noise of the transmission? One way is the PDH offset.

Anyway, Rana pointed out that IMC WFS QPDs had large spot offsets. Rana went to the AS table and fixed the WFS spot centering.
This actually removed the bump in TRX although we still don't know the mechanism of this coupling.

The bump at 30Hz was removed. However, the ASS issue still remains.

  12342   Wed Jul 27 15:03:02 2016 sisyphusMetaphysicsSUSBroken wire

While tightening the bolts on the ETMX wire clamp, the wire broke. All four face magnets broke off. 

Fortunately, no pieces were lost.

  12343   Wed Jul 27 16:56:47 2016 ranaMetaphysicsSUSBroken wire

For the rest of this vent, at least, we need to start using the EQ stops more frequently. Whenever the suspension is being worked on clamp the optic. When you need it to be free back off the stops, but only by a few hundred microns - never more than a millimeter.

Best to take our time and use the stops often. With all the magnets being broken off, its not clear now how many partially cracked glue joints we have on dumbells which didn't completely fall off.

  2131   Wed Oct 21 17:12:30 2009 AlbertoUpdateelogBrowser context menu enabled on the Elog under HTM editing mode

On behalf of Steve and of the rest of the not-native-English community at the 40m willing to have their browser's spell checker working while editing the Elog, I fixed the Elog's feature that prevented Firefox' context menu (that one which pops up with a mouse right click) to work when using the HTML editing interface (FCKeditor).

That let also Firefox spell checker to get enabled.

To get the browser context menu just press CTRL right-clicking.

To make sure that the features works properly on your browser, you might have to fully clear the browser's cache.

Basically I modified the FCKeditor config file (/cvs/cds/caltech/elog/elog-2.7.5/scripts/fckeditor/fckconfig.js). I added this also to the elog section on our Wiki.

  16245   Wed Jul 14 16:19:44 2021 gautamUpdateGeneralBrrr

Since the repair work, the temperature is significantly cooler. Surprisingly, even at the vertex (to be more specific, inside the PSL enclosure, which for the time being is the only place where we have a logged temperature sensor, but this is not attributable to any change in the HEPA speed), the temperature is a good 3 deg C cooler than it was before the HVAC work (even though Koji's wind vane suggest the vents at the vertex were working). The setpoint for the entire lab was modified? What should the setpoint even be?

Quote:
 

- I went to the south arm. There are two big vent ducts for the outlets and intakes. Both are not flowing the air.
  The current temp at 7pm was ~30degC. Max and min were 31degC and 18degC.

- Then I went to the vertex and the east arm. The outlets and intakes are flowing.

  16246   Wed Jul 14 19:21:44 2021 KojiUpdateGeneralBrrr

Jordan reported on Jun 18, 2021:
"HVAC tech came today, and replaced the thermostat and a coolant tube in the AC unit. It is working now and he left the thermostat set to 68F, which was what the old one was set to."

  11310   Tue May 19 14:51:44 2015 ericqUpdateModern ControlBrushing up on Wiener Filtering

As part of preparing for the SURF projects this summer, I grabbed ~50 minutes of MCL and STS_1 data from early this morning to do a little MISO wiener filtering. It was pretty straightforward to use the misofw.m code to achieve an offline subtraction factor of ~10 from 1-3Hz. This isn't the best ever, but doesn't compare so unfavorably to older work, especially given that I did no prefiltering, and didn't use all that long of a data stretch.

Code and plot (but not data) is attached. 

  11313   Tue May 19 17:53:38 2015 ranaUpdateModern ControlBrushing up on Wiener Filtering

Good to see that misofw.m is still alive and well. Todo:

  1. Apply weighting to the filter via time domain SOS prefiltering of the signals (see Jenne's code from the LLO Global FF paper)
  2. Consider using some of the MC SUSPOS signals. Its not strictly legal, but I wonder if its responsible for out noise below 1 Hz.
  3. Steve was in the midst of hooking up the Wilcoxones to get better subtraction at 5-15 Hz, but couldn't find cables. We need to hunt them down in W Bridge.
  4. Attach one of the medium or big Lings to the MC2 chamber platform and see if we can do this in hardware without driving the suspension. WE want to use a DAC channel (from where?) and pipe it to the Ling using a medium high current drive. Might start with the 50 Ohm output of the SR560 and later use a BUF634 ala Crackle coil driver.
  4418   Mon Mar 21 16:31:02 2011 steveUpdateSAFETYBryan Barr received safety training

Bryan Barr is visiting us from Glasgow for a month. He received 40m specific safety training on Friday.

  15991   Fri Apr 2 14:51:20 2021 AnchalUpdateSUSBug found, need to redo the balancing

Last run gave similar results as the quick run we did earlier. The code has been unable to strike out couplings with POS. We found the bug which is causing this. This was because the sampling rate of MC_F channel is different from the test-point channels used for PIT and YAW. Even though we were aware of it, we made an error in handling it while calculating CSD. Due to this, CSD calculation with POS data was performed by the code with zero padding which made it think that no PIT/YAW <-> POS coupling exist. blushHence our code was only able to fix PIT <-> YAW couplings.

We'll need to do another run with this bug fixed. I'll update this post with details of the new measurement.

 

  10754   Thu Dec 4 02:59:05 2014 ericqUpdateLSCBump in Darm Plant

[J,Q]

After some housekeeping (ASS is wonky, alignment of X green beat was bad, tuning of demod angles, fm gains for REFL165), we were able to bring the PRFPMI up to arm powers of 8 very stably. 

We were keeping an eye on the DARM OLG, to make sure the gain was correct. We then saw a bump around 120Hz. Here is the bump. 

Dec4_darmbump.pdf

Changing CARM offset changes its amplitude. Maybe it's a DARM optical spring. It didn't occur to me until after we lost lock that we could have tweaked the DARM offset to move it around if this was the case. 

Unfortunately, due to some unexplained locklosses, we weren't able to get back into a state to measure this more... which is annoying. During that stable lock, Jenne stated that PRCL and DARM noises were looking particularly good. 

We may want to tweak the way we handle the transmission PD handoff; maybe we want to force the switch at a certain place in the carm_up script, so that we're not flipping back and forth during an IR handoff; I think this may have been responsible for a lock loss or two. 

  10755   Thu Dec 4 03:09:06 2014 JenneUpdateLSCBump in Darm Plant: Lockloss after measurement

We were sitting around arm powers of 6, and that loop measurement had finished.  I was about to go down to arm powers of 5ish, but we lost lock.  I'm not sure why.  There's some slow stuff going on in some of the servos, but nothing jumps out at me as a loop oscillation.  It does however kind of look like the PRMI lost lock just before the arm powers went down?  Perhaps this somehow triggered a lockloss?

The time is 1101721675.

Wide view plots:

Arms6_3Dec2014_powers.png

Arms6_3Dec2014_errctrl.png

Arms6_3Dec2014_auxerr.png

Arms6_3Dec2014_angles.png

Zooms:

Arms6_3Dec2014_powers_Zoom.png

Arms6_3Dec2014_errctrl_Zoom.png

Arms6_3Dec2014_auxerr_Zoom.png

Arms6_3Dec2014_angles_Zoom.png


We're stopping for tonight because ETMX is back to its lame-o jumping around.  I went in and squished the cables, but it's still happening.

Also, the FSS PC drive has been high the last few minutes (only starting after we quit for the night).  When the MC re-locks, it sounds like an ocean wave dying out as the noise goes down a little bit.  But, after a few minutes, it'll get mad again and unlock the MC.

Also, also, I noticed this on Monday with Diego, but the LSC-ALS[x,y] filter module gains sometimes mysteriously get set to zero.  WTF?  Eric and I have both independently checked, and we cannot find a single script in the scripts directory with the string "LSC-ALS", so we aren't deliberately changing those.  Does anyone know what might be going on here?

  4528   Fri Apr 15 02:18:50 2011 KojiUpdateLSCBunch of RF cables removed

While Kiwamu was working on the RF cabling at the LSC rack, I removed 80% of SMA cables which were not connected anywhere.
The rack is cleaner now, but not perfect yet. We need patch panels/strain relieving for heliaxes, cleaning up of the RF/LO cables, etc.

  13899   Wed May 30 23:57:08 2018 gautamUpdatePEMBurning smell in office area / control room

[koji, gautam]

We noticed quite a strong burning smell in the office area and control room ~20mins ago. We did a round of the bake lab, 40m VEA and the perimeter of the CES building, and saw nothing burning. But the smell persists inside the office area/control room (although it may be getting less noticeable). There is a whining noise coming from the fan belt on top of the office area. Anyways, since nothing seems to be burning down, we are not investigating further.

Steve [ 10am 5-31 ] we should always check partical count in IFO room

Service requested 

 

  6634   Wed May 9 14:32:31 2012 JenneUpdateCDSBurt restored

Den and Alex left things not-burt restored, and Den mentioned to me that it might need doing.

I burt restored all of our epics.snaps to the 1am today snapshot.  We lost a few hours of striptool trends on the projector, but now they're back (things like the BLRMS don't work if the filters aren't engaged on the PEM model, so it makes sense).

  10026   Wed Jun 11 14:41:11 2014 JenneUpdateSUSBurt restored c1scxepics

ETMX had default 1's for gains, 0's for matrix elements, etc., so I did a burt restore to May 25th, 2pm, which was a few days before the Crash.  It looks fine now.

  4046   Mon Dec 13 17:18:47 2010 josephbUpdateCDSBurt updates

Problem:

Autoburt wouldn't restore settings for front ends on reboot

What was done:

First I moved the burt directory over to the new directory structure.

This involved moving /cvs/cds/caltech/burt/ to /opt/rtcds/caltech/c1/burt.

Then I updated the burt.cron file in the new location, /opt/rtcds/caltech/c1/burt/autoburt/.  This pointed to the new autoburt.pl script.

I created an autoburt directory in the /opt/rtcds/caltech/c1/scripts directory and placed the autoburt.pl script there.

I modified the autoburt.pl script so that it pointed to the new snapshot location.  I also modified it so it updates a directory called "latest" located in the /opt/rtcds/caltech/c1/burt/autoburt directory.  In there is a set of soft links to the latest autoburt backup.

Lastly, I edited the crontab on op340m (using crontab -e) to point to the new burt.cron file in the new location.

This was the easiest solution since the start script is just a simple bash script and I couldn't think of a quick and easy way to have it navigate the snapshots directory reliably.

I then modified the Makefile located in /opt/rtcds/caltech/c1/core/advLigoRTS/ which actually generates the start scripts, to point at the "latest" directory when doing restores.  Previously it had been pointing to /tmp/ which didn't really have anything in it.

So in the future, when building code, it should point to the correct snapshots now.  Using sed I modified all the existing start scripts to point to the latest directory when grabbing snapshots.

Future:

According to Keith directory documentation (see T1000248) , the burt restores should live in the individual target system directory i.e. /target/c1sus/burt, /target/c1lsc/burt, etc.  This is a distinctly different paradigm from what we've been using in the autoburt script, and would require a fairly extensive rewrite of that script to handle this properly.  For the moment I'm keeping the old style, everything in one directory by date.  It would probably be worth discussing if and how to move over to the new system.

  2459   Mon Dec 28 15:19:19 2009 AlbertoUpdateComputersBurtrestored to Dec 26 at 20:00

Since it wasn't sure whether all the front-ends had been restored after the bootfest, I burtrestored everything to Dec 26 at 20:00.

Always keep in mind that to burtrestore c1dcuepics, the snapshot file has to be modified by hand by moving the last quote up to the line before the last.

  3555   Thu Sep 9 18:53:56 2010 AlbertoConfigurationElectronicsBusby Box, Rai's Box, SR554 in the RF cabinet

I stored the Busby Box, the Rai's Box and the SR554 preamp in the RF cabinet down the Y arm.

  2286   Tue Nov 17 21:10:35 2009 ranaSummaryElectronicsBusby Low Noise Box: Photos and Upgrades

IMG_0217.JPG

It looked like the Busby Low Noise Box had too much low frequency noise and so I upgraded it. Here is a photo of the inside - I have changed out the 0.8 uF AC coupling cap with a big, white, 20 uF one I found on Rob's desk.

The Busby Box is still working well. The 9V batteries have only run down to 7.8V. The original designer also put a spare AD743 (ultra low current FET amp) and a OP27 (best for ~kOhm source impedances) in there.

Here's the noise after the fix. There's no change in the DC noise, but the AC noise is much lower than before:

busby-noise.png

I think that the AC coupled noise is higher because we are seeing the current noise of the opamp. In the DC coupled case, the impedance to ground from the input pins of the opamp is very low and so the current noise is irrelevant.

The change I implemented, puts in a corner frequency of fc = 1/2/pi/R/C = 1/2/pi/10e3/20e-6 = 0.8 Hz.

Overall, the box is pretty good. Not great in terms of current noise and so it misses getting an A+. But its easily a solid A-.

  11293   Sat May 16 20:37:09 2015 ranaHowToCDSBypassing the CDSUTILS prefix issue

The CDSUTILS package has a feature where it substitutes in a C1 or H1 or L1 prefix depending upon what site you are at. The idea is that this should make code portable between LLO and LHO.

Here at the 40m, we have no need to do that, so its better for us to be able to copy and paste channel names directly from MEDM or whatever without having to remove the "C1:" from all over the place.

the way to do this on the command line is (in bash) to type:

export IFO=''


To make this easier on us, I have implemented this in our shared .bashrc so that its always the case. This might break some scripts which have been adapted to use the weird CDSUTILS convention, so beware and fix appropriately.

  11302   Mon May 18 16:56:12 2015 ericqHowToCDSBypassing the CDSUTILS prefix issue
Quote:

export IFO=''

This makes things act weird:

controls@pianosa|MC 1> z avg 1 "C1:LSC-TRY_OUT"
IFO environment variable not specified.

  11304   Mon May 18 17:44:30 2015 ranaHowToCDSBypassing the CDSUTILS prefix issue

Too weird. I undid me changes. We'll have to make the C1: stuff work inside each python script.

Quote:
Quote:

export IFO=''

This makes things act weird:

controls@pianosa|MC 1> z avg 1 "C1:LSC-TRY_OUT"
IFO environment variable not specified.

 

  8672   Tue Jun 4 17:28:09 2013 AnnalisaUpdateLSCC1:ALS-TRY_OUT filter and green progress

 [Annalisa, Gautam, Rana]

I made the anti-whitening filter for the C1:ALS-TRY_OUT channel.

zpk [[150],[15],1] Hz

Now we can look at the picks of this signal to align the green into the cavity.

We already had some 00 flash, but a better alignment has to be done.

TO DO:

- put the shutter along the beam path

- check the polarization (we have a new PBS for visible)

 

  8674   Tue Jun 4 21:50:23 2013 AnnalisaUpdateLSCC1:ALS-TRY_OUT filter and green progress

 

 [Annalisa, Gautam]

 The green beam alignment has been improved, so we see much more 00 bright flashing. We checked the polarization and the Ygreen shutter is back in place.

A mirror is already in place to steer the rejected beam from the green Faraday into a PD, tomorrow morning we'll put a lens and the PD to take the signal for PDH locking.

 

  8677   Wed Jun 5 14:01:37 2013 ranaUpdateLSCC1:ALS-TRY_OUT filter and green progress

The rejected beam from this Faraday comes out at a tiny, tiny angle and so its tough to pick it off without clipping the main beam.

Some care must be taken in setting this up - Steve may have some good ideas on what kind of mount can be placed so close to the beam.

Why did we ever order this terrible Faraday? Let's never get a Faraday with a tiny angle between the beams again.

  8680   Wed Jun 5 15:03:42 2013 AnnalisaUpdateLSCC1:ALS-TRY_OUT filter and green progress

Quote:

The rejected beam from this Faraday comes out at a tiny, tiny angle and so its tough to pick it off without clipping the main beam.

Some care must be taken in setting this up - Steve may have some good ideas on what kind of mount can be placed so close to the beam.

Why did we ever order this terrible Faraday? Let's never get a Faraday with a tiny angle between the beams again.

The rejected beam from the Faraday is steered with a mirror into the PDA32A PD  and a 75mm fl lens is used to focus the beam into it.

The main beam is a few millimeters away from the mirror mount (maybe 2mm), and I think it should be fine as long as the main beam is not supposed to move.

 

  4961   Tue Jul 12 10:18:05 2011 JamieUpdateCDSC1:DAQ-FB0_C1???_STATUS indicators red, restored after controller restarts

Yesterday I found the C1:DAQ-FB0_C1???_STATUS lights to be red for the SUS, MCS, SCX, and SCY controllers.  I know this has something to do with model communication with the framebuilder, but I unfortunately don't remember exactly what it is.  I decided to try restarting the affected models to see if that cleared up the problem.  It did.  After restarting c1scx, c1scy, c1sus, and c1mcs everything came back up green.

We need some better documentation about what all of these status indicators mean.

  5006   Wed Jul 20 20:04:54 2011 JamieUpdateCDSC1:DAQ-FB0_C1XXX_STATUS sometimes unexplainably goes red

I have been noticing this happening occasionally, but I don't understand what is causing:

status-fb-red1.png

The channel in question above is C1:DAQ-FB0_C1SCX_STATUS.  This channel is (I believe) reporting some status of the front end model communication with the frame builder, but I'm not sure exactly what.

Usually this problem goes away when I restart the model or the frame builder, but it didn't work this time.  Tomorrow I will figure out what this channel means, why it's sporadically going red, and how to correct it.

  5901   Tue Nov 15 23:44:44 2011 MirkoUpdateCDSC1:LSC & C1:SUS restarted

Earlier this evening C1:LSC died then I hit the DAQ reload after adding an OAF channel to be recorded. No change to any model. Had to restart C1:SUS too. Reloaded burts from this morning 5am, except for C1:IOO, which I loaded from 16:07.

  4664   Mon May 9 12:33:40 2011 kiwamuUpdateLSCC1:LSC-TRIG_MTRX : wrong matrix size

I found that C1:LSC-TRIG_MTRX has a wrong matrix size. It needs to be fixed.

It is designed to have a 11x8 matrix in the simlink model file, but it's been compiled as a 6x8 matrix.

I recompiled c1lsc but it didn't fix the issue. Here below is the matrix statement in the C file :c1lsc.c. Indeed it is 6x8 matrix ....

// MuxMatrix:  LSC_TRIG_MTRX
for(ii=0;ii<8;ii++)
{
  lsc_trig_mtrx[ii] =
          pLocalEpics->lsc.LSC_TRIG_MTRX[ii][0] * lsc_imux_trigger[0] +
          pLocalEpics->lsc.LSC_TRIG_MTRX[ii][1] * lsc_imux_trigger[1] +
          pLocalEpics->lsc.LSC_TRIG_MTRX[ii][2] * lsc_imux_trigger[2] +
          pLocalEpics->lsc.LSC_TRIG_MTRX[ii][3] * lsc_imux_trigger[3] +
          pLocalEpics->lsc.LSC_TRIG_MTRX[ii][4] * lsc_imux_trigger[4] +
          pLocalEpics->lsc.LSC_TRIG_MTRX[ii][5] * lsc_imux_trigger[5];
 }

ELOG V3.1.3-