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

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.

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.

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).

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

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

+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.

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:  .  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.

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.
 

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.

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

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.

ETMX sus damping restored.

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  where 

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

The linear output signal canbe obtained for  

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 ~ 2x10⁸m/s.

[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.

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?

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

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.

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.

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

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

Please!

Don't put laptops on the ISC Tables!

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

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.

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.

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

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.

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.

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.

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. 

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

This is a simple BASH script 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 successfully. 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.

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.

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.

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.

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.

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.

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.

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).

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.

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

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

We want to have a VAC page in the summaries, so Steve - please put a list of important channel names for the vacuum system into the elog so that we can start monitoring for trouble.

Also, anyone that has any ideas can feel free to just add a comment to the summary pages DisQus comment section with the 40m shared account or make your own account.

Installed libmotif3 and libmotif4 on nodus so that we can run dataviewer on there.

Also, the lscsoft stuff wasn't installed for apt-get, so I did so following the instructions on the DASWG website:

https://www.lsc-group.phys.uwm.edu/daswg/download/repositories.html#debian

Then I installed libmetaio1, libfftw3-3. Now, rather than complain about missing librarries, diaggui just silently dies.

Then I noticed that the awggui error message tells us to use 'ssh -Y' instead of 'ssh -X'. Using that I could run DTT on nodus from my office.

We have 2 transduser PX303-3KG5V   http://www.omega.com/pressure/pdf/PX303.pdf They  will be installed on the out put of the N2 cylinders to read the supply pressure.

I will order one DC power supply  http://www.omega.com/pptst/PSU93_FPW15.html      PSU-93

One full cylinder pressure is ~ 2400 PSI max so two of them will give us ~9Vdc

The email reminder should be send at 1000 PSI  =  1.8 V

Rana asked me to include add slow outputs (OUT16) of the seismometer BLRMS channels to the frames. 

All of the PEM slow channels are already set up in c1/chans/daq/C1EDCU_PEM.ini, but up to this point, daqd had no knowledge of this file, since it wasn't included in c1/target/fb/master, which defines all the places to look for files describing channels to be written to disk. This file already includes lines for C1EDCU_LSC.ini and such, which from old elogs, looks like was set up by hand for subsystems we care about. 

Hence, since we now care about slow trends for the PEM subsystem, I have added a line to the daqd master file to tell it to save the PEM slow channels. This looks to have increased the size of the individual 16 second frame files from 57MB to 59MB, which isn't so bad.

Still processing, but I think it should work fine once we have a day of data. Until then, here's the summary pages so far, including Vac channels:

http://www.ligo.caltech.edu/~misi/summary/day/20150501/pem/

Same thing again today. So I renamed the /etc/init/elog.conf so that it doesn't keep respawning bootlessly. Until then restart elog using the start script in /cvs/cds/caltech/elog/ as usual.

I'll let EQ debug when he gets back - probably we need to pause the elog respawn so that it waits until nodus is up for a few minutes before starting.

https://ldas-jobs.ligo.caltech.edu/~max.isi/summary/day/20150502/pem/seismic/

Looks like some of our seismometers are oscillating, not mounted well, or something like that. No reason for them to be so different.

Which Guralp is where? And where are our accelerometers mounted?

X arm was far out in yaw, so I reran the ASS for Y and then X. Ran OK; the offload from ASS outputs to SUS bias is still pretty violent - needs smoother ramping.

After this I recentered the ITMX OL- it was off by 50 microradians in pitch. Just like the BS/PRM OLs, this one has a few badly assembled & flimsly mounts. Steve, please prepare for replacing the ITMX OL mirror mounts with the proper base/post/Polaris combo. I think we need ~3 of them. Pit/yaw loop measurements attached.

Based on the PEM-SEIS summary page, it looked like GUR1 was oscillating (and thereby saturating and suppressing the Z channel). So I power cycled both Guralps by turning off the interface box for ~30 seconds and the powering back on. Still not fixed; looks like the oscillations at 110 and 520 Hz have moved but GUR2_X/Y are suppressed above 1 Hz, and GUR1_Z is suppressed below 1 Hz. We need Jenne or Zach to come and use the Gur Paddle on these things to make them OK.

From the SUS-WatchDog summary page, it looked like the PRM tripped during the little 3.8 EQ at 4AM, so I un-tripped it.

Caryn's temperature sensors look like they're still plugged in. Does anyone know where they're connected?

Attached is the schematic of the analog DFD and the plot showing the zero-crossing for a delay line length of 27cm. The bandwidth for the linear output signal obtained roughly matches what is expected from the length difference (370MHz) .

We could use a smaller cable to further increase our bandwidth. I propose we use this analog DFD to determine the range at which the frequency counter needs to be set and then use the frequency counter readout as the error signal for FOL.

http://www.ligo.caltech.edu/~misi/summary/day/20150504/

I left the arms locked last night. Looks like the drift in the Y arm power is related to the Y arm control signal being much bigger than X.

Why would it be that Y > X  ?

Koji suggested that I make a cosine fit for the curve instead of a linear fit.

I fit the data to  
where L - cable length asymmetry (27 cm) , f_b - beat frequency and v - velocity of light in the cable (2*10⁸ m/s)

The plot with the cosine fit is attached. 

Fit coefficients (with 95% confidence bounds):
       A =      0.4177  (0.3763, 0.4591)
       B =       2.941  (2.89, 2.992)