40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 242 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  7792   Wed Dec 5 09:53:01 2012 ranaUpdateWienerFilteringThe microphones and the speaker on the AP table

  Don't try to re-invent the mic mount: just copy the LIGO mic mount for the first version.

  7768   Fri Nov 30 14:21:18 2012 ranaHowToComputer Scripts / ProgramsThe mystery of PDFs and you. As deep as the mystery of Rasputin.

This is how to post PDF:

From DTT, print the plot as a postscript file.

Then use ps2pdf to make a archival PDF version (the flag is the key!). Example:

ps2pdf -dPDFX /home/controls/Desktop/darm.ps

  190   Thu Dec 13 12:05:36 2007 albertoOmnistructureElectronicsThe new Butterworth seems to work quite well
It works better probably because of the small inductors I'm using this time.
The peak is at 30 MHz because I didn't have the precise elements to get 33.

The bandwidth and the Q could be improved by adding one or two more order to the filter and trying to better match the low-pass' resonant frequency with the high-pass'.

Also I have to see if it could work at 166 and 199 MHz as well.
  1861   Fri Aug 7 17:46:21 2009 ZachUpdateCamerasThe phase camera is sort of working

Shown below are the plots of the amplitude and phase of the Mephisto laser light modulated with a chopper as a square wave at about 1 kHz.  The color bar for the phase should run from -pi to pi, and it does when I don't accidently comment out the color bar function.  Anyway, the phase is consistently pi/4 or pi/4 plus or minus pi.  Usually all three of these phases occur within the same image, as shown below.  Also, the amplitude is a factor of two or so higher than it should be where this phase jump occurs.  I think these problems are associated with the nature of the square wave.  However, there is a software bug that appears to be independent of the input data: there is a rounding error that causes the amplitude to jump to infinity at certain points.  This happened for only a dozen or so pixels so I deleted them from the amplitude plot shown below.  I am currently working on a more robust code that will use the Newton-Raphson method for nonlinear systems of equations. 

  7845   Mon Dec 17 22:42:27 2012 KojiSummaryGeneralThe projector lamp ended its life?

i just heard a rather large exploding sound in the control room.
I tried to locate the source and found the projector is not illuminating the wall anymore.
There is a slight smell of burning, but nothing is smoking.

Probably the lamp ended its life.

Rana and I just talked about the projector life time an hour ago! It must have been hearing!

  7846   Mon Dec 17 22:49:33 2012 ManasaSummaryGeneralThe projector lamp ended its life?

Quote:

i just heard a rather large exploding sound in the control room.
I tried to locate the source and found the projector is not illuminating the wall anymore.
There is a slight smell of burning, but nothing is smoking.

Probably the lamp ended its life.

Rana and I just talked about the projector life time an hour ago! It must have been hearing!

 LOL

We should try purchase a projector with LED this time...longer lifetime! I guess the price of replacing the lamp in the one we have will be more or less same as a new one!

  7847   Tue Dec 18 00:45:19 2012 KojiSummaryGeneralThe projector lamp ended its life?

...Nah. The projector is pretty new (t<1yr) and this is the first time to have the lamp busted after the installation last year in Jan.

We just should purchase two bulbs.

  7885   Wed Jan 9 13:34:34 2013 KojiSummaryGeneralThe projector lamp ended its life?

[Koji, Manasa]

- A new projector lamp installed.

- The old lamp lasted 8751 "equivalent lamp hours".

- The old lamp was found being shattered inside. It contains mercury.
So next time you hear the explosion sound of the lamp, establish the ventilation of the room and escape for an hour.

  4920   Thu Jun 30 08:18:08 2011 SureshUpdateIOOThe resonances and notches on WFS1 have been tuned.

As noted before the  resonances had to be tuned to the 29.5 MHz ( or rather 29.485 MHz to match with the Wenzel) and notches to twice that frequency (58.97 MHz). 

I tuned these frequencies and remeasured the transimpedance curves .  These are in the attached pdf file. 

Some notes.

1) The variable inductances on the PCB have a ferrite core which is actually ferrite powder compacted around an iron screw.  The screw serves to provide the adjustability.  However, being iron, it seems to have rusted and so the cores are stuck.  So several of the cores splintered when I tried to adjust the frequencies.

2) The WFS1 had a finger print/smudge on the face of the PD.  I drag wiped it with methanol to get rid of it.

 

WFS1 is ready to go on the table.  I am going to work on WFS2 today.

 

  1186   Mon Dec 8 11:41:27 2008 YoichiSummaryVACThe rough pump for the TP2 replaced
Bob, Yoichi

The foreline pressure of the TP2 (the foreline pump for the main mag-lev turbo (TP1)) was at 2.8torr this morning
when Bob came in.
Looked like the foreline pump (Varian SH-110) was leaking.
Bob started the backup rough pump in parallel with the "leaking" one to keep the foreline pressure low.
We then closed the valve 4 (between TP2 and TP1) and stopped the TP2 and the SH-110.
We replaced SH-110 with another one, but still the foreline pressure was high.
So we replaced it with yet another one. We also changed the quick coupling fasteners on the SH-110 and wiped the O-rings.
This time, it worked fine and the foreline pressure dropped to around 38 mTorr.

Since there is no valve between the TP2 and the SH-110, we could not keep the TP2 running while we were replacing the
problematic SH-110. This means the TP1 was running without a foreline pump during the work. We tried to minimize the
down time of the TP2. The temperature of the TP1 was 33.6C before we stopped the TP2 and it went up to 37.3C during the
work. It is now coming down to the original temperature.

Since we don't know if the problem was caused by bad SH-110s or leaking quick couplings, Bob is checking these apparently
"leaking" SH-110s.
  2215   Mon Nov 9 14:59:34 2009 josephb, alexUpdateComputersThe saga of Megatron continues

Apparently the random file system failure on megatron was unrelated to the RFM card (or at least unrelated to the physical card itself, its possible I did something while installing it, however unlikely).

We installed a new hard drive, with a duplicate copy of RTL and assorted code stolen from another computer.  We still need to get the host name and a variety of little details straightened out, but it boots and can talk to the internet.  For the moment though, megatron thinks its name is scipe11.

You still use ssh megatron.martian to log in though.

We installed the RFM card again, and saw the exact same error as before.  "NMI EVENT!" and "System halted due to fatal NMI".

Alex has hypothesized that the interface card the actual RFM card plugs into, and which provides the PCI-X connection might be the wrong type, so he has gone back to Wilson house to look for a new interface card.  If that doesn't work out, we'll need to acquire a new RFM card at some point

After removing the RFM card, megatron booted up fine, and had no file system errors.  So the previous failure was in fact coincidence.

 

  16265   Wed Jul 28 20:20:09 2021 YehonathanUpdateGeneralThe temperature sensors and function generator have arrived in the lab

I put the temperature sensors box on Anchal's table (attachment 1) and the function generator on the table in front of the c1auxey Acromag chassis (attachment 2).

 

  3230   Thu Jul 15 16:57:31 2010 josephb, kiwamuUpdateCDSThe temporarily named c1scx machine getting ready to connect to IO chassis

This is the machine which will be the new x end front end machine.  Its IP is 192.168.113.86. 

We changed the root and controls passwords to the usual.  We have modified the controls user group to be 1001, by using "usermod -u 1001 controls" (we had to use the non-rtl kernel to get that command to work).

We changed /etc/fstab to point to /cvs/cds on Linux rather than some downs machine.  We added a link to /cvs/cds/rtcds in the local /opt directory.

We modified the /etc/rc.d/rc.local file to no longer run /opt/open-mx/sbin/omx_init start, /cvs/cds/geo/target/fb/mx_stream -d scipe12:0 om1, and /cvs/cds/geo/target/fb/mx_stream -d scipe12:0 -e2 -r2 om2.  We modified the /usr/bin/setup_shmem.rtl to run only c1x00 c1scx and c1spx.

I also commented out a line0 "/bin/rm -f /rtl*"

 

  4464   Wed Mar 30 19:43:33 2011 BryanConfigurationGreen LockingThe wonderful world of mode-matching

Right. I've got a whole load of info and data and assorted musings I've been saving up and cogitating upon before dumping it into these hallowed e-pages. there's so much I'll probably turn it into a threaded entry rather than put everything in one massive page.

An overview of what's coming:

I started out using http://lhocds.ligo-wa.caltech.edu:8000/40m/Advanced_Techniques/Green_Locking?action=AttachFile&do=get&target=modematch_END.png as a reference for roughly what we want to achieve... and from http://nodus.ligo.caltech.edu:8080/40m/100730_093643/efficiency_waist_edit.png we need a waist of about 50um at the green oven. Everything else up to this point is pretty much negotiable and the only defining things that matter are getting the right waist at the doubling oven with enough available power and (after that point) having enough space on the bench to separate off the green beam and match it into the Y arm.

 

So…

Step 1: Measure the properties of the beam out of the laser. Really just need this for reference later because we'll be using more easily measurable points on the bench.


Step 2:
Insert a lens a few cm from the laser to produce a waist of about of a few 100um around the Faraday. Note that there's really quite a lot of freedom here as to where the FI has to be - on the X arm it's around columns 29/30 on the bench, but as long as we get something that works we can get it closer to the laser if we need to.


Step 3:
After inserting the FI need to measure the beam after it (there *will* be some distortion and the beam is non-circular to begin with)


Step 3b:
If beam is non-circular, make it circular.


Step 4:
Insert a lens to produce a 50um waist at the doubling oven position. This is around holes 7/8 on the X arm but again, we're free to change the position of the oven if we find a better solution. The optical set-up is a little bit tight near that side of the bench on the X end so we might want to try aiming for something a bit closer to the middle of the bench? Depends how the lenses work out, but if it fits on the X end it will fit on the Y end.

 
Oh... almost forgot. While I've been doing most of the grunt-work and heavy lifting - thanks go out to Suresh, Kiwamu, Koji, Steve and everyone else who's helped out with discussion of results and assorted assists to numerous to mention.

 

  4465   Wed Mar 30 19:54:19 2011 BryanConfigurationGreen LockingThe wonderful world of mode-matching

RIght! Overview out of the way - now comes the trivial first bit

 

Step 1: Beam out of the laser - this will be tricky, but we'll see what we can actually measure in this set-up. Can't get the Beamscan head any closer to the laser and using a lambda/2 plate + polariser to control power until the Faraday isolator is in place. Using 1 inch separation holes as reference points for now - need better resolution later, but this is fine for now and gives an idea of where things need to go on the bench. The beam is aligned to the 3rd row up (T) for all measurements, the Beamscan spits out diameters (measuring only the 13.5% values) so convert as required to beam radius and the beam is checked to ensure a reasonable Gaussian profile throughout.

 

Position A1_13.5%_width A2_13.5%_width

(bench) (um mean) (um mean)

32 2166.1 1612.5

31 2283.4 1708.3

30 2416.1 1803.2

29 2547.5 1891.4

27 2860.1 2070.3

26 2930.2 2154.4

25 3074.4 2254.0

24 3207.0 2339.4

 

OK. As expected, this measurement is in the linear region of the beampath - i.e. not close to the  waist position and beyond the Rayleigh length) so it pretty much looks like two straight lines. There's no easy way to get into the path closer to the laser, so reckon we'll just need to infer back from the waist after we get a lens in there. Attached the plot, but about all you really need to get from this is that the beam out of the laser is very astigmatic and that the vertical axis expands faster than the horizontal.

Not terribly exciting, but have to start somewhere.

 

laser_output_non_circular.png

 

 

 

  4466   Wed Mar 30 20:08:34 2011 BryanConfigurationGreen LockingThe wonderful world of mode-matching

Step 2: Getting the beam through the Faraday isolator (FI).

Started out with an f=100mm lens at position 32,T on the bench which gave a decent looking waist of order 100 um in the right sort of position for the FI, but after checking the FI specs, it's limited to 500W/cm^2. In other words, if we have full power from the laser passing into it we'd need a beam width of more than 211 um. Solution? Use an f=150mm lens instead and don't put the FI at the waist. I normally don't put a FI at a waist anyway, for assorted reasons - scattering, thermal lensing, non-linear magnetic fields, the sharp changing of the field components in an area where you want as constant a beam as possible.  Checked with others to make sure they don't do things differently around these parts… Koji says it doesn't matter as long as it passes cleanly through the aperture. So… next step is inserting the Faraday.

The beam profiles in vertical and horizontal around the FI position with the f=150mm lens in place are attached. Note that the FI will be going in at around 0.56m.

Beam_Matching_02c_Vertical.pngBeam_Matching_02c_Horizontal.png

 

 

 

  4467   Wed Mar 30 20:14:17 2011 BryanConfigurationGreen LockingThe wonderful world of mode-matching

Additional:

I fired up some old waistplotter routines, and set the input conditions as the measured waist after the lens and used that to work out what the input waist is at the laser. It may not be entirely accurate, but it /will/ be self consistent later on.

 

Vertical waist      = 105.00 um at 6.282 cm after laser output (approx)

Horizontal waist = 144.63 um at 5.842 cm after laser output (approx)

 

Definitely astigmatic.

 

  4468   Wed Mar 30 20:31:30 2011 BryanConfigurationGreen LockingThe wonderful world of mode-matching

Step 3: Inserting FI and un-eliptical-ification of the beam

The FI set up on it's mount and the beam passes through it - centrally through the apertures on each side. Need to make sure it doesn't clip and also make sure we get 93% through (datasheet specs say this is what we should achieve). We will not achieve this, but anything close should be acceptable.

Setting up for minimum power through the FI is HWP @125deg.

Max is therefore @ 80deg

 

Power before FI = 544 mW

Power after FI =     496 mW (after optimising input polarisation)

Power dumped at input crystal = 8.6mW

Power dumped at input crystal from internal reflections etc = 3.5mW

Power dumped at output crystal on 1st pass = approx 8mW

 

OK. that gives us a 90.625% transmission and a 20.1mW absorption/unexplained loss.

 

Well - OK. The important part about isolators isn't their transmission, it's about how well they isolate. Let's see how much power gets ejected on returning through the isolator…

 

Using a beam splitter to pick off light going into and returning from the FI. A 50/50 BS1-1064-50-1025-45P. And using a mirror near the waist after the FI to send the beam back through. There are better ways to test the isolation performance of FI's but this will suffice for now - really only want to know if there's any reasonable isolation at all or if all of the beam is passing backwards through the device.

 

Power before BS = 536 mW (hmmn - it's gone down a bit)

Power through BS = (can't access ejected on first pass)

Power through FI = 164 mW (BS at odd angle to minimise refractive effect so less power gets through)

Power lost through mirror = 8.3mW (mirror is at normal incidence so a bit transmissive)

 

Using earlier 90.6% measurement as reference, power into FI = 170.83 mW

So BS transmission = 170.83/536 = 0.3187

BS reflectivity therefore = 1 - 0.3187 = 0.6813

 

Power back into FI = Thru FI - Thru mirror = 155.7 mW

 

Power reflected at BS after returning through FI = 2.2mW

Baseline power at BS reflection from assorted internal reflections in FI (blocked return beam) = 1.9mW

Note - these reflections don't appear to be back along the input beam, but they *are* detectable on the power meter.

 

Actual power returning into FI that gets reflected by BS = 0.3 mW

(note that this is in the fluctuating noise level of measurement so treat as an upper limit)

 

Accounting for BS reflectivity at this angle, this gives a return power = 0.3/0.6813 = 0.4403 mW

 

Reduction ratio (extinction ratio) of FI =  0.4403/155.7 = 0.00282

 

Again - note that this upper limit measurement is as rough and ready as it gets. It's easy to optimise this sort of thing later, preferable on a nice open bench with plenty of space and a well-calibrated photodiode. It's just to give an idea that the isolator is actually isolating at all and not spewing light back into the NPRO.

 

Next up… checking the mode-matching again now that the FI is in place. The beam profile was scanned after the FI and the vertical and horizontal waists are different...

  4469   Wed Mar 30 20:50:43 2011 BryanConfigurationGreen LockingThe wonderful world of mode-matching

Step 3b: Non-circular? We can fix that...

A quick Beamscan sweep of the beam after the Faraday:

Position A1_13.5%_width A2_13.5%_width

(bench) (um mean) (um mean)

25.8 503.9 478.8

25 477.5 489.0

24 447.1 512.4

21 441.6 604.5

20 476.3 645.4

19 545.4 704.1

18 620.3 762.8

 

After_Faraday.png

 

OK. It looks not too bad - doesn't look too different from what we had. Note that the x axis is in local table units - I found this useful for working out where things were relative to other things (like lenses and the FI) - but it means the beam propagates from right to left in the plot. in other words, the horizontal waist occurs first and is larger than the vertical waist. Also - they're not fitted curves - they're by-eye, best guesses and there's no solution for the vertical that doesn't involve offsets... discussion in a later part of the thread.

 

Anyway! The wonderful thing about this plot is that the horizontal and vertical widths cross and the horizontal focussing at this crossing point is shallower than the vertical. This means that we can put a lens in at the crossing point and rotate it such that the lens is stronger in the horizontal plane. The lens can be rotated until the effective horizontal focal length is right to fix the astigmatism.

 

 

I used a 200mm lens I had handy - a rough check sweeping the Beamscan quickly indicated should be about right though. Adjusting the angle until the beam size at a distant point is approx circular - I then move the profiler and adjust again. Repeat as required. Now… taking some data. with just that lens in:

 

Position A1_13.5%_width A2_13.5%_width

(bench) (um mean) (um mean)

24 371.7 366.1

21 360.3 342.7

20 447.8 427.8

19 552.4 519.0

18 656.4 599.2

17 780.1 709.9

16 885.9 831.1

 

After_Faraday_and_Rotated_Lens.png

 

Well now. That looks quite OK. Fit's a bit rubbish on vertical but looks like a slight offset on the measurement again.

The angle of the lens looks awful, but if it's stupid and it works then it isn't stupid. If necessary, the lens can be tweaked a bit more, but there's always more tweaking possible further down the line and most of the astigmatic behaviour has been removed. It's now just a case of finding a lens that works to give us a 50 um beam at the oven position...

 

 

  4470   Wed Mar 30 21:21:15 2011 BryanConfigurationGreen LockingThe wonderful world of mode-matching

Step 4: Matching into the oven

 

 

Now that the astigmatism is substantially reduced, we can work out a lens solution to obtain a 50um waist *anywhere* on the bench as long as there's enough room to work with the beam afterwards. The waist after the Faraday and lens is at position 22.5 on the bench. A 50 mm lens placed 18 cm after this position (position 14.92 on the bench) should give a waist of 50 um at  24.57 cm after the waist (position 12.83 on the bench). This doesn't give much room to measure the beam waist in though - the Beamscan head has a fairly large finite size… wonder if there's a slightly less strong lens I could use…

OK. With a 66 mm lens at 23 cm (position 13.45 on the bench) after the waist we get a 50 um waist at 31.37 cm after the waist (position 10.15 on the bench). 

 

Oven_Lens_Solution_66mm.png

 

Closest lens I found was 62.9mm which will put the 50um point a bit further towards the wall, but on the X-arm the oven is at position 8.75 ish. So anything around there is fine.

 

Using this lens and after a bit of manual fiddling and checking with the Beamscan, I figured we needed a close in, fine-grained measurement so set the Beamscan head up on a micrometer stage Took a whoie bunch of data around position 9 on the bench:

 

 

Position A1_13.5%_width A2_13.5%_width

(mm) (um mean) (um mean)

-15 226.8 221.9

-14 210.9 208.3

-13 195.5 196.7

-12 181.0 183.2

-11 166.0 168.4

-10 154.0 153.1

-9 139.5 141.0

-8 127.5 130.0

-7 118.0 121.7

-6 110.2 111.6

-5 105.0 104.8

-4 103.1 103.0

-3 105.2 104.7

-2 110.9 110.8

-1 116.8 117.0

0 125.6 125.6

0 125.6 125.1

1 134.8 135.3

2 145.1 145.6

3 155.7 157.2

4 168.0 168.1

5 180.5 180.6

6 197.7 198.6

7 211.4 209.7

8 224.0 222.7

9 238.5 233.7

10 250.9 245.8

11 261.5 256.4

12 274.0 270.4

13 291.3 283.6

14 304.2 296.5

15 317.9 309.5

 

Matching_Into_Green_Oven_zoomed_out.pngMatching_Into_Green_Oven_zoomed_in.png

 

And at this point the maximum power available at the oven-waist is 298mW. With 663mW available from the laser with a desired power setting of 700mW on the supply. Should make sure we understand where the power is being lost. The beam coming through the FI looks clean and unclipped, but there is some stray light around.

 

Position A1_13.5%_width A2_13.5%_width

(bench) (um mean) (um mean)

7 868.5   739.9

6 1324 1130

5 1765 1492

4 2214 1862

 

The plot looks pretty good, but again, there looks to be an offset on the 'fitted' curve. Taking a couple of additional points further on to make sure it all works out as the beam propagates. I took a few extra points at the suggestion of Kiwamu and Koji - see the zoomed out plot.  The zoomed in plot has by-eye fit lines - again, because to get the right shape to fit the points there appears to be an offset. Where is that coming from? My suspicion is that the Beamscan doesn't take account of the any background zero offsets when calculating the 13.5% and we've been using low power when doing these measurements - very small focussed beams and didn't want to risk damage to the profiler head.

 

Decided to take a few measurements to test this theory. Trying different power settings and seeing if it gives different offset and/or a changed width size

 

7 984.9 824.0 very low power

7 931.9 730.3 low power

7 821.6 730.6 higher power

7 816.4 729.5 as high as I'm comfortable going

 

Trying this near the waist…

 

8.75 130.09 132.04 low power

8.75 106.58 105.46 higher power

8.75 102.44 103.20 as high as it can go without making it's saturated

 

So it looks like offset *is* significant and the Beamscan measurements are more accurate with more power to make the offsets less significant. Additionally, if this is the case then we can do a fit to the previous data (which was all taken with the same power setting) and simply allow the offset to be a free parameter without affecting the accuracy of the waist calculation. This fit and data coming to an e-log near you soon.

 

Of course, it looks from the plots above (well... the code that produces the plots above) that the waist is actually a little bit small (around 46um) so some adjustment of the last lens back along the beam by about half a cm or so might be required.

 
  4473   Thu Mar 31 02:59:49 2011 KojiConfigurationGreen LockingThe wonderful world of mode-matching

 I went through the entries.

1. Give us a photo of the day. i.e. Faraday, tilted lens, etc...

2. After all, where did you put the faraday in the plot of the entry 4466?

3. Zoomed-in plot for the SHG crystal show no astigmatism. However, the zoomed out plot shows some astigmatism.
How consistent are they? ==> Interested in seeing the fit including the zoomed out measurements.

  4476   Thu Mar 31 14:10:00 2011 BryanConfigurationGreen LockingThe wonderful world of mode-matching

Quote:

 I went through the entries.

1. Give us a photo of the day. i.e. Faraday, tilted lens, etc...

2. After all, where did you put the faraday in the plot of the entry 4466?

3. Zoomed-in plot for the SHG crystal show no astigmatism. However, the zoomed out plot shows some astigmatism.
How consistent are they? ==> Interested in seeing the fit including the zoomed out measurements.

 OK. Taking these completely out of order in the easiest first...

2. The FI is between positions 27.75 and 32 on the bench - i.e. this is where the input and output apertures are. (corresponds to between 0.58 and 0.46 on the scale of those two plotsand just before both the vertical and horizontal waists) At these points the beam radius is around 400um and below, and the aperture of the Faraday is 4.8mm (diameter).

1. Photos...

Laser set up - note the odd angles of the mirrors. This is where we're losing a goodly chunk of the light. If need be we could set it up with an extra mirror and send the light round a square to provide alignment control AND reduce optical power loss...

P3310028.JPG

 

Faraday and angled lens - note that the lens angle is close to 45 degrees. In principle this could be replaced with an appropriate cylindrical lens, but as long as there's enough light passing through to the oven I think we're OK.

P3310029.JPG

3. Fitting... coming soon once I work out what it's actually telling me. Though I hasten to point out that the latter points were taken with a different laser power setting and might well be larger than the actual beam width which would lead to astigmatic behaviour.

  4477   Thu Mar 31 15:23:14 2011 BryanConfigurationGreen LockingThe wonderful world of mode-matching

Quote:

3. Zoomed-in plot for the SHG crystal show no astigmatism. However, the zoomed out plot shows some astigmatism.

How consistent are they? ==> Interested in seeing the fit including the zoomed out measurements.

Right. Fitting to the data. Zoomed out plots first. I used the general equation f(x) = w_o.*sqrt(1 + (((x-z_o)*1064e-9)./(pi*w_o.^2)).^2)+c for each fit which is basically just the Gaussian beam width parameter calculation but with an extra offset parameter 'c'

Vertical fit for zoomed out data:

Coefficients (with 95% confidence bounds):

       c =   7.542e-06  (5.161e-06, 9.923e-06)

       w_o =   3.831e-05  (3.797e-05, 3.866e-05)

       z_o =       1.045  (1.045, 1.046)

 

Goodness of fit:

  SSE: 1.236e-09

  R-square: 0.9994

 
Horizontal fit for zoomed out data:
 

Coefficients (with 95% confidence bounds):

       c =   1.083e-05  (9.701e-06, 1.195e-05)

       w_o =   4.523e-05  (4.5e-05, 4.546e-05)

       z_o =       1.046  (1.046, 1.046)

 

Goodness of fit:

  SSE: 2.884e-10

  R-square: 0.9998

  Adjusted R-square: 0.9998

  RMSE: 2.956e-06

 

Zoomed_out_fitting01.png

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 

OK. Looking at the plots and residuals for this, the deviation of the fit around the waist position, and in fact all over, looks to be of the order 10um. A bit large but is it real? Both w_o values are a bit lower than the 50um we'd like, but… let's check using only the zoomed in data -  hopefully more consistent since it was all taken with the same power setting.

 

 

Vertical data fit using only the zoomed in data:

 

Coefficients (with 95% confidence bounds):

       c =   1.023e-05  (9.487e-06, 1.098e-05)

       w_o =   4.313e-05  (4.252e-05, 4.374e-05)

       z_o =       1.046  (1.046, 1.046)

 

Goodness of fit:

  SSE: 9.583e-11

  R-square: 0.997

 

Horizontal data fit using only the zoomed in data:

 

Coefficients (with 95% confidence bounds):

       c =   1.031e-05  (9.418e-06, 1.121e-05)

       w_o =    4.41e-05  (4.332e-05, 4.489e-05)

       z_o =       1.046  (1.046, 1.046)

 

Goodness of fit:

  SSE: 1.434e-10

  R-square: 0.9951

 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Zoomed_in_fitting01.png

 

The waists are both fairly similar this time 43.13um and 44.1um and the offsets are similar too  - residuals are only spread by about 4um this time.

 

I'm inclined to trust the zoomed in measurement more due to the fact that all the data was obtained under the same conditions, but either way, the fitted waist is a bit smaller than the 50um we'd like to see. Think it's worthwhile moving the 62.9mm lens back along the bench by about 3/4 -> 1cm to increase the waist size.

 

 

 

 

 

  4485   Mon Apr 4 14:20:32 2011 BryanConfigurationGreen LockingThe wonderful world of mode-matching

Last bit of oven matching for now.

 

I moved the lens before the oven position back along the beam path by about 1cm - waist should be just above position 9 in this case. Note - due to power-findings from previous time I'm maximising the power into the head to reduce the effect of offsets.

 

From position 9:

Position A1_13.5%_width A2_13.5%_width

(mm) (um mean) (um mean)

-1 121.1 123.6

0 112.5 113.8

1 106.4 106.1

2 102.9 103.4

3 103.6 103.6

4 106.6 107.4

5 111.8 112.5

6 118.2 120.1

7 126.3 128.8

8 134.4 137.1

9 143.8 146.5

10 152.8 156.1

11 163.8 167.1

12 175.1 176.4

13 186.5 187.0

14 197.1 198.4

15 210.3 208.9

16 223.5 218.7

17 237.3 231.0

18 250.2 243.9

19 262.8 255.4

20 274.7 269.0

21 290.4 282.3

22 304.3 295.5

23 316.7 303.1

 

Note - had to reduce power due to peak saturation at 15mm - don't think scale changed, but be aware just in case. And saturated again at 11. And again at 7. A little bit of power adjustment each time to make sure the Beamscan head wasn't saturating. Running the fit gives...

 

Waist_Fits_from_laser.pngWaist_Fits_Bench_Position.png

 

OK. The fit is reasonably good. Residuals around the area of interest (with one exception) are <+/- 2um and the waists are 47.5um (vertical) and 50.0um (horizontal) at a position of 9.09 on the bench. And the details of the fitting output are given below.

 

-=-=-=-=-=-=-=-=-=-=-=-

Vertical Fit

 

cf_ =

 

     General model:

       cf_(x) = w_o.*sqrt(1 + (((x-z_o)*1064e-9)./(pi*w_o.^2)).^2)+c

     Coefficients (with 95% confidence bounds):

       c =   5.137e-06  (4.578e-06, 5.696e-06)

       w_o =   4.752e-05  (4.711e-05, 4.793e-05)

       z_o =        1.04  (1.039, 1.04)

 

 

cfgood_ = 

 

           sse: 1.0699e-11

       rsquare: 0.9996

           dfe: 22

    adjrsquare: 0.9996

          rmse: 6.9738e-07

 

-=-=-=-=-=-=-=-=-=-=-=-

Horizontal Fit

 

cf_ =

 

     General model:

       cf_(x) = w_o.*sqrt(1 + (((x-z_o)*1064e-9)./(pi*w_o.^2)).^2)+c

     Coefficients (with 95% confidence bounds):

       c =    3.81e-06  (2.452e-06, 5.168e-06)

       w_o =   5.006e-05  (4.909e-05, 5.102e-05)

       z_o =        1.04  (1.04, 1.04)

 

 

cfgood_ = 

 

           sse: 4.6073e-11

       rsquare: 0.9983

           dfe: 22

    adjrsquare: 0.9981

          rmse: 1.4471e-06

 

 

 

  9476   Sun Dec 15 20:37:41 2013 ranaSummaryTreasureThere is a Wagonga in the container that Steve does not believe in

From Linda and Bram:

  10272   Thu Jul 24 19:28:43 2014 AkhilUpdateGeneralThermal Actuator Transfer Functions

 As a part of temperature actuator characterization, today Eric Q and I made some measurements for the open loop TF of both the X-arm and Y-arm  thermal actuators. 

For this, we gave an input  of random excitation for the temperature offset input( since we faced some serious issues when we gave in Swept sine yesterday) and observed the PZT actuation signal keeping the arm to be locked all the time of our measurements and ensuring that the PZT signal doesn't saturate.

The  channels used for the measurement were  C1:ALS-X_SLOW_SERVO2_EXC as the input and C1:ALS-X_SLOW_SERVO1_IN1  as the output.

The random noise used for the measurement :

Y-ARM:  Gain- 6000;  Filter - butterworth-first order - band-pass filter with start frequency= 1 Hz stop frequency = 5 Hz.

X-ARM: Gain -3000; Filter - butterworth- first order- band-pass filter with start frequency 3 Hz and stop frequency = 30 Hz and  notch(1,10,20).

The Y-ARM measurement was stable but for the X-ARM, the PZT was saturating too often so Eriq Q went inside the lab and placed a 20dB attenuator in the path of the  X-ARM PZT signal readout to carry out the stable measurements.

The units of the TF of these measurements are not calibrated and are in count/count. I will have to calibrate the units by measuring the PZT count by changing the cavity length so that I can get a standard conversion into Hz/count. I will elog the calibrated TFs in my next elog after I take the cavity length and PZT TFs.

The attached are the bode plots for both the X-ARM and Y-ARM thermal actuators(non-calibrated). I will work on finding the poles and zeroes of this system once I finish calibration of the TF measurements.

  10275   Sat Jul 26 13:10:14 2014 AkhilUpdateGeneralThermal Actuator Transfer Functions

Koji said that the method we used for X-arm thermal actuator TF measurement was not correct and suggested us to make measurements separately for high and low frequencies( ensuring coherence at those frequencies is high).

(Edit by KA: The previous measurements for X/Y arm thermal actuators were done with each arm individually locked. This imposes the MC stability to the arm motion. The MC stability is worse than the arm stability due to shorter length and more number of the mirrors. Thus the arm motions were actually amplified rather than stabilized. The correct configuration was to stabilize MC using the other arm and control the measurement arm with the arm cavity length.)

So I and Eric Q took some improved TF measurements last night for the X-arm. The input excitation and the filters used were similar to that of the previous measurement . The attached are the TF plots showing two different frequency measurements.The data was saved and will be used to generate a complete TF. The attached (TFX_new.pdf)shows the independent TF measurement for X-arm temperature actuator. The black legend shows the TF at high frequencies(>1 Hz) and the red at low frequencies(<1 Hz). The final TF plots( from the data) will be posted in my next elog. 

We also made the measurements needed for calibration of these actuator Transfer functions. For this we gave some excitation for the arm length( separately for X arm and Y arm) and measured the PZT response. I will eLog with the details of the measurement and results shortly.

  2094   Thu Oct 15 01:21:31 2009 ranaSummaryCOCThermal Lensing in the ITM

Thermal lensing formula:

Untitled.png

from (T090018 by A. Abramovici (which references another doc).

In the above equation:

w        1/e^2 beam radius

k        thermal conductivity (not the wave vector) = 1.3 W / m/ K

alpha    absorption coefficient (~10 ppm/cm for our glass)

NP       power in the glass (alpha*NP = absorbed power)

dn/dT    index of refraction change per deg  (12 ppm/K)

d        mirror thickness (25 mm for all of our SOS)

I'm attaching a plot showing the focal length as a function of recycling cavity power for both our current MOS and future SOS designs.

I've assumed a 10 ppm/cm absorption here. It may actually be less for our current ITMs which are made of Heraeus low absorption glass - our new ITMs are Corning 7980-A (measured to have an absorption of 13 ppm/cm ala the iLIGO COC FDD). I expect that our thermal lens focal length will always be longer than 1 km and so I guess this isn't an issue.

  470   Thu May 8 02:06:13 2008 ranaSummaryCOCThermal Lensing in the ITMs and BS may be a problem
The iLIGO interferometers start to see thermal lensing effects with ~2W into the MC, a recycling
gain of ~50, and a beam waist on the ITMs of ~3.5 cm.

At the 40m, the laser power into the MC is 1/2 as much, the recycling gain is 4-5x less, but the
beam on the ITM has a 3 mm waist. So the power in the ITM bulk is 10x less but the power density
is 100x more
. Seems like the induced lens in the ITM bulk might be larger and that if there's
significant absorption on the ITM face (remember our Finesse is 4-5x higher) the beam size in the
arm cavity may also change enough to measure.

Someone (like Andrey) should calculate how much the beam sizes change with absorbed power.
  14041   Fri Jul 6 12:12:09 2018 AnnalisaConfigurationThermal CompensationThermal compensation setup

I tried to put together a rudimentary heater setup. 

As a heating element, I used the soldering iron tip heated up to ~800°C.

To make a reflector, I used the small basket which holds the cork of champains battles (see figure 1), and I covered it with alumnum foil. Of course, it cannot be really considered as a parabolic reflector, but it's something close (see figure 2).

Then, I put a ZnSe 1 inch lens, 3.5 inch FL (borrowed from TCS lab) right after the reflector, in order to collect as much as possible the radiation and focus it onto an image (figure 3). In principle, if the heat is collimated by the reflector, the lens should focus it in a pretty small image. Finally, in order to see the image, I put a screen and a small piece of packaging sponge (because it shouldn't diffuse too much), and I tried to see the projected pattern with a thermal camera (also borrowed from Aidan). However, putting the screen in the lens focal plane didn't really give a sharp image, maybe because the reflector is not exactly parabolic and the heater not in its focus. However, light is still focused on the focal plane, although the image appears still blurred. Perahps I should find a better material (with less dispersion) to project the thermal image onto. (figure 4)

Finally, I measured the transmitted power with a broadband power meter, which resulted to be around 10mW in the focal plane. 

  14071   Fri Jul 13 23:39:46 2018 AnnalisaConfigurationThermal CompensationThermal compensation setup - power supply

[Annalisa, Rana]

In order to power the heater setup to be installed in the ETMY chamber, we took the Sorensen DSC33-33E power supply from the Xend rack which was supposed to power the heater for the seismometer setup.

We modified the J3 connector behind in such a way to allow a remote control (unsoldered pins 9 and 8). 

Now pins 9 and 12 need to be connected to a BNC cable running to the EPICS.


RXA update: the Sorensen's have the capability to be controlled by an external current source, voltage source, or resistive load. We have configured it so that 0-5V moves the output from 0-33 V. There is also the possibility to make it a current source and have the output current (rather than voltage) follow the control voltage. This might be useful since out heater resistance is changing with temperature.

  3189   Fri Jul 9 20:16:19 2010 ranaSummaryPSLThings I did to the PSL today: Refcav, PMC, cameras, etc.

I re-aligned the beam into the PMC. I got basically no improvement. So I instead changed the .LOW setting so that PMCTRANS would no longer go yellow and make the donkey sound.

I did the same for the MOPA's AMPMON because its decayed state is now nominal.

 

Steve and I removed the thermal insulation from around the reference cavity vacuum chamber. It wasn't really any good anyways.

Here are the denuded photos:

 

Steve and I are now planning to replace the foam with some good foam, but before that we will wrap the RC chamber with copper sheets like you would wrap a filet mignon with applewood bacon.

This should reduce the thermal gradients across the can. We will then mount the sensors directly to the copper sheet using thermal epoxy. We will also use copper to cover most of this hugely

oversized window flange - we only need a ~1" hole to get the 0.3 mm beam out of there.

 

My hope is that all of this will improve the temperature stability of this cavity. Right now the daily frequency fluctuations of the NPRO (locked to the RC) are ~100 MHz. This implies

that the cavity dT = (100 MHz) / (299792458 / 1064e-9) / (5e-7) = 1 deg.    That's sad....

 

I also changed the RC_REFL cam to manual gain from AGC. I cranked it to max gain so that we can see the REFL image better.

  3196   Mon Jul 12 14:22:36 2010 JenneSummaryPSLThings I did to the PSL today: Refcav, PMC, cameras, etc.

Quote:

I re-aligned the beam into the PMC. I got basically no improvement. So I instead changed the .LOW setting so that PMCTRANS would no longer go yellow and make the donkey sound.

I did the same for the MOPA's AMPMON because its decayed state is now nominal.

[Jenne, Chip]

The alarm was still going, because the LOLO setting was higher than the LOW, which is a little bit silly.  So we changed the .LOLO setting to 0.80 (the LOW was set to 0.82)

We also changed psl.db to reflect these values, so that they'll be in there the next time c1psl gets rebooted.

  12225   Wed Jun 29 00:09:36 2016 AakashUpdateGeneralThings from past | SURF 2016

I have taken out the heaters and temperature sensors from the enclosure which was made by Megan last summer. Soon I will test and configure those heaters.

  3639   Fri Oct 1 18:53:33 2010 josephb, kiwamuUpdateCDSThings needing to be done next week

We realized we cannot build code with the current RCG compiler on c1ioo or c1iscex, since these are not Gentoo machines.  We need either to get a backwards compatible code generator, or change the boot priority (removing the harddrives also probably works) for c1ioo and c1iscex so they do the diskless Gentoo thing.  This would involve adding some MAC address to the framebuilder dhcpd.conf file in /etc/dhcp along with the computer IPs, and then modifying the /diskless/root/etc/rtsystab with the right machine names and models to start.

I also need to bring some of the older, neglected models up to current build standards. I.e. use cdsIPCx_RFM instead of cdsIPCx and so forth. 

Need to fix the binary outputs for c1sus/c1mcs.  Need to actually get the RFM running, since Kiwamu was having some issues with his green RFM test model.  We have the latest checkout from Rolf, but we have no proof that it actually works.

  680   Wed Jul 16 11:26:47 2008 Max JonesUpdate This Week
Baffles.

I got a battery for the magnetometer today which is slightly too large (~2 mm) in one dimension. Not sure what I'm going to do.

I'm attempting to calibrate the magnetometer but I'm having a hard time calibrating the axis that I cannot simply put through a coil parallel to the coils length. I have attempted to use the end fields of the solenoid but the measurements from the magnetometer are significantly different from the theoretical calculations.

I would appreciate suggestions. - Max.
  16308   Thu Sep 2 19:28:02 2021 KojiUpdate This week's FB1 GPS Timing Issue Solved

After the disk system trouble, we could not make the RTS running at the nominal state. A part of the troubleshoot FB1 was rebooted. But the we found that the GPS time was a year off from the current time

controls@fb1:/diskless/root/etc 0$ cat /proc/gps 
1283046156.91
controls@fb1:/diskless/root/etc 0$ date
Thu Sep  2 18:43:02 PDT 2021
controls@fb1:/diskless/root/etc 0$ timedatectl 
      Local time: Thu 2021-09-02 18:43:08 PDT
  Universal time: Fri 2021-09-03 01:43:08 UTC
        RTC time: Fri 2021-09-03 01:43:08
       Time zone: America/Los_Angeles (PDT, -0700)
     NTP enabled: no
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2021-03-14 01:59:59 PST
                  Sun 2021-03-14 03:00:00 PDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2021-11-07 01:59:59 PDT
                  Sun 2021-11-07 01:00:00 PST


Paco went through the process described in Jamie's elog [40m ELOG 16299] (except for the installation part) and it actually made the GPS time even strange

controls@fb1:~ 0$ cat /proc/gps
967861610.89

I decided to remove the gpstime module and then load it again. This made the gps time back to normal again.

controls@fb1:~ 0$ sudo modprobe -r gpstime
controls@fb1:~ 0$ cat /proc/gps
cat: /proc/gps: No such file or directory
controls@fb1:~ 1$ sudo modprobe gpstime
controls@fb1:~ 0$ cat /proc/gps
1314671254.11

 

  16309   Thu Sep 2 19:47:38 2021 KojiUpdateCDSThis week's FB1 GPS Timing Issue Solved

After the reboot daqd_dc was not working, but manual starting of open-mx / mx services solved the issue.

sudo systemctl start open-mx.service
sudo systemctl start mx.service
sudo systemctl start daqd_*

 

  9338   Mon Nov 4 15:46:17 2013 JenneUpdateLSCThoughts and Conclusions from last week's PRMI+2arms attempt

5:31pm - This is still a work in progress, but I'm going to submit so that I save my writing so far. I think I'm done writing now.


First, a transcription of some of the notes that I took last Tuesday night, then a few looks at the data, and finally some thoughts on things to investigate.


MICH and PRCL Transfer Functions while arms brought in to resonance (both arms locked to ALS beatnotes):

This is summarized in elog 9317, which I made as we were finishing up Tuesday night.  Here's the full story though.  Note that I didn't save the data for these, I just took notes (and screenshots for the 1st TF).

POP22I was ~140 counts, POP110I was ~100 counts.

MICH gain = -2.0, PRCL gain = 0.070. 

First TF (used as reference for 2-10), PRMI locked on REFL165, Xarm transmission = 0.03, Yarm transmission = 0.05 (both arms off resonance).  MICH UGF~40Hz, PRCL UGF~80Hz.

MICH_40Hz.pngPRCL_80Hz.png

2: X=off-res (xarm not moved), Y=0.13, no change in TF

3: X=off-res (xarm not moved), Y=0.35, no change in TF

4: X=off-res (xarm not moved), Y=0.60, MICH high freq gain went up a little, otherwise no change (no change in either UGF)

5:  X=off-res (xarm not moved), Y=0.95, same as TF#4.

6: X=0.20, Y=1.10 (yarm not moved), same as TF#4

7:  X=0.40, Y=1.30 (yarm not moved), same as TF#4

8:  X=0.70, Y=1.55 (yarm not moved), same as TF#4

9: X=1.40, Y=2.20 (yarm not moved), same as TF#4

10: X=4.0, Y=4.0 (yarm not moved), PRCL UGF is 10Hz higher than TF#4, MICH UGF is 20Hz lower than TF#4.

11: (No TF taken), Xarm and Yarm transmission both around 20!  To get this, MICH FMs that were triggered, are no longer triggered to turn on.  Also, MICH gain was lowered to -0.15 and PRCL gain was increased to 0.1

12: (No TF taken), Xarm and Yarm transmissions both around 40!  The peaks could be higher, but we don't have the QPD ready yet.

After that, we started moving away from resonance, but we didn't take any more transfer functions.


OpLev spectra for different arm resonance values:

We were concerned that the ETMs and ITMs might be moving more, when the arms are resonating high power, due to some optical spring / radiation pressure effects, so I took spectra of oplevs at various arm transmissions.

I titled the first file "no lock", and unfortunately I don't remember what wasn't locked.  I think, however, that nothing at all was locked.  No PRMI, no arm ALS, no nothing.  Anyhow, here's the spectrum:

ALS_noLock.pdf

I have a measurement when the Yarm's transmission was 1, and the Xarm's transmission was 1.75.  This was a PRMI lock, with ALS holding the arms partially on resonance:

ALS_X1pt75Y1.pdf

Next up, I have a measurement when Yarm was 0.8, Xarm was 2.  Again, PRMI with the arms held by ALS:

ALS_X2Y0pt8.pdf

And finally, a measurement when Xarm was 5, Yarm was 4:

ALS_X5Y4.pdf

Just so we have a "real" reference, I have just now taken a set of oplev spectra, with the ITMs, ETMs and PRM restored, but I shut the PSL shutter, so there was no light flashing around pushing on things.  I noticed, when taking this data, that if the PSL shutter was open, so the PRFPMI is flashing (but LSC is off), the PRM oplev looks much like the original "no Lock" spectra, but when I closed the shutter, the oplev looks like the others.  So, perhaps when we're getting to really high powers, the PRM is getting pushed around a bit?

ALS_noLock_noLaser.pdf

Conclusions from OpLev Spectra:  At least up to these resonances (which is, admittedly, not that much), I do not see any difference in the oplev spectra at the different buildup power levels.  What I need to do is make sure to take oplev spectra next time we do the PRMI+2arms test when the arms are resonating a lot. 


Time series while bringing arms into resonance:

PRMI_2arms_29Oct2013_POPrin.png

I had wondered if, since the POP 22 and 110 values looked so shakey, we were increasing the PRCL RIN while we brought the arms into resonance.  You can see in the above time series that that's not true.  The left side of the plot is PRMI locked, arms held out of resonance using ALS.  First the Yarm is brought close to resonance, then the Xarm follows.  The RIN of the arms is maybe increasing a little bit as we get closer to resonance, but not by that much.  But there seems to be no correlation between arm power and RIN of the power recycling cavity.

Alternatively, here is some time series when the arm powers got pretty high:

PRMI_2arms_29Oct2013_POPrin_highArmPowers.png


Possible Saturation of Signals:

One possibility for our locklosses of PRMI is that some signal somewhere is saturating, so here are some plots showing that that's not true for the error and control signals for the PRMI:

PRMI_2arms_29Oct2013_LSCcontrolSignals.png

Here, for the exact same time, is a set of time series for every optic except the SRM.  We can see that none of the signals are saturating, and I don't see any big differences for the ITMs or ETMs in the times that the PRMI is locked with high arm powers (center of the x-axis on the plot) and times that the PRMI is not locked, so we don't have high arm powers (edges of the plot - first half second, and last full second).  You can definitely see that the PRM moves much more when the PRMI is locked though, in both pitch and yaw. 

PRMI_2arms_29Oct2013_OpLevs_highArmPowers.png

DCPD signals at the same time:

PRMI_2arms_29Oct2013_DCPDs.png

NB:  These latest 3 plots were created with the getdata script, with arguments "-s 1067163405 -d 7".  It may be a good idea to take some spectra starting at, say 1067163406, 1 second in, and going for ~2 seconds. (It turns out that this is kind of a pain, and I can't convince DTT to give me a sensible spectrum of very short duration....we'll just need to do this live next time around).


Things to think about and investigate:

Why are we losing lock? 

On paper, is the (will the) optical spring a problem once we get high resonance in the arms? 

Spectra of oplevs when we're resonating high arm power.

What is the coupling between 110MHz and 165MHz on the REFL165 PD?  Do we need a stronger bandpass? 

Why are things so shakey when the arm power builds up?

Why do PRCL and MICH have different UGFs when the arms are controlled by ALS vs. ETMs misaligned?

Does QPD for arm transmissions switching work?  Can we then start using TRX and TRY for control?

What is the meaning of the similar features in both transmission signals, and the power recycling cavity?  Power fluctuation in the PRC due to PRM motion? 

  9339   Mon Nov 4 17:08:23 2013 JenneUpdateLSCThoughts on Transition to IR

Gabriele and I talked for a while on Wednesday afternoon about ideas for transitioning to IR control, from ALS. 

I think one of the baseline ideas was to use the sqrt(transmission) as an error signal.  Gabriele pointed out to me that to have a linear signal, really what we need is sqrt( [max transmission] - [current transmission] ), and this requires good knowledge of the maximum transmission that we expect.  However, we can't really measure this max transmission, since we aren't yet able to hold the arms that close to resonance.  If we get this number wrong, the error signal close to the resonance won't be very good.

Gabriele suggested maybe using just the raw transmission signal.  When we're near the half-resonance point, the transmission gives us an approximately linear signal, although it becomes totally non-linear as we get close to resonance.  Using this technique, however, requires lowering the finesse of PRCL by putting in a medium-large MICH offset, so that the PRC is lossy.  This lowering of the PRC finesse prevents the coupled-cavity linewidth of the arm to get too tiny.  Apparently this trick was very handy for Virgo when locking the PRFPMI, but it's not so clear that it will work for the DRFPMI, because the signal recycling cavity complicates things.

I need to look at, and meditate over, some Optickle simulations before I say much else about this stuff.

  9340   Mon Nov 4 18:24:15 2013 KojiUpdateLSCThoughts on Transition to IR

 You have the data. Why don't you just calculate 1/SQRT(TRX)?

...yeah, you can calculate it but of course you don't have no any reference for the true displacement...

  9344   Tue Nov 5 16:39:54 2013 GabrieleUpdateLSCThoughts on Transition to IR

Quote:

Gabriele and I talked for a while on Wednesday afternoon about ideas for transitioning to IR control, from ALS. 

I think one of the baseline ideas was to use the sqrt(transmission) as an error signal.  Gabriele pointed out to me that to have a linear signal, really what we need is sqrt( [max transmission] - [current transmission] ), and this requires good knowledge of the maximum transmission that we expect.  However, we can't really measure this max transmission, since we aren't yet able to hold the arms that close to resonance.  If we get this number wrong, the error signal close to the resonance won't be very good.

Gabriele suggested maybe using just the raw transmission signal.  When we're near the half-resonance point, the transmission gives us an approximately linear signal, although it becomes totally non-linear as we get close to resonance.  Using this technique, however, requires lowering the finesse of PRCL by putting in a medium-large MICH offset, so that the PRC is lossy.  This lowering of the PRC finesse prevents the coupled-cavity linewidth of the arm to get too tiny.  Apparently this trick was very handy for Virgo when locking the PRFPMI, but it's not so clear that it will work for the DRFPMI, because the signal recycling cavity complicates things.

I need to look at, and meditate over, some Optickle simulations before I say much else about this stuff.

 The idea of introducing a large MICH offset to reduce the PRC finesse might help us to get rid of the transmitted power signal. We might be able to increase enough the line width of the double cavity to make it larger than the ASL length fluctuations. Then we can switch from ASL to the IR demodulated signal without transitioning through the power signal.

  9636   Fri Feb 14 00:58:41 2014 JenneUpdateLSCThoughts on Transition to IR

[Koji, Jenne, EricQ, Manasa]

We had a short discussion this evening about what our game plan should be for transitioning from using the ALS system to IR-generated error signals. 


The most fundamental piece is that we want to, instead of having a completely separate ALS locking system, integrate the ALS into the LSC.  Some time ago, Koji did most of the structural changes to the LSC model (elog 9430), and exposed those changes on the LSC screen (elog 9449).  Tonight, I have thrown together a new ALS screen, which should eventually replace our current ALS screen.  My goal is to retain all the functionality of the old screen, but instead use the LSC-version of the error signals, so that it's smoother for our transition to IR.  Here is a screenshot of my new screen:

Screenshot-Untitled_Window-1.png

You will notice that there are several white blocks in the center of the screen. From our discussion this evening, it sounds like we may want to add 4 more locking servo paths to the LSC (ALS for each individual arm, and then ALS for CARM and DARM signals).  The reason these should be separate is that the ALS and the "regular" PDH signals have different noise characteristics, so we will want different servo shapes.  I am proposing to add these 4 new servo blocks to the c1lsc model.  If I don't hear an objection, I'll do this on Monday during the day, unless someone else beats me to it.  The names for these filter modules should be C1:LSC-ALS_XARM, C1:LSC-ALS_YARM, C1:LSC-ALS_DARM and C1:LSC_ALS_CARM.  This will add new rows to the input matrix, and new columns to the output matrix, so the LSC screen will need to be modified to reflect all of these changes.  The new ALS screen should automatically work, although the icons for the input and output matrices will need to be updated. 

The other major difference between this new paradigm and the old, is the place of the offset in the path.  Formerly, we had auxiliary filter banks, and the summation was done by entering multiple values in the ALS input matrix.  Now, since there is a filter bank in the c1lsc model for each of the ALS signals precisely where we want to add our offsets, and I don't expect us to need to put any filters into those filter modules, I have used the offset and TRAMP of those filter banks for the offsets.  Also, you can access the offset value, and the ramp time, as well as the "clear history" button for the phase tracker, all from the main screen, which should help reduce the number of different screens we need to have open at once when locking with ALS.  Anyhow, the actual point where the offset is added has not changed, just the way it happens has. 

When we make the move to using the ALS in the LSC, we'll also need to make sure our "watch arm" and "scan arm" scripts are updated appropriately.

As an intermediary locking step, we want to try to use the ALS system to actuate in a CARM and DARM way, not XARM and YARM.  We will transition from using each ALS signal to feed back to its own ETM, to having DARM feed back to the ETMs, and CARM feed back to MC2.  We may want to break this into smaller steps, first lock the arms to the beatnotes, then find the IR resonance points.  Transition to CARM and DARM feedback, but only using the ETMs.  After we've done that, then we can switch to actuating on MC2.  If we do this, then we'll be using the MC to reduce the CARM offset.

Once we can do this, and are able to reduce the CARM offset, we want to switch CARM over to a combination of the 1/sqrt(transmission) signals.  The CARM loop has a tighter noise requirement, so we can do this, but leave DARM locked to the beatnotes for a while.

After continuing to reduce the CARM offset, we will switch CARM over to one of the RF PDs, for its final low-noise state. 

We'll then do a quick swap of the DARM error signal to the AS port (maybe around the same time as CARM goes over to a PDH signal, before the CARM offset is zero?). 

During all of this, we hope that the vertex has stayed locked. If our 3f sensing matrix elements are totally degenerate when the arms are out of resonance, then we may need to acquire lock using REFL 1f signals, and as we approach the delicate point in the CARM offset reduction, move to 3f signals, and then move back to 1f signals after the arm reflection has done its phase flip.  Either way, we'll have to move from 3f to 1f for the final state.

  10900   Wed Jan 14 03:42:31 2015 JenneUpdateLSCThoughts on going forward with variable finesse

[Jenne, Rana]

We tried locking with the variable finesse MICH offset technique again today. 

A daytime task tomorrow will be to figure out where we are in MICH and CARM offset spaces.  This will require some thinking, and perhaps some modelling.

We were using the UGF servos and checking out their step resonses, and had the realization that we don't want the gain multiplication to happen before the offsets are applied, in the case of MICH and CARM.  Otherwise, as the UGF servo adjusts the gain, the offset is changed.  I think this is what ChrisW and I saw earlier on in the evening, when it seemed like the CARM offset spontaneously zoomed toward zero even though I didn't think I was touching any buttons or parameters.  Anyhow, we no longer used the MICH and CARM UGF servos for the rest of the night.  We need to think about where we want the offset to happen, and where we want the UGF servo multiplication to happen (maybe at the control point, with a very low bandwidth?) such that this is not an issue.

Also, I'm no longer sure that the sqrt(I^2 + Q^2) instead of the usual demodulation is going to work for the UGF servos (Q made this change the other day, after we had talked about it).  When the numbers going into the I and Q servo banks are small (around 1e-5), the total UGF servo gets the answer wrong by a factor of 10 or so.  If I made the "sin gain" and "cos gain" 1000 instead of the usual 1, the numbers were of the order 1e-2, and the servo worked like normal.  So, I think we were perhaps running into some kind of numerical error somehow.  We first noticed this when we lowered the DARM excitation by a factor of 10, and the servo no longer functioned.  We should take out this non-linear math and go back to linear math tomorrow.

During the evening tomorrow, we should try locking the PRMI with a large MICH offset, and then leaving CARM and DARM on ALS, and seeing how far we can get.  Is it possible to just jump over to RF signals, since we won't have to worry about the detuned cavity pole?

Tonight, the locking procedure was the same as usual, but stopping the carm_up script before it starts to lower the CARM offset at all.  Only difference was that MICH triggered FMs were 2,3,7 rather than the usual 2,6,8. 

So, assuming you have the IFO with CARM and DARM on ALS held at +3 CARM offset counts (which we think is about 3nm), and the PRMI is locked on REFL33I&Q with no offsets, here's what we did:

  • PRCL UGF servo on
  • MICH offset goes to -20
  • MICH transitions to ASDC (0.27*ASDC, then normalize by POPDC)
  • DARM UGF servo on
  • CARM offset to 1 (arms about 0.25)
  • CARM transition to SqrtInvTrans
  • Lower CARM gain to 4
  • CARM offset to 0.6 (arms about 1)
  • DARM transition to DC transmission
  • Increase MICH offset to about -650 or -670
  • Lower CARM offset, see what happens

Something else to think about:  Should we normalize our DC transmission signals by POPDC, so that the arm powers will change when we change the MICH offset (for a constant CARM offset)?

The best we got was holding for a few minutes at arm powers of 7.5, but since the MICH offset was large and the power recycling was low, this was perhaps pretty far.  This is why we need some calibration action.

Also, earlier today I copied the CARM and DARM "slide" filter module screens so that we have the same thing for MICH.  Now all 3 of these degrees of freedom have slider versions of the filter module screens, which are called from the ctrl_compact screen.

  10903   Thu Jan 15 04:41:01 2015 JenneUpdateLSCThoughts on going forward with variable finesse

[Jenne, Diego]

Life would be easier with the UGF servos working.  As Diego already elogged, we aren't sure why the demod phases are changing, but that is certainly causing the I-signals to dip below zero, which the log function can't handle (there is a limiter before the log, so that the signal can't go below 1e-3).  Anyhow, this is causing the UGF servos to freak out, so we have not been using them for tonight's locking.

Our goal tonight was to see if we could introduce a nice big MICH offset, and then lower the CARM offset while keeping the arms locked on ALS.  We hope to see some kind of sign of a PDH signal in some RF PD. 

In the end, the highest we got to was -460 MICH offset counts, which we think is about 29nm (if our rough calibration is accurate). The MICH half fringe should be 188nm. With this offset, we got down to 0.3 CARM offset counts while locked on ALS.  We think that this is around 300pm, plus or minus a lot.  Note that while yesterday I had a pretty easy time getting to -660 counts of MICH offset, tonight I struggled to get past -200.  The only way we ended up getting farther was by lowering the CARM offset.  Although, as I type this, I realized that last night's work already had a lower CARM offset, so maybe that's key to being able to increase the MICH offset. 

We watched REFL11I and REFL11I/(TRX+TRY) on striptool, but we didn't see any evidence of a PDH signal.  We lost lock when I tried to transition CARM over to REFLDC, but I wasn't careful about my offset-setting, so I am not convinced that REFLDC is hopeless.

So.  Tonight, we didn't make any major locking progress (the MC started being fussy for about an hour, right after I ran the LSC offsets script, just before we started locking in earnest).  However, we have some ideas from talking with Rana about directions to go:

* Can we transition CARM over to REFL11I, and then engage the AO path?

* Then, while the MICH offset is still large, can we transition DARM over to POX or POY, actuating on a single arm?  If CARM is totally suppressed, this is DARM-y.  If CARM doesn't have the AO path yet, this is halfsy-halfsy, but maybe we don't care.

* Then, can we lower the MICH offset and transition back to a REFLQ signal?

* Separately, it seemed like we kept losing PRC lock due to PRC motion.  If the MICH offset is very large, are we sideband-limited at the POP port, such that we can use the POP DC QPD?  Is it even worth it?

 

MICH calibration:

A single mirror (ITM) moving by lambda/2, in the MICH-only situation is the full range, from bright to dark fringe.  So, half fringe should be lambda/4, or about 133nm.  If we are thinking about pushing on the BS, there's an extra factor of sqrt(2), so I think the half fringe should be at 188nm of BS motion.

When we had MICH locked on ASDC/POPDC, we put in a line at 143.125Hz, at 20 counts to (0.5*BS-0.2625*PRM), so a total of 10 counts to the BS at 143Hz.  Given the BS calibration in http://nodus.ligo.caltech.edu:8080/40m/8242, this is 10.1pm of actuation.  We saw a line in the error signal of 0.1 counts, so we infer that the MICH error signal of ASDC/POPDC has a calibration of 94pm/count. This number was invariant over a few different MICH offsets, although the ones I measured at were all below about 100 counts of MICH offset, so maybe this number changes as we start to get farther from the MICH dark fringe.

 

IFO left flashing (all mirrors aligned except SRM) in case anyone wants fresh data for that.

  22   Sun Oct 28 03:03:42 2007 ranaConfigurationIOOThree Way Excitement
We've been trying to measure the MC mirror internal mode frequencies so that we can measure
their absorption before and after drag wiping.


It looked nearly impossible to see these modes as driven by their thermal excitation level;
we're looking at the "MC_F" or 'servo' output directly on the MC servo board.

Today, I set up a band limited noise drive into the 'Fast POS' inputs of the 3 MC coil
driver boards (turns out you can do this with either the old HP or the SR785).

Frequencies:
MC1     28.21625 kHz
MC2     28.036   kHz
MC3     28.21637 kHz

I don't really have this kind of absolute accuracy. These are just numbers read off of the SR785.

The other side of the setup is that the same "MC_F" signal is going into the SR830 Lock-In which
is set to 'lock-in' at 27.8 kHz. The resulting demodulated 'R" signal (magnitude) is going into
our MC_AO channel (110B ADC).

As you can see from the above table, MC1 and MC3 are astonishingly and annoyingly very close in
frequency. I identified mirrors with peaks by driving one at a time and measuring on the spectrum
analyzer. I repeated it several times to make sure I wasn't fooling myself; it seems like they
are really very close
but distinct peaks. I really wish we had chipped one of these mirrors
before installing them.



Because of the closeness of these drumhead modes, we will have to measure the absorption by making long
measurements of this channel.
  13665   Mon Mar 5 11:58:24 2018 gautamUpdateElectronicsThree opamps walked onto an AA board

For testing the new IR ALS noise, we had decided that we would like to use the differential output of the demodulated ALS beat signal, as opposed to a single-ended output, as measurements suggested the former to be a lower noise configuration than the latter. For this purpose, Koji and I acquired a couple of old AA boards from the WB electronics shop. These are however, rev2 of the board, whereas the latest version is v6. The main difference between v2 and v6 is that (i) the THS4131 instrumentation amplifier has the Vocm pin grounded in v6 but is floating in v2 and (ii) the buffer opamps are AD8622 in v6 but are AD8672 in v2. But in fact, the boards we have are stuffed with AD8682

I talked to Rich on Friday, and he seemed to think the AD8672 didn't have any issues noise-wise, the main reason they changed it was because its power consumption was high, and was causing overheating when several of these 1U chassis were packed closely together in an electronics rack. But the AD8682, which is what we have, has comparable power consumption to the AD8622. It is however a JFET opamp, and the voltage noise is a bit higher than the AD8622. 

I am sure there is a way to LISO model a differential output opamp like the THS4131, but I thought I'd simulate the noise in LTSPICE instead. But I couldn't get that to work. So instead, I just measured the transfer function and noise of a single channel, for which Koji had expertly hacked together a custom shorting of the THS4131 Vocm pin to ground. Attachments #1 and #2 show the measurement. All looks good. Note that the phase is 180 at DC because I had hooked up the input signal opposite to what it should have been. The voltage noise of the differential outputs (each measured w.r.t. ground, with both inputs shorted to ground by a short patch cable) at 10 Hz is <100nV/rtHz, and the ADC noise is expected to be ~1uV/rtHz, so I think this is fine.

Conclusion: I think for the ALS test, we can just use the AA board in this config without worrying too much about replacing the buffer stage opamps, even though we've ordered 100pcs of AD8622.


Addendum 7 Mar 2018 11am: As per this document, the output noise of the AA board should be <75nV/rtHz from 10 Hz-50 kHz. So maybe the AD8682 noise is a little high after all. I've gotten the LTSpice model working now, will post the comparison of modelled output noise for various combinations here shortly.

  13667   Wed Mar 7 12:04:14 2018 gautamUpdateElectronicsThree opamps walked onto an AA board

Here are the plots. Comments:

  1. Measurement and model agree quite well yes.
  2. Of the 3 OpAmps, the ones installed seem to be the noisiest (per model)
  3. Despite #2, I don't think it is critical to replace the buffer opamps as we only win by ~10nV/rtHz in the 300-10kHz range.
  4. I don't understand the spec given in T070146. It says the noise everywhere between 10Hz-50kHz should be <75nV/rtHz. But even the model suggests that at 10Hz, the noise is ~250nV/rtHz for any choice of buffer opamp, so that's a factor of 3 difference which seems large. Maybe I made a mistake in the model but the agreement between measurement and model for the AD8682 choice gives me confidence in the simulation. LTSpice files used are in Attachment #3. Could also be an artefact of the way I made the measurement - between an output and ground instead of differentially...

I like LTspice for such modeling - the GUI is nice to have (though I personally think that typing out a nodal file a la LISO is faster), and compared to LISO, I think that the LTspice infrastructure is a bit more versatile in terms of effects that can be modeled. We can also easily download SPICE models for OpAmps from manufacturers and simply add them to the library, rather than manually type out parameters in opamp.lib for LISO. But the version available for Mac is somewhat pared down in terms of the UI, so I had to struggle a bit to find the correct syntax for the various simulation commands. The format of the exported data is also not as amenable to python plotting as LISO output files, but i'm nitpicking...

Quote:

I've gotten the LTSpice model working now, will post the comparison of modelled output noise for various combinations here shortly.

 

  15442   Tue Jun 30 10:59:16 2020 gautamUpdateLSCThree sensing matrices

Summary:

I injected some sensing lines and measured their responses in the various photodiodes, with the interferometer in a few different configurations. The results are summarized in Attachments #1 - #3. Even with the PRMI (no arm cavities) locked on 1f error signals, the MICH and PRCL signals show up in nearly the same quadrature in the REFL port photodiodes, except REFL165. I am now thinking if the output (actuation) matrix has something to do with this - part of the MICH control signal is fed back to the PRM in order to minimize the appearance of the MICH dither in the PRCL error signal, but maybe this matrix element is somehow horribly mistuned?

Details:

Attachment #1:

  • ETMs were misaligned and the PRMI was locked with the carrier resonant in the cavity (i.e. sidebands reflected).
  • The locking scheme was AS55_Q --> MICH and REFL11_I --> PRCL.

Attachment #2:

  • The PRFPMI was locked. The vertex DoFs were still under control using 3f error signals (REFL165_I for PRCL and REFL165_Q for MICH).
  • Still, the MICH/PRCL degeneracy in all photodiodes except REFL165 persists.

Attachment #3:

  • Nearly identical configuration to Attachment #2.
  • The main difference here is that I applied some offsets to the MICH and PRCL error points.
  • The offsets were chosen so that the appearance of a ~300 Hz dither in the length of MICH/PRCL was nulled in the AS110_Q / POP22_I signals respectively.
  • For the latter, the appearance of this peak in the POP110_I signal was also nulled, as it should be if our macroscopic PRC length is set correctly.
  • The offsets that best nulled the peak were 110 cts for PRCL, 25 cts for MICH. The measured sensing response is 1e12 cts/m for PRCL in REFL165_I and 9.2e11 cts/m for MICH in REFL165_Q. So these offsets, in physical units, are: 110 pm for PRCL and 27 pm for MICH. They seem like reasonable numbers to me - the PRC linewidth is ~7.5 nm, so the detuning without any digital offset applied is only 1.5% of the linewidth.
  • Note that I changed the POP22/POP110 demod phases to maximize the signal in the I quadrature. The final numbers were -124 degrees / -10 degrees respectively.
  • Yet another piece of evidence suggesting these were the correct offsets is that the DC value of POX and POY were zero on average after these offsets were applied.
  • However, the MICH/PRCL responses in the 1f REFL port photodiodes remain nearly degenerate.

Some other mysteries that I will investigate further:

  1. While POP22 indicated stable buildup of 11 MHz power in the PRC, I couldn't make any sense of the AS110 signals at the dark port - there was large variation of the signal content in the two quadratures, so unlike the POP signals, I couldn't find a digital demod phase that consistently had all the signal in one of the two quadratures. This is all due to angular fluctuations?
  2. My ASC simulations suggest that the POP QPD is a poor sensor of PRM motion when the PRFPMI is locked. However, I find that turning on a feedback loop with the POP QPD as a sensor and the PRM as the actuator dramatically reduces the low-frequency fluctuations of the arm cavity carrier buildup. 🤔

I blew the long lock last night because I forgot to not clear the ASS offsets when trying to find the right settings for running the ASS system at high power. Will try again tonight...

Quote:

Lock the PRMI on carrier and measure the sensing matrix, see if the MICH and PRCL signals look sensible in 1f and 3f photodiodes.

  1493   Fri Apr 17 11:05:22 2009 YoichiUpdateLockingThursday night locking status
The last night, it was sort of robust to go up until arm power = 26.
The REFL_DC gain seems to change a lot around this region. So I did fine adjustments of the gain with small incremental steps of the arm power.
This work will continue.
The AutoDTT shows that the lock loss happens with an oscillation of CARM at around 100Hz. This indicates that the cross-over is the culprit.
I was also able to increase the CM UGF up to 10kHz.
ELOG V3.1.3-