40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 154 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  16252   Wed Jul 21 14:50:23 2021 KojiUpdateSUSNew electronics

Received:

Jun 29, 2021 BIO I/F 6 units
Jul 19, 2021 PZT Drivers x2 / QPD Transimedance amp x2

 

Attachment 1: P_20210629_183950.jpeg
P_20210629_183950.jpeg
Attachment 2: P_20210719_135938.jpeg
P_20210719_135938.jpeg
  16281   Tue Aug 17 04:30:35 2021 KojiUpdateSUSNew electronics

Received:

Aug 17, 2021 2x ISC Whitening

Delivered 2x Sat Amp board to Todd

 

Attachment 1: P_20210816_234136.jpg
P_20210816_234136.jpg
Attachment 2: P_20210816_235106.jpg
P_20210816_235106.jpg
Attachment 3: P_20210816_234220.jpg
P_20210816_234220.jpg
  16436   Wed Oct 27 19:34:52 2021 KojiSummaryElectronicsNew electronics racks

1. The rack we cleaned today (came from West Bridge) will be placed between 1X3 and 1X4, right next to 1X4 (after removing the plastic boxes). (Attachment 1)
For easier work at the side of the 1X4, the side panel of the 1X4 should be removed before placing the new rack. Note that this rack is imperial and has 10-32 threads

2. In terms of the other rack for the Y arm, we found the rack in the storage is quite dirty. Anchal pointed out that we have a few racks standing along the Y arm (as the storage of the old VME/Euro card electronics) (Attachments 2/3)
They are not too dirty and also doing nothing there. Let's vacate one of them (the one right next to the optics preparation table). Use this space as a new storage area placing a wire shelving rack for something.

BTW, I thought it is good to have the rack at the vertex side of 1Y1 (as 1Y0?), but the floor has "KEEP OUT" marking. I have no idea why we have this marking. Is this for crane operation??? Does any one know?

Attachment 1: P_20211027_180737.jpg
P_20211027_180737.jpg
Attachment 2: P_20211027_180443.jpg
P_20211027_180443.jpg
Attachment 3: P_20211027_180408.jpg
P_20211027_180408.jpg
Attachment 4: P_20211027_180139.jpg
P_20211027_180139.jpg
  16149   Fri May 21 00:05:45 2021 KojiUpdateSUSNew electronics: Sat Amp / Coil Drivers

11 new Satellite Amps were picked up from Downs. 7 more are coming from there. I have one spare unit I made. 1 sat amp has already been used at MC1.

We had 8 HAM-A coil drivers delivered from the assembling company. We also have two coil drivers delivered from Downs (Anchal tested)

Attachment 1: F3CDEF8D-4B1E-42CF-8EFC-EA1278C128EB_1_105_c.jpeg
F3CDEF8D-4B1E-42CF-8EFC-EA1278C128EB_1_105_c.jpeg
  16212   Thu Jun 17 22:25:38 2021 KojiUpdateSUSNew electronics: Sat Amp / Coil Drivers

It is a belated report: We received 5 more sat amps on June 4th. (I said 7 more but it was 6 more) So we still have one more sat amp coming from Todd.

- 1 already delivered long ago
- 8 received from Todd -> DeLeone -> Chub. They are in the lab.
- 11 units on May 21st
- 5 units on Jun 4th
Total 1+8+11+5 = 25
1 more unit is coming

 

Quote:

11 new Satellite Amps were picked up from Downs. 7 more are coming from there. I have one spare unit I made. 1 sat amp has already been used at MC1.

We had 8 HAM-A coil drivers delivered from the assembling company. We also have two coil drivers delivered from Downs (Anchal tested)

 

Attachment 1: P_20210604_231028.jpeg
P_20210604_231028.jpeg
  5815   Fri Nov 4 21:15:38 2011 KatrinUpdateGreen LockingNew fiber coupler (YARM)

63% coupling efficiency into the new fiber collimator (Thorlabs XXXX) and the blue fiber.This should be sufficient for a beat measurement with the PSL laser.

I think the coupling efficiency is not too bad with having no mode matching lenses and no adjustable collimator lens.

 

252mW in front of the fiber

159 mW fiber output

  15549   Sat Aug 29 22:46:29 2020 gautamUpdateBHDNew homodyne-phase control electronics

Summary:

The electronics chain used to drive the three elements of the PI PZT on which a mirror is mounted with the intention of controlling the LO phase has been changed, to now use the Trek Mode603 power amplifier instead of the OMC high voltage driver. Attachment #1 shows the new configuration.

Details:

The text of Attachment #1 contains most of the details. The main requirement was to map the DAC output voltage range, to something appropriate for the Trek amplifier. The latter applies a 50V/V gain to the signal received on its input pin, and also provides a voltage monitor output which I hooked up to an ADC channel in c1ioo. The gain of the interfacing electronics was chosen to map the full output range of the DAC (-5 to +5 V for a single-ended receiving config in which one pin is always grounded) to 0-2.5 V at the input of the Trek amplifier, so that the effective high voltage drive range is 0-125 V. I don't know what the damage threshold is for the PI PZT, maybe we can go higher. The only recommendation given in the Trek manual is to not exceed +/-12 V on the input jack, so I have configured D2000396 to have a supply voltage of 11.5 V, so that in the event of electronics failure, we still don't exceed this number.

On the electronics bench, I tested the drive chain, and also measured the transfer function, see Attachment #2. Seems reasonable (the Trek amplifier was driving a 3uF capacitive load used to protect the SR785 measurement device from any high voltage, hence the roll-off). The gain of D2000396 was changed from 1/8 to 1/4 after I realized that the DAC full range is only +/- 5 V when the receiving device is single-ended at both input and output. Maybe the next iteration of this curcuit should have differential sending, to preserve the range.

Testing:

To test the chain, I used the single bounce beam from the ITM, and interfered it with the LO. Clear fringing due to the seismic motion of the ITM (and also LO phase noise) is visible. In this configuration, I drove the PZT mirror in the LO path at a higher frequency, hoping to see the phase modulation in the DCPD output. However, I saw no signal, even when driving the PZT with 50% of the full DAC range. The voltage monitor ADC channel is reporting that the voltage is faithfully being sent to the PZTs, and I measured the capacitance of the PZTs (looked okay), so not sure what is going on here. Needs more investigation.

Update Aug 30 5pm: Turns out the problem here was a flaky elbow connector I used to pipe the high voltage to the PI PZT, it had some kind of flaky contact in it which meant the HV wasn't actually making it to the PZT. I rectified this and was immediately able to see the signal. Played around with the dark fringe Michelson for a while, trying to lock the homodyne phase by generating a dither line, but had no success with a simple loop shape. Probably needs more tuning of the servo shape (some boosts, notches etc) and also the dither/demod settings themselves (frequency, amplitude, post mixer LPF etc). At least the setup can now be worked on interferometrically.

Attachment 1: zetaDrive.pdf
zetaDrive.pdf
Attachment 2: trekTFs.pdf
trekTFs.pdf
  11423   Fri Jul 17 02:46:07 2015 IgnacioUpdateGeneralNew huddle test data for Wilcoxon 731A results

On Thursday, new huddle test data for the Wilcoxon 731A was aquired by Eric. 

The difference between this new data and the previous data, is:

1) We used three accelerometers instead of six this time around.

2) We used a foam box, and clamped cables on the experimental set up as shown in the previous elog, http://nodus.ligo.caltech.edu:8080/40m/11389

I have analyzed the new data. Here I present my results.

The following plot shows the ASD's for the three accelerometers raw outputs as well as their error signals computed using the three cornered hat method,

As before, I computed the mean for the output signals of the accelerometers above as well as their mean self noise to get the following plot

,

Now, below I compare the new results with the results that I got from the old data, 

Did the enclosure and cable clamping do much? Not really, according to the computed three hat results. Also, notice how much better, even if its a small improvement, we get from using six accelerometers and calculating their self noise by the six cornered hat method.

 

Now, I moved on to analyzing the same data with Wiener Filtering.

Here are again, the raw outputs, and the self noises of each individual accelerometer calculated using Wiener filtering,

The accelerometer in the Y direction is show a kind of funky signal at low frequncies. Why? Anyways, I calculated the mean of the above signals as I did for the three cornered hat method above to get the following, I also show the means of the signals computed with the old data using wiener filtering,

Is the enclosure really doing much? The Wiener filter that I applied to the huddle test old data gave me a much better, by an order of magnitude better self noise curve. Keep in mind that this was using SIX accelerometers, not THREE as we did this time. I want to REDO the huddle test for the WIlcoxon accelerometers using SIX accelerometers with the improved experimental setup to see what I get.

Finally, I compare the computed self noises above with what the manufacturer gives,

,

As I expected, the self noise using six accelerometers and Wiener filtering is the best I could work out. The three cornered hat method works out pretty well from 1 to 10 Hz, but the noise is just too much anywhere higher than 10 Hz. The enclosed, clamped, 3 accelerometer wiener filter result is an order of magnitude worse than the six accelerometer wiener filtered result, and two orders of magnitude worse than the three cornered hat method in the 1 to 10 Hz frequency band. 

As I stated, I think we must performed the huddle test with SIX accelerometers and see what kind of results we get.

Attachment 1: selfnoise_allthree_threehat_enclosed.png
selfnoise_allthree_threehat_enclosed.png
Attachment 2: selfnoise_3hat_enclosed_averages.png
selfnoise_3hat_enclosed_averages.png
Attachment 3: selfnoise_3hat_6hat_enc.png
selfnoise_3hat_6hat_enc.png
Attachment 4: miso_wiener_enclosedall.png
miso_wiener_enclosedall.png
Attachment 5: selfnoise_wiener_enclosed.png
selfnoise_wiener_enclosed.png
Attachment 6: compare_encl.png
compare_encl.png
  2886   Thu May 6 16:18:37 2010 AlbertoUpdate40m UpgradingNew improved design for the 11MHz photodiode

After munching analytical models, simulations, measurements of photodiodes I think I got a better grasp of what we want from them, and how to get it. For instance I now know that we need a transimpedance of about 5000 V/A if we want them to be shot noise limited for ~mW of light power.

Adding 2-omega and f1/f2 notch filters complicates the issue, forcing to make trade-offs in the choice of the components (i.e., the Q of the notches)

Here's a better improved design of the 11Mhz PD.

Attachment 1: pox11.pdf
pox11.pdf
  2893   Thu May 6 19:57:26 2010 AlbertoUpdate40m UpgradingNew improved design for the 11MHz photodiode

Quote:

After munching analytical models, simulations, measurements of photodiodes I think I got a better grasp of what we want from them, and how to get it. For instance I now know that we need a transimpedance of about 5000 V/A if we want them to be shot noise limited for ~mW of light power.

Adding 2-omega and f1/f2 notch filters complicates the issue, forcing to make trade-offs in the choice of the components (i.e., the Q of the notches)

Here's a better improved design of the 11Mhz PD.

 This should be better. It should also have larger resonance width.

Attachment 1: pox11.pdf
pox11.pdf
  2894   Fri May 7 11:21:49 2010 kojiUpdate40m UpgradingNew improved design for the 11MHz photodiode

How much is the width?

Quote:

 This should be better. It should also have larger resonance width.

 

  2896   Fri May 7 18:18:02 2010 AlbertoUpdate40m UpgradingNew improved design for the 11MHz photodiode

Quote:

How much is the width?

Quote:

 This should be better. It should also have larger resonance width.

 

 The transfer function phase drops by 180 degrees in about 2MHz. Is that a good way to measure the width?

  2897   Fri May 7 19:02:27 2010 ranaUpdate40m UpgradingNew improved design for the 11MHz photodiode

To measure the width of a resonance, the standard method is to state the center frequency and the Q. Use the definition of Q from the Wikipedia.

As far as how much phase is OK, you should use the method that we discussed - think about the full closed loop system and try to write down how many things are effected by there being a phase slope around the modulation frequency. You should be able to calculate how this effects the error signal, noise, the loop shape, etc. Then consider what this RFPD will be used for and come up with some requirements.

  8116   Wed Feb 20 18:35:42 2013 JenneUpdateAlignmentNew in-vac alignment procedure

I have updated the vacuum checklist for in vacuum alignment.  Please take a look (https://wiki-40m.ligo.caltech.edu/vent/checklist) and see if I missed anything.  My goal was to make it incredibly step-by-step so there can be no mistakes.

  6969   Thu Jul 12 15:43:07 2012 YaakovUpdateSTACISNew input point, using accelerometers for feedback

 Here's a picture of where I am now inputting signals into the STACIS with the accelerometers (the orange and blue wires): 

new_input.JPG

I know this is the right point because I could see the geophone signal from these points . By inputting a swept sine signal into this point, I was able to take a transfer function of this first amplifier/filtering circuit board, which will be useful if I need to make my own filter for the STACIS:

cBoard_tFunction.png

I have unplugged the geophones and am inputting a signal from an accelerometer into this point. The accelerometers output a different signal than the geophones, so I am trying to modify the accelerometer signal to be closer to the geophone one. I've lowered the gain on all the pots for the z axis and put in several BNC attenuators to lower the accelerometer signal amplitude.

At the moment, using the accelerometers as feedback makes the platform vibration worse, which will hopefully be solved by some more attenuation or filtering of the accelerometer signal.

  10990   Mon Feb 9 17:23:17 2015 diegoUpdateComputer Scripts / ProgramsNew laptops

I forgot to elog about these ones, my bad... The new/updated laptops are giada, viviana and paola; paola is already in the lab, while giada and viviana are in the control room waiting for a new home. The Pool of Names Wiki page has already been updated to reflect the changes.

  15508   Thu Aug 6 22:57:20 2020 gautamUpdatesafetyNew live HV Supplies

Be aware that there is now a KEPCO HV supply that is energized, sitting on the floor immediately adjacent to the OMC rack, east of the AP table. It is currently set to 100 V DC, and a PI PZT installed on the AP table has its 3 PZTs energized by said supply (via an OMC piezo driver). I will post pictures etc of the work from the last 10 days over the weekend.

  9250   Thu Oct 17 13:40:55 2013 JenneUpdateLSCNew lockin / sensing matrix frequencies

I locked PRMI, and (after fixing the POP QPD situation, noted in elog 9249) took power spectra of all the REFL RFPDs.  It looks like the area above 500 Hz is pretty clean and flat for all the signals, so I'm going to use 560Hz, 562Hz, 564Hz, 566Hz and 568Hz for my 5 sensing matrix frequencies.

Also, I'm not sure what is going on with REFL11, but there's a weird dip between 630 Hz and 660 Hz in both I and Q.  I recentered this guy not too long ago (elog 9218), but it clearly needs some more looking-at.

All_REFL_PRMI_17Oct2013.pdf

  9245   Wed Oct 16 03:04:37 2013 JenneUpdateLSCNew lockin / sensing matrix model parts

Quote:

Still to do:

* Put a little more stuff into the front end so that we get total mag and phase of the sensing matrix element, not just uncalibrated lockin outputs.

 I worked today some more on the new Sensing Matrix situation.  I have added stuff to the CAL model, so that the sensing matrix elements come out calibrated to W/m, with phase in degrees.  The idea is that we can see time series of the calibrated lockin outputs, so that we have minimal post-processing to do, since these are things that will be interesting to look at live.

 

The first step is to go from I and Q to magnitude and phase.  Each "sensor" (ex. REFL55Q) is demodulated with a lockin part, which outputs sub I and Q channels (so, something like REFL55Q_I and REFL55Q_Q).  We are only interested in the _I component of the lockin.  But, REFL55I also has a _I and _Q.  Again, we only take the _I part.  Now, we have REFL55I_I and REFL55Q_I.  We call these the I and Q components of the sensors (this is exactly what we normally call them, but it can get confusing since the lockins also have _I and _Q before we discard the _Q part).  Now, we want to take these I and Q components, and transform them to a magnitude and phase. After we do that, we want to calibrate the magnitude to "Watts per meter" from "counts sensed per counts driven".  I also converted the phase to degrees, since that's the unit we usually use when talking about the sensing matrices. 

To go from the I and Q components to Mag and Phase, I wrote a little block of c-code, which is in /opt/rtcds/caltech/c1/userapps/release/isc/c1/src/MagPhaseFromIQ.c . Since we can't use the arctan function, I approximated it using equation 17 from Full Quadrant Approximations for the Arctangent Function [Tips and Tricks] from IEEE.  (I used x -> y/x in equation 17, so that I had a 2D situation).  I also have an "if / else if" cascade to determine what quadrant I'm in.  Since the formula in the paper is from [0,pi/2), I just needed to add pi, subtract the answer from pi, or negate the answer to get to the other quadrants.  Also, note that they are using a "normalized" arctan function, so equation 17 is really from [0,1), and you have to remember to multiply by pi/2 on your own.

To get from drive counts to drive meters, I put in an EPICS variable for the optic's actuation constant (ex, PRM's constant can be found in elog 8255).  Right now, we have to transfer the oscillation frequency from the oscillator part's _FREQ variable to a new EPICS variable, but Zach and Joe just today made a new oscillator part that makes it easier to access the frequency and amplitude of the drive within the front end.  See LLO aLog 9139 for details on this new part.  I had trouble compiling with their new part, but once I get that figured out, I won't need to do this transfer of information.  Anyhow, the drive calibration is (optic actuation constant)/[(drive frequency)^2]. 

Then the total calibration of the magnitude is Mag in cts/m = 2 * mag / [(drive amplitude) * (drive calibration)] .  The factor of 2 comes from the fact that the lockin output is a factor of 2 smaller than the true sensing matrix element.  The lower case "mag" in the formula is the output of the c-code. 

After this, there is yet another EPICS variable, to hold the calibration for the photodiode, to get from counts sensed to Watts of power at the actual port.  By "actual port", I mean the true IFO port, taking into account any optical elements between the port and the photodiode, like beam splitters and dumps, or loss from the imperfect reverse isolation of the input Faraday.

The code all compiles and runs fine, although I haven't done any explicit testing yet.

Still to-do for Sensing Matrix:

* Find all of the numbers for all of the EPICS variables.  In particular, I need to get the ratio of the power hitting each photodiode to the power at that port. 

* Write a script to do a burt-restore with all the correct settings, and turn on the dither lines.

* Put the lowpass filters back in the demodulators, now that they have new (shorter) names.

* Try it, and compare with the optickle model, and previous measurements.

* Copy Anamaria's script to look at the error statistics for my measurements.

 

  9270   Wed Oct 23 19:28:22 2013 JenneUpdateLSCNew lockin / sensing matrix model parts

I have modified the Sensing Matrix I,Q to Mag, Phase library part in the new sensing matrix system.

I had forgotten that in the c-code, I convert from radians to degrees, and so was doing the conversion again in the model.  As it turns out, this gives you a nonsense number.  I removed the multiplication by 180/pi in the model, and just use the output of the c-code, which is already in degrees.

I also put in some "choice" blocks just before the divisions in the calibration section of this library part.  If it's about to divide by zero, divide by one instead.

The last modification so far today was adding the _PHASE_DEG and _MAG_WPERM (watts per meter) channels to a DAQ channels block, so that they are saved.

The RCG was very unhappy with me having 2 channels, with no data rate after them (doing this is supposed to imply that both should be saved at the default data rate), however after I put in "2048", it was happy.  The symptom was a little tricky:  The channel names in Dataviewer showed up red, even though the model compiles and runs.  An indicator that you have a problem is a note in the model's "GDS" screen (the details screen that you can click to from the CDS front end overview screen).  The channel name is "C1:FEC-50_MSGDAQ" (where the number 50 is specific to the c1cal model).  After restarting the model, but before restarting the framebuilder's daqd process, this channel said "Error reading DAQ file!", rather than the date and time of the last successful read.   At this point, before restarting the daqd process on the framebuilder, all of the fb statuses are green and good.  However, after restarting the daqd process on the framebuilder, I got status "0x2000".  Anyhow, after trying many different things, I determined that I could have 1 channel, without a specified rate, but if I wanted more than one channel, I needed to specify the rate for both.

  9227   Wed Oct 9 22:05:55 2013 JenneUpdateLSCNew lockin / sensing matrix screens

After finishing up working on the models for today, I made corresponding screens.  

The new Sensing Matrix (and lockin) overview screen is accessible from the sitemap:  LSC -> Sensing Matrix. 

From there, you have the oscillators, input matrices (one per degree of freedom), output matrix, and the lockin modules themselves.  You can either look at several PDs for one degree of freedom (ex. there is a screen for all the AS RFPDs, demodulated for the DARM oscillation), or all the degrees of freedom for a single PD (ex. how are all the degrees of freedom seen in AS55Q?).  The LSC screen has been updated to match - now you see 5 oscillator readbacks, and a larger output matrix.  There is a button for the Sensing Matrix overview screen, and if you click on the cartoons of the oscillators, it'll take you to the oscillators screen.

Still to do:

* Decide what 5 frequencies to use for excitation.

* Put the bandpass and lowpass filters into the lockin modules.

* Put matching notch filters into each LSC servo.

* Re-write the sensing matrix scripts.

* Put a little more stuff into the front end so that we get total mag and phase of the sensing matrix element, not just uncalibrated lockin outputs.

  9234   Fri Oct 11 17:37:08 2013 JenneUpdateLSCNew lockin / sensing matrix screens

Quote:

Still to do:

* Decide what 5 frequencies to use for excitation.

* Put the bandpass and lowpass filters into the lockin modules.

* Put a little more stuff into the front end so that we get total mag and phase of the sensing matrix element, not just uncalibrated lockin outputs.

 I worked on some of these "to-do" things today for the new sensing matrix setup.  I chose several frequencies around 90 Hz for my measurements.  This was an area (while PRMI was locked with REFL 165 I&Q, and all 4 REFL PDs had their whitening on) there was a pretty wide clean space in the noise spectrum.

I put bandpass filters into the _SIG banks of the lockin modules, and lowpass filters into the _I banks.  However, when I loaded the new filter coefficients, it looks like not all of them are showing up in the screens.  I'm a little confused as to why.  They are still there if I close and re-open Foton, so I think I really put them in.

Also, I don't think that I'm successfully getting any signal from the LSC model into the new lockin modules on the CAL model.  I'm not sure if this is to do with the fact that I added 32 more IPC connections the other day.  I've emailed Jamie to ask whether or not we may have hit some limit.

I also tried testing out a small bit of c-code for the calibration of the lockin outputs.  It seems as though I cannot do an arctangent in the front end.  When I compile the c1tst model, and start it up, if I have an "atan2" in the code, it tells me "No Sync".  However, if I remove that line of c-code, the model compiles fine (which it did in the case with the arctan), and the model runs just fine (which it doesn't with the arctan).  My backup plan is to include a Taylor expansion for the arctangent in some c-code.

  9236   Sun Oct 13 13:29:09 2013 ranaUpdateLSCNew lockin / sensing matrix screens

  I think that we always drive above the UGF for sensing matrix measurements since we like to put notches in the servo. In principle, we could drive within the control band and then take out the effect by measuring the control signal and undoing the gain in the digital filters. But that seems pretty complicated for any MIMO system.

  9237   Mon Oct 14 17:40:15 2013 JenneUpdateLSCNew lockin / sensing matrix screens

 Hmmmm, yup.  I forgot to pay attention to what the UGFs of our LSC loops are when I was picking a low-noise region.  Since they're (currently, at least) around 100Hz, I want to find a frequency in the few hundred Hz region.  Masayuki has the IFO right now for ALS diagnostics, so I'll pick new frequencies later.   If we decide to omit the bandpass filters, it's even easier to change frequencies on the fly (although we'll always still have to make the servo notch filters match).

  9239   Mon Oct 14 21:12:35 2013 JenneUpdateLSCNew lockin / sensing matrix screens

After staring and thinking, I remembered that there is a limit to the number of characters that a channel name can have.  So, I removed the "_LOCKIN" part of the names, and recompiled, and everything seems to work.  I modified the screens that I had made, and they show all the appropriate things now.  

The symptoms were that the numbers in the filter banks (for example, INMON) were white with the usual black background.  The numbers are supposed to be green with a black background.  After I recompiled, all the numbers were green.

This also means I need to re-put in the low pass filters. 

  13789   Wed Apr 25 19:09:37 2018 gautamConfigurationALSNew look EX Fiber coupling

Summary:

I implemented most of the things outlined in my previous elog. Implementing the a la mode solution after including all lenses, I managed to achieve >90% mode-matching into the fiber. Power monitor PD has not been re-installed yet, neither has the bracket I removed. The polarization monitoring setup on the PSL table has now been hooked up to the EX fiber, let's see how it does overnight. All quoted power measurements in this elog were made with the Ophir power meter (filter off).

Details:  

Attachment #1 shows the implemented MM solution. I did not include the PBS substrate in the calculation, maybe that will help a little.

Attachment #2 shows the new layout. The beam is a little low on the PBS and HWP - I will swap these out to mounts with slightly lower height, that should improve the situation a little. There is no evidence of clipping, and the beam clears all edges by at least 3 beam diameters.

Attachments #3 and #4 show the EX fiber before and after cleaning respectively. Seems like the cleaning was successful.

Attachment #5 shows the beam incident on the coupler with on an IR card. This beam only goes through a QWP, lens, BS and 45 degree steering mirror, so I'm not sure what's responsible for the large halo around the main beam. There is significant power in the halo too - I measured 25mW right before the coupler, but if I use an iris to try and cut off the halo, the power is measured to be ~19mW.

Alignment Procedure:

  • Connect spare fiber such that I can monitor coupled power (minus fiber losses and joint loss) at EX table.
  • Use Fluke fault analyzer to align input and collimator modes coarsely.
  • Monitored coupled power continuously using Fiber Power Meter (although MM calculations were made with Ophir, this was more convenient for "Live" viewing).
  • Tweaked one available steering mirror and K6XS axes to maximize coupled power. 
  • Tweaked lens positions slightly to see if significant improvement could be made.
  • After optimizing, I measured 17.1mW coming out of the EX fiber at the PSL table. As mentioned earlier, the input power is tricky to measure given the large amount of junk light around the main mode. But I measured 18.6 mW after the iris. So this is ~95%. In any case, safe to say that we are waaaay better than the previous situation of 380uW out of 1.9mW. 
  • Added PBS and HWP to cut the incident power to 1.6mW. I measured 1.2mW on the PSL table. Probably adding the PBS screwed up the MM a bit, to be tweaked tomorrow. 
  • I had moved the Green shutter a bit during this work - as a result, the Green REFL was not making it back to the REFL PD. I remedied this, and EX Green TEM00 mode was locked to the arm. GTRX of ~0.4 was recovered, which is around the number I'm used to seeing.
Attachment 1: EX_fiber_MM.pdf
EX_fiber_MM.pdf
Attachment 2: IMG_6977.JPG
IMG_6977.JPG
Attachment 3: IMG_6972.JPG
IMG_6972.JPG
Attachment 4: IMG_6974.JPG
IMG_6974.JPG
Attachment 5: IMG_6976.JPG
IMG_6976.JPG
  13791   Thu Apr 26 11:24:50 2018 gautamConfigurationALSNew look EX Fiber coupling - pol stability

Here is a first look at the overnight stability. For the temperature, I used the calibration I found in the old psl database file, seems to give sensible results. It's only 15 hours of data plotted, so we don't see the full 24 hour temperature swing, but I think it is safe to say that for the EX fiber, the dominant cause of the "waveplate effect" is not in fact temperature drift. The polarization extinction is still better than 10dB in the entire period of observation though... I'm going to push ahead with a beat spectrum measurement, though there is room for improvement in the input coupling alignment to fiber special axes.

The apparent increase in these plots towards the end of the 15 hour period is because the lights on the PSL table were switched on.


Annoyingly, it seems like the PSL NPRO channels (which I have hijacked to do this test) do not have minute trend data directly accessible from NDS2. Not sure whether this is an NDS2 problem, or something missing in the way the channels are setup with Acromag. Probably the former, as I am able to generate minute trend plots with dataviewer. I forget whether this is the same as the infamous minute trend problem. Second trend data is available though, and is what I used to make these plots...

Attachment 1: polStab.pdf
polStab.pdf
  13792   Thu Apr 26 18:58:21 2018 BruceConfigurationALSNew look EX Fiber coupling - pol stability

  7824   Thu Dec 13 18:06:59 2012 AyakaUpdateWienerFilteringNew microphone mounts

 Yesterday, I made new mounts for microphones.

IMG_0129.JPGIMG_0130.JPG

I glued a microphone on a pedestal. The cables are attached loosely so that its tension does not make any noise.
At the bottom of the mount, I attached the surgical tube forming a ring by double-side tape so that it damps the seismic vibration.

I made 6 mounts and these are all on the AS table now.
I took some data of XARM signal controlled by AS.

My plan is to find/set an upper limit on acoustic coupling noise in AS signal.
The acoustic noise can be estimated by the Wiener filter, but it is not accurate because it may see residual correlation between AS and microphone signals that should be 0 when the data is long enough.
I will find/set an upper limit by the analysis based on Neuman-Pearson criterion, that is analog of a stochastic GW background search.
If I can find the acoustic coupling noise should be below the shot noise, I am happy. If not, some improvements may be needed someday.

  6620   Tue May 8 03:33:24 2012 JenneUpdateSUSNew misalign / restore scripts for IFO_ALIGN screen

Since Den wasn't able to fix c1sus (make it talk to the framebuilder) before he left a few hours ago, I decided to do some housekeeping rather than actual locking. 

I wrote new save / misalign / restore scripts for all of the suspended optics on the C1IFO_ALIGN screen.  Adding save / restore versions for the mode cleaner optics should be quick and easy.  Now when you use the ! button for each optic, it points you to the new scripts.  I still have the burt capabilities there, but the restore script has the burt-restore line commented out.

Functionality:

SAVE:  burt-save the PIT_COMM and YAW_COMM values, as well as write those values and the date to a text file.

MISALIGN:  Turn off oplevs, move 100 steps of 0.01 in the "+" direction.

RESTORE: Move ~100 steps toward the saved value, until you're within 0.001 of the saved value (step size is "saved val" minus "current val" divided by 100).  Then just write the saved value to the slider (otherwise if the slider were touched between the last "save" and the restore, we might not be able to step precisely to the value we want). Turn oplevs back on.

Scripts are in the same place the old ones used to live:  ...../caltech/c1/medm/c1ifo/cmd/   New scripts are C1IFO_OPTIC(save/restore/misalign)_soft.cmd

I'm checking this one off of the to-do list.

 

Good things:  (a) I remembered / re-learned / just plain learned a lot about scripting.  (b) the optics are now walked slowly over to their misaligned state, and slowly walked back.  The past regime had the optics suddenly kicked over by a lot, sometimes enough to trip / come close to tripping watchdogs, which was never good.

Bad things: it took a long time.  Now it's bedtime.

  8949   Thu Aug 1 12:12:35 2013 gautamUpdateCDSNew model for endtable PZTs

I have made a new model for the endtable PZT servo, and have put it in c1iscex. Model name is c1asx. Yesterday, Koji helped me start the model up. The model seems to be running fine now (there were some problems initially, I will post a more detailed elog about this in a bit) but some channels, which are computer generated, don't seem to exist (they show up as white blocks on the MEDM GDS_TP screen). I am attaching a screenshot of the said screen and the names of the channels. More detailed elog about what was done in making the model to follow.

 

C1ASX_GDS_TP.png

 

Channel Names:

C1:DAQ-DC0_C1ASX_STATUS (this is the channel name for the two leftmost white blocks)

C1:DAQ_DC0_C1ASX_CRC_CPS

C1:DAQ-DC0_C1ASX_CRC_SUM

  8951   Thu Aug 1 15:06:59 2013 jamieUpdateCDSNew model for endtable PZTs

Quote:

I have made a new model for the endtable PZT servo, and have put it in c1iscex. Model name is c1asx. Yesterday, Koji helped me start the model up. The model seems to be running fine now (there were some problems initially, I will post a more detailed elog about this in a bit) but some channels, which are computer generated, don't seem to exist (they show up as white blocks on the MEDM GDS_TP screen). I am attaching a screenshot of the said screen and the names of the channels. More detailed elog about what was done in making the model to follow.

 

C1ASX_GDS_TP.png

 

Channel Names:

C1:DAQ-DC0_C1ASX_STATUS (this is the channel name for the two leftmost white blocks)

C1:DAQ_DC0_C1ASX_CRC_CPS

C1:DAQ-DC0_C1ASX_CRC_SUM

I don't know what's going on here (why the channels are white), and I don't yet have a suggestion of where to look to fix it but...

Is there a reason that you're making a new model for this?  You could just use and existing model at c1iscex, like the c1scx, and put your stuff in a top-names block.  Then you wouldn't have to worry about all of the issues with adding and integrating a new model.

  8956   Thu Aug 1 20:58:56 2013 gautamUpdateCDSNew model for endtable PZTs-MEDM Screens setup

 

I have made some minor changes to the model, made all the MEDM screens, and linked monitors on these to the appropriate channels. I have borrowed heavily from the C1ASS MEDM screens (particularly for the small filter modules-it was convenient to just copy and paste an existing module, and edit the channel names using EMACS/GEDIT), and have edited these to suit the needs of this servo. Some features:

  • The feedback signal (only the output of the servo to the PZTs, plus any contribution from the on-screen sliders, and not including the LO output) is monitored with both a slow (using CDS_EPICS_OUTPUT block from the CDS_PARTS library) and fast channel (using Test Point from the same library). The idea is that it would be useful to know the output to the PZTs such that if coarse adjustment ever needs to be done at the endtable, the PZTs can be restored to the middle of its operating range by means of the sliders.
  • Sliders are incorporated into the master screen for adjusting the output to the PZTs. There are text-input fields below the sliders as well, which control the same channel.
  • I have removed the 4 remaining excitation points to the DAC set up in C1SCX, and have relocated them to channels 12-15 of the DAC in C1ASX.

I think I am now ready to take some measurements and try and optimize this servo. There is no green transmission at the PSL table at the moment, so not much can be done, though the first step would be to take the power spectrum of the error signal, which would help me decide the appropriate frequencies for the LOs. I would then have to add the appropriate filters to the model. The last, and most difficult step, would be the measurement of the output matrix, though Koji has given me some ideas about how this measurement can be done. I also have a template script ready, though I will only finalise this after optimising the servo and running it a couple of times manually.

 

Attached are screenshots of the MEDM screens.

 

MAIN_SCREEN.pdf      MATRICES.pdf   

LOCKINS.pdf      CONTROL_FILTERS.pdf

 

  8952   Thu Aug 1 15:28:44 2013 gautamUpdateCDSNew model for endtable PZTs-problem solved

Quote:

 

I don't know what's going on here (why the channels are white), and I don't yet have a suggestion of where to look to fix it but...

Is there a reason that you're making a new model for this?  You could just use and existing model at c1iscex, like the c1scx, and put your stuff in a top-names block.  Then you wouldn't have to worry about all of the issues with adding and integrating a new model.

Koji just fixed this.

It seems that the new model's channels were not automatically added to the master file in the framebuilder (/opt/rtcds/caltech/c1/target/master). Adding the following two lines to the master file fixed the problem;

/opt/rtcds/caltech/c1/chans/daq/C1ASX.ini

/opt/rtcds/caltech/c1/target/gds/param/tpchn_c1asx.par

The box is now green. It looks like C1ASX.ini is created automatically in /opt/rtcds/caltech/c1/chans but the master file needs to be manually edited. The channels are now showing up on dataviewer etc. I have updated the information on the wiki page.


 

 

 

 

 

  8950   Thu Aug 1 13:09:17 2013 gautamUpdateCDSNew model for endtable PZTs-procedure

 

 These are roughly the steps I followed in setting up the new model for the endtable PZT servo - C1ASX.


Simulink model:

I made a SIMULINK model of the servo, using MATLAB R2013a. The path to the model is /opt/rtcds/caltech/c1/userapps/release/isc/c1/models/c1asx.mdl. I am listing the parameters set on the CDS_PARAMETERS block:

  • host = c1iscex
  • site = c1
  • rate = 16k
  • dcuid = 44 (which I chose after making sure that this dcuid was not used on this list which was last updated end Feb 2013)
  • specific_cpu = 5 (again chosen after checking the available CPUs in the above list).
  • adc_Slave = 1
  • shmem_daq = 1
  • no_rfm_dma = 1
  • biquad = 1

 

Making, Compiling and Installing the Model:

After saving the model, I ssh-ed into c1iscex and ran the following commands:

rtcds make c1asx - this gave me a whole bunch of errors initially, which I tracked down to a naming problem in some of the from and goto flags: there should not be any spaces.

rtcds install c1asx 

rtcds start c1asx - this gave me an error which said something like 'can't start/stop model.' Koji pointed out that given that a new model is being started, there is an additional step involved, which is to add the model name to the rtsystab file (this is located at /diskless/root/etc/rtsystab on framebuilder, and is mirrored in the various computers. It would be advisable to make sure that the changes are mirrored in the corresponding file on the computer in which the new model is being installed). 

After adding the model name to the rtsystab file, I tried running rtcds start c1asx again. This time, no errors were output, but the model was not up and running as verified by looking at the C1:ASX_GDS_TP medm screen.


 Debugging 

Koji suggested making a simple model (1 CDS parameters block, 1 ADC block and 2 filter modules, appropriately terminated) and see if that starts up, which it did. I then tried adding my servo minus the DAC block and recompiled and restarted the model. This too worked fine. I figured that the next logical step would be to add the DAC block to the model, and restart the model. But when I tried this, c1iscex crashed .

Jenne helped in restoring things to a working state (we reverted the c1asx model to just 2 filter modules, and went to the X-end and restarted the computer. This did not work the first time so I went back in and restarted it again, at which point we were able to ssh into c1iscex again and restart the four models running on it).

Since Manasa and Koji were working on getting things set up for the pumpdown,I did not try anything again till later in the evening, when Koji helped in debugging the problem further. In the meantime, at Jenne' suggestion, I made the model once again in MATLAB R2010b. In the evening, when I tried restarting the model, Koji suggested that the DAC channels in c1asx may be used by other models, at which point I realised I had set up excitation points on channels 8 through 15 of the DAC in c1scx (detailed here) in order to test the hardware at 1X9. I removed the excitation points from channels 8-11 of the DAC block in c1scx (these are the ones used in c1asx), and recompiled and restarted c1asx (using the above sequence of commands). I then tried recompiling and starting c1asx once more, and this time, it worked . At least, the GDS_TP screen suggests that the model is running alright, except for the fact that some computer generated channels seem to be missing. This problem is unresolved for now, and probably has something to do with the fact that C1ASX channels do not appear in Dataviewer.

I do not think this has to do with restarting framebuilder (I did the usual telnel fb 8088 followed by shutdown). In any case, I have added the new model to the CDS_FE_STATUS screen, and will continue to debug the same. I have also got a template medm screen (work in progress) which I will elog about soon as I get it done.

 

Note to self: There are 4 more excitation channels still hooked up to the DAC (channels 12-15) in the c1scx model. I plan to remove these and put them in c1asx.

 

  8700   Thu Jun 13 15:04:16 2013 JenneUpdateLSCNew modeled sensing matrix

Using all of the latest parameters that I can find, I have re-modeled the 40m sensing matrix.  Also, I have it output the data in a format that can be used by the same plotting function as the measured sensing matrix, so they are nice and easy to compare.

The newly modeled 40m sensing matrix:

SensMatModel_13June2013.png

To compare, here is the measured sensing matrix from elog 8644:

SensMatMeas_23May2013.png

Notice that (a) the units are different, so don't focus too much on the amplitudes of the lines, and (b) all of the measured and modeled matrix elements are pretty similar, except for the REFL11.  REFL11 (top right in model plot, top center in measured plot) looks like it's flipped, as well as rotated.  The new model doesn't match up too well with the Kiwamu/Koji models (which matched eachother okay), but I like that the new model matches the measurements fairly well.  The Koji sensing matrix: on the 40m wiki

EDIT: I have replaced the modelled plot with a new version.  The data and numbers are the same, but I have switched the labels on the individual radar plots, and forced them to be in the same order as they are in the measured plot.

  8702   Thu Jun 13 16:13:08 2013 nicolasUpdateLSCNew modeled sensing matrix

I'd repeat the measurement for REFL11. The PRC arrow has some big error bar on it, and maybe the true error is even bigger.

Also, please make the placement of the plots the same for modeled and measured so it's easy to compare.

  8705   Fri Jun 14 00:32:43 2013 JenneUpdateLSCNew modeled sensing matrix

I put in a new version of the modelled plot.  I figured out a different way to keep things generic so the same script can be used for other sites, but writes the names in the same format as the measured matrix, so the correct order is preserved.

The REFL11 measurement is consistent with the one in elog 8648 (data taken a few days earlier), within the error bars.  My goal for tonight is to hopefully get the POP path back in order, so that I can lock the PRMI again, and can measure again if I want.

The error bars for each sensor are only taken once (with no drive, so it's the noise in the "dark" sensor).  I take 6 "dark" measurements for each sensor, and get the stdev.  Then I use that and propagate it through for each measured sensing matrix element.  So, the PRCL and MICH error bars for REFL11 were created from the same standard deviation, and propagated in the same way, but the values plugged into the partial derivative of the function were different for PRCL and MICH. 

s_f = \sqrt{ \left(\frac{\partial f}{\partial {x} }\right)^2 s_x^2 + \left(\frac{\partial f}{\partial {y} }\right)^2 s_y^2 + \left(\frac{\partial f}{\partial {z} }\right)^2 s_z^2 + ...}(wikipedia - propagation of uncertainties)

 

Also, to answer an emailed question via the elog, the "0 degree" axis of the plots is the 0 demod phase axis, which corresponds to the I output of the demod boards (the I input to the RFPDs, before the phase rotation).  The "I" axis that I've drawn is the current demodulation phase that we have, which corresponds to the I_ERR output of the RFPDs after the phase rotation, which is the PD_I signal that goes into the LSC input matrix.  I draw this to help us see if our current demod phase is well tuned or not.

Yes, the MICH and PRCL signals are not at all orthogonal in the REFL33 sensor.  I think this is because our modulation frequency was chosen to be good in the case of the full DRFPMI IFO, not the corner IFO cavities.  As I calculated in elog 8538, the ideal frequency for the PRMI is 18kHz larger than our current modulation frequency. 

For the plots below, note that 11.066134 MHz is our current actual modulation frequency, and 11.0843 MHz is my calculated ideal modulation freq

Model, using our current modulation frequency, and the designed PRCL cavity length (same as elog earlier today):

SensMatModel_13June2013_currentPRMIfreq.png

Model, using the "ideal" PRMI modulation freq, and the PRCL cavity length used in elog 8538, where I calculated that number (a few cm different than the design PRCL length):

SensMatModel_13June2013_idealPRMIfreq.png

You can see that if we could use a better frequency, we would get much, much better signal separation.  Since our modulation frequency choice is related to our vacuum envelope constraints (we can't make the arms of a length that will have the sidebands exactly antiresonant when the arms are locked on the carrier), I hope that this will not be a significant issue in aLIGO. 

  8706   Fri Jun 14 02:38:07 2013 ranaUpdateLSCNew modeled sensing matrix

 This is nice - how about figuring out how to plot the measurement and model on the same plot? I guess we need to figure out how to go from counts to Watts.

  8737   Mon Jun 24 11:51:23 2013 JenneUpdateLSCNew modeled sensing matrix

Quote:

 This is nice - how about figuring out how to plot the measurement and model on the same plot? I guess we need to figure out how to go from counts to Watts.

I haven't done a units conversion for the measured vs. modelled plot,  but at least we can compare the separation between the different degree of freedom signals.  Figuring out why the REFL11 measurement and models are so different is still high on my to-do list.  But at least the measurements that were taken last month are consistent with one another. EDIT:  The separation angles match up pretty well between the 2 sets of measurements, but the overall rotation isn't really consistent.  I do not believe that the phase rotation values that we're using online changed between the measurements, so the I&Q lines should be the same for both seets of measurements....however, I did not write down the phase rotation values at the time of the first measurement, so there's a chance that they were different.  Also, something that I need to monitor is the coherence of my measurement, to make sure I'm really driving and measuring something.

 

2 measurements, with overall rotation arbitrarily rotated to make MICH lines match up:

SensMatMeas_23May2013_21May2013_overlay.png

Same 2 measurements, without the arbitrary overall rotation:

SensMatMeas_23May2013_21May2013_NoRotation_overlay.png

Measurement vs. Model, with the *modelled* phase arbitrarily rotated:

SensMatMeas_23May2013meas_13June2013model_overlay.png

  5511   Thu Sep 22 01:05:28 2011 KatrinUpdateGreen LockingNew modulation frequency (Y arm)

[Kiwamu / Katrin]

 

On Wednesday, the green light was locked to the Y arm cavity.

Modulation frequency was changed from 279kHz to 178875Hz. The amplitude was changed from 10Vpp to 0.01Vpp to achieve a modulation index of 0.38. The modulation frequency was changed to minimize AM. With the new modulation frequency the laser light could still locked to the cavity.

The signal of the LO and the photodiode are multiplied by a ZAD-8 mini circuit mixer (Level 7). This mixer requires LO input is +7dBm = 1.4Vpp. Thus we put a 36dB attenuator between the LO and the PZT at the laser. PDH error signal shows lots of peaks that are most likely higher order sidebands. Thus, the next step is to work on the low-pass filter. However the SNR of the error signal has improved with the new modulation frequency. With the old mod. frequency the PDH signal was 4mVpp and the noise floor was 2mVpp.

Phase between the photodiode signal and LO is shifted by about 10 degrees. Step two is to work on a phase shifter.

 

 

  3055   Tue Jun 8 15:58:25 2010 josephb, alexUpdateCDSNew multi-filter matrix part added to RCG (at the 40m at least)

A new webview of the LSP model is available at:

https://nodus.ligo.caltech.edu:30889/FE/lsp_slwebview_files/

This model include a couple example noise generators as well as the new Matrix of Filter banks (5 inputs x 15 outputs = 75 Filters!).  The attached png shows where these parts can be found in the CDS_PARTS library.  I'm still working on the automatic generation of the matrix and filter bank medm screens for this part.  The plan is to have a matrix screen similar to current ones, except that the value entry points to the gain setting of the associated filter.  In addition, underneath each value, there will be a link to the full filter bank screen.  Ideally, I'd like to have the filter adl files located in a sub-directory of the system, to keep clutter down.

I've cut and past the new Foton file generated by the LSP model below.  The first number following the MTRX is the input the filter is taking data from and the second number is the output its pushing data to.  This means for the script parsing Valera's transfer functions, I need to input which channel corresponds to which number, such as DARM = 0, MICH = 1, etc.  So the next step is to write this script and populate the filter banks in this file.

# FILTERS FOR ONLINE SYSTEM
#
# Computer generated file: DO NOT EDIT
#
# MODULES DOF2PD_AS11I DOF2PD_AS11Q DOF2PD_AS55I DOF2PD_AS55Q
# MODULES DOF2PD_ASDC DOF2PD_POP11I DOF2PD_POP11Q DOF2PD_POP55I
# MODULES DOF2PD_POP55Q DOF2PD_POPDC DOF2PD_REFL11I DOF2PD_REFL11Q
# MODULES DOF2PD_REFL55I DOF2PD_REFL55Q DOF2PD_REFLDC Mirror2DOF_f2x1
# MODULES Mirror2DOF_f2x2 Mirror2DOF_f2x3 Mirror2DOF_f2x4 Mirror2DOF_f2x5
# MODULES Mirror2DOF_f2x6 Mirror2DOF_f2x7 DOF2PD_MTRX_0_0 DOF2PD_MTRX_0_1
# MODULES DOF2PD_MTRX_0_2 DOF2PD_MTRX_0_3 DOF2PD_MTRX_0_4 DOF2PD_MTRX_0_5
# MODULES DOF2PD_MTRX_0_6 DOF2PD_MTRX_0_7 DOF2PD_MTRX_0_8 DOF2PD_MTRX_0_9
# MODULES DOF2PD_MTRX_0_10 DOF2PD_MTRX_0_11 DOF2PD_MTRX_0_12 DOF2PD_MTRX_0_13
# MODULES DOF2PD_MTRX_0_14 DOF2PD_MTRX_1_0 DOF2PD_MTRX_1_1 DOF2PD_MTRX_1_2
# MODULES DOF2PD_MTRX_1_3 DOF2PD_MTRX_1_4 DOF2PD_MTRX_1_5 DOF2PD_MTRX_1_6
# MODULES DOF2PD_MTRX_1_7 DOF2PD_MTRX_1_8 DOF2PD_MTRX_1_9 DOF2PD_MTRX_1_10
# MODULES DOF2PD_MTRX_1_11 DOF2PD_MTRX_1_12 DOF2PD_MTRX_1_13 DOF2PD_MTRX_1_14
# MODULES DOF2PD_MTRX_2_0 DOF2PD_MTRX_2_1 DOF2PD_MTRX_2_2 DOF2PD_MTRX_2_3
# MODULES DOF2PD_MTRX_2_4 DOF2PD_MTRX_2_5 DOF2PD_MTRX_2_6 DOF2PD_MTRX_2_7
# MODULES DOF2PD_MTRX_2_8 DOF2PD_MTRX_2_9 DOF2PD_MTRX_2_10 DOF2PD_MTRX_2_11
# MODULES DOF2PD_MTRX_2_12 DOF2PD_MTRX_2_13 DOF2PD_MTRX_2_14 DOF2PD_MTRX_3_0
# MODULES DOF2PD_MTRX_3_1 DOF2PD_MTRX_3_2 DOF2PD_MTRX_3_3 DOF2PD_MTRX_3_4
# MODULES DOF2PD_MTRX_3_5 DOF2PD_MTRX_3_6 DOF2PD_MTRX_3_7 DOF2PD_MTRX_3_8
# MODULES DOF2PD_MTRX_3_9 DOF2PD_MTRX_3_10 DOF2PD_MTRX_3_11 DOF2PD_MTRX_3_12
# MODULES DOF2PD_MTRX_3_13 DOF2PD_MTRX_3_14 DOF2PD_MTRX_4_0 DOF2PD_MTRX_4_1
# MODULES DOF2PD_MTRX_4_2 DOF2PD_MTRX_4_3 DOF2PD_MTRX_4_4 DOF2PD_MTRX_4_5
# MODULES DOF2PD_MTRX_4_6 DOF2PD_MTRX_4_7 DOF2PD_MTRX_4_8 DOF2PD_MTRX_4_9
# MODULES DOF2PD_MTRX_4_10 DOF2PD_MTRX_4_11 DOF2PD_MTRX_4_12 DOF2PD_MTRX_4_13
# MODULES DOF2PD_MTRX_4_14  
# MODULES 

Attachment 1: CDS_Library.png
CDS_Library.png
  9954   Wed May 14 17:36:32 2014 ericqUpdateCDSNew netgpib scripts for SR785

 I have redone the SPSR785 (spectrum measurement) and TFSR785 (TF measurement) commands in scripts/general/netgpibdata. This was mostly motivated by my frustration with typing out either a ton of command line arguments, or rooting around in the script itself; I'd rather just have a static file where I define the measurement, and can keep track of easier. 

They currently take one argument: a parameter file where all the measurement details are specified. (i.e. IP address, frequencies, etc.) There are a few template files in the same directory that they use as default. (Such as TFSR785template.yml)

If you call the functions with the option '--template', it will copy a template file into your working directory for you to modify as you wish. "SPSR785 -h" gives you some information as well (currently minimal, but I'll be adding more)

In the parameter file, you can also ask for the data to be plotted (and saved as pdf) when the measurement is finished. In SPSR785, and soon TFSR785, you can specify a directory where the script will look for reference traces to plot along with the results, presuming they were taken with the same measurement parameters and have the same filename stem. 

I've tested both on Pianosa, and they seem to work as expected. 

Todo:

  • Add support for modifying some parameters at the command line 
  • Extend to the Agilent analyzer
  • Maybe the analyzer settings written to the output file should be verified by GPIB query, instead of writing out the intended settings. (I've never seen them go wrong, though)
  • Make sure that the analyzer has PSD units off when taking a TF. (Thought I could use resetSR785 for this, but there's some funkiness happening with that script currently.)
  • Possibly unify into one script that sees what kind of analyzer you're requesting, and then passes of to the device/measurement type specific script, so we don't have to remember many commands. 

Comments, criticism, and requests are very welcome. 

(P.S. all the random measurement files and plots that were in netgpibdata are now in netgpibdata/junk. I feel like this isn't really a good place to be keeping data. Old versions of the scripts I changed are in netgpibdata/oldScripts)

  10935   Fri Jan 23 14:25:03 2015 evanUpdateCDSNew netgpib scripts for SR785

Does netgpibdata/TFSR785 work at the 40m currently? I rsynced the netgpibdata directory to LHO this morning to do some measurements, but I had to modify a few lines in order to get it to call the SR785 functions properly. My version is attached.

Attachment 1: TFSR785.zip
  10936   Fri Jan 23 15:46:21 2015 ericqUpdateCDSNew netgpib scripts for SR785
Quote:

Does netgpibdata/TFSR785 work at the 40m currently? 

It does appear to work here. However, I've since supplanted TFSR785 and SPSR785 with SRmeasure, which has some simpler command line options for directly downloading a manually configured measurement. I've also set up a git repository for the gpib scripts I've done at https://github.com/e-q/netgpibdata, which could be easier than grabbing the whole 40m directory. 

  1267   Mon Feb 2 19:23:53 2009 YoichiUpdateGeneralNew optical layout plan
The attached is a plan of the optical layout in the central part for the upgrade.
I included, the folded recycling cavities, oplevs for the core optics, POX, POY, POB and video views.
I have not worked out how to handle the beams outside the chambers. It should not be that difficult.
I also did not include beam dumps for unwanted beams.

I used pink for main beams, brown for picked off beams, red for oplevs.

Comments, suggestions are welcome.
Attachment 1: 40mUpgradeOpticalLayoutPlan01.pdf.zip
  1269   Tue Feb 3 19:24:14 2009 YoichiUpdateGeneralNew optics layout wiki page
I uploaded a slightly updated version of the new optics layout on the 40m wiki.
http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_08/Optical_Layout

I also uploaded the Mathematica notebook I used to calculate various parameters of the new recycling cavities, including the lengths, asymmetry, ROCs, PRM reflectivity and TT-mirror loss margin etc.
It would be nice if someone could check if the calculation is reasonable.
There is a PDF version of the document for non-Mathematica users.
  198   Tue Dec 18 23:27:36 2007 AndreyConfigurationComputer Scripts / ProgramsNew overnight measurements (this night from Tue to Wed)

I am making overnight measurements in XARM tonight.

This is the third night of measurements in XARM, but tonight I am scanning the narrower region between values of damping gain 1.00 and 4.50 with the smaller step 0.25. (for comparison, during two previous measurements the region was between 1.0 and 7.0 with the step 0.5).

I have relocked the XARM before the start of the measurements.

I started running the program at 9.30PM, and it should collect all the data by 9.00AM wednesday morning.

Below are explanations why I chose these different parameters for the interval and step:

I am going to put the results of previous night measurements into the next ELOG entry, and it we be pretty obvious from those graphs that results in XARM from the two previous (different) nights agree well with each other, and the approximate positions of minima and areas of "big growth" of the surfaces are pretty obvious from those graphs. It is clear that RMS are too big for the values of the damping gain bigger than 4.0, and that minima are somewhere near the values of 2.0. But those graphs were too rough to locate a somewhat precise value for the minima. Therefore, I am studying tonight the interval of gains between 1.00 and 4.50 with a smaller step.

A short note how I estimate time that is necessary to collect the experimental data.

there are 15 experimental points for each ETMX and ITMX suspension gains in the interval between 1.00 and 4.50 with the step 0.25. They are: 1.00, 1.25, 1.50, 1.75, 2.00, ..., 3.75, 4.00, 4.25, 4.50. As I am changing both ETMX and ITMX gains, I have an array of 15*15=225 elements.
It takes 3 minutes for each point to collect the data (I wrote the program that way). Therefore, the total time it takes to run the program is: 225*3=675 minutes, or 675/60=11.25 hours, almost 11 and a half hours.
  205   Thu Dec 20 02:04:09 2007 AndreyUpdateComputer Scripts / ProgramsNew overnight measurements in XARM and their results

I ran in the daytime/evening time my program, changing the damping gains in suspension "position" degree of freedom for ETMX and ITMX
in the interval from 1.00 to 3.75 with the step 0.25 (see entry # 201).

Now I am running overnight (from 2AM till 9AM) the program changing the gains in the interval from 1.3 to 3.5 with the step 0.20,
12 X 12 = 144 experimental points. I started so late because I fell asleep after my Wednesday evening dinner, then woke up half an hour ago and hurried to the lab.

BELOW: RESULTS OF MEASUREMENTS WERE ADDED ON THURSDAY EVENING, DEC. 20.

All the meaning of the attachments 1-3, 4-6, 7-9, 10-11 is the same as in previous ELOG entries # 195, # 199, # 202, see in those entries which graph corresponds to which coordinate axes orientation.
Attachment 1: RMS-08Hz-Top-View.png
RMS-08Hz-Top-View.png
Attachment 2: RMS-3Hz-Top-View.png
RMS-3Hz-Top-View.png
Attachment 3: RMS-broadband-Top-View.png
RMS-broadband-Top-View.png
Attachment 4: RMS-08Hz-Side_View.png
RMS-08Hz-Side_View.png
Attachment 5: RMS-3Hz-Side_View.png
RMS-3Hz-Side_View.png
Attachment 6: RMS-broadband-Side_View.png
RMS-broadband-Side_View.png
Attachment 7: RMS-08Hz-Q_I-Q_E-Axes.png
RMS-08Hz-Q_I-Q_E-Axes.png
Attachment 8: RMS-3Hz-Q_I-Q_E-Axes.png
RMS-3Hz-Q_I-Q_E-Axes.png
Attachment 9: RMS-broadband-Q_I-Q_E-Axes.png
RMS-broadband-Q_I-Q_E-Axes.png
Attachment 10: Accelerometer-ETMX.png
Accelerometer-ETMX.png
Attachment 11: Accelerometer-ITMX.png
Accelerometer-ITMX.png
  15554   Thu Sep 3 00:00:57 2020 gautamUpdateBHDNew patch cable installed
  • 10m PM1064 cable was installed. I tried a double shielding approach (photos tmrw here), but I suspect the real weak point is where the fiber is plugged into the collimator - it's hard to imagine we can stabilize this sort of arrangement to better than 100um absolute length over long periods of time, I'd think thermal/mechanical strains in the fiber will modulate the length by ~mm (?). Anyways, let's see what the heterodyne measurement tells us.
  • This work required (i) realignment at the input coupler and (ii) change of position of mode matching lenses in the LO path on the AS table to see any interference with the IFO beam. This indicates something was seriously wrong with the old patch cable, as the collimator should set the mode. The MFD of the two fibers may have been different, but I don't know if that alone can account for it.
  • As of now, I have fringes between the ITM single bounce and the LO, but the fringe pk-pk is only 10% of the theoretical pk-pk based on DC values of the LO and AS beams. So the mode matching can be improved significantly (I preivously had ~60%).

To be continued tomorrow. I think it's a good idea to let the newly installed fiber relax into some sort of stable configuration overnight.

ELOG V3.1.3-