40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 305 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  6959   Wed Jul 11 11:18:21 2012 steveUpdatePEMmore seismic noise next week
 
   The fabricators of the big flume in the CES lab have begun testing the sediment feed system which is the noisiest component and plan to test off and on during the day for the next week.
   Please let me know if you detect the noise or have any issues.
 
 
Brian Fuller

phone: 626-395-2465

  6961   Wed Jul 11 13:45:01 2012 JenneUpdatePEMmore seismic noise next week

Quote:
 
   The fabricators of the big flume in the CES lab have begun testing the sediment feed system which is the noisiest component and plan to test off and on during the day for the next week.
   Please let me know if you detect the noise or have any issues.
 
 
Brian Fuller

phone: 626-395-2465

 Masha and Yaakov - this is an excellent opportunity for you guys to test out your triangulation stuff!  Also, it might give a lot of good data times for the learning algorithms.

Maybe you should also put out the 3 accelerometers that Yaakov isn't using (take them off their cube, so they can be placed separately), then you'll have 6 sensors for vertical motion.  Or you can leave the accelerometers as a cube, and have 4 3-axis sensors (3 seismometers + accelerometer set).

  12794   Fri Feb 3 11:03:06 2017 jamieUpdateCDSmore testing fb1; DAQ DOWN DURING TEST

More testing of fb1 today.  DAQ DOWN UNTIL FURTHER NOTICE.

Testing Wednesday did not resolve anything, but Jonathan Hanks is helping.

  10714   Fri Nov 14 08:25:29 2014 SteveUpdateSUSmorning issues

PRM, SRM and the ENDs are kicking up.  Computers are down.  PMC slider is stuck at low voltage.

Attachment 1: morning.png
morning.png
  9726   Fri Mar 14 09:44:34 2014 SteveUpdateLSCmorning lock
Attachment 1: 2hrsMorningLock.png
2hrsMorningLock.png
  13504   Fri Jan 5 17:50:47 2018 ranaConfigurationComputersmotif on nodus

I had to do 'sudo yum install motif' on nodus so that we could get libXm.so.4 so that we could run MEDM. Works now.

  12582   Thu Oct 27 09:38:32 2016 SteveUpdatePEMmouse

We may have a mouse in the lab.  Do not leave any food scrap in trash ! Traps will be set.

 

Attachment 1: mouse.jpg
mouse.jpg
  12605   Tue Nov 8 08:51:59 2016 SteveUpdatePEMmouse hole sealed

This is where the mammal came though. It is reach able from room 108 CES

Quote:

We may have a mouse in the lab.  Do not leave any food scrap in trash ! Traps will be set.

 

 

Attachment 1: CES108rs.jpg
CES108rs.jpg
  3646   Tue Oct 5 09:26:04 2010 steveConfigurationPEMmoved accelerometers

Accelerometers xyz were moved from IOO-south/west  corner to under PSL table. They were turned off for ~20 minutes.

Guralp was also moved eastward about 2 ft. It is not leveled.

This is part of the preparation to remove access connector.

  698   Fri Jul 18 19:30:20 2008 MashaUpdateAuxiliary lockingmoving from 40m
I will be working in the basement of Bridge probably starting next week; I moved the NPRO laser and some of the optics from my mach zehnder setup on the SP table to Bridge. Thanks for your help!
  2182   Thu Nov 5 16:30:56 2009 peteUpdateComputersmoving megatron

 Joe and I moved megatron and its associated IO chassis from 1Y3 to 1Y9, in preparations for RCG tests at ETMY.

  12521   Wed Sep 28 04:27:33 2016 ericqUpdateGeneralmucking about

PMC was terribly misaligned. The PMCR camera seems to have drifted somewhat off target too, but I didn't touch it.

Realigned ITMX for the nth time today.

Finding ALSY beatnote was easy, ALSX eludes me. I did a rough one-point realignment on the X beat PD which is usually enough, but it's probably been long enough that near/far field alignmnet is neccesary. 

ALSY noise is mostly nominal, but there is a large 3Hz peak that is visible in the spot motion, and also modulates the beat amplitude by multiple dBs.

It looked to me that the ETMY oplev spot was moving too much, which led me to measure the oplev OLGs. There is some wierd inter-loop interference going on between OLPIT and OLYAW. With both on (whether OSEM damping is on or off, so input matrix shenanigans can't be to blame) there is a very shallow "notch" at around 4.5Hz, which leads to very little phase at 3Hz, and thus tons of control noise. Turning the OL loop not being measured off makes this dip go away, but the overall phase is still signfinicantly less than we should have. I'm not sure why. I'll just show the PIT plot, but things look pretty much the same for YAW. 


I did some more ETMX tests. Locked arm, raised the servo output limit to 15k, then increased the gain to make the loop unstable. I saw the SUS LSC signals go up to tens of thousands of counts when the unlock happened. I did this a dozen times or so, and every time the ETM settled in the same angular position according to the oplev.

Right now, another hysteresis script is running, misaliging in pitch and yaw. Amplitude 1V in each direction. So far, everything is stable after three on/off cycles.

Attachment 1: alscheck.pdf
alscheck.pdf
Attachment 2: weird_olpit.pdf
weird_olpit.pdf
  12522   Thu Sep 29 09:49:53 2016 ranaUpdateGeneralmucking about

With the WFS and OL, we never have figured out a good way to separate pit and yaw. Need to figure out a reference for up/down and then align everything to it: quad matrix + SUS output matrix

  12527   Sat Oct 1 10:03:28 2016 ericqUpdateGeneralmucking about

Some things I did last night:

I measured the X PDH OLG, and turned the gain down by ~6dB to bring the UGF back to 10kHz, ~50deg phase margin, 10dB gain margin. However, the error signal on the oscilloscope remained pretty ratty. Zooming in, it was dominated by glitches occuring at 120Hz. I went to hook up the SR785 to the control signal monitor to see what the spectrum of these glitches looked like, but weirdly enough connecting the SR785's input made the glitches go away. In fact, with one end of a BNC connector plugged into a floating SR785 input, touching the other end's shield to any of the BNC shields on the uPDH chassis made the glitches go away.

This suggested some ground loop shenanigans to me; everything in the little green PDH shelves is plugged into a power strip which is itself plugged into a power strip at the X end electronics rack, behind all of the sorensens. I tried plugging the power strip into some different places (including over by the chamber where the laser and green refl PD are powered), but nothing made the glitches go away. In fact, it often resulted in being unable to lock the PDH loop for unknown reasons. This remains unsolved.

As Gautam and Johannes observed, the X green beat was puny. By hooking up a fast scope directly to the beat PD output, I was able to fine tune the alignment to get a 80mVpp beat, which I think is substaintially bigger than what we used to have. (Is this plus the PDH gain changed really attributable to arm loss reduction? Hm)

However, the DFD I and Q outputs have intermittent glitches that are big enough to saturate the ADC when the whitening filters are on, even with 0dB whitening gain, which makes it hard to see any real ALS noise above a few tens of Hz or so. Turning off the whitening and cranking up the whitening gain still shows a reasonably elevated spectrum from the glitches. (I left a DTT instance with a spectrum on in on the desktop, but forgot to export...) The glitches are not uniformly spaced at 120Hz as in the PDH error signal. However, the transmitted green power also showed intermittant quick drops. This also remains unsolved for the time being. 

  12529   Tue Oct 4 02:59:48 2016 ericqUpdateGeneralmucking about

[ericq, gautam]

We poked around trying to figure out the X PDH situation. In brief, the glitchiness comes and goes, not sure what causes it. Tried temp servo on/off and flow bench fan on/off. Gautam placed a PD to pick off the pre-doubler AUX X IR light to see if there is some intermittant intensity fluctuation overnight. During non-glitchy times, ALSX noise profile doesn't look too crazy, but some new peak around 80Hz and somewhat elevated noise compared to historical levels above 100Hz. It's all coherent with the PDH control up there though, and still looks like smooth frequency noise...

NB: The IR intensity monitoring PD is temporarily using the high gain Transmon PD ADC channel, and is thus the source of the signal at C1:LSC-TRY_OUT_DQ. If you want to IR lock the X arm, you must change the transmon PD triggering to use the QPD.

Attachment 1: 2016-10-04_ALSXspectra.pdf
2016-10-04_ALSXspectra.pdf
  2294   Wed Nov 18 16:58:36 2009 kiwamuUpdateElectronicsmulti-resonant EOM --- EOM characterization ---

In designing the whole circuit it is better to know the characteristic of the EOM.

I made impedance measurement with the EOM (New Focus model 4064) and I found it has capacitance of 10pF.

This is good agreement with the data sheet which says "5-10pF".

The measured plot is attached below. For comparison there also plotted "open" and "10pF mica".

In the interested band( from 1MHz to 100MHz), EOM looks just a capacitor.

But indeed it has lead inductance of 12nH, resistance of 0.74[Ohm], and parasitic capacitance of 5.5pF.

In some case we have to take account of those parasites in designing.

EOM_impedance.png

 

  2295   Wed Nov 18 22:38:17 2009 KojiUpdateElectronicsmulti-resonant EOM --- EOM characterization ---

How can I get those values from the figure?

Quote:

But indeed it has lead inductance of 12nH, resistance of 0.74[Ohm], and parasitic capacitance of 5.5pF. 

 

  2292   Wed Nov 18 14:55:59 2009 kiwamuUpdateElectronicsmulti-resonant EOM --- circuit design ----

The circuit design of multi-resonant EOM have proceeded.

By using numerical method, I found the some best choice of the parameters (capacitors and inductors).

In fact there are 6 parameters (Lp, L1, L2, Cp, C1, C2) in the circuit to be determined.

whole_circuit.png

In general the less parameter gives the less calculation time with performing the numerical analysis. Of course it looks 6 parameters are little bit large number.

In order to reduce the arbitrary parameters, I put 4 boundary conditions.

Each boundary conditions fixed resonant peaks and valleys; first peak=11MHz, third peak=55MHz, first valley=19MHz, second valley=44MHz.

designed.png

So now the remaining arbitrary parameters successfully get reduced to 2. Only we have to do is optimize the second peak as it to be 29.5MHz.

Then I take C1 and C2 as free parameters seeing how the second peak agree with 29.5MHz by changing the value of the C1 and C2.

mont.png

the red color represents the good agreement with 29.5MHz, in contrast blue contour represents the bad.

 You can see some best choice along the yellow belt. Now what we should do is to examine some of that and to select one of those.

  2263   Fri Nov 13 05:03:09 2009 kiwamuUpdateElectronicsmulti-resonant EOM --- input impedance of LC tank ----

I measured the input impedance of the LC tank circuit with the transformer. The result is attached.

It looks interesting because the input impedance is almost dominated

by the primary coil of the transformer with inductance of 75nH (see attachment 1).

The impedance at the resonance is ~100 [Ohm], I think this number is quite reasonable because I expected that as 93 [Ohm]

 

Note that the input impedance can be derived as follower;

(input impedance) = L1 + Z/n^2.

Where L1 is the inductance of the primary coil, Z is the load in the secondary loop and n is the turn ratio.

 

I think now I am getting ready to enter the next phase \(^o^)/

Attachment 1: input_impedance.png
input_impedance.png
Attachment 2: input_impedance2.png
input_impedance2.png
  2262   Fri Nov 13 03:38:47 2009 kiwamuUpdateElectronicsmulti-resonant EOM --- impedance of LC tank circuit ----

I have measured the impedance of the LC tank circuit which I referred on my last entry.

The configuration of the circuit is exactly the same as that time.

In order to observe the impedance, by using Koji's technique I injected a RF signal into the output of the resonant circuit.

In addition I left the input opened, therefore the measured impedance does not include the effect of the transformer.

 

- - - - - - - - - - - - results

The measured impedance is attached below; "LCtank_impedance.png"

The peak around 50MHz is the main resonance and it has impedance of ~1500 [Ohm], which should go to infinity in the ideal case (no losses).

In fact the impedance looked from the input of the circuit gets reduced by 1/n^2, where "n" is the turn ratio of the transformer.

By putting the n=4, the input impedance of the circuit should be 93 [Ohm]. This is a moderate value we can easily perform impedance-matching by some technique.

I also fitted the data with a standard model of equivalent circuit (see attachment 2).

In the figure.2 red component and red letter represents the design. All the other black stuff are parasites.

But right now I have no idea the fitted value is reasonable or not.

For the next I should check the input impedance again by the direct way; putting the signal into the input.

 

 

 

Attachment 1: LCtank_impedance.png
LCtank_impedance.png
Attachment 2: LCtank_model.png
LCtank_model.png
  346   Thu Feb 28 19:37:41 2008 robConfigurationComputersmultiple cameras running and seisBLRMS

Quote:
1) Mafalda is now connected via an orange Cat5E ethernet cord to the gigabit ethernet switch in rack in the office space. It has been labeled at both ends with "mafalda".

2) Both the GC650M camera (from MIT) and the GC750M are working. I can run the sampleviewer code and get images simultaneously. Unforutnately, the fps on both cameras seems to drop roughly in half (not an exact measurement) when displaying both simultaneously at full resolution.

3)Discovered the Gigabit ethernet card in Mafalda doesn't support jumbo packets (packets of up to 9k bytes), which is what they recommend for optimum speed.

4)However, connecting the cameras through only gigabit switches to Mafalda did seem to increase the data rate anyways, roughly by a factor of 2. (Used to take about 80 seconds to get 1000 frames saved, now takes roughly 40 seconds).

5)Need to determine the bottleneck on the cameras. It may be the ethernet card, although its possible to connect multiple gigabit cards to single computer (depending on the number of PCI slots it has). Given the ethernet cards are cheap ($300 for 20) compared to even a single camera (~$800-1500), it might be worth while outfitting a computer with multiple.


I found the SampleViewer running and displaying images from the two cameras. This kept mafalda's network so busy that the seisBLRMS program fell behind by a half-hour from its nominal delay (so 45 minutes instead of 12), and was probably getting steadily further behind. I killed the SampleViewer display on linux2, and seisBLRMS is catching up.
  6152   Tue Dec 27 22:17:56 2011 kiwamuUpdateLSCmultiple-LOCKIN new screens

Some new screens have been made for the new multiple-LOCKIN system running on the LSC realtime controller.

The medm screens are not so pretty because I didn't spend so long time for it, but it is fine for doing some actual measurements with those new screens.

So the basic works for installing the multiple-LOCKIN are done.

 

 The attached figure is a screen shot of the LOCKIN overview window.

As usual most of the components shown in the screen are clickable and one can go to deeper levels by clicking them. 

Untitled.png

Quote from #6150
The multiple LOCKIN module has been newly added on the LSC realtime model.
I will make some MEDM screens for this multiple-LOCKIN system.

  6150   Mon Dec 26 14:01:45 2011 kiwamuUpdateLSCmultiple-LOCKIN newly added
The multiple LOCKIN module has been newly added on the LSC realtime model.
The purpose is to demodulate ALL the LSC sensors at once while a particular DOF is excited by an oscillator.
So far the model has been successfully compiled and running okay.
I will make some MEDM screens for this multiple-LOCKIN system.
 

(Some details)

The picture below is a screen shot of the LSC real time model, zoomed in the new LOCKIN part.

multiple-lockin.png

The LOCKIN module consists of three big components:

  1. A Master oscillator
    • This shakes a desired DOF through the LSC output matrix and provides each demodulator with sine and cosine local oscillator signals.
    • This part is shown in the upper side of the screen shot.
    • The sine and cosine local oscillator signals appear as red and blue tags respectively in the screen shot.
  2. An input matrix
    • To allow us to select the signals that we want to demodulate.
    • This is shown in the left hand side of the screen shot.
  3. Demodulators
    • These demodulators demodulate the LSC sensor signals by the sine and cosine signals provided from the master oscillator.
    • With the input matrix fully diagonalized, one can demodulate all the LSC signals at once.
    • The number of demodulators is 27, which corresponds to that of available LSC error signals (e.g. AS55_I, AS55_Q, and etc.).
    • This part is shown in the middle of the screen shot.
  7457   Mon Oct 1 16:05:01 2012 jamieUpdateCDSmx stream restart required on all front ends

For some reason the frame builder and mx stream processes on ALL front ends were down.  I restarted the frame builder and all the mx_stream processes and everything seems to be back to normal.  Unclear what caused this.  The CDS guys are aware of the issue with the mx_stream stability and are working on it.

  11103   Thu Mar 5 19:13:17 2015 ranaUpdateCDSmxStream all restart at ~7:10 pm
  6609   Sun May 6 00:11:00 2012 DenUpdateCDSmx_stream

c1sus and c1iscex computers could not connect to framebuilder, I restarted it, did not help. Then I restarted mx_stream daemon on each of the computers and this fixed the problem.

sudo /etc/init.d/mx_stream restart

  9825   Thu Apr 17 17:15:54 2014 jamieUpdateCDSmx_stream not starting on c1ioo

While trying to get dolphin working on c1ioo, the c1ioo mx_stream processes mysteriously stopped working.  The mx_stream process itself just won't start now.  I have no idea why, or what could have happened to cause this change.  I was working on PCIe dolphin stuff, but have since backed out everything that I had done, and still the c1ioo mx_stream process will not start.

mx_stream relies on the open-mx kernel module, but that appears to be fine:

controls@c1ioo ~ 0$ /opt/open-mx/bin/omx_info  
Open-MX version 1.3.901
 build: root@fb:/root/open-mx-1.3.901 Wed Feb 23 11:13:17 PST 2011

Found 1 boards (32 max) supporting 32 endpoints each:
 c1ioo:0 (board #0 name eth1 addr 00:14:4f:40:64:25)
   managed by driver 'e1000'
   attached to numa node 0

Peer table is ready, mapper is 00:30:48:d6:11:17
================================================
  0) 00:14:4f:40:64:25 c1ioo:0
  1) 00:30:48:d6:11:17 c1iscey:0
  2) 00:25:90:0d:75:bb c1sus:0
  3) 00:30:48:be:11:5d c1iscex:0
  4) 00:30:48:bf:69:4f c1lsc:0
controls@c1ioo ~ 0$ 

However, if trying to start mx_stream now fails:

controls@c1ioo ~ 0$ /opt/rtcds/caltech/c1/target/fb/mx_stream -s c1x03 c1ioo c1als -d fb:0
c1x03
mmapped address is 0x7f885f576000
mapped at 0x7f885f576000
send len = 263596
OMX: Failed to find peer index of board 00:00:00:00:00:00 (Peer Not Found in the Table)
mx_connect failed
controls@c1ioo ~ 1$ 

I'm not quite sure how to interpret this error message.  The "00:00:00:00:00:00" has the form of a 48-bit MAC address that would be used for a hardware identifier, ala the second column of the OMC "peer table" above, although of course all zeros is not an actual address.  So there's some disconnect between mx_stream and the actually omx configuration stuff that's running underneath.

Again, I have no idea what happened.  I spoke to Rolf and he's going to try to help sort this out tomorrow.

Attachment 1: c1ioo_no_mx_stream.png
c1ioo_no_mx_stream.png
  9830   Fri Apr 18 14:00:48 2014 rolfUpdateCDSmx_stream not starting on c1ioo

 

 To fix open-mx connection to c1ioo, had to restart the mx mapper on fb machine. Command is /opt/mx/sbin/mx_start_mapper, to be run as root. Once this was done, omx_info on c1ioo computer showed fb:0 in the table and mx_stream started back up on its own. 

  9831   Fri Apr 18 19:05:17 2014 jamieUpdateCDSmx_stream not starting on c1ioo

Quote:

To fix open-mx connection to c1ioo, had to restart the mx mapper on fb machine. Command is /opt/mx/sbin/mx_start_mapper, to be run as root. Once this was done, omx_info on c1ioo computer showed fb:0 in the table and mx_stream started back up on its own. 

Thanks so much Rolf (and Keith)!

  9826   Thu Apr 17 17:22:32 2014 JenneUpdateCDSmx_stream not starting on c1ioo, locking okay

Jamie tells me that the 2 big consequences of this are (a) we are not archiving any data that is collected on the ioo machine, and (b) that we will not have access to test points on the IOO or ALS models.

To make sure that this is not a show-stopper for locking, I have locked the arms using ALS.  The signals seem to still be getting from the ALS model to the LSC model, and I'm able to acquire ALS lock, so we should be able to work tonight.  All of the data that I have been looking at lately has been coming off of the LSC machine, so we should even be okay in terms of look-back for lockloss studies, etc.

 

  6778   Thu Jun 7 03:37:26 2012 yutaUpdateCDSmx_stream restarted on c1lsc, c1ioo

c1lsc and c1ioo computers had FB net statuses all red. So, I restarted mx_stream on each computer.

ssh controls@c1lsc
sudo /etc/init.d/mx_stream restart

  6761   Wed Jun 6 00:37:11 2012 JenneUpdateComputersmx_stream restarted on iscey, sus

Just as Yuta and I were sitting down to look at our beatnote (really the output of the freq discriminator) on Dataviewer, all the FB net boxes on the CDS status screen were white.  I restarted daqd, and most of the computers came back fine.  c1iscey and c1sus still had some red bad boxes.  So I restarted mx_stream on both, and they are now fine.

Somehow, this also fixed whatever I had done to the lsc model yesterday (although I think TRY is still not recorded at this time - not messing with it yet).

  7612   Wed Oct 24 19:55:06 2012 jamieUpdate my assesment of the folding mirror (passive tip-tilt) situation

We removed all the folding mirrors ({P,S}R{2,3}) from the IFO and took them into the bake lab clean room.  The idea was that at the very least we would install the new dichroic mirrors, and then maybe replace the suspension wires with thinner ones.

I went in to spend some quality time with one of the tip-tilts.  I got the oplev setup working to characterize the pointing.

I grabbed tip-tilt SN003, which was at PR2.  When I set it up it  was already pointing down by a couple cm over about a meter, which is worse than what we were seeing when it was installed.  I assume it got jostled during transport to the clean room?

I removed the optic that was in there and tried installing one of the dichroics.  It was essentially not possible to remove the optic without bending the wires by quite a bit (~45 degrees).  I decided to remove the whole suspension system (top clamps and mirror assembly) so that I could lay it flat on the table to swap the optic.

I was able to put in the dichroic without much trouble and get the suspension assembly back on to the frame.  I adjusted the clamp at the mirror mount to get it hanging back vertical again.  I was able to get it more-or-less vertical without too much trouble.

I poked at the mirror mount a bit to see how I could affect the hysteresis.  The answer is quite a bit, and stochastically.  Some times I would man-handle it and it wouldn't move at all.  Sometimes I would poke it just a bit and it would move by something like a radian.

A couple of other things I noted:

  • The eddy current damping blocks are not at all suspended.  The wires are way too think, so they're basically flexures.  They were all pretty cocked, so I repositioned them by just pushing on them so they were all aligned and centered on the mirror mount magnets.
  • The mirror mounts are very clearly purposely made to be light.  All mass that could be milled out has been.  This is very confusing to me, since this is basically the entire problem.  Why were they designed to be so light?  What problem was that supposed to solve?

I also investigated the weights that Steve baked.  These won't work at all.  The gap between the bottom of the mirror mount and the base is too small.  Even the smalled "weights" would hit the base.  So that whole solution is a no-go.

What else can we do?

At this point not much.  We're not going to be able to install more masses without re-engineering things, which is going to take too much time.  We could install thinner wires.  The wires that are being used now are all 0.0036", and we could install 0.0017" wires.  The problem is that we would have to mill down the clamps in order to reuse them, which would be time consuming.

The plan

So at this point I say we just install the dichroics, get them nicely suspended, and then VERY CAREFULLY reinstall them.  We have to be careful we don't jostle them too much when we transport them back to the IFO.  They look like they were too jostled when they were transported to the clean room.

My big question right now is: is the plan to install new dichroics in PR2 and SR2 as well, or just in PR3 and SR3, where the green beams are extracted?  I think the answer is no, we only want to install new dichroics in {P,S}R3.

The future

If we're going to stick with these passive tip-tilts, I think we need to consider machining completely new mirror mounts, that are not designed to be so light.  I think that's basically the only way we're going to solve the hysteresis problem.

I also note that the new active tip-tilts that we're going to use for the IO steering mirrors are going to have all the same problems.  The frame is taller, so the suspensions are longer, but everything else, including the mirror mounts are exactly the same.  I can't see that they're not going to suffer the same issues.  Luckily we'll be able to point them so I guess we won't notice.

  7617   Thu Oct 25 02:10:22 2012 KojiUpdate my assesment of the folding mirror (passive tip-tilt) situation

The thinner wire has a history that it did not improve the hysteresis (ask Jenne). Nevertheless, it's worth to try.

If you flip the clamp upside-down, you can lift the clamping point up. This will make the gravity restoring torque stronger.
(i.e. Equivalent effect to increasing the mass)

Luckily (or unluckily) the clamp has no defined location for the wire as we have no wire fixture.
Therefore the clamp will grab the wire firmly even without milling.

  7618   Thu Oct 25 06:49:49 2012 KojiUpdate my assesment of the folding mirror (passive tip-tilt) situation

Quote:

My big question right now is: is the plan to install new dichroics in PR2 and SR2 as well, or just in PR3 and SR3, where the green beams are extracted?  I think the answer is no, we only want to install new dichroics in {P,S}R3.

 Why not? The new dichroic mirrors have more transmission of 1064nm than G&H. Thus it will give us more POP beam and will help locking.

  7619   Thu Oct 25 08:04:45 2012 SteveUpdateSUSmy assesment of the folding mirror (passive tip-tilt) situation

Quote:

The thinner wire has a history that it did not improve the hysteresis (ask Jenne). Nevertheless, it's worth to try.

If you flip the clamp upside-down, you can lift the clamping point up. This will make the gravity restoring torque stronger.
(i.e. Equivalent effect to increasing the mass)

Luckily (or unluckily) the clamp has no defined location for the wire as we have no wire fixture.
Therefore the clamp will grab the wire firmly even without milling.

 The wire clamps should be taken off at the top and at the mirror holder. They need a mill touch up. It would be nice to have the centering jig from LLO for the 0.0017"

The clamps in this condition are really bad. It can sleep, it is not adjustable.

 

Attachment 1: IMG_1748.JPG
IMG_1748.JPG
  6810   Wed Jun 13 02:11:59 2012 yutaUpdateGreen Lockingmy first modescan (sort of)

I stabilized Y arm length by using only I phase coarse signal from the beat(C1:ALS-BEATY_COARSE_I_ERR).
I sweeped the arm length by injecting 0.05Hz sine wave from C1:ALS_OFFSETTER2_EXC.
Below is the plot of TRY and the error signal(ideally, Y arm length) while the sweep.

modescan20120612_1.png

I couldn't hold the arm length tight, so you can see multiple peaks close to each other.
We need to
  - adjust offsets
  - adjust rotation phase of I-Q mixing
  - adjust servo filters

to hold the length tighter.

Also, I couldn't sweep the Y arm length very much. I need to calibrate, but to do the modescan for many FSRs, we need to
  - introduce automatic phase optimizing system
There were sin/cos function in the CDS_PARTS, so I think we can feedback I_ERR to control rotation phase of I-Q mixing.

  6811   Wed Jun 13 02:24:02 2012 ranaUpdateGreen Lockingmy first modescan (sort of)

 That sounds goofy.

With the delay line technique, you can get a linear signal over 50 MHz with no phase shifting. What is with all this I/Q stuff?

  6812   Wed Jun 13 03:03:38 2012 yutaUpdateGreen Lockingmy first modescan (sort of)

Linear range df of the delay line technique is about df ~ c/(2D). So, the linear range for the fine signal(delay line length D=30m) is about 5 MHz.
Arm cavity FSR = c/(2L) = 3.7 MHz.
So, I think we need phase shifting to do mode scan for more than 2 FSRs by holding the arm length finely with fine servo.
For the coarse (D=1.5m), the linear range is about 100 MHz, so if we can do mode scan using coarse servo, it is OK.

In any case, I think it is nice to have linear signal with fixed slope even if we don't adjust the phase every time.

Quote:

 That sounds goofy.

With the delay line technique, you can get a linear signal over 50 MHz with no phase shifting. What is with all this I/Q stuff?

 

  6813   Wed Jun 13 11:10:56 2012 ranaUpdateGreen Lockingmy first modescan (sort of)

You can easily calculate whether or not the coarse readout will work by thinking about the scan resolution you need given the ADC dynamic range and the whitening filter that you use.

  559   Tue Jun 24 22:31:10 2008 MashaUpdateAuxiliary lockingmy first step in fiber stabilization
There is a new 1W INNOLIGHT NPRO laser at the Symmetric Port.

Set up an interferometer to measure difference in phase noise introduced by a fiber. Works as expected without the fiber! (balanced intensity, out of phase noise in the two outputs).
  6071   Mon Dec 5 17:44:41 2011 kiwamuUpdateGeneralmy plan tonight

I am going to try handing off the ALS servo to the IR PDH servo on the Y arm and measure the noise.

 - first I need to investigate why the Y end PDH servo becomes unstable when the ALS is engaged with a high UGF.

 

(some notes)

 So far I still kept failing to increase the UGF of the ALS servo for some reason (see #6024).

Every time when I increased the UGF more then 50 Hz, the Y arm PDH lock became unlocked. It needs an explanation and a solution.

Another thing: During several trials in this evening I found the ETMY_SUSPOS_GAIN had been set to 1, so I reset it to 20, which gives us the damping Q of about 5.

 

(Temperature feedback activated)

 As planed in #6024 I have activated the temperature feedback, so that the PZT control signal is offloaded to the temperature. And it seems working fine.

Currently the gain is set to 0.03, which gives us a time constant of ~30 sec for offloading the control signal.

  7161   Mon Aug 13 16:58:07 2012 jamieUpdateCDSmysterious stuck test points on c1spx model

We were not able to open up any test points in the revived c1spx model (dcuid 61).

Looking at the GDS_TP screen we found that every test point was being held open (C1:FEC-61_GDS_MON_?).  Tried closing all test points, awg and otherwise, with the diag comnand line (diag -l), but it would crash when we attempted to look at the test points for node 61.

Rebuild, install, restart of the model had no affect.  As soon as awgtpman came back up all the testpoints were full again.

I called Alex and he said he had seen this issue before as a problem with the mbuf kernel module.  Somehow the mbuf module was holding those memory locations open and not freeing them.

He suggested we reboot the machine or restart mbuf.  I used the following procedure to restart mbuf:

  • log into c1iscex as controls
  • sudo /etc/init.d/monit stop (needed so that monit doesn't auto-restart the awgtpman processes)
  • rtcds stop all
  • sudo /etc/init.d/mx_stream stop
  • sudo rmmod mbuf
  • sudo modprobe mbuf
  • sudo /etc/init.d/mx_stream start
  • sudo /etc/init.d/monit start
  • rtcds start all

Once this was done, all the test points were cleared.

Alex seems to think this issue is fixed in a newer version of mbuf.  I should probably rebuild and install the updated mbuf kernel module at some point soon to prevent this happening again.

Unfortunately this isn't the end of the story, though.  While the test points were cleared, the channels were still not available from c1spx.

I looked in the framebuilder logs to see if I could see anything suspicious.  Grep'ing for the DCUID (61), I found something that looked a little problematic:

...
GDS server NODE=25 HOST=c1iscex DCUID=61
GDS server NODE=28 HOST=c1ioo DCUID=28
GDS server NODE=33 HOST=c1ioo DCUID=33
GDS server NODE=34 HOST=c1ioo DCUID=34
GDS server NODE=36 HOST=c1sus DCUID=36
GDS server NODE=38 HOST=c1sus DCUID=38
GDS server NODE=39 HOST=c1sus DCUID=39
GDS server NODE=40 HOST=c1lsc DCUID=40
GDS server NODE=42 HOST=c1lsc DCUID=42
GDS server NODE=45 HOST=c1iscex DCUID=45
GDS server NODE=46 HOST=c1iscey DCUID=46
GDS server NODE=47 HOST=c1iscey DCUID=47
GDS server NODE=48 HOST=c1lsc DCUID=48
GDS server NODE=50 HOST=c1lsc DCUID=50
GDS server NODE=60 HOST=c1lsc DCUID=60
GDS server NODE=61 HOST=c1iscex DCUID=61
...

Note that two nodes, 25 and 61, are associated with the same dcuid.  25 was the old dcuid of c1spx, before I renumbered it.  I tracked this down to the target/gds/param/testpoint.par file which had the following:

[C-node25]
hostname=c1iscex
system=c1spx
...
[C-node61]
hostname=c1iscex
system=c1spx

It appears that this file is just amended with new dcuids, so dcuid changes can show up in duplicate.  I removed the offending old stanza and tried restarting fb again...

Unfortunately this didn't fix the issue either.  We're still not seeing any channels for c1spx.

  7162   Mon Aug 13 17:31:19 2012 jamieUpdateCDSmysterious stuck test points on c1spx model

Quote:

Unfortunately this didn't fix the issue either.  We're still not seeing any channels for c1spx.

So I was wrong, the channels are showing up.  I had forgotten that they are showing up under C1SUP, not C1SPX.

  4384   Tue Mar 8 14:50:19 2011 kiwamuUpdateCDSnames for filter modules

[Joe/Kiwamu]

 We found there are some filter names that we can not properly build for some reason.

The following names are not properly going to be built :

 - REFL_DC

 - AUX

If we use the names shown above for filters, it doesn't compile any filter modules.

We took a quick look around the src files including feCodegen.pl, but didn't find any obvious bugs.

  3308   Wed Jul 28 12:53:32 2010 channaUpdateComputersnds data listener

For the sake of writing it down: /cvs/cds/caltech/apps/linux64/rockNDS

  9216   Mon Oct 7 18:32:01 2013 John ZweizigSummaryComputer Scripts / Programsnds2 installed, restarted

The upgrade of megatron broke the nds2 service. I have fixed things by

  1) installing the latest version of framecpp (1.19.32) from the lsc debian repository (this was necessary because I couldn't link to the existing version)

  2) built nds2-server-0.5.11 and installed it in the system directories (/usr/bin)

  3) there were a few scripts/links/etc that didn't seem to be set up correctly and I fixed them to correspond with my preious message.

 nds2 is now running and the channel list should be updated regularly and the service restarted as appropriate.

 

  3718   Thu Oct 14 13:09:01 2010 Leo SingerConfigurationComputersnds2-client-devel installed on rossa

I installed nds2-client-devel on rossa using the following command:

$ sudo yum install nds2-client-devel

  15716   Tue Dec 8 15:07:13 2020 gautamUpdateComputer Scripts / Programsndscope updated

I updated the ndscope on rossa to a bleeding edge version (0.7.9+dev0) which has many of the fixes I've requested in recent times (e.g. direct PDF export, see Attachment #1). As usual if you find issue, report it on the issue tracker. The basic functionality for looking at signals seems to be okay so this shouldn't adversely impact locking efforts.


In hindsight - I decided to roll-back to 0.7.9, and have the bleeding edge as a separate binary. So if you call ndscope from the command line, you should still get 0.7.9 and not the bleeding edge.

Attachment 1: test.pdf
test.pdf
  500   Tue May 27 16:24:54 2008 tobinConfigurationComputer Scripts / Programsndsproxy
The NDS Proxy is a program that accepts NDS (LIGO Network Data Server) connections from the internet and relays them to
our internal frame-builder, so that you can get DAQ and test-point channel data from off-site.

I stopped the ndsproxy that was running on rana and started it on nodus, its new home. This will be
documented in the wiki.

So far I haven't found a mechanism by which the ndsproxy was restarted automatically on rana. Has it just been
restarted by hand?

The ndsproxy stuff lives in target/ndsproxy. Restarting it seems to be just a matter of running "start_ndsproxy" in
that directory.
ELOG V3.1.3-