40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 129 of 330  Not logged in ELOG logo
ID Date Author Type Category Subject
  10126   Wed Jul 2 22:58:11 2014 JenneUpdateLSCLittle Bo-Peep has found her phase

Never mind.  This is just the low pass filter that Den put in to try to deal with the moving cavity pole. 

Before I realized this, just in case it was a computer quirk, Koji and I rebooted the end station front end machines.  This had no effect other than to keep me searching and measuring until I figured it out.  If I turn off the low pass, the phase pops back up to very close to the reference.  The low pass currently comes on automatically as part of the carm_cm_up script.

  10125   Wed Jul 2 21:30:42 2014 JenneUpdateLSCLittle Bo-Peep has lost her phase
Little Bo-Peep has lost her phase,
And can't tell where to find it;
Leave it alone, and it'll come home,
Bringing its degrees behind it.
 
Seriously.  What?  I was holding CARM on sqrtTrans with arm powers of about 1, DARM was still ALS diff, PRMI on REFL33.  CARM was actuating on +ETMX+ETMX, since I kept kicking the MC out of lock, but other than that, everything was set by the carm_cm_up script, so I don't think there should be any big differences.  I took a CARM transfer function, and it seems like the phase bubble has all but disappeared compared to the reference from mid-May. 

CARM_loop_ArmPowers1_2July2014.pdf

I need to figure this out before it's worth trying any acrobatic AO path turn-on scenarios.

 

Also this evening, I went to the Yend and did another tweak-up of the green beam alignment. 

  10124   Wed Jul 2 16:18:32 2014 JenneUpdateASCIFO aligned, PRMI + 2 arms achieved

After the meeting, I aligned the IFO to the IR, and then I aligned the Ygreen to the Yarm.  I then found the beatnotes and used ALS to hold the arms with CARM/DARM, locked the PRMI, and reduced the CARM offset until I had arm powers of about 3.  Given that this was at 3pm, and people were tromping all over inside the IFO room, I feel positive about tonight.  

So, IFO seems ready, carm_cm_up script was successful, and got me to arm powers of 1, and then I further reduced the offset by a bit to go a little higher. 

  10123   Wed Jul 2 16:16:45 2014 NichinUpdateGeneralLAN wire added

 [Nichin, Eric Q]

We added a new LAN wire from Rack 1Y4 to 1Y1 to connect the RF switch at 1Y1 to the martian network. The wire is labelled "To RF Switch (1Y1)"

The wire was run along the Y arm in the tray right next to the vaccum chamber, not the one on top.

 

  10122   Wed Jul 2 15:35:34 2014 ericqUpdateComputer Scripts / ProgramsLocal Chiara backups

Koji has provided a 2TB USB3 external hard drive that will get daily backups of chiara:/home/cds, the idea being that if the internal HD at /dev/sdb1 fails, we can physically open the external up, and swap the hard drive into chiara. 

We're running an rsync job on it right now, which should be done in a few hours. (USB3 is fast!)

I've also written a backup script at scripts/backup/rsync_chiara.backup which keeps its books in scripts/backup/rsync_chiara.backup.log 

I'm adding a entry to the root crontab on chiara to execute the script every day at 7am. 

 

  10121   Wed Jul 2 14:19:17 2014 SteveUpdateGeneralOphir pmeter gets new filter

Ophir power meter gets new filter with calibration. This is not cheap. It was the second time we lost it.

Filter leash is attached.

Attachment 1: ophirNewFilter.jpg
ophirNewFilter.jpg
  10120   Wed Jul 2 11:47:26 2014 SteveUpdateVACbroken changeover regulator of N2 supply

Quote:

This morning valve condition: V1, VM1, V4 and V5 valves were closed. IFO pressure rose to 1.3 mTorr

It was caused by low N2 pressure.  Our vacuum valves are moved-controlled by 60-70 PSI of nitrogen.

When this supply drops below 50-60 PSI the interlock closes V1 valve. This is the minimum pressure required to move the large valves.

It is our responsibility to check the N2 cylinder pressure supply.

The vacuum valve configuration is back to VAC. NORMAL,  CC1  4.8E-6 Torr

 

PS: Bob says that the second cylinder was full this morning, but the auto-switch over did not happen.

 The TESCOM automatic changeover regulator  [ model ACS 012-1011 ] manifold is most likely  clogged. The new one will arrive 8-8-2014

This means that the IFO pressure may go up to a few mTorr when we change cylinder or V1 valve triggered because there is no nitrogen supply.

  10119   Wed Jul 2 11:32:44 2014 Jenne, TaraVUpdatePEMStatus of seismometer stations, Yend Guralp moved

[Jenne, TaraV]

We had a look this morning at the status of the seismometer array, so that we can get it all put together. While we were looking at the Guralp at the Yend, we noticed that it was pointing the wrong way.  The North-South nubbins were pointed East-West, so X and Y coming out of the seismometer were backward.

 

To fix the Yend's Guralp, we powered off the Guralp readout box, rotated the seismometer, re-leveled it, and then turned the power back on.  Now X from the seismometer lines up with the X data channel, and similarly for Y.

The Yend Guralp has all of the cabling needed, and is installed on the granite slab.  This seismometer doesn't need any more work for now.  When we get around to it, we'll need to do some kind of thermal insulation, but other than that, it's good to go.

The Xend will also have a Guralp (Zach still has it in the Gyro lab for now).  We have the long cable that should go from the readout box to the slab that we'll need to put into the cable tray.  The short cable from the slab's plate to the seismometer is already in place.  For this seismometer, we should just need to plop the instrument in place and lay the cable in the overhead cable trays.  We should also remove the now obsolete STS-2 cable while we're doing that.  So, the Xend seismometer station doesn't need too much work.

The corner station will need more work.  Zach made for us the long cable, although he still has it in the Gyro lab, so when we get the seismometer and cable back, we'll need to lay that cable in the overhead trays.  The short cable from the slab's plate to the seismometer does not exist yet.  We want to make sure that we can feed the finished cable and connector through the hole in the slab, and then we'll solder it up out here on the EE bench.  I think this is how Den was doing things.  If not, we'll have to do the soldering in-situ, which we don't want.  So, for the corner station, we need to make the short cable, lay the long cable, get the T-240 back from Zach and put it on the slab, re-install the readout box that Zach has, etc, etc.  We should also make sure that the spaghetti pot fits on the slab, underneath the piece of metal that's sticking out over the slab.  We think that it's the same amount of clearance that the Yend pot has, so it should be okay, but we'll check.  The O-ring seems to be sitting on the MC2 chamber, so we should remember that. 

Neither the Xend nor the corner station had the yellow dog clamps, so we'll have to figure out where Den / Steve have hidden them. 

 EDIT:  We have checked, and the Guralp connector, which is larger than the Trillium connector, fits through the hole in the slab (with some disassembly), so we can solder together the short cable out here on the EE bench, and install it separately.  Eeeeexxxxxcelllent.

  10118   Tue Jul 1 21:20:37 2014 AkhilUpdateElectronicsGain plots of UFC-6000 for 0.1s Sampling Rate

 The attached are the gain plots at carrier frequencies of 100 MHz, 500 MHz and 1 GHz measured using IFR 2023B (Marconi).

Attachment 1: gain.png
gain.png
Attachment 2: gain.pdf
gain.pdf
  10117   Tue Jul 1 18:06:13 2014 nichinUpdateComputer Scripts / ProgramsNetwork Analyzer NWAG4395A data acquisition

EDIT: The script and template file have been moved to /opt/rtcds/caltech/c1/scripts/general/netgpibdata/

 

___________________________________________________________________________________________________________

The NEW and IMPROVED script for remotely getting data from Agilent 4395A network analyzer is located at /users/nichin

This script is quite different from the one in Elog 10108 and fetches us both magnitude and phase. There is an added feature of setting the IF Bandwidth.

The network analyzer is located at crocetta.martian (192.168.113.108)

How to run the script:

> python NWAG4395A_data_acq.py [filename.yml]

  1. The script accepts sweep parameters and output options via a .yml file that is written following a template that can be found at /users/nichin/NWAG4395A_parameters.yml
  2. The data obtained is stored as a .dat file and the corresponding details regarding the acquired data is in a .par parameter file
  3. Separate .dat and .par files are created for phase and magnitude of voltage data.
  4. You can choose to get a plot of the data obtained by specifying it in the .yml file. The plots are automatically stored as PDF.
  5. Plots, data and parameter files are all stored in a new folder that is created with a timestamp in its name.
  6. NOTE: Plotting options are only available in computers running numpy versions of 1.6.0 or above.(Currently only Ottavia and Chiara)

Test Run:

I connected a simple 2MHz Low pass filter between the modulation output and signal input of the NA and ran a scan from 100KHz to 20MHz. The script was run from Ottavia.

The expected plot was obtained and is attached here.

Current work:

Setting up the RF switch in rack 1Y1 to select between required PDs and scripts to tell it which channel to choose over the Ethernet.

 

Attachment 1: LPF2_01-07-2014_175443.pdf
LPF2_01-07-2014_175443.pdf
  10116   Tue Jul 1 13:57:33 2014 ericqUpdateComputer Scripts / ProgramsMC Autolocker on Megatron

 Just a quick update on the status of the auto locker:

The auto locker now runs and respawns automatically on megatron, through ubuntu's "upstart" init system, instead of cron. 

  • The autolocker script itself is:/opt/rtcds/caltech/c1/scripts/MC/AutoLockMC.csh
  • The startup script called by the upstart system is: /opt/rtcds/caltech/c1/scripts/MC/AutoLockMC.init
  • The upstart configuration is: /etc/init/MCautolocker.conf
  • The auto locker is started by executing this command on megatron: sudo initctl start MCautolocker

This was pretty simple to set up, once I figured out how to provide the necessary environment variables in AutoLockMC.init 

  10115   Mon Jun 30 22:40:21 2014 ManasaUpdatePSLAOM ringdown

Quote:

Quote:

I would like to measure the switching time of the AOM. So I have disconnected the modulation input to the AOM that comes from the ISS. I have also turned OFF the SR560's and the AWG that belong to ISS. 

Pics and cable connections of the state in which the ISS setup was left at, will be updated soon.

I installed a fast PDA10CF along the path of a leaking beam from one of the steering mirrors that direct the main beam to the PMC. This beam was dumped to a razor blade. I removed the razor blade and installed a Y1 to steer this beam through a lens on the PD.

Pics of the layout post-installation will be updated.

Also, I tested the AOM by giving it 0-1V modulation input from the AWG. This has been disconnected after the test. So everything should be as it was pre-testing.

Edit/manasa/ Data has not been fit correctly in here. A proper fit will follow this elog.

Proper fits and numbers are here :elog

Earlier last week I had tried to measure the AOM ringdown and concluded I could not make one.

I was proved wrong and I was able to make a measurement. I am still not sure why I was not able to make the measurement earlier with the very same settings and configuration.

What I did:

I gave the AOM a 0-1V modulation input using the signal generator (50 ohm feedthrough bnc was used to impedance match the AOM driver's modulation input). For the measurement here I used a 1Hz square wave. I used a 300MHz oscilloscope to look at the falling edge of the ringdown PD output installed.

I recorded a few ringdown samples. To get a quick number, I fit one such sample to find the AOM switching time as 1.48us (Plot attached). 

Attachment 1: AOM_ringSample1.pdf
AOM_ringSample1.pdf
  10114   Mon Jun 30 22:06:55 2014 JenneUpdateASCIFO (mostly) aligned - ASS working

[Koji, Jenne]

The Yarm ASS is now working (as is the Xarm ASS).  Both of the TT's pitch servos had a sign flip.  We don't know why.

To start, we lowered the matrix elements that push on the TTs by a factor of 3, to compensate for the new factor of 3 in the slider gains:  ezcastep C1:ASS-YARM_OUT_MTRX_5_5 /3 C1:ASS-YARM_OUT_MTRX_5_7 /3 C1:ASS-YARM_OUT_MTRX_6_6 /3 C1:ASS-YARM_OUT_MTRX_6_8 /3 C1:ASS-YARM_OUT_MTRX_7_5 /3 C1:ASS-YARM_OUT_MTRX_7_7 /3 C1:ASS-YARM_OUT_MTRX_8_6 /3 C1:ASS-YARM_OUT_MTRX_8_8 /3

We turned off all 4 tip tilt ASS servos (in the Yarm ASS servo screen), and turned them on one at a time.  By doing this, we discovered that the pitch servos for both TT1 and TT2 needed to have the opposite sign from what they used to have.  However, the yaw servos kept the original signs.  It really doesn't make sense to me why this should be, but this is the way the ASS servo works.  We left both Xarm and Yarm ASSs on for several minutes, and saw that they didn't push any mirrors out of alignment.

The ASS_DOTHER_ON burt snapshot has been resaved with the new values.

 

Also, earlier this evening, I aligned the Yarm green beam to the cavity, although the cavity was not optimally aligned, so this needs to be re-done.

 

On our to-do list should be to add the tip tilt slider values to the DAQ channels list.

  10113   Mon Jun 30 16:55:24 2014 ericqUpdateGeneralIFO (mostly) aligned

IR Alignment of the IFO is recovered! Green alignment could use some attention. 

Arms and PRC hold well, powers are within normal ranges. (TR[X,Y] >.9, POP110I > 400)

Details:

  • Starting from where Koji had brought things (i.e. beams on REFL, AS), I gradually stepped the PRM back to where I had a PRC lock right before the bootfest, using SUSPIT_IN and SUSYAW IN, while stepping the TT pointing (arbitrarily shifting TT1 and TT2) to keep the REFL camera spot centered. 
  • Green was locked fairly well to the Yarm (GTRY = 0.8), so I knew it supported a mode. I misaligned ITMX to keep the Xarm out of the way. 
  • Adjusting TT1 and TT2, I was able to get some light on the POP camera, while keeping REFL spot visible with small adjustments to PRM
  • I set up the PRM to set up some PRM-ITMY retroreflection, and saw tiny flashes in TRY. 
  • From here, I wandered around with the tip-tilts to try and get better arm pointing, while tweaking PRM for the REFL spot and retroflection, and BS for the AS spot. I got this to TRY flashes of ~0.3

Then, Jenne took over, worked some alignment magic, and did the hard part of getting the Yarm locked and ASS'd. 

  • I then took back over and got the Xarm locked and ASS'd.
  • I saved relevant mirror positions, and set up the PRMI, got it locked, saved PRM position. 
  • Jiggled the BS/PRM oplev HeNe power connector, it turns on now, oplevs are working. 
  • Similar to TT1, TT2 gains for PIT and YAW are now 300. Strictly speaking, they don't have to be, but PIT would be very nearly railed, and I changed YAW so that all four gains would be consistent.

Caveats:

Green no longer locks to 00 on the Y-arm, and the X-arm green transmission isn't the best despite PZT fiddling (~.6). Also, when green is locked to the Xarm, I see a distinct circular spot on the GTRY camera, with Y green and PSL green shutters closed. 

While Jenne used Yarm ASS successfully, when I run it now, it slowly pushes things out of alignment, and two of the traces (YARM_ETM_YAW_L_DEMOD_I_OUTPUT, and the same for ITM) have a reasonable constant offset that doesn't move away. 

 

  10112   Mon Jun 30 10:06:39 2014 SteveUpdateVAClow on pneumatic pressure of vacuum valves

This morning valve condition: V1, VM1, V4 and V5 valves were closed. IFO pressure rose to 1.3 mTorr

It was caused by low N2 pressure.  Our vacuum valves are moved-controlled by 60-70 PSI of nitrogen.

When this supply drops below 50-60 PSI the interlock closes V1 valve. This is the minimum pressure required to move the large valves.

It is our responsibility to check the N2 cylinder pressure supply.

The vacuum valve configuration is back to VAC. NORMAL,  CC1  4.8E-6 Torr

 

PS: Bob says that the second cylinder was full this morning, but the auto-switch over did not happen.

Attachment 1: runoutofN2.png
runoutofN2.png
Attachment 2: lowN2.png
lowN2.png
Attachment 3: N2d100.png
N2d100.png
  10111   Mon Jun 30 00:18:15 2014 NichinUpdateComputer Scripts / ProgramsUpdated script for acquiring data from Agilent 4395A network analyzer

Quote:

 

RXA: I've deleted your plot because it didn't meet the minimal Bode plot standards. Please look up "Bode Plot" using Google/Wikipedia and try to follow some good example. Bode plot should contain Phase as well as magnitude. Also, the axes must be labeled with some physical units.

Sorry Rana for not giving much attention to the plot. I will definitely change the way they are being plotted.

I was more focused on getting the data acquisition to work. Also, the current script gets only the magnitude and not the phase... I still have to work on that.

  10110   Fri Jun 27 23:49:56 2014 KojiUpdateGeneralIR beam found, TTs not aligned well yet

The IR beam was found on the PRM surface, some CCDs, and in the X arm. The TTs are not aligned well yet.

I'm leaving the IFO with the following state.


Status:

ITMY/ETMY - aligned to the given green beam. GTRY (no PSL green) 1.0~1.1

ITMX/ETMX - aligned to the green beam. The end PZT for the green beam was steered to have maximum GTRX (0.76 without PSL green)

TT1/TT2 - unknown alignment, TT1/TT2 are related such that the spot is on the POP CCD

PRM - aligned to the given IR beam (i.e. PRM spot on the REFL CCD)

BS - aligned to the given IR beam (i.e. ITMX spot on the AS CCD, The X arm is flashing)


Notes:

- ITMX was stuck in the suspension. it was caused by the EQ.

- When the X arm was aligned to the green beam, there was no green hitting on the GTRX PD. That's why the end PZT was adjusted.

- In order to earn more range for TT1, C1:IOO-TT1_YAW_GAIN and C1:IOO-TT1_PIT_GAIN were increased to 300 (100 nominal) and the limiter (at 500) were removed.

- The HeNe laser for BS/PRM does not emit the beam even with the driver turned on. Is there a hidden shutter or something? ==> Jenne

 


TO DO:

- Find the Y arm fringe by moving TT1 and TT2 without loosing the PRM/AS/POP spots.

 

  10109   Fri Jun 27 20:52:30 2014 KojiUpdateCDSOTTAVIA was not on network

I came in the lab. Found bunch of white EPICS boxes on ottavia.
It turned out that only ottavia was kicked out from the network.

After some struggle, I figured out that ottavia needs the ethernet cable unplugged / plugged
to connect (or reconnect) to the network.

For some unknown reason, ottavia was isolated from the martian network and couldn't come back.
This caused the MC autolocker frozen.

I logged in to megatron from ottavia, and ran at .../scritpt/MC

nohup ./AutoLockMC.csh &

Now the MC is happy.

  10108   Fri Jun 27 18:07:38 2014 NichinUpdateComputer Scripts / ProgramsUpdated script for acquiring data from Agilent 4395A network analyzer

The updated script for remotely getting data from Agilent 4395A network analyzer is located at /users/nichin

This network analyzer device is located at crocetta.martian (192.168.113.108)

How to run the script:

> python NWAG4395A_modified.py [filename.yml]

  1. The script accepts sweep parameters and output options via a .yml file that is written following a template that can be found at /users/nichin/NWAG4395template.yml
  2. The data obtained is stored as a .dat file and the corresponding details regarding the acquired data is in a .par parameter file
  3. You can choose to get a plot of the data obtained by specifying it in the .yml file. The plots are automatically stored as PDF.
  4. Plots, data and parameter files are all stored in a new folder that is created with a timestamp in its name.
  5. NOTE: Plotting options are only available in computers running numpy versions of 1.6.0 or above. The plotting sections of the code worked on Chiara, which has a 1.6.1 numpy, but did not work on Rossa which only had 1.3.0 numpy. Anyway, I have added an extra function that checks the version and skips the plotting part if needed.

Test Run:

I connected a simple 2MHz Low pass filter between the modulation output and signal input of the NA and ran a scan from 0Hz to 20MHz. The script was run from Chiara.

The expected plot was obtained and is attached here.

Further work:

I now have to work on setting up the RF switch in rack 1Y1 to select between required PDs and also on the code that chooses which channel is being selected.

There is also a problem of 2 8x1 RF switches being present, instead of one 16x1. Alex's code for RF switching does not take this into account.

RXA: I've deleted your plot because it didn't meet the minimal Bode plot standards. Please look up "Bode Plot" using Google/Wikipedia and try to follow some good example. Bode plot should contain Phase as well as magnitude. Also, the axes must be labeled with some physical units.

  10107   Fri Jun 27 12:54:13 2014 AkhilUpdateElectronicsGain plots of UFC-6000 for 0.1s Sampling Rate

 Finally, the 0.1s sampling rate of the frequency counter(FC) has been achieved. For this I had to :

 Send in byte codes to set a particular range of the frequency counter.

I was digging  in to find how exactly the circuit inside the frequency counter works and how the processor inside is able to read and write bytes through a HID-USB interface. I found out that the 'AutoRange' setting (which I have been using so far) has an independent  multiplexing circuit  which consumes some time(that varies with the drift in frequencies) and thus, the the processor waits for some specific time for this process and cannot reach the minimum 0.1 s sampling time. To mitigate this issue, I set the range bytes to the appropriate range of frequencies so that I can bypass the MUX  delay. Here is the list of Range and frequencies for the FC:

Range 1:    1 - 40 MHz

Range 2:    40 - 190 MHz

Range 3:    190 - 1400 MHz

Range 4 :   1400 - 6000 MHz

I then took measurements for sampling time of 0.1 s at carrier frequencies of 5 MHz and 25 MHz from SRS DS345  and plotted the improvised gain plots(attached) to those in my previous elog(10070)  with the same procedure mentioned before.

 

To do Next:

Plot the gain plots for higher carrier frequencies till range 3 using Marconi Function generator.

Write the data from FC into C1: ALS-Y_SLOW_SERVO1_OFFSET EPICS channel.

 

 

Attachment 1: Sampling-0.1s.pdf
Sampling-0.1s.pdf
Attachment 2: 12.png
12.png
  10106   Fri Jun 27 10:09:10 2014 HarryUpdateGeneralBeam Waist Measurement

Purpose

To use a razorblade to measure beam waist at four points along the optical axis, so as to later extrapolate the waist. This information will then be used to effectively couple AUX laser light to fibers for use in the frequency offset locking apparatus.

Data Acquisition

1) Step the micrometer-controlled razorblade across the beam at a given value of Z, along optical axis, in the plane orthogonal to it (arbitrarily called X).

2) At each value of X, record the corresponding output of a photodiode, (Thorlabs PD A55) here given in mV.

3) Repeat in Y plane at the same value of Z

4) Repeat process at multiple points along Z

Analysis

Data from each iteration were fitted to the error function shown below.

y(x) = (.5*P)*(1-erf((sqrt(2)*(x-x0))/wz))

'P' corresponds to peak power, 'x0' to the corresponding value of x (or y, as the case may be), and 'wz' to the spot size at the Z value in question.

The spot sizes from the four Z values were then fit to:

y(x) = w0*sqrt(1+((x*x)/(zr*zr)))

Where 'w0' corresponds to beam waist, and 'zr' to Rayleigh Range.

Conclusion

This yielded a Y-Waist of 783.5 um, and an X-Waist of 915.2 um.

The respective Rayleigh ranges were 2.965e+05 um (Y) and 3.145e+05  um (X).

Next

I will do the same analysis with light from the optical cables, which information I will then use to design a telescope to effectively couple the beams.

Attachment 1: BeamWaist.zip
  10105   Wed Jun 25 20:45:04 2014 NichinUpdateElectronicsAS55 Bodeplot

 [Nichin]

I finally did carry out a measurement on the network analyzer. This proves that the previous system will work properly. Just the optical splitter problem is to be taken care of.

For this, after Elog 10102, I did not touch any of the tables or photodiodes. Only turned on the laser at 1Y1 and took readings from the NA located nearby. I switched off the laser after measurements. The power to REF PD remains on.

I plotted transimpedence plots in the usual way and got ridiculous values of 15 ohms at 55MHz. Obviously there is the problem of varying amount of power illuminating the REF PD and AS55.

So, I just plotted the bode plots of transfer function got from the NA to check if the characteristics of AS55 looks as it was supposed to be and Yes! I got a nice peak at 55MHz.

 

Acquiring data

 RACK 1Y1

  • Diode Laser driving current: 240mA 
  • The following conditions were set on Network Analyzer Agilent 4395:

 

1) Frequency sweep range: 1MHz to 100 MHz.

2) Number of Points sampled in  the range: 801

3) Type of sweep: Linear

  • Set the NA to give the corresponding transfer function value (output of AS55 over output of 1611) and also Phase response in degrees.
  • Save the data into floppy disk for processing on the computer.

 

 

The experimental values obtained were:

DC output voltage of REF PD: 7.48V

DC output voltage of AS55: 53.7mV

Power incident on REF PD and AS55 respectively: 2.4mW  and 1.6mW

Taking the DC transimpedence of AS55 as 66.2 ohms (from schematic given at D1300586-v1) and for REF PD as 1E04 ohms

Hence, Responsivity for REF PD and AS55 respectively are:  0.312 A/W and 0.51 A/W

 

The data and code used are in the zip file.

Attachment 1: AS55_06-25-2014.zip
Attachment 2: AS55_bodeplot.pdf
AS55_bodeplot.pdf
  10104   Wed Jun 25 19:29:19 2014 AkhilUpdateElectronicsAnalog-to-Digital Converter

 I have been trying to use an ADC with the Raspberry Pi to be able to measure the phase difference between FC input and output signals.I had a hard time interfacing the ADC  with the Pi (setup attached) even after trying to debug the issue for last two days. So I and Eriq Q performed a system reboot on the Pi and tried all the possible ways for the Pi to detect the ADC but we were not able to. At the end we decided to order another IC(Microchip MCP 3008) which we hope can be interfaced with the Pi. Till then I will finish to write data from the FC into pipes so that the control computers can access the real time data. I will also look the correctness of the sampling time that is provided by the spec of the MCL-Mini circuits that is if we could really achieve 0.1 s sampling time with the FC.

Attachment 1: IMG_1496.png
IMG_1496.png
  10103   Wed Jun 25 17:49:36 2014 HarryUpdateGeneralRazorblade Analysis Pt. 2

Reconfigured razorblade analysis setup on the PD table as per instructions. Used it to collect data to calculate beam waist with, analyses to follow.

See attached schematic for optical setup.

Attachment 1: RazorbladeSetup.pdf
RazorbladeSetup.pdf
  10102   Wed Jun 25 17:13:10 2014 NichinUpdateElectronicsLaser power check - PDFR system

[Nichin, Manasa]

I wanted to make sure Alex's system of Diode laser + laser controller + optical splitter was working fine and then make a manual measurement for AS55 PD. Manasa was supervising my work and helping me with unhooking the fibers and taking power meter readings. I have tuned on the power to REF DET from under the POY table.

I switched on the laser sitting in the 1Y1 rack and turned up the driving current to 240mA. On checking the laser power readings at AS55 (AS table) and REF DET (POY table) simultaneously, we got readings of 1.6mA and 2.4mA respectively. This much difference in readings was not expected and I did not continue taking the readings for transimpedence measurement.

I will rectify if this unequal splitting of power by the 1x16 optical splitter is going to cause any difficulties for the automated PDFR system measurement technique and resolve it if needed.

 

  10101   Wed Jun 25 14:52:22 2014 Andres MedinaUpdateelogPlacing a lens between the steering mirrors and another lens between the second steering mirror and the cavity

 I was asked to calculate the lenses that we need in order to obtained a Gouy phase close to 90 degrees between the two mirrors that are in the Xend green. Yesterday, I measured the distances between the mirrors, and the distance between the mirror relative to the cavity as illustrate in the image attached below. I looked in to the 40m elog and Manasa did the last update on the length of the cavity. She measured 37.7 + 0.05m. The waist size of the beam that was measured by Annalisa in ID 8637 after the Faraday was w0=2.943e-5m @ -0.039m. I calculated the waist size inside the cavity, and I found a waist of w0=2.2 mm. My plan this week is to keep working in the calculation and finish all the calculation this week so that next week I can go inside and place the lenses. 

Attachment 1: SchematicForXendGreenGoingToTheCavity.pdf
SchematicForXendGreenGoingToTheCavity.pdf
  10100   Wed Jun 25 09:30:44 2014 HarryUpdateGeneralWeekly Update

See attached weekly update

Attachment 1: Weekly_Update—June_25_thru_July_1.pdf
Weekly_Update—June_25_thru_July_1.pdf
  10099   Wed Jun 25 09:17:33 2014 Harry, ManasaUpdateGeneralRazorblade Beam Analysis Setup

Quote:

Harry will update this elog with details about his beam waist measurements for the old NPRO on the SP table.

 see http://nodus.ligo.caltech.edu:8080/40m/10098 for the update

  10098   Wed Jun 25 09:16:52 2014 HarryUpdateGeneralRazorblade Measurements

Purpose

To use a razorblade to measure beam waist at multiple points along the optical axis, so as to later extrapolate the modal profile of the entire beam. This information will then be used to effectively couple AUX laser light to fibers for use in the frequency offset locking apparatus.

Data Acquisition

1) Step the micrometer-controlled razorblade across the beam at a given value of Z, along optical axis, in the plane orthogonal to it (arbitrarily called X).

2) At each value of X, record the corresponding output of a photodiode, (Thorlabs PD A55) here given in mV.

3) Repeat process at multiple points along Z

Analysis

Data from each iteration in the X were fitted to the error function shown below.

V(x) = A*(erf((x-m)/s)+c)

In the Y, they were fitted to:

V(x) = -A*(erf((x-m)/s)+c)

'A' corresponds to an amplitude, 'm' to a mean, 's' to a σ, and 'c' to an offset.

(Only because in Y measurements, the blade progressed toward eclipsing the beam, as opposed to in the X where it progressively revealed the beam.

These fits can be solved for x = (erf-1((V/A)-c)*s)+m1  which can be calculated at the points (Vmax/e2) and (Vmax*(1-1/e2)). The difference between these points will yield beam waist, w(z).

Conclusion

Calculations yielded waists of: X1=66.43um, X2=67.73um, X3=49.45um, Y1=61.20um, Y2=58.70, Y3=58.89

These data seem suspect, and shall be subjected to further analysis.

 

Attachment 1: 40m.zip
  10097   Wed Jun 25 02:01:21 2014 NichinSummaryGeneralWeekly Report

 Attached is the weekly work plan / equipment requirement / lab expert's presence needed for the upcoming week.

Attachment 1: Nichin_Week4_update.pdf
Nichin_Week4_update.pdf Nichin_Week4_update.pdf
  10096   Wed Jun 25 01:18:24 2014 AkhilUpdateelogWeekly Update

 Plans for the Week:

  • Phase and noise characterization of the UFC RF Frequency Counter.
  •  Characterization of the temperature actuator.

Progress and Problems Faced:

  • Since past two days, I have been trying to measure the phase difference between the input and output signals of the FC using a 16 bit ADC ADS1115 (for input phase measurement) on Raspberry Pi(RPI).For that I have assembled a Circuit on a breadboard( Details will be mentioned in my next eLog). 
  • The interfacing and the codes seem to be alright but the RPI is not able to detect the address of the ADC chip. I will try to debug the issue as soon as possible and try to take data through the Pi so that I can have both delay and noise introduced by the FC.
  • Now since the minimum sampling time of the FC has been brought down to 0.1s, I will test how accurately the FC is writing values every 0.1 s for a modulating input.
  • The output data of the FC will be fitted into the input and the order of accuracy will be presented.Also the gain plots will be plotted at higher frequencies like 50 MHz, 100 MHz, 500 MHz and 1000 MHz using the network analyzer.

Work Inside the Lab:

  • On Friday Morning I will  go inside the  lab with Manasa to make measurements from the NPRO to characterize its response to the temperature.
  • I will be in the lab in the morning session(9 am- 1 pm) and make the required measurements. I will then analyze the data and by the end of the week will finish characterization of the FC and temperature actuator.
  • For the rest of the time in this week, I'll be on my desk and will not be entering  the lab.

Electronics Required:

  • I will require the network analyzer on Wednesday and Thursday to make measurements at higher frequencies(30 MHz <F<1000 MHz) from the R PI.

Goal- By the end of the week:

  • To characterize both the FC and the NPRO that would go into the FOL-PID loop.
  • The FC will be ready to replace the network analyzers that are currently being used in the 40m.

 

 

 

 

 

  10095   Tue Jun 24 22:46:15 2014 ericqUpdateComputer Scripts / Programsop340m crons

Quote:

The FSSSlowServo.pl now seems to be holding the NPRO PZT to ~6 V. I twiddled the PID settings a little bit to make sure nothing was squirrelly. Seems OK. Time constant of the loop is ~1 minute.

As a reminder, op340m runs our autoburt for all the FE machines, VME IOCs, does the watchdog threshold rampdown, and also the RefCav and NPRO temperature control.

 We had fiddled with the scripts/general/scripto_cron script to try and get the MC auto locker working on ottavia, but in doing so broke op340m's reliance on it to run it's cron jobs, like FSSSlowServo.

I've reverted scripto_cron to its original state, and the FSS slow servo starts up again.  

However, scripts like this that we want to always have on seem to be a better fit, to me, for the init system, like we do with daqd and nds on the FB. op340m's inittab looks different than what I'm used to, so I'm not making any changes; this is just a thought. 

MC autolocker is still being ran from an Ottavia GUI terminal; I'll try to get it consistently running on megatron, as suggested in  ELOG10039, now that caget/caput issues seem to be sorted. 

Addendum: I've changed the MC auto locker script to have megatron as its host. Haven't yet gotten it to run automatically; it's running in a detached tmux terminal. I'll finish it up tomorrow. 

  10094   Tue Jun 24 18:35:53 2014 JenneUpdateLSCStill no beam going to IFO

[Jenne, EricQ, Manasa]

We are still not able to get the beam to go to the interferometer, which is super frustrating. 

We tried using cameras and viewers to look into several ports, however all we can see is the face of MMT1, which I  posted a still of last night.  I have a camera looking at the back of the PRM, in hopes that we could see the beam on PRM, but no luck.  The thought was that the lever arm between TT2 and PRM is so short that as long as TT2 is reasonably in the center of its range, it doesn't need to be precise.  However, it seems that no matter how much I move TT1, I am not able to get a nice beam spot on PRM.  Part of this is that we have to be close enough to the right alignment to hit MMT1, MMT2 and TT2. 

Anyhow, we're frustrated, and I'm not sure what our next step is.  I would very much prefer it if we didn't have to open any chambers, but I don't currently have any new ideas on how to see the spot on MMT2 or TT2.

  10093   Tue Jun 24 16:52:43 2014 NichinUpdateElectronicsAn RF cable re-installed

Quote:

 [Nichin, Eric G]

As mentioned in Elog 10062, we found RF cables running between demodulators in rack 1Y2 and RF switch in 1Y1 to have bad SMA connectors (No shield / bad soldering / no caps).

we pulled out all the cables belonging to PD frequency response measurement system , 8 in total, and all of them about 5.5m in length.

Their labels read :

REFL33, REFL11, REFL55, AS55, POX11, REFL165, POP22 and POP110. 

All of them are now sitting inside a plastic box in the contorl room.

On another note, instead of fixing all the cables ourselves, Steve and Eric G decided to order custom made RF cables from Pasternack as professionally soldered cables are worth it. We have placed an order for 2 cables (RG405-550CM) to check out  and test them before we order all of the cables.

 The new RF cables arrived. But unfortunately we did not realize that RG405 was a Semi-rigid coax cable, with a copper shielding. These are meant to be installed in setups that will not be changed / disturbed. We need to order a different set of cables. The new cables have joined the other cables in the plastic box mentioned above.

For now to check if the old setup is still working, I have installed an RF cable (that we earlier pulled out and looks like in good shape, labelled REFL33) between the AS55 Demodulator output PD RF MON in rack 1Y2 and the network analyzer input. Since Manasa and the others were busy working with the interferometer, I did not switch on the laser and did not take any readings. The power supply to REF DET remains off.

I will continue with the measurements tomorrow morning and also try to get the data wirelessly using Alex's code. 

  10092   Tue Jun 24 13:04:49 2014 Harry, ManasaUpdateGeneralRazorblade Beam Analysis Setup

Harry will update this elog with details about his beam waist measurements for the old NPRO on the SP table.

  10091   Tue Jun 24 13:02:54 2014 ManasaUpdatePSLRingdown PD installed

Quote:

I would like to measure the switching time of the AOM. So I have disconnected the modulation input to the AOM that comes from the ISS. I have also turned OFF the SR560's and the AWG that belong to ISS. 

Pics and cable connections of the state in which the ISS setup was left at, will be updated soon.

I installed a fast PDA10CF along the path of a leaking beam from one of the steering mirrors that direct the main beam to the PMC. This beam was dumped to a razor blade. I removed the razor blade and installed a Y1 to steer this beam through a lens on the PD.

Pics of the layout post-installation will be updated.

Also, I tested the AOM by giving it 0-1V modulation input from the AWG. This has been disconnected after the test. So everything should be as it was pre-testing.

Attachment 1: PSL_ringdown.png
PSL_ringdown.png
  10090   Tue Jun 24 01:07:56 2014 JenneUpdateLSCBootfest 2014!

Still no real luck getting the beam back aligned to the IFO.

Koji and I tried a few minutes of wiggling the input pointing tip tilts (TT1 and TT2) around, and then tried doing some thinking.

We note that the beam propagates (modulo a few pickoffs):

IMC -> Faraday -> TT1 -> MMT1 -> MMT2 -> TT2 -> PRM.

Since moving TT1 to the rails does make beam reflections in the BS chamber move (as seen by movement of the general illumination on the PRM face camera), I posit that the beam is getting through the Faraday.  It is certainly getting at least mostly through the Faraday, although since the MC locked so easily, I assume that we didn't have too much movement after the ~2pm Alaskan earthquake & aftershocks, so we're at pretty much the same alignment as usual, in terms of beam pointing coming from the IMC.

The plan is then to see the position of the beam on MMT1, and steer using TT1 to get the beam to roughly the center.  Then, see the beam propagate to MMT2 (if possible) and TT2 (if possible).    From here, we should be able to see the spot on PRM.  We should be able to use TT2 to tweak things up, and get the beam back to about the right place on POP, or REFL, or somewhere farther along.  Hopefully at this point, we'd see some flashes in the Yarm. 

Using a spare Watek camera, I was able to capture a shot of the face of MMT1.  This is when the TTs were restored to their values that were saved last Monday.  I checked, and this is also roughly the center of the actuation range of TT1, for both pitch and yaw.

MMT1_face_23June2014_2315pm.png

I am not able to see the face of MMT2, or TT2.  If I leave TT1, and move TT2, I am not able to see any movement of any beam or reflections seen in the PRM face camera.

Koji and I are checking the MC spot positions, but it may be time to leave this for the morning crew.

EDIT:  The MC spots were actually pretty bad, and the WFS were working really hard.  Koji realigned the MC suspensions, and now the MC spots are slightly better, although quite similar, to what Manasa measured last week.  The restored TT values still don't give us any flashes in the arms.

  10089   Mon Jun 23 21:16:14 2014 NichinUpdateElectronicsTransimpedence measurement-BBPD

  [Nichin, Koji] 

Today evening, me and koji decided to get down to the problem of why the trasimpedence plots were not as they were supposed to be for Broadband photodiode (D1002969-v8) S1200269. There were a few problems that we encountered:

  • Turns out the REF PD was not illuminated properly, for maximum output. The DC output voltage turned out to be much higher than the previous measurement. Since I assumed that the REF PD had not been touched since the first day I took readings, I did not check this.
  • The fork holding the Test PD was a bit out of shape and only one side of it was clamping down the PD. This made the PD vulnerable swivel about that one side. We replaced it with a new one.
  • I was setting the current diving the Jenne laser to about 20mA and this resulted in nocthes at higer frequencies in the network analyzer due to over driving of the diode laser. Once we reduced this to about 12.5-13 mA they disappeared. Also, the current limit setting was set at 40mA which is way too high for the jenne laser and might have resulted in damaging it if someone had accidentally increased the current. We have now set it at 20mA.

After these changes the measurements are as follows:

I moved the NA from near rack 1Y1 to the Jenne laser table. 

 Acquiring data

  • Jenne Laser driving current: 12.8mA 
  • The following conditions were set on Network Analyzer Agilent 4395:

 

1) Frequency sweep range: 1MHz to 300 MHz.

2) Number of Points sampled in  the range: 801

3) Type of sweep: Logarithmic

  • Set the NA to give the corresponding transfer function value (output of BBPD over output of 1611) and also Phase response in degrees.
  • Save the data into floppy disk for processing on the computer.

 Results

DC output voltage of REF PD: 0.568V

DC output voltage of BBPD: 18mV

Power incident on REF PD and BBPD respectively: 0.184mW  and 0.143mW

Hence, Responsivity for REF PD and BBPD respectively:  0.315 A/W and 0.063 A/W 

Responsivity given in the Datasheet for REF PD and BBPD : 0.68 A/W and 0.1 A/W

 

 

The reason for these differences are unknown to me and must be investigated.

The Plots of transimpedence obtained are attached. The data and matlab code used is in the zip file.

The transimpedance of  Broadband photodiode (D1002969-v8) S1200269 was around 1kV/A-2kV/A for most of the range, but the value started falling as the frequency approached 100 MHz. This BBPD is best when used at 10-30 MHz.

Attachment 1: BBPD_transimpedence_06-23-2014.pdf
BBPD_transimpedence_06-23-2014.pdf
Attachment 2: BBPD_readings_06-23-2014.zip
  10088   Mon Jun 23 20:58:38 2014 ericqUpdateCDSBootfest 2014!

This afternoon, I wanted to start the nominal alignment/adjustment steps for evening time locking, but got sucked into CDS frustrations. 

Primary symptom: TRX and TRY signals were not making it from C1:SUS-ETMX_TR[X,Y]_OUT to C1:LSC-TR[X,Y]_IN1. Various RFM bits were red on the CDS status page. 

 Secondary symptom: ITMX was randomly getting a good sized kick for no apparent reason. I still don't know what was behind this. 

First fix attempt: run sudo ntpdate -b -s -u pool.ntp.org on c1sus and c1lsc front ends, to see if NTP issues were responsible. No result.

Second fix attempt: Restart c1lsc, c1sus and c1rfm models. No change

Next fix attempt: Restart c1lsc and c1sus frontend machines. c1lsc models come back, c1sus models fail to sync / time out/ dmesg has some weird message about ADC channel hopping. At this point, c1ioo, c1iscey and c1iscex all have their models stop working due to sync problems. 

I then ran the above ntp command on all front ends and the FB, and restarted everyone's models (except c1lsc, who stayed working from here on out) which didn't change anything. I command-line rebooted all front ends (except c1lsc) and the FB (which had some dmesg messages about daqd segfaulting, but daqd issues weren't the problem). Still nothing. 

Finally, Koji came along and relieved me from my agony by hard rebooting all of the front ends; pulling out their power cables and seeing the life in their lights fade away... He did this first with the end station machines (c1iscey and c1iscex), and we saw them come back up perfectly happy, and then c1ioo and c1sus followed. At this point, all models came back; green RFM bits abounding, and TR[X,Y] signals propagating through as desired. 

Then, we tried turning the damping/watchdogs back on, which for some strange reason started shaking the hell out of everyone except the ETMs and ITMX. We restarted c1sus and c1mcs, and then damping worked again. Maybe a bad BURT restore was to blame?

At this point, all models were happy, all optics were damped, mode cleaner + WFS locked happily, but no beams were to be seen in the IFO 

The Yarm green would lock fine though, so tip-tilt alignment is probably to blame. I then left the interferometer to Jenne and Koji. 

  10087   Sat Jun 21 01:46:28 2014 NichinUpdateElectronicsBBPD Transimepedence plot

Sorry for the late update Koji.

There was a bug in my code that was pointed out by koji and here is the revised plot of transimpedence. The correct code attached.

The transimpedence value is unusually high, about 50kV/A-70kV/A for most of the range. The same was observed when the transimpedence was calculated on another BBPD in Elog.

It is highly unlikely that both the BBPDs are faulty and might be because I am doing the calculations wrong. Must dig deeper into this. Maybe it is a good idea to try the shot noise method of calculating the transimpedence and see how the values turn out. Will do that ASAP.

Attachment 1: BBPD_06-18-2014.pdf
BBPD_06-18-2014.pdf
Attachment 2: BBPD_readings_06-18-2014.zip
  10086   Sat Jun 21 01:25:12 2014 NichinHowToElectronicsPD Trasimpedence measurement theory

 Here is the logic that I have been using to calculate the transimpedence of PDs. Please let me know if you think anything is wrong.

Attachment 1: Transimpedence_Calculation_.pdf
Transimpedence_Calculation_.pdf
  10085   Fri Jun 20 19:09:23 2014 KojiUpdateElectronicsTransimpedence measurement-BBPD

Oh, nice! This must be a new technique to have a higher transimpedance by breaking the PD.

Now both BBPDs are showing abnormally high impedance.
(Remember, you have not revised your
previous entry after my pointing out you have a bug in the code.)

You should break down the measurement into each raw numbers for validation.
And if this high impedance is still true, you should point out what is causing of this anomaly.

  10084   Fri Jun 20 19:07:44 2014 ranaUpdateComputer Scripts / Programsop340m DNS

I had forgotten to fix the DNS setup on op340m and so our slow, perl, PID loops for the laser were not running well (and that's why the FSS-FAST has been saturating).

I edited /etc/resolv.conf on there and then did /usr/sbin/reboot as super-user.

op340m:~>more /etc/resolv.conf
domain martian
nameserver 192.168.113.104
nameserver 131.215.125.1
nameserver 131.215.139.100
nameserver 131.215.9.49
op340m:~>date
Fri Jun 20 19:06:37 PDT 2014

The FSSSlowServo.pl now seems to be holding the NPRO PZT to ~6 V. I twiddled the PID settings a little bit to make sure nothing was squirrelly. Seems OK. Time constant of the loop is ~1 minute.

As a reminder, op340m runs our autoburt for all the FE machines, VME IOCs, does the watchdog threshold rampdown, and also the RefCav and NPRO temperature control.

  10083   Fri Jun 20 18:33:53 2014 HarryUpdateGeneralRazorblade Beam Analysis Setup

 Eric Q and I set up the optical configuration for razorblade beam analysis on SP table for future use.

It has been aligned, and will be in use on Monday.

The beam will be characterized for future characterization of optical fibers.

  10082   Fri Jun 20 16:36:44 2014 NichinUpdateElectronicsRF cables removed

 [Nichin, Eric G]

As mentioned in Elog 10062, we found RF cables running between demodulators in rack 1Y2 and RF switch in 1Y1 to have bad SMA connectors (No shield / bad soldering / no caps).

we pulled out all the cables belonging to PD frequency response measurement system , 8 in total, and all of them about 5.5m in length.

Their labels read :

REFL33, REFL11, REFL55, AS55, POX11, REFL165, POP22 and POP110. 

All of them are now sitting inside a plastic box in the contorl room.

On another note, instead of fixing all the cables ourselves, Steve and Eric G decided to order custom made RF cables from Pasternack as professionally soldered cables are worth it. We have placed an order for 2 cables (RG405-550CM) to check out  and test them before we order all of the cables.

  10081   Fri Jun 20 14:42:57 2014 steveUpdateSUSvac illuminators turned off
  10080   Fri Jun 20 11:43:30 2014 ericqUpdateComputer Scripts / ProgramsRestarting ELOG

Manasa let me know that the ELOG was down, and that she used the normal restart procedure, but then all entries were gone. 

This is because the ELOG has been moved on nodus, so going to the old place and running the restart script starts up the old dysfunctional ELOG installation. 

The proper place to restart the ELOG is now nodus:/export/home/elog/start-elog.csh

I'm updating the relevant 40m wiki page now. 

  10079   Fri Jun 20 11:41:18 2014 NichinUpdateElectronicsTransimpedence measurement-BBPD

EDIT: Please ignore the following data. The revised data and plot are in Elog 10089 

Yesterday evening, I conducted the same measurements done in Elog-10059 using the same REF PD (NF 1611) and the same model of BBPD, but on different piece that needed to be checked. 

I moved the NA from near rack 1Y1 to the Jenne laser table and back again after the readings were done.

 Acquiring data

  • The following conditions were set on Network Analyzer Agilent 4395:

1) Frequency sweep range: 1MHz to 300 MHz.

2) Number of Points sampled in  the range: 201

3) Type of sweep: Logarithmic

  • Set the NA to give the corresponding transfer function value (output of BBPD over output of 1611) and also Phase response in degrees.
  • Save the data into floppy disk for processing on the computer.

 Results

The Plots of transimpedence obtained are attached. The data and matlab code used is in the zip file.

The transimpedance of  Broadband photodiode (D1002969-v8) was around 50kV/A-70kV/A (Unusually high) for most of the range (2), but the value started falling as the frequency approached 200 MHz.

 

The high impedance might be because the PD is faulty.   

 

 

 

 

Attachment 1: BBPD_readings_06-19-2014.zip
Attachment 2: BBPD_transimpedence_19thJune2014.pdf
BBPD_transimpedence_19thJune2014.pdf
  10078   Fri Jun 20 09:46:49 2014 manasaUpdateIOOMC WFS servo turned ON

The IMC stayed locked last night, but with  a high REFL ~3.0. I found the WFS servo OFF; so went ahead and enabled it. (Did somebody disable it for reasons not elog'd?)

MC returned to a happy state. But the WFS offsets are quite large. So I tweaked the alignment and got MC REFL down to ~0.45 and MC TRANS SUM to ~16500 counts. MC WFS offsets also dropped significantly after this without any need to touch the alignment to the WFS PDs.

  10077   Thu Jun 19 22:04:23 2014 ericqUpdateComputer Scripts / Programscaget/caput now return in reasonable time

I think I've fixed the caget/caput issue. Rana's observation that pinging the IP directly was faster than pinging the hostname set me on a path of googling which informed making the following changes to the DNS setup on chiara (specifically, informed by this thread: http://www.dslreports.com/forum/r11836974-BIND-slow-to-reply-over-LAN-Solved)

/etc/bind/named.conf.local has these lines:

zone "martian" IN {
 type master;
 file "/etc/bind/zones/martian.db";
 };
zone "113.168.192.in-addr.arpa" {
 type master;
 file "/etc/bind/zones/rev.113.168.192.in-addr.arpa";
};

The first zone command links hostnames like c1lsc to an IP like 192.168.113.62, but apparently in the second, we need to do the inverse. So, for each line in martian.db like

c1lsc           A       192.168.113.62

I added a line in rev.113.168.192.in-addr.arpa like so:

62 IN PTR c1lsc.martian

This seems kind of silly, but now if you do the host command from a workstation, it can find the hostname associated with an IP. 

controls@pianosa|~ > host 192.168.113.62
62.113.168.192.in-addr.arpa domain name pointer scipe12.martian.113.168.192.in-addr.arpa.
62.113.168.192.in-addr.arpa domain name pointer c1lsc.martian.113.168.192.in-addr.arpa.

[At this point, note that we have a bunch of duplicate entries in https://wiki-40m.ligo.caltech.edu/Martian_Host_Table  with these scipe## hostnames. What are these for?]


 
Now (edited for brevity):
 
controls@ottavia|~ > ping -c 5 -D c1sus
PING c1sus.martian (192.168.113.85) 56(84) bytes of data.
<SNIP>
--- c1sus.martian ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3997ms
rtt min/avg/max/mdev = 0.051/0.075/0.114/0.028 ms
controls@ottavia|~ > ping -c 5 -D 192.168.113.85
PING 192.168.113.85 (192.168.113.85) 56(84) bytes of data.
<SNIP>
--- 192.168.113.85 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.052/0.130/0.380/0.127 ms
 
controls@pianosa|~ > time caget C1:LSC-XARM_GAIN
C1:LSC-XARM_GAIN               0.015
real    0m0.039s
 
controls@pianosa|~ > time caput C1:LSC-XARM_GAIN 0.0151
Old : C1:LSC-XARM_GAIN               0.015
New : C1:LSC-XARM_GAIN               0.0151
real    0m0.054s
 
 
 

 

ELOG V3.1.3-