40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 144 of 346  Not logged in ELOG logo
ID Date Author Type Category Subject
  10183   Fri Jul 11 11:51:03 2014 NichinUpdateElectronicsPDFR: List of DC transimpedances

The following values are going to be entered in the param_[PDname].yml file for each PD. I am elogging them for future reference.

I got the values from combing schematics and old Elog entries. Please let me know if you believe the values are different.

  • AS55: 66.2 ohms
  • REFL11 : 66.2 ohms 
  • REFL33 : 50.2 ohms
  • REFL55: 50 ohms (Elog 4605)
  • REFL165: 50.2 ohms
  • POY11: 66.2 ohms
  • POX11: 50.2 ohms
  • REF (NF1611): 700 ohms
  • POP22: ?? (This is currently a Thorlab BBPD )
  10182   Fri Jul 11 09:41:43 2014 not KojiUpdateGeneralCoupling telescope design

Quote:

CFC-2X-C has a FIXED focal length of 2mm, but the collimator lens position is adjustable.
I'm not yet sure this affects your calculation or not as what you need is an approximate mode calculation;
once you couple the any amount of the beam into the fiber, you can actually measure it at the output of the fiber with a collimator attached.

 I don't believe it had any effect, as all the calculations gave me the same target waist.

  10181   Fri Jul 11 08:11:56 2014 SteveUpdateCDSETMX needs help
  10180   Thu Jul 10 19:37:54 2014 ManasaUpdateGeneralPM980 fiber tested OK

[Harry, Manasa]

This is the update from yesterday that Harry missed to elog.

We pulled out the first spool of the PM980 fiber yesterday and checked it using the illuminator at the SP table. Harry will be using this for all his tests and characterisation of the fiber.

  10179   Thu Jul 10 18:25:18 2014 KojiUpdateGeneralCoupling telescope design

CFC-2X-C has a FIXED focal length of 2mm, but the collimator lens position is adjustable.
I'm not yet sure this affects your calculation or not as what you need is an approximate mode calculation;
once you couple the any amount of the beam into the fiber, you can actually measure it at the output of the fiber with a collimator attached.

  10178   Thu Jul 10 17:53:19 2014 AkhilConfigurationComputer Scripts / ProgramsEPICS installed on Raspberry Pi

 I finished the installation of EPICS base on Raspberry Pi (domenica:  /opt/epics). I tested it by creating a test SoftIoc (controls@domenica~/freqCountIOC/simple.db) and was able to read from the channel on Chiara.

Now  I am looking into how to call my C code that talks to Raspberry Pi through a  .db script and write  it into the assigned channel. 

For installation I had to make these declarations in the environment (~/.bash_aliases):

 

 

 

export EPICS_EXT=${EPICS_ROOT}/extensions
export EPICS_EXT_BIN=${EPICS_EXT}/bin/${EPICS_HOST_ARCH}
export EPICS_EXT_LIB=${EPICS_EXT}/lib/${EPICS_HOST_ARCH}
if [ "" = "${LD_LIBRARY_PATH}" ]; then
    export LD_LIBRARY_PATH=${EPICS_EXT_LIB}
else
    export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${EPICS_BASE_LIB}
fi
export PATH=${PATH}:${EPICS_EXT_BIN}

 

  10177   Thu Jul 10 17:33:26 2014 jamieOmnistructureComputer Scripts / Programsubuntu12 software installed, gds 2.16.3.2

Rana wanted the latest GDS installed (for newest DTT), so I made an ubuntu 12 install directory into which I installed

  • gds-2.16.3.2
  • root_v5.34.03

I installed this stuff in

/ligo/apps/ubuntu12

which is the "official" location for stuff compiled specifically for ubuntu12.

Given that the workstations are diverging in OS (some ubuntu10, some ubuntu12), we're going to have to start supporting different software packages for the different versions, thus the new ubuntu12 directory.  This will be a pain in the butt, and will certainly lead to different versions of things for different machines, different features, etc.  We should really try to keep things at the same OS.

In any event, if you want to enable the GDS on an ubuntu 12 machine, source the ubuntu12 ligoapps-user-env.sh file:

controls@ottavia|~ > . /ligo/apps/ubuntu12/ligoapps-user-env.sh

  10176   Thu Jul 10 15:57:00 2014 SteveUpdateSUSflow bench is turned off

Flow bench effect on oplev error signal     is here.

I turned off the south X-end flow bench.

  10175   Thu Jul 10 15:27:09 2014 HarryUpdateGeneralCoupling telescope design

 I designed this telescope to couple the 1064 NPRO into the PM980 fiber, using lenses from the Thorlabs LSB04-C kit.

The collimator is a CFC-2X-C, which has a variable focus length (2.0, 4.6, 7.5, and 11.0 mm) which gives corresponding angles of divergence of 0.298, 0.130, 0.79, and 0.054 degrees by the formula theta = (180*MFD) / (pi*f).

Then, using these values I calculated the spot size of a beam collimated by the CFC-2X-C, using f = w / tan(theta) where w is the spot size. This gave a value of 10.4 um.

I used this value (10.4 um) as a target waist for the telescope system, with the NPRO waist as a seed, at the origin.

telescopeBeamProfile.png

It consists of two lenses, one located at Z = 77cm f = 50cm, and the second located at Z = 85.88 cm f = 2.54cm, which yields a waist of 13um at Z = 88.32cm, (which is where the collimator would go) for an overlap of .974.

Note that the telescope is so far "downrange" from the NPRO waist because it's a virtual waist, and the NPRO itself is located at about Z = 73cm.

Find attached the alm code used.

  10174   Thu Jul 10 02:15:36 2014 JenneUpdateLSCQPD dark noise checkout

I have put beam dumps in front of both of the end transmission QPDs so that I could measure the dark noise.  They are still there.

I checked that the Yend QPD sliders and switches were doing things as I expected.  I couldn't do the Xend since c1auxex is still lost (elog 10165).  I'll post plots and actual information on this checkout, as well as my calculation of what this dark noise means in terms of meters for CARM when we're using 1/sqrt(trans) signals tomorrow morning. 

  10173   Thu Jul 10 02:09:20 2014 JenneUpdatePSLFSS Fast gain set

I have put in a new nominal value for the FSS fast gain:  21.5 dB. 

There is an oscillation peak in the MC error point spectra around 41.5 kHz if the FSS gain is set too high.  I used the 4395 to have a look at the MC error point, and saw that if I set the FSS fast gain any lower than about 18 dB, the peak wasn't getting any smaller than -41 dBm.  If I set the fast gain any higher than about 26 dB the peak wouldn't get any larger than about -34 dBm. 

However, if I set the gain to 19.5dB, the PC RMS drive is consistently above 2 V, which isn't so good.  If I crank the gain up to 27 dB or more, the PC RMS will stay below 0.9 V, which is great. 

As a compromise, I have decided on 21.5 dB as the new FSS fast gain.  This puts the oscillation peak at about -39.5 dBm, and the PC RMS around 1.6 V.

I changed the nominal gain by ezcawrite C1:PSL-STAT_FSS_NOM_F_GAIN 21.5.  This sets the nominal value so that the FSS screen's fast slider doesn't turn red at the new value.  And, since the MC autolocker reads this epics channel and puts that into the gain during the mcup script, the MC autolocker now uses this new gain.  For reference, it used to be set to 23.5 dB.

  10172   Thu Jul 10 01:02:13 2014 ranaUpdatePSLmore PMC science

Increased gain and SNR in PMC LO monitor circuit.

  1. R20: 499 -> 50k Ohms (increases gain by 100)
  2. Used Marconi to drive the LO input and readout C1:PSL-PMC_LODET
  3. Fit this function and loaded it into the psl.db file. The old Kalmus way used LOGE, but I wanted to use log10, so I did. The sensor is only useful in a narrow band. Since the signal is so low at low levels, I just fit to the highest 4 points because I was too lazy to do proper weighting. Do as I say, not as I do.

Plot with data and fit attached.

** N.B.: in order to update the calibration without rebooting, I used the following command: z write C1:PSL-PMC_LOCALC.CALC "2.235*LOG(B)+12.265". This allows us to update EPICS CALC records without rebooting the IOC.

  10171   Thu Jul 10 00:38:20 2014 manasaUpdateGeneralAOM and PSL Ringdown

Quote:

RXA: some more comments...

  1. The fact that the AOM can only modulate the power by a tiny bit means that it is very mis-aligned or that the driver is broken.
  2. You need to take into account the AOM step time in the calculation of the PMC step time. Its not a step response if the input step is not a step, but a exponential.
  3. I wouldn't trust that old John Miller entry for the PMC Finesse. As you can see from his elog, even he didn't trust it.
  4. As we were discussing before, making a little step is not the same as a full ringdown. cf. G000413 and T900007

 

I think we should revisit the AOM alignment because the last time it was aligned, PMC trans dropped from 0.84 to 0.15 (a little more than 80%) for 0-1V modulation input to the AOM driver [elog]. The drop in power right now is ~10-15% only.

I could not find any elogs of AOM alignment touchups after Oct 2012.
But can the ISS team throw some light on the status of AOM when they were installing the ISS servo before we decide on touching the AOM alignment? [elog

  10170   Wed Jul 9 23:02:33 2014 HarryUpdateGeneralBeam Waists via Beamscan

 Today, I borrowed the beam profiler from Brian (another SURF) in order to double check my razor blade measurement figures, using the below setup:

beamscanSetup.png

Measurements are included in the a la mode code that is attached entitled beamfit.m. The beam fitting application yielded me waists (after the lens) of 35.44 um in the x plane, and 33.26 um in the y plane. These are both within 3 um of the measurements I found using the razor blade method. (I moved and resized the labels for the waists in the figure below for readability purposes.)

beamScanWaists.png

I then plugged these waists back into ALM, in addition to the lens specifications, to determine waist size and location of the NPRO, which turned out to be 543 um in the x located at Z = 1.160m, and 536 um in the y, located at 1.268m. These measurements are based upon zero at the waist after the lens, and the positive direction being back toward the NPRO.

beamProfileX.pngbeamProfileY.png

The only systemic difference between these measurement and my original razor blade measurements was that I had taken the focal length of the lens as 75mm, which is advertised on the manufacturer's site. However, the more detailed specs revealed that the focal length was 85.8mm at 1064nm, which made a difference of about 400 um for the final waist determination.

  10169   Wed Jul 9 21:43:41 2014 JenneUpdateElectronicsPMC servo card modifications in DCC

[Rana, Jenne]

We have decided to keep better track (using new-fangled digital "computers") of our modifications to electronics boards. 

The idea will be to create a new DCC document for every electronics board (when we pull a board and modify it, it should receive this treatment) that we have, and that document will become a history of the board's life.  Version 1 will be a copy of the original drawing.  Version 2 should be a modified version of that drawing with the current situation.  All future versions should be modified from the most recent version, to reflect any changes.  Notes for each updated version should include an elog reference to the work, so that we know why we did things, and have a place to find photos of the actual modifications.  Elogs should also include a link to the DCC version.  DCC titles should include the phrase "40m Revisions" for ease of searching.

Patient Zero for this new system will be the PMC servo card.  The DCC number is D1400221.  As of this moment, this just has the V1 original drawing with no modifications.

This has been included in the 40m's DCC document tree that Jamie started back in November 2012.

  10168   Wed Jul 9 21:05:31 2014 manasaUpdateGeneralAOM and PSL Ringdown

After the fits, here are the numbers!

Component Measured Expected
AOM 85.1 ns 200 ns (spec sheet) 
PMC 164.6 ns  Finesse/(2*pi*FSR)  = 163.4 ns

* We have a huge difference to the AOM switching time that was measured. The spec sheet mentions acoustic velocity in the material to be 4.2 mm/us and the well matched diameter in the AOM to be 1100 um. This would give a switching time ~ 200 ns. We could probably be having a much smaller beam size in the AOM for the measured switching time.

* The PMC  parameters that I had been referring to from the wiki were actually wrong and which was the reason for the mismatch that I was finding. I modified the wiki according to the found references to the actual measurement here: PMC parameters The measured values now and then match pretty well.

* Since the AOM does not change the power of the output beam by very much, what we see is actually a step response. Also, we have a lot of noise in the data obtained at the PD. 

RXA: some more comments...

  1. The fact that the AOM can only modulate the power by a tiny bit means that it is very mis-aligned or that the driver is broken.
  2. You need to take into account the AOM step time in the calculation of the PMC step time. Its not a step response if the input step is not a step, but a exponential.
  3. I wouldn't trust that old John Miller entry for the PMC Finesse. As you can see from his elog, even he didn't trust it.
  4. As we were discussing before, making a little step is not the same as a full ringdown. cf. G000413 and T900007

 

  10167   Wed Jul 9 19:53:34 2014 ranaUpdatePSLPMC LO monitor trend (5 years)

LODET.png

The first step is

The second uptick (In Nov 14, 2013) is when I removed a 3 dB attenuator from the LO line. Don't know why the decay accelerates after that.

  10166   Wed Jul 9 17:34:11 2014 NichinUpdateElectronicsPDFR: Beam pointing adjustments and DC measurements

 [Nichin, Manasa]

AIM: Taking DC output readings with multimeter for each PD to create a database (required for transimpedance calculations), by taking off the table tops. Also, making sure each PD is illuminated properly.

What we did:

  • In rack 1Y1: Diode laser controller was set to 150.0 mA at all times. This gave powers in the neighbourhood of 1mW at the end of fibers illuminating all PDs. The laser outputs light of 1064nm wavelength. The laser was switched off in the end.
  • Checked the collimation of the fiber for each PD. In some cases they were not focused to give a sharp spot, so we had to unmount the fibers and fix it and mount them back. Manasa did it initially and I learnt how it was done properly. Eventually I got better and did it myself (under her supervision)
  • Set the mount alignment for maximum illumination of the PD.
  • Record the power falling on the laser and also the DC voltage output. Any light that did not come from my fiber was blocked when taking the readings and then unblocked. I also took care of offset voltage present when taking the DC readings.

Recorded measurements:

REFL11:   Pinc = 0.91 mW         VDC = 34.9 mV 

REFL33:   Pinc = 0.83 mW         VDC = 33.2 mV 

REFL55:   Pinc = 1.08 mW         VDC = 42.7 mV 

REFL165: Pinc = 0.79 mW         VDC = 115.3 mV

AS55:         Pinc = 0.78 mW         VDC = 31.3 mV

POX11:      Pinc = 0.83 mW         VDC = 34.7 mV

POP22**:   Pinc = 1.08 mW         VDC = 5.82 mV

POY11:      Not illuminated; there was no optical fiber mount. Although, there was a fiber near it with a cap on the end. It also looks like there is no space to put in a new mount near the PD. 

REF PD:    Pinc = 1.19 mW         VDC = 8.2 V     (REF PD = New focus 1611)

**Note: The current POP 22 PD does not have 2 different outputs for DC and RF signals. I unplugged the RF cable from the output, took readings with the multimeter and then plugged back the RF cable.

Further work:

I will calculate the responsivity for each PD and compare it to the expected values. 

  10165   Wed Jul 9 17:08:29 2014 JenneUpdateCDSc1auxex "Unknown Host"

c1auxex has forgotten who it is.  Slow sliders for the QPD head were not responding, so I did a soft reboot from telnet. The machine didn't come back, so I plugged the RJ45-DB9 cable into the machine and looked at it through a minicom session.  When I key the crate, it gives me an error that it can't load a file, with the error code 0x320001.  Looking that up on a List of VxWorks error codes, I see that it is:    S_hostLib_UNKNOWN_HOST (3276801 or 0x320001)

I'm not sure how this happened.  I unplugged and replugged in the ethernet cable on the computer, but that didn't help.  Rana is going in to wiggle the other end of the ethernet cable, in case that's the problem.  EDIT:  Replacing the ethernet cable did not help.

Former elogs that are useful:  10025, 10015

EDIT:  The actual error message is:

boot device          : ei                                                      
processor number     : 0                                                       
host name            : chiara                                                  
file name            : /cvs/cds/vw/mv162-262-16M/vxWorks                       
inet on ethernet (e) : 192.168.113.59:ffffff00                                 
host inet (h)        : 192.168.113.104                                         
user (u)             : controls                                                
flags (f)            : 0x0                                                     
target name (tn)     : c1auxex                                                 
startup script (s)   : /cvs/cds/caltech/target/c1auxex/startup.cmd             
                                                                               
Attaching network interface ei0... done.                                       
Attaching network interface lo0... done.                                       
Loading...                                                                     
Error loading file: errno = 0x320001.                                          
Can't load boot file!! 

  10164   Wed Jul 9 16:33:05 2014 manasaUpdatePSLPMC ringdown setup

Quote:

Quote:

I moved stuff on the PSL table to accommodate the PMC ringdown setup.

I used the beam that leaks from the steering mirror at the PMC transmission that was dumped to a razor blade dump. I installed a Y1 to steer the beam to the ringdown PD. Power in the beam 75mW. 

 I am guessing that 75 mW will burn / destroy any Thorlabs PD. I hope that mW is supposed to be uW.

 It was ~7.5mW and measured ~2V at the PD output (given its range 0-5V ) on the oscilloscope . So PD is safe !

  10163   Wed Jul 9 12:01:43 2014 AkhilConfigurationElectronicsSetup Plan for placing the Frequency Counter inside the lab

Today, me and Manasa went inside the lab to figure out a place for the place for the FC. The whole setup will be placed in a chassis box . The chassis in figure(setupforFC.pdf) will be placed in the highlighted(red) box in the figure(setup.png). All the cables will be routed to the computers from behind the box and the RF cables from the beat box will be routed from the front end of the box. The two raspberry Pi boxes will be placed inside the box and the Frequency counters will be mounted as shown so that the frequency count can be seen from outside. 

  10162   Wed Jul 9 11:41:12 2014 KoushikUpdatePSLPMC local oscillator is going wonky

Quote:

Koushik replaced an ERA-5 in the PC path. We put the module back to the rack and found no change.
The epics LO level monitor monitor is still fluctuating from 6~11dBm. We need more thorough investigation
by tracing the signals everywhere on the board.

Despite the poor situation of the modulation, PMC was locking (~9PM). Rana suspect that the PMC demodulation
phase was not correctly adjusted long time. 

Koushik has the measured power levels and the photos of the board. I'll ask him to report on them.

 Updates from Koushik:

The power levels measured (before and after relacement of ERA-5) are as follows:

LO to Servo : Vout = 2.3 Vpp / Pout = 11.21 dBm at f = 35.5 MHz

RF to PC   :   Vout = 354 mVpp / Pout = -5.1 dBm at f= 35.5 MHz

The measurements were done using an oscilloscope with 50 ohms load impedance. Unfortunately the photos are not available from the camera.

  10161   Wed Jul 9 08:50:30 2014 AkhilUpdateGeneralWeekly Update

 

Last Week's Work:

  • Worked on the setup to mitigate timing issues arising due to the non-synchronization of clocks of the Frequency counter and Raspberry Pi .
  • Took measurements with the mentioned setup and generated PSD plots of the FC.
  • Completed the setup for phase measurements by using an external ADC.

 

Work Plan for this Week:

  • Complete the installation of the Mini Circuits Frequency Counter on the EPICS. This involves installation of EPICS base on Raspberry Pi, creating an IOC server on the R Pi and writing the data from the FC into a specific IOC  channel. 
  • Complete phase measurements and obtain the delay in the FC thus completing the characterization of the FC.
  • Install the FC at a suitable place inside the 40m so that the beat note system can be remotely managed from any of the Control computers thus effectively replacing the spectrum analyzer(This will be done with proper supervision once the recently ordered FC is shipped)

 

Inside the 40m :

  • I will be going inside the lab today around 9 am with Manasa to make a plan about where the FC must be placed and the routing of the RF cables and the cables which run  into computers from the FC.
  • Once the channel is created and tested, we will install the FC inside the lab possibly by the end of this week or by next week.
  10160   Wed Jul 9 00:59:09 2014 ranaUpdatePSLPMC local oscillator is going wonky

Quote:

Koushik and Koji try to fix the PMC oscillator issue. So we remove the module from the rack.
This means we don't have the PMC transmission during the work.

 After the ERA-5 was replaced (see Koushik elog) we relocked the PMC.

The new LO level going into the PMC servo card is +11.5 dBm. The LO mon on the PMC card reads 9 dBm and seems so flat I now suspect the monitor circuit.

I also measured the RF drive to the EOM as a function of C1:PSL-PMC_RFADJ on the Phase Shifter screen.

The phase shifter slider gives ~75 deg/V in phase shift of the RF out to the EOM. I tried to optimize the loop gain quickly using the fluctuations in the reflected power. The loop oscillates at high frequency with the slider at 21 dB and also at 9 dB. So I set the gain at +14 dB. Needs to be optimized correctly in the daytime.

 

  10159   Wed Jul 9 00:47:22 2014 KojiUpdatePSLPMC local oscillator is going wonky

Koushik replaced an ERA-5 in the PC path. We put the module back to the rack and found no change.
The epics LO level monitor monitor is still fluctuating from 6~11dBm. We need more thorough investigation
by tracing the signals everywhere on the board.

Despite the poor situation of the modulation, PMC was locking (~9PM). Rana suspect that the PMC demodulation
phase was not correctly adjusted long time. 

Koushik has the measured power levels and the photos of the board. I'll ask him to report on them.

  10158   Tue Jul 8 23:59:49 2014 HarryUpdateGeneralWeekly Plan (7.8.14)

 Last Week:

-I continued to struggle with the razorblade beam analysis, though after a sixth round of measurements, and a lot of fiddling around with fit parameters in matlab, there seems to be a light at the end of the tunnel.

 

Next Week:

-I plan to check my work with the beamscan tomorrow (wednesday) morning

-Further characterize the light from the fibers, and set up the collimator

-Design and hopefully construct the telescope that will focus the beam into the collimator

 

Materials:

- Razorblade setup or beamscan (preferably beamscan)

- Fiber Illuminator

- Collimator (soon to be ordered)

- Lenses for telescope (TBD)

 

  10157   Tue Jul 8 22:53:02 2014 Jenne, RanaUpdateElectronicsTransmon QPD / whitening

We need to work farther on checking out the end transmission QPD electronics situation. 

In bullet-point form, we need to:

* Ensure that the Weiss QPD head modifications have been made on these diodes.  (cf. Rai W's LLO elogs on QPDs)

* Ensure that the QPD biases are somewhere in the range of 10-15V, not the old 100V.  (Because we only need HV to make the capacitance low for RF use. Low voltage means less power dissipation in the head)

* Ensure the Rana/Rob modifications have been propagated to the whitening boards, so that we have full dynamic range.  (Steve is looking for the marked up paper schematics)

* Replace signal path resistors with low noise metal film resistors.

* Check QPDs / whitening boards for oscillation (with a scope probe), ensure that we chose an appropriate analog gain.

 

In thinking about the transimpedances that we want, we thought about the current that we expect.  We should get about 100 mW of light transmitted through the ETMs when we have full IFO lock.  There is a 50/50 BS to split the light between the QPD and the Thorlabs transmission diode, so we have about 50 mW incident on the QPDs, which is about 13 mW per quadrant.  With a sensitivity of about 0.15 Amps/Watt for silicon, this means that we're expecting to see about 2 mA of current per quadrant once we have the IFO fully resonant. We want this to correspond to about 5V, which means we want a transimpedance gain of around 2.5 kOhm. 

 

For the things that need checking, each quadrant has:

Photodiode  ------  Gain Switch 1 ----- Gain Switch 2  ------ Gain Switch 3 ------ Variable Gain Amplifier ------- Whitening stage 1 (z @ 4 Hz, p @ 40 Hz)  ------- Whitening stage 2 (z @ 4 Hz, p @ 40 Hz)

We want to check on the status of each of these switches, and whether they actually do what they say on the QPD Head screens.  Q has checked out and fixed the bit outputs for the whitening stages, but the rest still needs to be checked out.  Also note that the Switch 1, Switch 2 and Switch 3 are common to all 4 quadrants (i.e. enabling switch 1 on one quadrant enables it on all quadrants), but the variable gains and the whitening stages are individual for each quadrant.

  10156   Tue Jul 8 18:20:15 2014 jamieOmnistructureElectronicsJamie 1811 power supply fixed!

 Placed in PD cabinet in Y arm, next to the OTHER Jamie-made 1811 power supply from 1998.

  10155   Tue Jul 8 17:59:12 2014 jamieOmnistructureElectronicsJamie 1811 power supply fixed!

I finally made good on the LIFE TIME WARRANTY on the ancient, Jamie-made 1811 power supply with the faulty switch:

20140708_165010.jpg

Back to fully working form.  Hopefully I'll still be around the next time it breaks in 16 years.

  10154   Tue Jul 8 16:45:15 2014 NichinUpdateGeneralWeekly plan

 My plan for next week is...

1)    1) Taking DC output readings with multimeter for each PD to create a database for all the PDs. Requires taking off the table tops for each PD.  Also, making sure each PD is illuminated properly.

    2 - 3 Hours inside the lab 

    Requires presence of expert

Occupies all the PDs , RF switch and the Network analyzer.

2)    2)  Integrate the switch selection script with the Network analyzer script to complete the automation part of the project.  (If time permits, build a simple GUI for easy operation)

Occupies the control room computer, RF switch and the Network analyzer

3)    3)  Create a database of canonical plots for each PD to compare with the current plot and maybe even plot the difference between the current plot and canonical plot.

Occupies the control room computer, PDs , RF switch and the Network analyzer.

4)    4)  Fit the transfer function or transimpedance using vector fitting. (vectfit4.m)

5)    5) Update 40m-Wiki

6)    6) Progress Report to be submitted to SFP.

  10153   Tue Jul 8 15:28:32 2014 KojiUpdatePSLPMC local oscillator is going wonky

Koushik and Koji try to fix the PMC oscillator issue. So we remove the module from the rack.
This means we don't have the PMC transmission during the work.

  10152   Tue Jul 8 15:07:24 2014 NichinHowToElectronicsRF Multiplexer in rack 1Y1

The RF multiplexer is configured as shown in the figure. It is now effectively a 15x1 RF mux.

RF_Multiplexers.png

To select a required channel:

Run the script as shown below 

/opt/rtcds/caltech/c1/scripts/general/rfMux.py

>python rfMux.py ch11

For channel 10 to 16, you can just enter the required channel number and it is routed to the output.

For channel 1 to 8, you only need to input the required channel number as above. No need to run the code again to select ch9 after selecting ch1-8

 

How the NI-8100 controller works:

Whenever any channel of one switch is selected, the output of the other switch is set to its ch0 (ch1 and ch9 in the figure).

So selecting ch1-8 will automatically select ch9 as output for the other switch. IF you send a command to select ch9 afterwards, the first switch will be automatically set to ch1 and not stay on what you had selected before.

  10151   Tue Jul 8 09:02:02 2014 AkhilUpdateElectronicsPSD Plots for different sampling times of the Frequency Counter

 Although there were few timing issues with the FC and the Raspberry Pi at the lowest sampling time of the FC (0.1s) even after adding an external trigger circuit, it turned out that most of these issues are not prevalent at higher sampling times(>0.5 s)(narrow peaks of PSD seen for higher sampling times). Rana suggested me to look at the PSD plots at different sampling times of the FC so that we can decide which would be the optimal sampling time to work with the FC before replacing the spectrum analyzer. I took the measurements with the setup discussed in my previous elog(http://nodus.ligo.caltech.edu:8080/40m/10129) . However, the  noise of the R Pi- FC interface should be taken care of (I will discuss it with my mentors).

Attached are the plots at 100 MHz carrier frequency at  different sampling times of the FC( 0.1s, 0.2s, 0.3s, 0.5s, 1s) (pdfs and code attached in a zip file)

RXA: Put all the plots in a single PDF file and use the same axis limits for all plots so that its easy to compare.      (Attached in PSD.pdf)


 

 

  10150   Tue Jul 8 01:55:21 2014 JenneUpdateSUSETMX glitching

[Jenne, Rana]

A few times this evening, I had been having trouble locking CARM and DARM with ALS, and holding it for very long.  When it started happening again, I switched over to locking the individual arms with ALS.  Yarm seems to be totally fine, but Xarm has something funny going on. 

Rana and I have narrowed it down to being a problem with ETMX.  We were watching ETMX's oplev and local damping error signals, and would see occasional glitch events.  This happened when oplev + local damping were both on, both off, and when only local damping was on.  We believe that this points to something weird with the coil driver and actuator chain.

We tried to watch for a while to see if it was a step event (something switching on and off periodically), or an impulse event (some transient oscillation in an opamp perhaps), but the problem went away again.  We have come to no conclusions other than we have a problem that needs watching.

During our investigations, to more softly turn off the damping, Rana set the local damping gains, as well as the oplev gains to zero using a ramp time.  We don't recall the precise numbers, and conlog doesn't have the gains recorded, so we made an educated guess.  The local damping seems fine, but the oplev damping should be re-confirmed.  Steve, can you please show Harry how, and have him help you measure the ETMX pitch and yaw oplev loops, and set the gains so that they match up to the references, and then post the measured bode plots when you're done? 

  10149   Mon Jul 7 23:19:55 2014 ranaUpdatePSLPMC ringdown setup

Quote:

I moved stuff on the PSL table to accommodate the PMC ringdown setup.

I used the beam that leaks from the steering mirror at the PMC transmission that was dumped to a razor blade dump. I installed a Y1 to steer the beam to the ringdown PD. Power in the beam 75mW. 

 I am guessing that 75 mW will burn / destroy any Thorlabs PD. I hope that mW is supposed to be uW.

  10148   Mon Jul 7 22:18:26 2014 KojiUpdatePSLPMC local oscillator is going wonky

It seems that there is no better chip in MiniCircuits line-up with the same form factor.
ERA-5 is the most powerful one in the ERA (or MAR) series.

If the output is ~0dBm we have MAR-6SM in stock. But I suspect that ERA-5 was driven at the power level close to its saturation (~18dBm).

If we allow different form factors, we have GVA-** or GALI-** in the market and also in the blue tower, in order to gain more performance margin.
If it is difficult to apply them, I would rather use another ERA-5 with enhanced heat radiation.

I'm sure that Downs has EAR-5 replacement.

  10147   Mon Jul 7 22:07:29 2014 ranaUpdateElectronicsRF cables rerouted

This Red Ladder movement also probably included some bumping of the MC2 stack (be more careful when working in the lab). Around 5 PM today, the MC lost lock.

When I came in later, I found that the MC was flashing the TEM17,9 mode and had been misaligned like this for ~1 hour. I looked through the MC SUS sensor trends and moved MC2 back to its old position to get the locking back. I disabled the WFS, tweaked the TEM00 mode alignment using only MC2 sliders, and then re-enabled WFS. Its been OK for the past 5 hours.

  10146   Mon Jul 7 21:36:33 2014 Jenne, ranaUpdatePSLPMC local oscillator is going wonky

The PMC local oscillator is going a little weird dyingWe need to check out why the level is fluctuating so much.

Here's a 6 month plot, where you can see that the lower level keeps getting lower (y-axis is dBm):

PMC_LO_failing.pdf

This LHO entry from 2008 shows where we first discovered this effect. As Rick Savage and Paul Schwinberg later found out, the ERA-5SM+ amplifier slowly degrades over several years and was replaced for both of the eLIGO interferometers. We have spares in the Blue box and can replace this sometime during the day.

Our PMC LO is made by this obsolete crystal oscillator circuit: D000419. There are many versions of this floating around, but they all have the ERA-5 issue.

  10145   Mon Jul 7 18:38:27 2014 NichinUpdateElectronicsRF cables rerouted

Quote:

The RF cables have been routed incorrectly. The cables run to the module from the front of the rack. We cannot close the doors to the racks if they are to remain this way.

I have asked Nichin to reroute the cables properly.

RF cables have been rerouted from the side of the rack, under the supervising eye of Manasa.

I moved the red ladder from near 1X4 to 1Y1 and back again.

Current list of RF cables:

REFL11, REFL33, REFL55, REFL165,

AS55

POX11

POP22

POY11

I have not connected them to the RF switch yet. ( until I figure out how to get both the switches working properly)

  10144   Mon Jul 7 18:11:04 2014 KojiUpdateGeneralBeam Waists

- Plots should be directly attached on the elog. (Attaching codes in a zip is OK.)

- Plot legends should not touch or hide any data points.

- Don't exclude data points.

- The model for the beam profile fitting is incorrect: zr and w0 are dependent

- The code needs to be reviewed by someone for refinement.
  (
EricQ, or possibly Jamie, Jenne while he is absent).

  10143   Mon Jul 7 17:20:09 2014 NichinUpdateElectronicsRF PDs needed

Quote:

Quote:

 REFL33, AS55, REFL55,REFL165,REFL11,POX11,POP22

There were quite a few more demodulator units labelled with PD names. Do any of them need to be included in the automated frequency response measurement system? Please let me know so that I can include them to the RF switch and check them for proper illumination, which i will do for all the above PDs next week.

 In the order that makes more sense to me, it looks like you have:

REFL11, REFL33, REFL55, REFL165,

AS55

POX11

POP22

We don't really need POP22 right now, although we do want the facility to do both POP22 and POP110 for when we (eventually) put in a better PD there.  Also, we want cabling for POP55, so that we can illuminate it after we re-install it.  If we're working on 2f PDs, we might as well consider AS110 also, although I don't know that there was a fiber layed for it.  The big one that you're missing is POY11.

 A new RF cable has been included for POY11. Cabling for POP55 and POP110 might or might not exist. I will check and report it.

  10142   Mon Jul 7 16:52:02 2014 manasaUpdateElectronicsRF cables need to be rerouted

The RF cables have been routed incorrectly. The cables run to the module from the front of the rack. We cannot close the doors to the racks if they are to remain this way.

I have asked Nichin to reroute the cables properly.

  10141   Mon Jul 7 16:39:26 2014 SteveUpdatePEMants on the PSL table

Quote:

Quote:

We observed one or two ants climbing over PMC optics without booties and safety glasses.

The floor was mopped with strong Bayer Home Pest Control solution in the Vertex area.

Do not work inside the 40m lab if you are sensitive to chemicals!

 

 The floor is mopped again with strong PEST CONTROL SOLUTION in water in the Vertex area.

Do not plane to work in the IFO-room till noon if you are sensitive to chemicals!

 Ants are back on the PSL table. We'll be mopping the floor with pest control solution tomorrow morning.

  10140   Mon Jul 7 16:39:09 2014 manasaUpdatePSLPMC ringdown setup

I moved stuff on the PSL table to accommodate the PMC ringdown setup.

I used the beam that leaks from the steering mirror at the PMC transmission that was dumped to a razor blade dump. I installed a Y1 to steer the beam to the ringdown PD. Power in the beam 75mW.

Results are in here elog 

  10139   Mon Jul 7 14:42:33 2014 HarryUpdateGeneralBeam Waists

I was finally able to get a reasonable measurement for the beam waist(s) of the spare NPRO.

Methods

I used a razorblade setup, pictured below, to characterize the beam waist of the spare 1064nm NPRO after a lens (PLCX-25.4-38.6-UV-1064) in order to subsequently calculate the overall waist of the beam. The setup is pictured below:

 

RzorbladeSetupFinal.pdf

After many failed attempts, this was the apparatus we (Manasa, Eric Q, Koji, and I) arrived with. The first lens after the laser was installed to focus the laser, because it's true waist was at an inaccessible location. Using the lens as the origin for the Z axis, I was able to determine the waist of the beam after the lens, and then calculate the beam waist of the laser itself using the equation wf = (lambda*f)/(pi*wo) where wf is the waist after the lens, lambda the wavelength of the laser, f the focal legth of the lens (75.0 mm in this case) and wo the waist before the lens.

We put the razorblade, second lens (to focus the beam onto the photodiode (Thorlabs PDA255)), and the PD with two attenuating filters with optical density of 1.0 and 3.0, all on a stage, so that they could be moved as a unit, in order to avoid errors caused by fringing effects caused by the razorblade.

I took measurements at six different locations along the optical axis, in orthogonal cross sections (referred to as X and Y) in case the beam turned to be elliptical, instead of perfectly circular in cross section. These measurements were carried out in 1" increments, starting at 2" from the lens, as measured by the holes in the optical table.

Analysis

Once I had the data, each cross section was fit to V(x) = (.5*Vmax)*(1-erf((sqrt(2)*(x-x0))/wz))+c, which corresponds to the voltage supplied to the PD at a particular location in x (or y, as the case may be). Vmax is the maximum voltage supplied, x0 is an offset in x from zero, wz is the spot size at that location in z, and c is a DC offset (ie the voltage on the PD when the laser is fully eclipsed.) These fits may all be viewed in the attached .zip file.

The spot sizes, extracted as parameters of the previous fits, were then fit to the equation which describes the propagation of the spot radius, w(z) = wo*sqrt(1+((z-b)/zr)^2)+c, w(z) = w0*sqrt(1+((((z-b)*.000001064)^2)/((pi*w0^2)^2))) where wo corresponds to beam waist, b is an offset in the z. Examples of these fits can be viewed in the attached .zip file.

Finally, since the waists given by the fits were the waists after a lens, I used the equation wf = (lambda*f)/(pi*wo), described above, to determine the waist of the beam before the lens.

Plots

 

note: I was not able to open the first measurement in the X plane (Z = 2in). The rest of the plots have been included in the body of the elog, as per Manasa's request.

Y_Waist_Fit.pngY_plane_measurement_6_(Z_7in).pngY_plane_measurement_5_(Z_6in).pngY_plane_measurement_4(Z_5in).pngY_plane_measurement_3_(Z_4in).pngY_plane_measurement_2_(Z_3in).png

 

Y_plane_measurement_1_(Z_2in).png X_plane_measurement_6_(Z_7in).pngX_plane_measurement_5_(Z_6in).pngX_plane_measurement_4_(Z_5in).pngX_plane_measurement_3_(Z_4in).pngX_plane_measurement_2_(Z_3in).pngX_plane_measurement_1_(Z_2in).pngX_Waist_fit.png

Conclusion

The X Waist after the lens (originally yielded from fit parameters) was 90.8 27.99 ± .14 um. The corresponding Y Waist was 106.2 30.22 ± .11 um.

After adjustment for the lens, the X Waist was 279.7 907.5 ± 4.5 um and the Y Waist was 239.2 840.5 ± 3.0 um.

edit: After making changes suggested by koji, these were the new results of the fits.

Attachments

Attached you should be able to find the razor blade schematic, all of the fits, along with code used to generate them, plus the matlab workspace containing all the necessary variables.

NOTE: Rana brought to my attention that my error bars need to be adjusted, which I will do as soon as possible.

  10138   Mon Jul 7 14:38:55 2014 SteveUpdatesafetysafety training

TaraV - geology major undergrad -  of Jenne's summer help received 40m specific basic safety training.

  10137   Mon Jul 7 13:56:13 2014 AkhilConfigurationElectronicsSetup Used for Characterization of Frequency Counter

When I was trying to plot PSD of the measurements, I still couldn't get better resolution. There still seems to be a problem with timing and synchronization of the R Pi with the FC even after addition of the external trigger circuit. Now, I am looking to debug this issue. Attached are the plots showing missing data points and data from the FC at uneven spacing(zoomed in plot).

 

  10136   Mon Jul 7 13:55:26 2014 JenneUpdateLSCc1cal model restarted

I'm not sure why the c1cal model didn't come up the last time c1lsc was rebooted, but I did an "rtcds start c1cal" on the lsc machine, and it's up and running now.

  10135   Mon Jul 7 13:44:21 2014 JenneUpdateCDSc1sus - bad fb connection

Quote:

 

I managed to recover c1sus.  It required stopping all the models, and the restarting them one-by-one:

$ rtcds stop all     # <-- this does the right to stop all the models with the IOP stopped last, so they will all unload properly.

$ rtcds start iop

$ rtcds start c1sus c1mcs c1rfm

I have no idea why the c1sus models got wedged, or why restarting them in this way fixed the issue.

 In addition to needing obnoxiously regular mxstream restarts, this afternoon the sus machine was doing something slightly differently.  Only 1 fb block per core was red (the mxstream symptom is 3 fb-related blocks are red per core), and restarting the mxstream didn't help.  Anyhow, I was searching through the elog, and this entry to which I'm replying had similar symptoms.  However, by the time I went back to the CDS FE screen, c1sus had regular mxstream symptoms, and an mxstream restart fixed things right up. 

So, I don't know what the issue is or was, nor do I know why it is fixed, but it's fine for now, but I wanted to make a note for the future.

  10134   Mon Jul 7 11:02:22 2014 manasaConfigurationGeneralIFO status post earthquake

Quote:

All suspension damping restored. There had to be an earth quake.

PMC was relocked.

MC did not need any fixing to its alignment. I had to lock it manually and autolocker is set running now. So that should take care of things

The arms were aligned and ASS'd for IR PDH.

Green light PDH locks to the arms alright.

ELOG V3.1.3-