40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 121 of 344  Not logged in ELOG logo
ID Date Author Type Category Subject
  11260   Mon Apr 27 14:37:55 2015 SteveUpdateVACN2 pneumatic pressure watch

 

Quote:

Based on Jenne's chiara disk usage monitoring script, I made a script that checks the N2 pressure, which will send an email to myself, Jenne, Rana, Koji, and Steve, should the pressure fall below 60psi. I also updated the chiara disk checking script to work on the new Nodus setup. I tested the two, only emailing myself, and they appear to work as expected. 

The scripts are committed to the svn. Nodus' crontab now includes these two scripts, as well as the crontab backup script. (It occurs to me that the crontab backup script could be a little smarter, only backing it up if a change is made, but the archive is only a few MB, so it's probably not so important...)

This watch script gives little time to replace N2 cylinder. When the regulated supply drops below 60 psi the cylinder pressure is 60 psi too.

It is more of a statement that V1 is closed and act accordingly. It's only practical if you are in the lab.

Rana pointed it out correctly that we need this message 24 hrs before it happens. This requires monitoring  of total supplies , not the regulated one.

So we need pressure transducers on each nitrogen cylinder, before the regulator. The sum of the two N2 cylinder when they are full 4000 - 4500 psi

The first email should be send out at 1000 psi as sum of the two cylinders. This means that you have  1 day to replace nitrogen cylinder.

 Most of the time the daily consumption is 750 +-50 psi   

However sometimes  this variation goes up   ~750 +-150 psi

  11259   Mon Apr 27 09:09:15 2015 SteveUpdatePEMair cond filters checked

 

Quote:

 

Quote:

Yesterday morning was dusty. I wonder why?

The PRM sus damping was restored this morning.

Yesterday afternoon at 4 the dust count peaked 70,000 counts

Manasa's alergy was bad at the X-end yesterday. What is going on?

There was no wind and CES neighbors did not do anything.

Air cond filters checked by Chris. The 400 days plot show 3 bad peaks at 1-20, 2-5 & 2-19

Attachment 1: 400d.png
400d.png
  11258   Mon Apr 27 01:13:08 2015 JenneUpdateLSCPRCL angular FF not working, no locking :(

I'm sad.  And frustrated. 

The PRCL angular feed forward is not working, and without it I am having a very difficult time keeping the PRMI locked while the arms are at high power (either buzzing, or the one time I got stable high power partway through the transition).  Obviously if the PRMI unlocks once CARM and DARM are mostly relying on the REFL signals, I lose the whole IFO. 

Q and I had been noticing over the last few weeks that the angular feed forward wasn't seeming quite as awesome as it did when I first implemented it.  We speculated that this was likely because we had started DC coupling the ITM optical levers, which changes the way seismic motion is propagated to cavity axis motion (since the ITMs are reacting differently).

Anyhow, today it does not work at all.  It just pushes the PRM until the PRMI loses lock. I am worried that, even though Rana re-tuned the BS and PRM oplev servos to be very similar to how they used to be, there is enough of a difference (especially when compounded with the DC coupled ITMs) that the feed forward transfer functions just aren't valid anymore.

Since this prevents whole IFO locking, I spent some time trying to get it back under control, although it's still not working. 

I remeasured the actuator transfer function of how moving PRM affects the sideband spot at the QPD, in the PRMI-only situation.  I didn't make a comparison plot for the yaw degree of freedom, but you can see that the pitch transfer function is pretty different below ~20Hz, which is the whole region that we care about.  In the plot below, black is from January (PRMI-only, no DC-coupled ITMs) and blue is from today (PRMI-only, with DC-coupled ITMs, and somewhat different BS/PRM oplev setup):

Pitch_oldVsNew.pdf

I calculated new Wiener filters, and tried to put them in, but sometimes (and I don't understand what the pattern is yet) I get "error" in the Alternate box, rather than the zpk version of my sos filter.  It seems to go away if you use fewer and fewer poles for fitting the Wiener filters, but then the fit is so poor that you're not going to get any subtraction (according to the residual estimation plot that uses the fitted filters rather than the ideal Wiener filters). The pitch filters could only handle 6 poles, although the yaw filters were fine with 20.

The feed forward just keeps pushing the PRM away though.  I flipped the signs on the Wiener filters, I tried recalculating without the actuator pre-filtering, I don't know why it's failing.  But, I'm not able to lock the interferometer.  Which sucks, because I was hoping to finally get most of my noise coupling measurements done today.

 

Attachment 1: Pitch_oldVsNew.pdf
Pitch_oldVsNew.pdf
  11257   Sun Apr 26 20:10:10 2015 max isiHowToGeneralSummary pages

I have set up new summary pages for the 40m: http://www.ligo.caltech.edu/~misi/summary/
This website shows plots (time series, spectra, spectrograms, Rayleigh statistics) of relevant channels and is updated with new data every 30 min.

The content and structure of the pages is determined by configuration files stored in nodus:/users/public_html/gwsumm-ini/ . The code looks at all files in that directory matching c1*.ini. You can look at the c1hoft.ini file to see how this works. Besides, a quick guide to the format can be found here http://www.ligo.caltech.edu/~misi/iniguide.pdf

Please look at the pages and edit the config files to make them useful to you. The files are under version control, so don’t worry about breaking anything.

Do let me know if you have any questions (or leave a comment in the pages).

  11256   Sun Apr 26 15:34:34 2015 JenneUpdateSUSPRM oplev centered

After last week's work on the BS/PRM oplev table, I think the PRM oplev got centered while the PRM was misaligned.  With the PRM aligned, the oplev spot was not on the QPD.  It has been centered.

  11255   Sun Apr 26 15:05:35 2015 JenneUpdateASCunBroken Xass?

Thank you both.

I have updated the .snap file, so that it'll use these parameters, as Rana left them.  Also, so that the "unfreeze" script works without changes (since it wants to make the overall gain 1), I have changed the Xarm input matrix elements from 1 to 0.1, for all of them.  This should be equivalent to the overall gain being 0.1.

  11254   Sun Apr 26 14:17:40 2015 JenneUpdateLSCPOXDC, POYDC unplugged for now

I have unplugged POXDC and POYDC from their whitening inputs.  They have labels on them which whitening channel they belong to (POY=5, POX=6) on the DCPD whitening board.

TT3_LR's DAC output is Tee-ed, going to the POYDC input and also to an SR560 near the Marconi.

TT4_LR's DAC output is Tee-ed, going to the POXDC input and also to the CM board's ExcB input.

  11253   Sun Apr 26 01:10:18 2015 ranaUpdateASCunBroken Xass?

Today I tried some things, but basically, lowering the input gain by 10 made the thing stable. In the attached screenshotstrip, you can see what happens with the gain at 1. After a few cycles of oscillation, I turned the gain back to 0.1.

There still is an uncontrolled DoF, but I that's just the way it is since we only have one mirror (the BS) to steer into the x arm once the yarm pointing is fixed.

Along the way, I also changed the phase for POX, just in case that was an issue. I changed it from +86 to +101 deg. The attached spectra shows how that lowered the POX_Q noise.

I also changed the frequencies for ETM_P/Y dither from ~14/18 Hz to 11.31/14.13 Hz. This seemed to make no difference, but since the TR and PO signals were quieter there I left it like that.

This is probably OK for now and we can tune up the matrix by measuring some sensing matrix stuff again later.

Attachment 1: xasstune_150426.png
xasstune_150426.png
Attachment 2: xassnoise.pdf
xassnoise.pdf
  11252   Sun Apr 26 00:56:21 2015 ranaSummaryComputer Scripts / Programsproblems with new restart procedures for elogd and apache

Since the nodus upgrade, Eric/Diego changed the old csh restart procedures to be more UNIX standard. The instructions are in the wiki.

After doing some software updates on nodus today, apache and elogd didn't come back OK. Maybe because of some race condition, elog tried to start but didn't get apache. Apache couldn't start because it found that someone was already binding the ELOGD port. So I killed ELOGD several times (because it kept trying to respawn). Once it stopped trying to come back I could restart Apache using the Wiki instructions. But the instructions didn't work for ELOGD, so I had to restart that using the usual .csh script way that we used to use.

  11251   Sun Apr 26 00:08:56 2015 ranaHowToelogTroubles with putting plots in external locations

If it all possible, don't use links to your home directory. Its not robust. It would be like if you clicked on your Google Music and it told you to ask me to sing that song to you. Imagine that on auto-repeat next time your fancy-bone itches.

Attachment 1: 48.png
48.png
  11250   Sat Apr 25 22:17:49 2015 ranaUpdateCDSMXstream restart script working (beta)

Since python from crontab seemed intractableangry, I replaced autoMX.py with a soft link that points at autoMX.sh.

This is a simple BASH scriptcool that looks at the LSC FB stat (C1:DAQ-DC0_C1LSC_STATUS), and runs the restart mxstream script if its non-zero.

So far its run 5 times successfullylaugh. I guess this is good enough for now. Later on, someone ought to make it loop over other FE, but this ought to catch 99% of the FB issues.

  11249   Sat Apr 25 18:50:47 2015 ericqUpdateVACPressure watch script broken

Ugh, this turns out to be because cron doesn't source the controls bashrc that defines where to find caget and all that jazz that many commands depend on. This is probably also why the AutoMX cron job isn't working either. 

Also, cron automatically emails everything from stderr to the email address that is configured for the user, which is why the n2 script blew up the foteee account and why the AutoMX script was blowing up my email yesterday. This can be avoided by doing something like this in the crontab:

0 8 * * * /bin/somecommand >> somefile.log 2>&1

(The >> part means that the standard output is appended to some log file, while the 2>&1 means send the standard error stream to the same place as stdout)

I made this change for the n2 script, so the foteee email account should be safe from this script. I haven't figured out the right way to set up cron to have all the right $PATH and other environment stuff, such as epics may need, so the script is still not working. 

  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.

  11247   Sat Apr 25 00:20:16 2015 ranaUpdateCDSmegatron python autoMC cron

Upgraded python on megatron. Added lines to the crontab to run autoMX.py. Edited crontab to have a PYTHONPATH so that it can run .py stuff.

But autoMX.py is still not working from inside of cron, just from command line.

  11246   Fri Apr 24 23:40:15 2015 ranaUpdateSUSPRM and BS oplev laser replaced

Recently, Steve replaced the HeNe which was sourcing the BS & PRM OL. After replacement, no one checked the beam sizes and we've been living with a mostly broken BS OL. The beam spot on the QPD was so tiny that we were seeing the 'beam is nearly the size of the segment gap' effect.

Today I removed 2 of the lenses which were in the beam path: one removed from the common PRM/BS path, and one removed from the PRM path. The beams on both the BS & PRM got bigger. The BS beam is bigger by a factor of 7. I've increased the loop gains by a factor of 6 and now the UGFs are ~6 Hz. The loop gains were much too high with the small beam spots that Steve had left there. I would prefer for the beams to be ~1.5-2x smaller than they are now, but its not terrible.

Many of the mounts on the table are low quality and not constructed stably. One of the PRM turning mirror mounts twisted all the way around when I tried to align it. This table needs some help this summer.

In the future: never try locking after an OL laser change. Always redo the telescope and alignment and check the servo shape before the OL job is done.

Also, I reduced the height of the RG3.3 in the OL loops from 30 to 18 dB. The BS OL loops were conditionally stable before and thats a no-no. It makes it oscillate if it saturates.

Attachment 1: BSOL.pdf
BSOL.pdf
  11245   Fri Apr 24 21:31:20 2015 KojiSummaryCDSautomatic mxstream resetting

We were too much annoyed by frequent stall of mxstream. We'll update the RCG when time comes (not too much future).

But for now, we need an automatic mxstream resetting.

I found there is such a script already.

/opt/rtcds/caltech/c1/scripts/cds/autoMX

So this script was registered to crontab on megatron.
It is invoked every 5 minutes.

# Auto MXstream reset when it fails
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /opt/rtcds/caltech/c1/scripts/cds/autoMX >> /opt/rtcds/caltech/c1/scripts/cds/autoMX.log

  11244   Fri Apr 24 18:13:36 2015 ranaUpdateGeneraltorque for 1/4-20

For 1/4-20 bolts made of 18-8 Stainless Steel, the recommended torque varies from 65-100 inch-pounds, depending upon the application, the lubrication, how loose the bolt is, if there's a washer, etc.

For our case, where we are going into a tapped, ferromagnetic stainless table, its less clear, but it will certainly by in the 60-80 range. This is close to the 5-6 foot-lbs that I recommended on Wednesday.

I've ordered 3 torque wrenches with 1/4" drive so that we can have one at each end and one in the toolbox near MC2. We'll indicate the recommended torque on there so that we can tighten everything appropriately.

  11243   Fri Apr 24 17:30:32 2015 JenneUpdateVACPressure watch script broken
Quote:

I made a script that checks the N2 pressure, which will send an email to myself, Jenne, Rana, Koji, and Steve, should the pressure fall below 60psi.

The script checking the N2 pressure is not working.  I signed into the foteee account to look at some of the picasa photos, and there are thousands of emails (one every 10 minutes for the past month!) with error messages.  Q, can you please make it stop (having errors)?

The error looks like it's mad about a "caget" command.  I don't have time to investigate further though.

  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!!

  11241   Thu Apr 23 23:07:23 2015 DugoliniFrogsALARMlaptops warning

Please!

Don't put laptops on the ISC Tables!

  11240   Thu Apr 23 21:05:23 2015 ranaUpdateComputer Scripts / ProgramsCDSutils upgrade undone

Q: please update this Wiki page with the go-back procedure:

https://wiki-40m.ligo.caltech.edu/CDSutils_Upgrade_Procedure

  11239   Thu Apr 23 15:40:41 2015 SteveUpdateGeneraltorque for 1/4-20

 

Few 1/4 -20 socket cap head screw with washers were tested for optimum torque.

QJR 117E Snap On  torque wrench was used. I found that 40 lb in was enough.

Looked up recommended values on the web later:

Our Thorlab SS 1/4-20 screw kits are SS 18-8 as DRY 70 inch / lbs max, lubricated  60 inch / lbs max

These numbers will varie with washers, material it's going into and so on!

BLACK-OXIDE Alloy Steel Socket Head Cap Screws can go much higher value

Thread Size 1/4"-20
Length 1/4"
Thread Length Full
Additional Specifications Black-Oxide Alloy Steel
RoHS Compliant

The standard among high-strength fasteners, these screws are stronger than Grade 8 steel screws. They have a minimum tensile strength of 170,000 psi. and a minimum Rockwell hardness of C37. Length is measured from under the head.

Inch screws have a Class 3A thread fit. They meet ASTM A574.

Black Oxide—Screws have been heat-treated for hardness, which results in a dark surface color.

 
The information in this 3-D model is provided for reference only. Details
 
 

We still do not know that what torque values we get best performance : minimum jiggel and drift etc.

After looking at these numbers I raise my recommendation to 50 inch / lbs on a std aplication.

Rana is next to calibrate his feelings and declare the right number.

Than Koji....and so on

Once we a number, than I buy more torque wrenches to fit it.

Attachment 1: snapon.jpg
snapon.jpg
Attachment 2: QJR117E.jpg
QJR117E.jpg
  11238   Thu Apr 23 08:43:40 2015 SteveUpdateElectronicsEG&G InGaAs diodes in stock

RFpds box is moved from RF cabinet E4 to clean cabinet S15

Inventory updated at https://wiki-40m.ligo.caltech.edu/RF_Pd_Inventory

Large Area InGaAs PIN Photodiode -- C30642GH      6 pieces in stock

Product Details
in: Photodiodes

 

Large Area InGaAs PIN Photodiode -- C30642GH -- View Larger Image

Large Area InGaAs PIN Photodiode with a 2,0 mm active diameter chip in TO-5 package with flat glass window

Large area InGaAs PIN photodiode with useful diameter of 2,0 mm in a T0-5 package with a flat glass window. The C30642GH provides high quantum efficiency from 800nm to 1700nm. It features high responsivity, high shunt resistance, low dark current, low capacitance for fast response time and uniformity within 2% across the detector active area.

  11237   Wed Apr 22 17:04:11 2015 ranaUpdateElectronicsMC REFL PD back from the dead

Just randomly found this old entry from 3 years ago. We should never have installed a GAP 2000 - they are an inferior type of InGaAs diode. We should add to our list replacing these with a 2 mm EG&G diode.

How many 2 mm EG&G InGaAs diodes do we have Steve? Can you please find a good clean diode case so that we can store them in the optics cabinet on the south arm?

Quote:

 [Yuta, Manasa]

We replaced the dead photodiode on MC REFL PD with a new one (GAP 2000). We measured the frequency response of the PD and tuned the resonant frequency using inductor L5 (in the circuit diagram) to be 29.575MHz - over an average of 10 measurements.

 

  11236   Wed Apr 22 14:56:18 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

[Koji, Manasa]

Since the bandwidth of the fiber PD is ~ 1GHz, we could design the frequency discriminator to have a wider bandwidth (~ 500MHz). The output from the frequency discriminator could then be used to define the range setting of the frequency counter for readout or may be even error signal to the PID loop.

A test run for the analog DFD with cable length difference of 27cm gave a linear output signal with zero-crossing at ~206MHz.

Detailed schematic of the setup and plot (voltage vs frequency) will be updated shortly.

  11235   Wed Apr 22 11:48:30 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

Since the Frequency counters have not been a reliable error signal for FOL PID loop, we will put together an analog delay line frequency dicriminator as an alternative method to obtain the beat frequency.

The configuration will be similar to what was done in elog 4254 in the first place.

For a delay line frequency dicriminator, the output at the mixer is proportional to cos(\theta_{b}) where \theta_{b} = 2 \pi f_{b}L/v

L - cable length asymmetry, fb - beat frequency and v - velocity of light in the cable.

The linear output signal canbe obtained for  0< \theta_{b}<\pi

For our purpose in FOL, if we would like to measure beat frequency over a bandwidth of 200MHz, this would correspond to a cable length difference of 0.5 m (assuming the speed of light in the coaxial cable is ~ 2x108m/s.

  11234   Wed Apr 22 11:43:28 2015 SteveUpdateSUSETMX damping restored

ETMX sus damping restored.

  11233   Wed Apr 22 11:21:51 2015 SteveUpdateOptical LeversBS & PRM oplevs are back to normal

BS & PRM oplev is restored. Note: the F -150 lens was removed right after the first turning mirror from the laser. This helped Rana to get small spot on the qpd.

It also means that the oplev paths are somewhat different now.

 

 

 

  11232   Tue Apr 21 21:46:34 2015 ranaUpdateOptical Levers1103P noise measurement

To test what the inherent angular noise of the HeNe 1103P laser is, we're testing it on a table pointing into the BS OL QPD with only a few steering mirrors.

From the setup that I found today, I've removed the lens nearest to the laser (which was used for the BS and PRM) as well as the ND filter (what was this for?) and the lens placed just before the BS QPD.

With the ND filter removed, the quadrant signals are now ~15000 if we misalign it and ~9000 each with the beam centered.

In order to calibrate the OLPIT_IN1 and OLYAW_IN1 signals into mm of beam motion, I misaligned the mirror just before the QPD. The knobs on there actuate the 100 TPI screws and the knurling on the knob itself has 10 ridges, so that's 36 deg per bump.

Pit Knob (deg) OLPIT Yaw Knob (deg) OLYAW
0 29 0 -36
45 13 36 -16
90 -16 72 19
135 -39 108 36
       

PIT cal ~ 1.55 (knob deg / count) -->> 10 microns / count --->>> 10 urad / count

YAW cal ~ 1 (knob deg / count)  -->> 6.5 microns / count --->>> 6.5 urad / count

Distance from the 45 deg turning mirror to the QPD silicon surface is 23 cm. Distance between knob tip and fixed pivot point is ~4 cm. 1 knob turn = 0.01" = 0.254 mm = 0.254/40 radians of mirror angle.

So 360 deg of knob gives 2*0.254/40 = 0.012 radians of beam angle = 0.012 * 230 mm ~2.3 mm of beam spot motion. Or 6.4 microns of translation / deg of knob.

The distance from the face of the laser to the QPD is 96 cm.


The punchline is that the laser shows a level of noise which has a similar shape to what's seen at LLO, but 10x lower.

The noise at 0.05 - 0.2 Hz is ~2-3x worse than the PR3 at LLO. Not sure if this is inherent to the HeNe or the wind in our setup.

Attachment 1: oplev1103P.png
oplev1103P.png
Attachment 2: L1-ISI_SUS_ODC_FC496F_SPECTRUM-1113523216-86400.png
L1-ISI_SUS_ODC_FC496F_SPECTRUM-1113523216-86400.png
  11231   Tue Apr 21 15:03:27 2015 ranaUpdateOptical Levers1103P noise measurement

It doesn't work with the lens in there, but it seems pretty close. Please leave it as is and I'll play with it after 5 today.

  11230   Tue Apr 21 11:55:05 2015 SteveUpdateOptical Levers1103P noise measurement

Manasa and Steve,

Is this what you want?  Dashed lines are dark.

BS and PRM oplevs are blocked for this measurement. I will restore to normal operation at 4pm today.
 

Attachment 1: 1103P@qpdBS.jpg
1103P@qpdBS.jpg
Attachment 2: oplev1103P.png
oplev1103P.png
Attachment 3: oplevSum1103Pbs.png
oplevSum1103Pbs.png
  11229   Tue Apr 21 01:17:13 2015 JenneUpdateModern ControlT-240 self-noise propagated through stack and pendulum

Going back to Wiener filtering for a moment, I took a look at what the T-240 noise level looks like in terms of pitch motion on one of our SOS optics (eg. PRM).

The self-noise of the T-240 (PSD, in dB referenced to 1m^2/s^4/Hz) was taken by pulling numbers from the Users Guide.  This is the ideal noise floor, if our installation was perfect.  I'm not sure where Kissel got the numbers from, but on page 13 of G1200556 he shows higher "measured" noise values for a T-240, although his numbers are already transformed to m/rtHz.

To get the noise numbers to meters, I use:  \left[ \frac{\rm m}{\sqrt{\rm Hz}} \right] = \frac{\sqrt{10^{\frac{[\rm dB/\sqrt{Hz}]}{10}}}}{(2 \pi f)^2}.  The top of that fraction is (a) getting to magnitude from power-dB and (b) getting to asd units from psd units.  The bottom of the fraction is getting rid of the extra 1/s^2.

 

Next I propagate this seismometer noise (in units of m/rtHz) to effective pendulum pitch motion, by propagating through the stacks and the transfer function for pos motion at the anchor point of the pendulum to pitch motion of the mirror (see eq 63 of T000134 for the calculation of this TF).   This gives me radians/rtHz of mirror motion, caused by the ground motion:

.

I have not actually calibrated the POP QPD, so I will need to do that in order to compare this seismometer noise to my Wiener filter results.

 

Attachment 1: T240selfnoise.png
T240selfnoise.png
Attachment 2: Limits.tar.gz
  11228   Mon Apr 20 21:26:46 2015 ranaUpdateElectronicsLow noise pre-amps: returned

+1 to both Evan and Zach for prompt info and +2 to you for getting more stuff than you started looking for. -2 karma to whomever had swiped them and hoarded without signing. You should put a 40m sticker on both of them. Make sure to check / use fresh batteries. The Busby box is BJT based and works on low impedance sources, the Rai box works on anything, but (I am guessing) has less CMRR.

Quote:

The Rai box was in the Cryo lab, and the Busby box was in the TCS lab.  Neither had been signed out.  Lame.  Anyhow, thanks to Evan and Zach's memories of having seen them recently, they have been returned to the 40m where they belong.  (Also, I grabbed a spare Marconi while I was over there, for the phase noise measurement).

 

  11227   Mon Apr 20 16:42:48 2015 steveUpdateSUSPRM and BS oplev laser replaced

The laser below is dead. JDSU 1103P, SN P845655 lived for 3.5 years.

Quote:

 

JDSU 1103P died after 4 years of service. It was replaced with new identical head of 2.9 mW output. The power supply was also changed.

The return spots of 0.04 mW  2.5 mm diameter on qpds are BS  3,700 counts and PRM 4,250 counts.

 

It was replaced by JDSU P/N 22037130,( It has a new name for 1103P Uniphase ) sn P919639 of mfg date 12-2014

Beam shape at 5 m nicely round. Output power 2.8 mW of 633 nm

BS spot size on qpd ~1 mm &  60 micro W

PRM spot size on qpd ~1 mm & 50 micro W

Attachment 1: newOplevLaser.png
newOplevLaser.png
  11226   Mon Apr 20 16:18:29 2015 JenneUpdateElectronicsLow noise pre-amps: returned

The Rai box was in the Cryo lab, and the Busby box was in the TCS lab.  Neither had been signed out.  Lame.  Anyhow, thanks to Evan and Zach's memories of having seen them recently, they have been returned to the 40m where they belong.  (Also, I grabbed a spare Marconi while I was over there, for the phase noise measurement).

  11225   Sun Apr 19 15:03:26 2015 JenneUpdateElectronicsLow noise pre-amps?

Does anyone know where the Busby or Rai low noise pre-amp boxes are? 

I think I need one in order to measure the noise of the Marconi.  Right now, I am trying to measure the amplitude noise, but I'm not seeing anything on the SR785 above the analyzer's noise level.

  11224   Thu Apr 16 10:32:42 2015 SteveUpdateOptical Leversoplevs monitoring

The IFO_overview of oplevs seems ok, The servos are working fine. The green arms are locked, but master and oplev_summary monitoring screens are not.

I'm proposing to Erick G. to postpone the oplev noise measurement.

Attachment 1: oplevCond.png
oplevCond.png
  11223   Wed Apr 15 23:29:08 2015 JenneUpdateComputer Scripts / ProgramsCDSutils upgrade undone

Q remotely reverted this change.  Scripts seem to work again.

Quote:

The SUS align/misalign scripts don't work after the new CDS utils upgrade. 

I don't know if it's looking for the _SWSTAT channel to confirm that the offset has been turned on/off, or if it is trying to set that channel, to do the switching, but either way, the script is failing.  Recall that our version of the RCG still has _SW1R and _SW2R, rather than the newer _SWSTAT for the filter banks. 

ezca.ezca.EzcaConnectError: Could not connect to channel (timeout=2s): C1:SUS-PRM_OL_PIT_SWSTAT

Q, can you please (please, please, pretty please) undo this upgrade, and then hold off on any further changes to the system for a few weeks?

 

  11222   Wed Apr 15 21:00:56 2015 JenneUpdateLSCDAC fine

The DAC was fine.  I realized tonight that the digital filter bank outputs were off, so I wasn't actually sending signals out.  Oooops.  blush

 

  11221   Wed Apr 15 20:54:18 2015 JenneUpdateComputer Scripts / ProgramsCDSutils upgrade bad

The SUS align/misalign scripts don't work after the new CDS utils upgrade. 

I don't know if it's looking for the _SWSTAT channel to confirm that the offset has been turned on/off, or if it is trying to set that channel, to do the switching, but either way, the script is failing.  Recall that our version of the RCG still has _SW1R and _SW2R, rather than the newer _SWSTAT for the filter banks. 

ezca.ezca.EzcaConnectError: Could not connect to channel (timeout=2s): C1:SUS-PRM_OL_PIT_SWSTAT

Q, can you please (please, please, pretty please) undo this upgrade, and then hold off on any further changes to the system for a few weeks?

  11220   Wed Apr 15 15:14:18 2015 ericqUpdateComputer Scripts / ProgramsCDSutils upgraded to v474

CDSutlils has been updated to the newest version, 474; there are some matrix interface methods that will make our locking scripts easier to read, modify, and maintain.

I've tested the ALS and CARM down scripts, and the LSC offsets script, and they all work fine. 

  11219   Wed Apr 15 02:26:41 2015 ericqUpdateLSCAttempted DRMI + ALS arms

I spent some time tonight trying to revive DRMI locking, with the arms held off on ALS. Not much news, I haven't been able to get more than a few short spurts of resonance, using 1F signals.

I did use SRY to measure the BS->SRCL coupling by exciting each mirror and looking at their relative coupling to AS55Q. I found that we should use a value of +0.28 +-0.01 in the MICH->SRM element.

  11217   Tue Apr 14 11:19:52 2015 SteveUpdatePEMlarge chamber has arrived

It is here.

Quote:

The 40m fenced area will start storing this large ~ 8000 lbs chamber on April 14. The asphalt will be cut, jack hammered the next 2-3 days in order to lay concrete.

Their schedule is from 8 to 5 starting tomorrow.  We are asking them to work from 6 to 3pm

ETMX is about 12-15 ft away

 

Attachment 1: ETMXfriend.png
ETMXfriend.png
Attachment 2: 8000lbs.png
8000lbs.png
  11216   Mon Apr 13 19:34:02 2015 ericqUpdateIOOModulation Frequency Tuned to IMC Length

I've been fiddling with the mode cleaner and green beat box today, to try and get an absolute frequency calibration for MC2 motion. The AC measurements have all turned out weird, I get fractional power laws instead of the 1/f^2 that we expect from the MC2 pendulum. At DC, I get a rough number of 15 green kHz per MC2 count, but this translates to ~7e-10 m/count which is in contrast to the 6e-9 m/count from 2009. I will meditate on this a bit. 


In any case, while working at the IOO rack, I tuned the 11MHz modulation frequency, as was done in ELOGs 9324 and 10314, by minimizing one of the beats of the 11MHz and 29.5MHz sidebands. 

The new modulation frequency / current IMC FSR is 11.066209 +- 1 Hz, which is a only a few ppm change from the tuning from last July.

This implies a IMC round trip length of 27.090800m +- 2um.

Attached is a plot showing the beat of 55-29.5 going down as I changed the marconi frequency. 

 

Attachment 1: fMod_tuning.pdf
fMod_tuning.pdf
  11215   Fri Apr 10 18:39:39 2015 ericqUpdateLSCRelative ETM calibration (Rough MC2 calibration)

I didn't verify that the loop gain was low enough at the excitation frequencies. blush

I put a 1kHz ELP in both arm servos, and got cleaner data for both. The ETM numbers are pretty much consistent with the previously posted ones, and the MC2 data now is consistent across frequencies. However, the MC2 numbers derived from each arm are not consistent.

Now:

  • ETMX / ITMX: 2.831 +- 0.043
  • MC2 / ITMX: 3.260 +- 0.062
  • ETMY / ITMY: 2.916 +- 0.041
  • MC2 / ITMY: 3.014 +- 0.036

With the data from ELOG 8242, this implies:

  • ETMX: 13.31 +- 0.21 x 10-9 / f2 m/counts
  • ETMY: 13.59 +- 0.20 x 10-9 / f2 m/counts
  • MC2 in Xarm meters : 15.32 +- 0.30 x 10-9 / f2 m/counts
  • MC2 in Yarm meters : 14.04 +- 0.18 x 10-9 / f2 m/counts
This is, of course, pretty fishy. Each arm sees the same frequency fluctuation of the light coming out of the IMC, especially given that the MC2 to arm data was taken simultaneously for both arms. Now, one possible source of this kind of mismatch would be a mismatch of the arm lengths, but there is no way they differ by 10%, as they would have to in order to explain the above numbers. To me, it seems more likely that the ITM calibrations are off. 
Attachment 1: betterCal.png
betterCal.png
  11214   Fri Apr 10 17:05:45 2015 ericqUpdateLSCRelative ETM calibration (Rough MC2 calibration)

I did a quick measurement get an idea of the ETM actuator calibration, relative to the ITMs. This will still hold if/when we revisit the ITM calibration via the Michelson. 

For the test masses, I locked the arms individually using MC2 as the actuator, and took transfer functions from the SUS-[OPTIC]_LSC_EXC point to the PO[X/Y]_I_ERR error signals. There were two points with coherence less than 99% that I threw away. I then took the fraction at each point, and am using the standard deviation of those fractions as the reported random error, since the coherence was super high for all points, making the error of each point negligible relative to their spread. 

This gives:

  • ETMX/ITMX: 2.765 +- 0.046
  • ETMY/ITMY: 2.857 +- 0.029

With the data from ELOG 8242, this implies:

  • ETMX: 13.00 +- 0.22 x 10 -9 / f2 m/counts
  • ETMY: 13.31 +- 0.15x 10 -9 / f2 m/counts

MC2 data was taken with the arms locked with the ETMs. The results are not so clean, the fractions don't line up; there is some trend with excitation frequency... The ratio is around the same as the ETMs, but I'm not going to quote any sort of precision, since I don't fully understand what's happening. Kind of a bummer, because it struck me that we could get an idea of the arm length mismatch by the difference in IMC frequency / arm FSR. I'll think about this some more...

Attachment 1: quickCal.png
quickCal.png
  11213   Fri Apr 10 12:09:19 2015 ericqUpdateLSCSome small progress, may have DAC problem?
Quote:

At the very end, the last 10 seconds or so, the POP110 power goes down, and sits at about half it's maximum value.  POP22 isn't quite as bad, in that it still touches the max, but the RIN is about 50%.  The carrier DC signals (TRX, TRY, POPDC) don't see this huge jump.  I don't think I was touching anything the last few tens of seconds.  I'm not sure yet how I can so significantly lose sideband power, without losing a similar amount of carrier power. 

I saw this same kind of behavior in my locklosses on Wednesday night; we should check out the 165 data, and see if the 3f PRCL error signal shows some drift away from zero.

Also, it's odd that CARM_IN1 and REFL11_I_ERR have different low frequency behavior in the plot you posted. I guess they have some difference in demodulation phase.  REFL11_I's bump at -40sec coincides with the dip in arm power and a rise in REFLDC, but ASDC seems pretty smooth, so maybe it is a real CARM fluctuation.

I set the REFL11 analog demodulation angle (via cable length) about a year ago (ELOG 9850), with some assumption about PRCL having the same demod angle as CARM, but this was probably set with the arms misaligned. We should recheck this; maybe we're coupling some other junk into CARM. 

  11212   Fri Apr 10 03:44:51 2015 JenneUpdateLSCSome small progress, may have DAC problem?

Small steps tonight, but all in the forward direction.

On one of my better locks, I saw a kind of weird phenomenon with the PRMI sideband powers versus the carrier powers:

For the last 100 seconds of this plot, I'm all 1f.  Alignment is being handled mostly by Q's DC coupled ITM oplevs, and the transmission QPD ASC loops, although I was trying to adjust the offsets in the ASC loops to improve transmission for a bit.

At the very end, the last 10 seconds or so, the POP110 power goes down, and sits at about half it's maximum value.  POP22 isn't quite as bad, in that it still touches the max, but the RIN is about 50%.  The carrier DC signals (TRX, TRY, POPDC) don't see this huge jump.  I don't think I was touching anything the last few tens of seconds.  I'm not sure yet how I can so significantly lose sideband power, without losing a similar amount of carrier power. 

The ring-ups at about -70sec in the CARM and DARM outs are the bounce mode. 

I tried looking at 2D histograms of different combinations of channels, for the time around -30 seconds where things looked pretty clean.  It looks like the offsets that Q put in last night (+1 for MICH_B and -3 for PRCL_B) are still about right.  The PRCL_IN1 and MICH_IN1 were centered around zero at the maximum power points.  CARM and DARM had small offsets, which I put into the DARM_B and CARM_B filter banks (0.0066 for DARM_B, and 0.027 for CARM_B), although these are small enough that I don't know that they really do anything.


As a break from locking for a little while, I tried to see if I could get the TT3 and TT4 DAC channels to work for me.  I had hoped it would be a quick and easy task, but I'm not seeing signal out.  Since it wasn't working, I decided to go back to locking for the night, and look into the DAC in the daytime.  I want to use one channel as the IN2 input of the CM board, and another as the external modulation input to the Marconi for transfer functions, so I need them to work. 

As a side note on the input to the Marconi situation, it occurred to me that instead of laying a new cable, I can borrow the POP55 heliax.  We don't have a POP55 diode right now, and the other end comes out across the hall from the Marconi, so it would be pretty easy to have a medium-length cable go from ITMX table to the Marconi.  Objections to this? 

Attachment 1: PRMI_sb_powers_9Apr2015.png
PRMI_sb_powers_9Apr2015.png
  11211   Thu Apr 9 07:41:22 2015 SteveUpdatePEMjackhammering at ETMX

There was a period of short unexpected jackhammering this morning. I asked them to stop.

The good mood of GTRX was not changed.smiley

 

Attachment 1: moreJackHam.png
moreJackHam.png
Attachment 2: GTRX.jpg
GTRX.jpg
  11210   Thu Apr 9 02:58:26 2015 ericqUpdateLSCAll 1F, all whitened

blarg. Chrome ate my elog. 

112607010 is the start of five minutes on all whitened 1F PDs. REFL55 has more low frequency noise than REFL165, I think we may need more CARM supression (i.e. we need to think about the required gain). This is also supported by the difference in shape of these two histograms, taken at the same time in 3f full lock. The CARM fluctuations seem to spread REFL55 out much more.  

I made some filters and scripts to do DC coupling of the ITM oplevs. This makes maintaining stable alignment in full lock much easier. 

I had a few 15+ minute locks on 3f, that only broke because I did something to break it.  

Here's one of the few "quick" locklosses I had. I think it really is CARM/AO action, since the IMC sees it right away, but I don't see anything ringing up; just a spontaneous freakout. 

Attachment 1: quickLockLoss.png
quickLockLoss.png
Attachment 2: 55_1.png
55_1.png
Attachment 3: 55_2.png
55_2.png
ELOG V3.1.3-