40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 90 of 339 Not logged in
ID Date Author Type Category Subject
14665   Wed Jun 12 02:15:50 2019 KruthiUpdateCamerasGigE setup

[Koji, Kruthi]

Yesterday, Koji helped me clean all the optics that are being used for the setup. We tried aligning the cameras with the previous configuration we had, but after connecting the analog camera cables there wasn't much room to align the beam splitter. Today, I tried a different configuration and tested the alignment of analog camera, GigE, beam splitter and the mirror using a laser beam [pictures attached]. But the MC2 isn't locked to test if the whole setup is actually aligned with the mirror inside the vacuum.

Also, with this setup, just by using posts of different lengths with the middle 90º-post-clamp, we will be able to move all the components. This way, we can easily image the beam spot in all the cavities.

Attachment 1: MC2_GigE_setup.jpg
14666   Wed Jun 12 21:55:34 2019 KruthiUpdateCamerasGigE setup

I'm attaching a picture of the screen. I just positioned the enclosure by turning it a bit and I suppose we can see the mirror inside the vacuum now (the MC2 is still not locked).

 Quote: [Koji, Kruthi] Yesterday, Koji helped me clean all the optics that are being used for the setup. We tried aligning the cameras with the previous configuration we had, but after connecting the analog camera cables there wasn't much room to align the beam splitter. Today, I tried a different configuration and tested the alignment of analog camera, GigE, beam splitter and the mirror using a laser beam [pictures attached]. But the MC2 isn't locked to test if the whole setup is actually aligned with the mirror inside the vacuum.  Also, with this setup, just by using posts of different lengths, we will be able to image the beam spot in all the cavities.

Attachment 1: MC2_analog_pic.jpg
14668   Thu Jun 13 14:28:46 2019 ranaUpdateCamerasGigE setup

don't need to lock - make sure the 4 OSEMs are centered on the camera field just as we have for the arm cavity mirrors

 Quote: I'm attaching a picture of the screen. I just positioned the enclosure by turning it a bit and I suppose we can see the mirror inside the vacuum now (the MC2 is still not locked).

14674   Fri Jun 14 00:40:33 2019 KruthiUpdateCamerasGigE setup

Today, I tried aligning it further; I'm attaching a picture of it. We are not able to see all the 4 OSEMs yet. In the reference picture I had taken, before taking off the previous analog setup, the OSEMs are not seen. So, I don't really understand what the other 2 spots seen on the current screen are. Are they actually OSEMs?

I need a laptop next to MC2, so that I can have a look at it and make further alignments. So, I tried accessing the GigE attached to the telescope using Paola. The pylon app in it, throws an error, few seconds after running it in continuous shot mode, and disconnects the GigE; everything works fine on Rossa though. I'll put up further details soon.

Quote:

don't need to lock - make sure the 4 OSEMs are centered on the camera field just as we have for the arm cavity mirrors

 Quote: I'm attaching a picture of the screen. I just positioned the enclosure by turning it a bit and I suppose we can see the mirror inside the vacuum now (the MC2 is still not locked).

Attachment 1: Reference_image_taken_with_previous_analog_camera_setup.jpeg
Attachment 2: MC2_image.JPG
14676   Sat Jun 15 00:03:26 2019 KruthiUpdateCamerasGigE setup

The analog camera is aligned and we are able to see all the 4 OSEMs (pictures attached). Due to secondary reflection from the beamspiltter (BS1-1064-33-2037-45S), when the MC2 is locked, we are getting a ghost image of the beam spot along with the primary image.

The pylon app in Paola was reporting an error saying "0xE1000014: The buffer was incompletely grabbed". I followed the instructions given in this site, and changed the 'Packet Size' to 1500 and 'Inter-Packet Delay parameter' to a value greater than 20,000 (µs). This did the trick and I was able to use the continuous shot mode without any interruption. I'm attaching a picture of MC2 that I captured using GigE.

Quote:

Today, I tried aligning it further; I'm attaching a picture of it. We are not able to see all the 4 OSEMs yet. In the reference picture I had taken, before taking off the previous analog setup, the OSEMs are not seen. So, I don't really understand what the other 2 spots seen on the current screen are. Are they actually OSEMs?

I need a laptop next to MC2, so that I can have a look at it and make further alignments. So, I tried accessing the GigE attached to the telescope using Paola. The pylon app in it, throws an error, few seconds after running it in continuous shot mode, and disconnects the GigE; everything works fine on Rossa though. I'll put up further details soon.

Quote:

don't need to lock - make sure the 4 OSEMs are centered on the camera field just as we have for the arm cavity mirrors

 Quote: I'm attaching a picture of the screen. I just positioned the enclosure by turning it a bit and I suppose we can see the mirror inside the vacuum now (the MC2 is still not locked).

Attachment 1: mc2_GigE.pdf
Attachment 2: MC2_analog.jpeg
Attachment 3: MC2_analog_OSEMs.jpeg
227   Tue Jan 8 15:20:17 2008 PkpUpdateCamerasGigE update
[Tobin , Pinkesh]

Finally we got the camera doing something (other than giving out its attributes). The only thing that seems to work so far is a program called AAviewer, which converts the image into an ASCII format and displays it on the screen. If you want to play around with it, log into mafalda (131.215.113.23) via rana.ligo.caltech.edu. Access /cvs/cds/caltech/target/Prosilica/bin-pc/x86/ and there should be a few programs in there, one of which is AAviewer, which requires you to get an IP address (which is 131.215.113.103) for the camera right now. (You can also get the IP information via the ListCameras program). The camera is physically in the 40m near the network rack.

Other programs dont seem to be working and its probably due to the network/packetsize issues. Since linux2 can change its packetsize to a higher number, I will get it to compile on linux2 for now and then give it a shot.
15306   Sat Apr 18 13:32:31 2020 ranaUpdateCamerasGigE w better NIR sensitivvity

There's this elog from Stephen about better 1064 sensitivity from Basler. We should consider getting one if he finds that its actual SNR is as good as we would expect from the QE improvement.

Might allow for better scatter measurements - not that we need more signal, but it could allow us to use shorter exposure times and reduce blurring due to the wobbly beams.

15311   Thu Apr 23 09:52:02 2020 JonUpdateCamerasGigE w better NIR sensitivvity

Nice, and we should also permanently install the camera server (c1cam) which is still sitting on the electronics bench. It is running an adapted version of the Python 2/Debian 8 site code. Maybe if COVID continues long enough I'll get around to making the Python 3 version we've long discussed.

 Quote: There's this elog from Stephen about better 1064 sensitivity from Basler. We should consider getting one if he finds that its actual SNR is as good as we would expect from the QE improvement.
1006   Mon Sep 29 13:33:39 2008 josephbConfigurationComputersGigabit network finished and conlog available on Nodus
The last 100 Mb unmounted hub has been removed (or at least of the ones I could find). We should be on a fully gigabit network with Cat6 cables and lots and lots of labels.

In other news, the pearl script that runs the web interface on linux1 for the conlog has been copied to /cvs/cds/caltech/apache/cgi-bin/ and is now being pointed to by the apache server on Nodus.

https://nodus.ligo.caltech.edu:30889/cgi-bin/conlog_web.pl
471   Thu May 8 16:40:36 2008 josephbConfigurationCamerasGige Camera currently on PSL table
Andrey and myself were working on the PSL table today, using a pickoff of a pickoff of the main beam (adding a microscope slide to pickoff ~4% of the original pickoff) to the GC750 GigeCam.

At the time we left, we scanned the area with a beam scan and didn't see any new stray beams, and nothing in any useful beam paths should have changed. We also strung a Cat 6 cable from the control room switch out to the PSL table in the cable trays, and then above the PSL table.

Currently, its not as well aligned as it could be, and also requires a very low exposure setting, of -E 50 or so to avoid saturation.
3082   Wed Jun 16 18:14:13 2010 AidanUpdateGeneralGlass cover from overhead light smashed on PSL table

I was giving a tour of the 40m yesterday. We were looking at the PSL table. About 30 seconds after I turned the lights on a glass cover from one of the lights (NW corner) popped out of its holder and smashed on the table.

I've cleaned up all the broken glass I could see but there may be some small shards there. Please use caution in that area.

Attachment 1: DSC_1769.JPG
Attachment 2: DSC_1768.JPG
13199   Sat Aug 12 14:09:36 2017 gautamUpdateSUSGlitches stay on MC1

### Even in the switched state, the glitches stayed on MC1.

The coil driver electronics for MC1, upstream of the Satellite box, was what was previously MC3 electronics.

Attachment #1 shows that there were no glitches in MC3 sensor channels (which are now physically connected to what was previously MC1 coil driver electronics).

Attachment #2 shows the second trends for a 12 hour period for MC1 and MC3 sensor channels. The MC3 channels look well behaved, but there are frequent glitches (at least 9 in the last 12 hours ) visible in the MC1 channels.

So to recap:

• We switched MC1 satellite box - but glitch stayed on MC1, so it would seem the Satellite box is not to blame.
• We shutdown the watchdog and the glitches persisted.
• We switched the coil driver electronics for MC1, but glitches remained on MC1, and MC3 doesn't show any evidence of glitching. This and the previous bullet point suggest the coil driver electronics are not to blame.
• For the glitch posted in Attachment #1, I could see the MC-REFL spot moving around on the CCD monitors, so the glitches aren't just a feature in the shadow sensor readout.

I need to confirm that the output of the coil driver board goes straight to the Sat. Box, but if there are no intermediate elements, the problem is either in the cable from coil driver to sat. box, or downstream of the Satellite box - i.e. vacuum feedthroughs or the suspension itself? The size of the glitches is roughly the same in all 4 face channels (~60-80cts pp).

 Quote: About 30mins ago, I saw another glitch on MC1 - this happened while the Watchdog was shutdown. In order to further narrow down the cause of the glitch, we switched the Coil Driver Board --> Satellite box DB(15?) connectors on the coil drivers between MC1 and MC3 coil driver boards. I also changed the static PIT/YAW bias voltages to MC1 and MC3 such that MC-REFL is now approximately back to the center of the CCD monitor.

GV addendum 14 Aug 2017, 10.30am: Attachment #3 shows the second trend for the MC sensor channels over the weekend. While there were many on Saturday, it seems that Sunday was quieter.

Attachment 1: MC1_glitch.png
Attachment 2: MC_12hr_trend.png
Attachment 3: MC1_glitches_intermittent.png
13200   Sat Aug 12 22:35:22 2017 ranaUpdateSUSGlitches stay on MC1

To add to Gautam's entry: we swapped the cables at the coil driver side (these are the ones that go from coil driver to sat box). In this state, damping is not useable since the MC1 servos would drive MC3.

~70 counts in the sensor means ~70 microns of motion. Since the watchdogs are off and the coil drivers are swapped, this can't be laser beam getting in to the sensors.

WE have to consider that these are some real strain release type events happening in the suspension wire or wire standoff, so may require a vent to inspect and possible repair MC1.

13201   Sun Aug 13 01:35:09 2017 KojiUpdateSUSGlitches stay on MC1

We used to have similar suspension excursion at ETMX. This was the motivation to replace the stand-offs from Al ones to ruby ones. Did the replacement solve the issue at ETMX?

13206   Mon Aug 14 20:01:38 2017 gautamUpdateSUSGlitches stay on MC1

I don't think we can say for sure. I was just talking to EricQ about this, he said the glitches were often seen when changing the alignment offsets when aligning the arm. I am pretty sure I have seen the ETMX alignment change abruptly since the Ruby Standoff replacement (the Oplev spot just slides across the MEDM display rapidly), but I can't find an elog where I've put in details. I also haven't done a whole lot of work with the arm cavities where I would have noticed this problem. There is this test that Eric did, and it didn't throw up any red flags. But the suspension can be well behaved for weeks at a time before this problem pops up again.

There was also the flaky power connection to the timing card on the ETMX expansion chassis which was fixed only recently, after which there has been no systematic investigation of the status of ETMX.

If it is true that these events are caused by strain building up in the suspension wire, I wonder how we can take systematic steps to avoid it. From what I remember of the SOS assembly procedure, the (unglued) standoff is slid along the optic with the wire under slight tension until the wire slips into the groove on the standoff. Then the tension in the wire is adjusted till the optic is pitch balanced and at the desired height. But it is easy to imagine imprinting some torsional stresses in the (40 um?) wire during this process of looping it around under the optic and placing it in the groove. But perhaps this mechanism makes a negligible contribution to the effect we are seeing, and some other mechanism is responsible in this case.

 Quote: We used to have similar suspension excursion at ETMX. This was the motivation to replace the stand-offs from Al ones to ruby ones. Did the replacement solve the issue at ETMX?

14107   Fri Jul 27 02:30:51 2018 gautamUpdateGeneralGlitchy MC

Kevin and I saw some weird IMC / PEM BLRMS behaviour today - see Attached screenshot. Not sure what was happening with the IMC, but MCtrans was oscillating at ~3Hz for a good 20 minutes or so. I just killed the lock, and restarted MCautolocker on megatron. There was a strange feature in the 3-10Hz BLRMS around that time as well. All seems back to normal now...

Attachment 1: 38.png
14131   Fri Aug 3 18:54:58 2018 gautamUpdateSUSGlitchy MC1

The wall StripTool indicated that the IMC wasn't too happy when I came in today. Specifically:

• MC1 watchdog was tripped.
• Even in the tripped state, MC REFL spot on the camera showed spot motion that was too large to be explained as normal seismic driven motion (i.e. with local damping supposedly disabled).
• Strange excursions were observed in the MC1 shadow sensor signal levels as well, see Attachment #1 - negative values don't make any sense for this readout.

The last time this happened, it was due to the Sorensens not spitting out the correct voltages. This time, there were no indications on the Sorensens that anything was funky. So I just disabled the MCautolocker and figured I'd debug later in the evening.

However, around 5pm, the shadow sensor values looked nominal again, and when I re-enabled the local damping, the MC REFL spot suggested that the local damping was working just fine. I re-enabled the MCautolocker, MC re-locked almost immediately. To re-iterate, I did nothing to the electronics inside the VEA. Anyways, this enabled us to work on the X arm ASS (next elog).

Attachment 1: MC1_sensorAnomaly.png
15443   Tue Jun 30 22:00:04 2020 gautamUpdateElectronicsGlitchy POX resurfaces

This problem reared its ugly head again. I am inclined to believe the problem is electronic and not on the light, since the POY channels seem immune to this issue (see Attachment #1). I will investigate in the daytime tomorrow. Note that while the POX photodiode head has ~twice the transimpedance than POY (per measurement), the POY signal gets amplified by a ZHL-500-HLN amplifier before heading to the demod electronics (nominal gain is 19dB = x9). There is also some imbalance in the light level at the photodiodes I guess, because overall, the PDH fringe is ~twice as large for the Y arm as the X arm. Basically, the y-axes of the attached plot cannot be directly compared between POX and POY.

Mostly this is an annoyance - right now, the POX signal is only used for locking and dither aligning the X arm cavity, and so once that is done, the locking can proceed (as long as the other channels, e.g. REFL11, aren't glitching as well...)

Attachment 1: glitchyPOX.jpg
8220   Mon Mar 4 16:26:45 2013 BrettUpdateSUSGlobal Damping Noise Measurement

Here is an amplitude spectrum plot of y-arm cavity noise with a 50 Hz cutoff damping filter of the form zpk(0,[50;50],1). The low passing of this filter was intentionally extremely poor in order to see the damping noise in the cavity. The blue trace is the noise with no damping, which may be considered the 'best case' scenario from a noise point of view. The green has regular local damping on the ITMY. The ETMY has no damping for this measurement because the cavity control feedback to the ETMY takes care of its control when the cavity is locked. Notice the the large increase in noise from 40 Hz to 250 Hz, up to 1 order of magnitude. This noise is from the OSEM sensors passing through the damping loops. The red curve shows the y-arm noise with the exact same damping, except it is now applied in the global scheme. In this case, the damping noise falls completely below the baseline level of the cavity and becomes indistinguishable from the 'no damping' case.

If the damping injected enough noise I'd expect we would see a drop of 50 to 80 times switching from local to global. That is, the same factor measured in the transfer functions listed in log entry 8193.  However, the damping noise is only at most 1 order of magnitude above the baseline in this measurement. We would have to increase the damping noise by about another order of magnitude before we could expect to see the global damping noise in the cavity measurement.

The units of the cavity displacement in the plot were calculated using the 1.4e12 counts per meter calibration in log 6834. The measured UGF of the LSC loop at the time was 205 Hz. The peak in the plot above 200 Hz appears to be from this unity crossing. Moving the UGF also moves this peak.

Moral of the story: global damping can isolate the damping noise pretty well from the cavity signal.

Attachment 1: YARM_Noise.png
8174   Tue Feb 26 17:56:15 2013 BrettUpdateSUSGlobal Damping Update

The global damping input and output matrices were installed to run for the Y-arm. Since we are using just one arm for now, only the DARM and CARM DOFs were entered into the matrices.

The input matrix was set to have elements with magnitudes of 0.5 while the output matrix was set to have elements with magnitudes of 1. The input matrix gets the 0.5 because the sensor signals must be avergaed for each global DOF, to make an 'equivalent sensor' with the same gain. The output matrix gets magnitudes of 1 so that the overall gain of the global loops is the same as the local loops. A transfer function was measured on the CARM loop to check that the overall gain is in fact the same as the measured ITMY and ETMY loops.

Simple damping filters were installed for the ITMY and ETMY as well as the global y arm CARM and DARM loops.

The ETMY output tuning filter ETMY_GLOBPOS was set to have a gain of 0.4 because there is an extra gain of 2.5 relative to ITMY in some mysterious place as discussed in log 8172.

8193   Wed Feb 27 22:28:53 2013 BrettUpdateSUSGlobal Damping Update

New excitation points were added after the global damping loops for more testing options. The updated c1sus.mdl model was re-committed to the svn. Two interesting simulink 'requirements' were found during this minor modification. First, excitation points must be placed on the top level of the diagram. If they are in a subsystem you will get compiling errors. Second, the excitation name must end in _EXC. It will compile OK if you don't do this, but the excitation points will not put out any excitations.

To do further investigation on the mysterious gain factor of 2.5 between the ETMY and ITMY POS damping loops, I measured TFs in the POS direction to the locked YARM signal for each. This provides an additional sensor, common to both, so we can see if the gain is coming from the actuation side or sensing side of the damping loops. The difference in these TFs is about

2.895

So it seems the majority of the damping gain difference is on the actuation side with some small difference on the sensing side. In order to allow for the later splitting of YARM LSC control between ITMY and ETMY (global damping and the cavity control must be along the same coordinate system), I placed this gain of 2.95 in ITMY_LSC.

To get a first measure of the relative performance of global damping to local damping I measured some TFs between the sensor signal inputs and YARM. So first, while the cavity was still locked with just ETMY, I measured a TF between C1:SUS-ITMY_SUSPOS_EXC and C1:LSC-YARM_IN1. Second, I split the cavity control evenly between the ETMY and ITMY by adjusting C1:LSC-OUTPUT_MTRX. I turned off the local damping and turned on the common DOF global damping (called CARM at this point despite being on just one arm). I then repeated the same TF but driving from C1:SUS-GLOBAL_CARMDAMP_EXC.

The resulting TFs are displayed in the attached figure. The blue curve is then the TF from local damping sensor noise to YARM. The green is global damping sensor noise to YARM. The suppression between local to global is in red. The global damping curve is about 50 to 100 times lower (better) than local damping. This can probably be improved with further tuning to account for remaining differences between the ITMY and ETMY.

Note, the damping loop used in the filter modules for all of these is zpk(0,[15 15],1), with a gain of 30. This purposely has little high frequency filtering so it is easier to see the influence on YARM.

Attachment 1: DampNoise_to_YARM_fig_27Feb2013.png
8207   Fri Mar 1 16:37:45 2013 BrettUpdateSUSGlobal Damping Update

Brett and Kamal

The global damping testing for the week is now complete. The c1sus.mdl simulink diagram settled on the attached screenshot. The top level of c1sus.mdl is shown on the left zoomed in over the new global damping block. The right shows the inside of that block. Also attached in the second screenshot are two of the modal damping MEDM screens. The left shows the main overview screen, the right shows the global damping filters. The overview screen is called C1SUS_GLOBAL.adl and is found in ...medm/c1sus/master/.

We have measured transfer functions and power spectra that show that global damping, with just a moderate amount of tuning (30 minutes of work) reduces the OSEM damping noise seen by YARM_IN1 by a factor between 50 and 80. Log 8193 highlights the transfer function measurements. The power spectra directly measure the noise in the cavity. I am not putting that data here because I have to catch. I will process the data and post it here later.

Overall the global damping tests appear to have been successful, isolating (not removing) the test mass damping noise from the cavity by almost 2 orders of magnitude. Presumably even more isolation is possible with more tuning.

Attachment 2: GlobalDampScreens.png
16039   Fri Apr 16 00:21:52 2021 KojiUpdateGeneralGlue Freezer completely frozen

I was looking at the laser head/amp and somehow decided to open the glue freezer. And it was stuck. I've managed to open it but the upper room was completely frozen.
Some of the batteries were embedded in a block of ice. I think we should throw them out.

Can the person who comes in the morning work on defrosting?

- Coordinate with Yehonathan and move the amps and the wooden crate so that you can move the freezer.

- Remove the contents to somewhere (it's OK to be room temp for a while)

- Unplug the freezer

- Leave the freezer outside with the door open. After a while, the ice will fall without care.

- At the end of the day, move it back to the lab. Continue defrosting the other day if the ice remains.

Attachment 1: P_20210416_000906.jpg
Attachment 2: P_20210416_000850.jpg
16040   Fri Apr 16 10:58:16 2021 YehonathanUpdateGeneralGlue Freezer completely frozen

{Paco, Anchal, Yehonathan}

We emptied the fridge and moved the amplifier equipment on top of the amplifier crate. We unplugged the freezer and moved it out of the lab to defrost (attachment).

 Quote: I was looking at the laser head/amp and somehow decided to open the glue freezer. And it was stuck. I've managed to open it but the upper room was completely frozen. Some of the batteries were embedded in a block of ice. I think we should throw them out. Can the person who comes in the morning work on defrosting? - Coordinate with Yehonathan and move the amps and the wooden crate so that you can move the freezer. - Remove the contents to somewhere (it's OK to be room temp for a while) - Unplug the freezer - Leave the freezer outside with the door open. After a while, the ice will fall without care. - At the end of the day, move it back to the lab. Continue defrosting the other day if the ice remains.

Attachment 1: 20210416_105048.jpg
16045   Fri Apr 16 19:07:31 2021 YehonathanUpdateGeneralGlue Freezer completely frozen

There is still a huge chunk of unmelted ice in the fridge. I moved the content of that fridge in the main fridge and put "do not eat" warning signs.

I returned the fridge to the lab and plugged it back in to prevent flooding.

Defrosting will have to continue on Monday.

16048   Mon Apr 19 10:52:27 2021 YehonathanUpdateGeneralGlue Freezer completely frozen

{Anchal, Paco, Yehonathan}

We took the glue fridge outside.

16051   Mon Apr 19 19:40:54 2021 YehonathanUpdateGeneralGlue Freezer completely frozen

{Paco, Yehonathan}

We broke the last chunk of ice and cleaned the fridge. We move the fridge back inside and plugged it into the wall. The glues were moved back from the main fridge.

The batteries that were found soaking wet are now somewhat dry and were left on the cabinet drawers for future recycling.

 Quote: {Anchal, Paco, Yehonathan} We took the glue fridge outside.

3958   Fri Nov 19 18:20:59 2010 SureshUpdateSUSGlue dynamics!

I examined the magnet-dumbbell joints under the microscope to see whether the glue that I applied yesterday was sufficient or in excess.

I think the pictures below speak for themselves !

During the gluing process the Al dumbbell stays below and the magnet with a drop of glue on the lower face is placed on it and held in the teflon fixture.  As seen in the pics the glue seems to have run up the surface of the magnet and has not collected in the narrow part of the dumbell.  So it has climbed up along the narrow gaps between the magnet and the teflon fixture by capillary action. The glue stops where the teflon fixture ends, a little before reaching the free end of the magnet, which further indicates the capillary action.

Attachment 2: Too_much_glue_2.jpg
2618   Fri Feb 19 15:29:14 2010 kiwamuUpdateCOCGluing dumbbells and magnets

Jenne and kiwamu

We have glued the dumbbells to the magnets that will be used for the ITMs

We made two sets of glued pair of the dumbbell and the magnet ( one set means 6 pairs of the dumbbell and the magnet. Therefore in total we got 12 pairs. )

You can see the detailed procedure we did on the LIGO document E990196.

Actually we performed one different thing from the documented procedure;

we made scratch lines on the surface of the both dumbbells and magnets by a razor blade.

According to Steve and Bod, these scratch make the strength of the glues stronger.

Now the dumbbell-magnet pairs are on the flow bench in the clean room, and supported by a fixture Betsy sent us.

- -  notes

On the bench the left set is composed by magnets of 244 +/- 3 Gauss and the right set is 255 +/- 3 Gauss.

12305   Fri Jul 15 16:23:51 2016 ericq UpdateGeneralGluing setbacks

[ericq, Lydia]

Here is a picture of the ETMX guide rod post-gluing. There is unfortunately a fair amount of excess. The "tab" is the result from the epoxy travelling along the finger of the fixture arm that held the guide rod.

We set out to glue the previously remove ETMX side magnet, and set up the fixture to do so. For ETMX we needed 3 mm of shimming on the thick side, and 6mm on the thin side.

However, while cleaning the magnet+dumbbell base of epoxy residue, I broke the dumbbell off of the magnet

We then fetched the spare side magnet that Steve had been holding onto. While cleaning it, it was dropped and dissapeared from this plane of existence

So, instead of gluing a side magnet today, we are gluing the existing magnet and dumbbell back together:

Sadly, this used up the last of our EP30.

Though Koji had the foresight to order more(), it will not arrive until Monday/Tuesday, so no side magnet gluing until then.

5850   Wed Nov 9 16:03:21 2011 kiwamuSummaryGeneralGoal this week

Goal of this week :  ALS on the Y arm

Minimum success : Detection of the green beatnote between the freq-doubled PSL and the Y arm transmitted light

5885   Mon Nov 14 11:32:02 2011 kiwamuSummaryGeneralGoal this week

Goal of this week : Noise budgeting on the Y arm ALS

Minimum success : bring the Y arm to the resonance by using ALS  NOISE BUDGETING!!!

=> as a preparation the incident beam pointing needs to be fixed by steering the MC suspensions.

 Quote from #5850http://nodus.ligo.caltech.edu:8080/40m/5850 Goal of this week :  ALS on the Y arm (DONE)

3651   Tue Oct 5 14:11:09 2010 josephb, alexUpdateCDSGoing to from rtlinux to Gentoo requires front end code clean out

Apparently when updating front end codes from rtlinux to the patched Gentoo, certain files don't get deleted when running make clean, such as the sysfe.rtl files in the advLigoRTS/src/fe/sys directories.  This fouls the start up scripts by making it think it should be configured for rtlinux rather than the Gentoo kernel module.

13304   Fri Sep 8 12:08:32 2017 GabrieleSummaryLSCGood reconstruction of PRMI degrees of freedom with deep learning

## Introduction

This is an update of my previous reports on applications of deep learning to the reconstruction of PRMI degrees of freedom (MICH/PRCL) from real free swinging data. The results shown here are improved with respect to elog 13274 and 13294. The training is performed in two steps, the first one using simulated data, and the second one fine tuning the parameters on real data.

## First step: training with simulation

This step is exactly the same already described in the previous entries and in my talks at the CSWG and LVC. For details on the DNN architecture please refer to G1701455 or G1701589. Or if you really want all the details you can look at the code. I used the following signals as input to the DNN: POPDC, POP22_Q, ASDC, REFL11_I/Q, REFL55_I/Q, AS55_I/Q. The network is trained using linear trajectories in the PRCL/MICH space, and signals obtained from a model that simulates the PRMI behavior in the plane wave approximation. A total of 150000 trajectories are used. The model includes uncertainties in all the optical parameters of the 40m PRMI configuration, so that the optical signals for each trajectory are actually computed using random optical parameteres, drwn from gaussian distributions with proper mean and width. Also, white random gaussian sensing noise is added to all signals with levels comparable to the measured sensing noise.

The typical performance on real data of a network pre-trained in this way was already described in elog 13274, and although being reasoble, it was not too good.

## Second step: training with real data

Real free swinging data is used in this step. I fine tuned the demodulation phases of the real signals. Please note that due to an old mistake, my convention for phases is 90 degrees off, so for example REFL11 is tuned such that PRCL is maximized in Q instead of I. Regardless of this convention confusion, here's how I tuned the phases:

• REFL11: PRCL is all in Q when crossing the carrier resonance
• REFL55: PRCL is all in Q when crossing the carrier resonance
• AS55: MICH is all in Q when crossing the PRCL carrier resonance
• POP22: signal peaking in Q when crossing carrier or sideband resonances. Carrier resonance crossing gives positive sign

Then I built the following training architecture. The neural network takes the real signals and produces estimates of PRCL and MICH for each time sample. Those estimates are used as the input for the PRMI model, to produce the corresponding simulated optical signals. My cost function is the squared difference of the simulated versus real signals. The training data is generated from the real signals, by selection 100000 random 0.25s long chunks: the history of real signal over the whole 0.25s is used as input, and only the last sample is used for the cost function computation. The weights and biases of the neural network, as well as the model parameters are allowed to change during the learning process. The model parameters are regularized to suppress large deviations from the nominal values.

One side note here. At first sight it might seems weird that I'm actually fedding as input the last sample and at the same time using it as the reference for the loss function. However, you have to remember that there is no "direct" path from input to output: instead all goes through the estimated MICH/PRCL degrees of freedom, and the optical model. So this actually forces the network to tune the reconstruction to the model. This approach is very similar to the auto-encoder architectures used in unsupervised feature learning in image recognition.

## Results

After trainng the network with the two previous steps, I can produce time domain plots like the one below, which show MICH and PRCL signals behaving reasonably well:

To get a feeling of how good the reconstruction is, I produced the 2d maps shown below. I divided the MICH/PRCL plane in 51x51 bins, and averaged the real optical signals with binning determined by the reconstructed MICH and PRCL degrees of freedom. For comparison the expected simulation results are shown. I would say that reconstructed and simulated results match quite well. It looks like MICH reconstruction is still a bit "compressed", but this should not be a big issue, since it should still work for lock acquisition.

## Next steps

There a few things that can be done to futher tune the network. Those are mostly details, and I don't expect significant improvements. However, I think the results are good enough to move on to the next step, which is the on-line implementation of the neural network in the real time system.

14044   Sun Jul 8 12:20:12 2018 JonSummaryAUXGouy Phase Measurements from AUX-Laser Scans

This note reports analysis of cavity scans made by directly sweeping the AUX laser carrier frequency (no sidebands). The measurement is made by sweeping the RF offset of the AUX-PSL phase-locked loop and demodulating the cavity reflection/transmission signal at the offset frequency.

# Y-Arm Scan

Due to the simplicity of its expected response, the Y-arm cavity was scanned first as a test of the AUX hardware and the sensitivity of the technique. Attachment 1 shows the measured cavity transmission with respect to RF drive signal.

The AUX laser launch setup is capable of injecting up to 9.3 mW into the AS port. This high-power measurement is shown by the black trace. The same measurement is repeated for a realistic SQZ injection power, 70 uW, indicated by the red curve. At low power, the technique still clearly resolves the FSR and six HOM resonances. From the identified mode resonance frequencies the following cavity parameters are directly extracted.

YARM Gautam's Finesse Model Actual
FSR 3.966 MHz 3.967 MHz
Gouy phase 54.2 deg 52.0 deg

# PRC Scan

An analogous scan was performed for the PRC, with the IFO locked on PSL carrier in PRMI. Attachment 2 shows the measurement of PRC transmission with respect to drive signal.

The scan resolves HOM resonances to at least ~13th order, whose frequencies yield the following cavity parameters.

PRC Gautam's Finesse Model Actual
FSR 22.30 MHz 22.20 MHz
Gouy phase 13.4 deg 15.4 deg

# SRC Scan

Ideally (and at the sites) the SRC mode resonances will be measured in SRMI configuration. Because every other cavity is misaligned, this configuration provides an easily-interpretable spectrum whose resonances can all be attributed to the SRC.

Due to time constraints at the 40m, the IFO could not be restored to lockability in SRMI. It has been more than two years since this configuration was last run. For this reason the scan was made instead with the IFO locked in DRMI, as shown in Attachment 3. The quantity measured is the AUX reflection with respect to drive signal.

This result requires far more interpretation because resonances of both the SRC and PRC are superposed. However, the resonances of the PRC are known a priori from the independent PRMI scan. The SRC mode resonances identified below do not conincide with any of the first five PRC mode resonances.

Based on the identified mode resonance frequencies, the SRC parameters are measured as follows.

SRC Gautam's Finesse Model Actual
FSR 27.65 MHz 27.97 MHz
Gouy phase 10.9 deg 8.8 deg

# Lessons Learned

From experience with the 40m, the main challenges to repeating this measurement at the sites will be the following.

• Pointing jitter of the input AUX beam. This causes the PSL-AUX beam overlap to vary at transmission (or reflection), causing variation in the amplitude of the AUX-PSL beat note. As far as we can tell, the frequency of the resonances (the only object of this measurement) is not changing in time, only the relative amplitudes of the diferent mode peaks. I believe the SQZ alignment loops will mitigate this problem at the sites.
• Stabilization of the network analyzer time base. We found the intrinsic frequency stability of the network analyzer (Agilent 4395A) to be unacceptably large. We solved this problem by phase-locking the Agilent to an external reference, a 10-MHz signal provided by an atomic clock.
Attachment 1: yarm_aux_carrier_trans.pdf
Attachment 2: prmi_aux_carrier_trans.pdf
Attachment 3: drmi_aux_carrier_trans.pdf
Draft   Wed Jul 11 18:13:19 2018 keerthanaSummaryAUXGouy Phase Measurements from AUX-Laser Scans

From the Measurement Jon made, FSR is 3.967 MHz and the Gouy phase is 52 degrees. From this, the length of the Y-arm cavity seems to be 37.78 m and the radius of curvature of the mirror seems to be 60.85 m.

$Guoy Phase = \cos^{-1} \sqrt{g1.g2}$

$\\ g = 1- \frac{L}{R}$

$L = \frac {c} {2*FSR}$

FSR = Free spectral Range

L = Lenth of the arm

R = Radius of curvature of the mirror (R1 =$\infty$  , R2= unknown)

Quote:

This note reports analysis of cavity scans made by directly sweeping the AUX laser carrier frequency (no sidebands). The measurement is made by sweeping the RF offset of the AUX-PSL phase-locked loop and demodulating the cavity reflection/transmission signal at the offset frequency.

# Y-Arm Scan

Due to the simplicity of its expected response, the Y-arm cavity was scanned first as a test of the AUX hardware and the sensitivity of the technique. Attachment 1 shows the measured cavity transmission with respect to RF drive signal.

The AUX laser launch setup is capable of injecting up to 9.3 mW into the AS port. This high-power measurement is shown by the black trace. The same measurement is repeated for a realistic SQZ injection power, 70 uW, indicated by the red curve. At low power, the technique still clearly resolves the FSR and six HOM resonances. From the identified mode resonance frequencies the following cavity parameters are directly extracted.

YARM Gautam V. Finesse Model Actual
FSR 3.966 MHz 3.967 MHz
Gouy phase 54.2 deg 52.0 deg

14822   Thu Aug 1 13:55:34 2019 DuoBureaucracyEquipment loanGpib module taken to QIL lab

vanna --> QIL.

gautam 20190804: The GPIB module + power supply were returned to me by Duo ~5pm today at the 40m.

4433   Wed Mar 23 14:19:35 2011 KojiSummaryGeneralGrand Plan

This is the grand plan we talked about in the beginning of the meeting.

• (Kiwamu) X-end Green cleaning up / Prep for DRMI
• (Bryan) Y-end Green
• (Suresh) Help Bryan / RF (w. Kevin)
• (Jenne) MC WFS / Y-arm IR alignment / MC adaptive feedforward (incl. CDS)
• (Koji) LSC
• (Joe) CDS cleaning up
• (Jamie) Help Joe / Noise Budget
• (Larisa) PMC scan / PSL photo&diagram
• (Barbarela) ASS
3018   Sun May 30 22:18:49 2010 ranaUpdatePEMGranite slab w/ lead balls is so far a flop

The seismometers showed an increased noise in the Y-direction when put on top of the granite slab. By tapping the slab, you can tell that its really a mechanical resonance of the lead balls + granite system at ~15-20 Hz.

I tried new balls, flipping the slab upside down, and sitting on the slab for awhile. None of this changed the qualitative behavior, although each of the actions changed the resonance frequencies by several Hz.

I have removed the granite/balls and put the seismometers back on the linoleum floor. The excess noise is gone. I have put the new big box back on top of them and we'll see how the data looks overnight.

I expect that we should remove the linoleum in a wider area and put the seismometers directly on the floor.

3022   Mon May 31 22:52:57 2010 ranaUpdatePEMGranite slab w/ lead balls is so far a flop

This plot shows the noise with the box on, but no granite. We're still pretty far off from the Guralp data sheet.

I implemented software rotation in the huddle subtraction as Valera suggested and it works much better. The two plots below show the before and after. So far this is just 2 deg. of rotation around the z-axis. I'm assuming that aligning the seismometers vertically via bubble level is good enough for the z-axis, but I haven't calibrated the bubble yet.

The residual slope is now suspiciously smooth. I somehow suspect that our readout electronics can still be responsible. We need to hook up a 9V battery to the input terminals to check it out. Its a little steeper than 1/f and I thought that we had exonerated the Guralp breakout box in the past, but now I'm not so sure. I'll let Jenne comment on that.

I also noticed that we have not yet divided by sqrt(2) to account for the fact that we are subtracting 2 seismometers. In principle, an unbiased estimate of the single seismometer noise will be lower by sqrt(2) than the green curve.

8414   Thu Apr 4 13:39:12 2013 Max HortonUpdateSummary PagesGraph Limits

Graph Limits: The limits on graphs have been problematic.  They often reflect too large of a range of values, usually because of dropouts in data collection.  Thus, they do not provide useful information because the important information is washed out by the large limits on the graph.  For example, the graph below shows data over an unnecessarily large range, because of the dropout in the 300-1000Hz pressure values.

The limits on the graphs can be modified using the config file found in /40m-summary/share/c1_summary_page.ini.  At the entry for the appropriate graph, change the amplitude-lim=y1,y2 line by setting y1 to the desired lower limit and y2 to the desired upper limit.  For example, I changed the amplitude limits on the above graph to amplitude-lim=.001,1, and achieved the following graph.

The limits could be tightened further to improve clarity - this is easily done by modifying the config file.  I modified the config file for all the 2D plots to improve the bounds.  However, on some plots, I wasn't sure what bounds were appropriate or what range of values we were interested in, so I will have to ask someone to find out.

Next:  I now want to fix all the funny little problems with the site, such as scroll bars appearing where they should not appear, and graphs only plotting until 6PM.  In order to do this most effectively, I need to restructure the code and factor it into several files.  Otherwise, the code will not only be much harder to edit, but will become more and more confusing as I add on to it, compounding the problems that we currently have (i.e. that this code isn't very well documented and nobody knows how it works).  We need lots of specific documentation on what exactly is happening before too many changes are made.  Take the config files, for example.  Someone put a lot of work into them, but we need a README specifying which options are supported for which types of graphs, etc.  So we are slowed down because I have to figure out what is going on before I make small changes.

To fix this, I will divide the code into three main sectors.  The division of labor will be:
- Sector 1: Figure out what the user wants (i.e. read config files, create a ConfigParser, etc...)
- Sector 2: Process the data and generate the plots based on what the user wants
- Sector 3: Generate the HTML

3418   Fri Aug 13 01:53:12 2010 GopalUpdateOptic StacksGravity Implementation Confirmed

Time Domain Analysis on a Driven, Damped Simple Pendulum has produced a method for implementing gravity.

• Previous Frequency Domain testing lead to unwanted oscillations of all loads.
• Prescribed accelerations at first seemed to create a constant gravity, but instead incorrectly constrained net acceleration to the inputted amount

Methodology:

1) An (approximately) impulse displacement was applied in the horizontal direction. The pendulum bob's displacement was observed for varying pendulum lengths.

2) The drive and response displacements vs. time were FFT'd to produce transfer functions.

3) The fundamental frequencies were inverted, squared, and plotted against frequency.

4) Since the graph is linear with an R^2 of over 0.99, it is reasonable to assume that gravity is properly acting as a restoration force.

Attachment 1: Pendulum_Length.png
Attachment 2: Pendulum_Length.png
15062   Tue Dec 3 00:03:57 2019 gautamUpdateLSCGreen ALS also shows elevated noise with high arm buildup

Summary:

1. While noisier, I was able to control the arm lengths to ~30pm RMS(!) using the green ALS beats as error signals (cf. ~10 pm RMS with the IR ALS system).
2. The PRMI could be locked with a CARM offset applied.
3. When lowering the CARM offset, I saw an increase in the in-loop ALS error signal, just as I had with the IR beat.
4. IR TRX / TRY unsurprisingly did not stabilize in any meaningful way.
5. The noise increase seems to have some periodicity along the frequency axis - need to think about what this means.
6. Since there is no apparent benefit to using the green ALS beats, I restored the IR system. The green PDs should still retain somewhat good alignment if one wishes to do a comparison measurement.
7. While the shadow sensors of the ITMs report elevated noise, it is unlikely to be responsible for the cavity moving by the amount suggested by the elevated ALS error signals because of the digital low-pass filtering and 1/f^2 of the pendulum.
8. I confirmed that the ITM shadow sensors do not report elevated noise when the PRMI is locked such that the carrier is resonant. In this config, there is comparable circulating power in the PRC as to when the CARM offset is reduced to ~0.
9. The fact that the IR and green beats both show similar increase in noise suggestes that the cavity length / laser frequency is in fact being modulated, but I still don't know what the exact mechanism is.

was worth a shot i guess.

Trawling through some elogs, I see that this kind of feature showing up in the ALS CARM is not a new problem, see for example here. But I can't find out what the resolution was.

Attachment 1: ALSnoiseIncrease_greenBeat.pdf
15058   Mon Dec 2 00:27:20 2019 gautamUpdateALSGreen ALS resurrection

Attachment #1 - comparison of phase tracker servo angle fluctuations for the green beat vs IR beat.

• To convert to Hz, I used the PT servo calibration detailed here.
• This is only a function of the delay line length and not the signal strength, so shouldn't be affected by the difference in signal strength between the IR and green beats.
• For the green beat - I divided the measured spectra by 2 to convert the green beat frequency fluctuations into equivalent IR frequency fluctuations.
• There is no whitening before digitization. I believe the measured spectra are dominated by ADC noise above ~50 Hz. See this elog for the frequency discriminant as a funtion of signal strength, so 5uV/rtHz ADC noise would be ~2 Hz/rtHz for a -5dBm signal, which is what I expect for the Y beat, and ~0.5 Hz/rtHz for a +5dBm signal, which is what I expect for the X beat. Hence the brown (Green beat, XARM) being lower than the green trace (IR beat, XARM) isn't real, it is just because of my division of 2. So I guess that calibration factor I applied is misleading.
• I did not yet check the noise in the other configuration - arm lengths controlled using ALS, and POX/POY as the OOL sensors. To be tried tonight.

Attachment #2 - RIN of the DCPDs.

• I noticed that over 10s of seconds, the GTRY level was fluctuating by ~5%.
• This was much more than any drift seen in the GTRX level.
• Measuring the RIN on the DCPDs (Thorlabs PDA36A) supports this observation (spectra were divided by DC value to convert into RIN units).
• There is ~120uW (1.6 VDC, compatible with 30dB gain setting) incident on the GTRX PD, and ~6uW (170 mVDC, compatible with 40dB gain setting) incident on the GTRY PD.
• Not sure what is driving this drift - I don't see any coherence with the IR TRY signal, so doesn't seem like it's the cavity.

Characterization of the green beat setup [past numbers]:

• With some patient alignment effort (usual near-field/far-field matching), I was able to recover the green beat signals.
• Overall, the numbers I measured today are consistent with what was seen in the past when we had the ability to lock using green ALS.
• The mode-matching between the PSL and AUX green beams are still pretty abysmal, ~40-50%. The mode shapes are clearly different, but for now, I don't worry about this.
• I saw some strong AM of the beat signal (for both EX and EY beats) while I was looking at it on a scope, see Attachment #3. This AM is not visible in the IR beat, not sure what to make of it. The frequency of the AM is ~1 MHz, but it's hard to nail this down because the scope doesn't have a very long buffer, and I didn't look at the frequency content on the Agilent (yet).

o BBPD DC output (mV), all measured with Fluke DMM

             XARM   YARM
 V_DARK:     +1.0    +2.0  V_PSL:      +8.0    +13.0  V_ARM:      +157.0  +8.0

o BBPD DC photocurrent (uA)
I_DC = V_DC / R_DC ... R_DC: DC transimpedance (2kOhm)  I_PSL:       3.5    5.5  I_ARM:      78.0    3.0

o Expected beat note amplitude I_beat_full = I1 + I2 + 2 sqrt(e I1 I2) cos(w t) ... e: mode overlap (in power) I_beat_RF = 2 sqrt(e I1 I2) V_RF = 2 R sqrt(e I1 I2) ... R: RF transimpedance (2kOhm) P_RF = V_RF^2/2/50 [Watt]      = 10 log10(V_RF^2/2/50*1000) [dBm]
     = 10 log10(e I1 I2) + 82.0412 [dBm]
     = 10 log10(e) +10 log10(I1 I2) + 82.0412 [dBm]

for e=1, the expected RF power at the PDs [dBm]  P_RF:      -13.6  -25.8

o Measured beat note power (measured with oscilloscope, 50 ohm input impedance)        P_RF:      -17.95dBm (80 mVpp)  -28.4dBm (24mVpp)   (40MHz and 42MHz)       e:        37%                    55  [%]                                             

I also measured the various green powers with the Ophir power meter (filter off):

o Green light power (uW) [measured just before PD, does not consider reflection off the PD]
 P_PSL:       18    24  P_ARM:       400     13

The IR beat is not being made at the moment because I blocked the PSL beam entering the fiber.

Attachment 1: ALSnoiseComparison.pdf
Attachment 2: ALS_TR_RIN.pdf
Attachment 3: GreemAM.pdf
9406   Tue Nov 19 00:18:30 2013 JenneUpdateLSCGreen ALS wishlist

EricQ said that he's going to start hanging out at the 40m a bit, and I was thinking about what I can have him help me with.  This lead to me writing up a wishlist for things that have to do with the ALS system and green lasers.  Some of these are very small tasks, while others are pretty big.  They are certainly not all high priority.  But, they're on my wishlist.

Calibrations

• How many counts of SLOW_SERVO2_OFFSET is one green FSR (for each arm)?
• Calibrate ALS OFFSETTER#_OFFSET counts to nm or Hz offset between the end lasers and the PSL.

Automation / script writing

• Automate finding the beatnotes (requires freq counters)
• Automate locking the ALS

Digital Acquisition

• All 3 laser temperatures
• Frequency counting of beatnotes

Hardware

• Install flipper mirrors on the PSL table to switch between trans DCPDs and far-field views of beam overlap for each arm.
• IR beatnote project - send pickoff of end lasers to PSL via fiber, set up beat detection for each arm, create PLLs.
• Yarm PZT installation and autoalignment.
16845   Wed May 11 15:49:42 2022 JCUpdateOPLEV TablesGreen Beam OPLEV Alignment

[Paco, JC]

Paco and I began aligning the Green Beam in the BS Oplev Table. while aligning the GRN-TRX, the initial beam was entering the table a bit low. To fix this, Paco went into the chamber and correcting the pitch with the steering mirror. The GRN-TRX is now set up, both the PD and Camera. Paco is continuing to work on the GRN-TRY and will update later on today.

In the morning, I will update this post with photos of the new arrangement of the BS OPLEV Table.

Update Wed May 11 16:54:49 2022

[Paco]

GRY is now better mode matched to the YARM and is on the edge of locking, but it more work is needed to improve the alignment. The key difference this time with respect to previous attempts was to scan the two lenses on translation stages along the green injection path. This improved the GTRY level by a factor of 2.5, and I know it can be further improved. Anyways, the locked HOMs are nicely centered on the GTRY PD, so we are likely done with the in-vac GTRY GTRX alignment.

Update Wed May 12 10:59:22 2022

[JC]

The GTRX PD is now set up and connected. The camera have been set to an angle because the cable to connect it is too thick for the camera to maintain its original position along the side.

Attachment 1: IMG_0770.jpeg
2907   Mon May 10 20:03:22 2010 KevinUpdateGreen LockingGreen Laser Beam Profile

Kiwamu and Kevin measured the beam profile of the green laser by the south arm ETM.

The following measurements were made with 1.984A injection current and 39.65°C laser crystal temperature.

Two vertical scans (one up and one down) were taken with a razor blocking light entering a photodiode with the razor 7.2cm from the center of the lens. This data was fit to

b + a*erf(sqrt(2)*(x-x0)/w) with the following results:

scan down: w = (0.908 ± 0.030)mm  chi^2 = 3.8

scan up:      w = (0.853 ± 0.025)mm   chi^2 = 2.9

giving a weighted value of w = (0.876 ± 0.019)mm at this distance.

The beam widths for the profile fits were measured with the beam scanner. The widths are measured as the full width at 13.5% of the maximum. Each measurement was averaged over 100 samples. The distance is measured from the back of the lens mount to the front face of the beam scanner.

 distance (cm) vertical w (µm) horizontal w (µm) 3.2 ± 0.1 1231 ± 8 1186 ± 7 4.7 ± 0.1 1400 ± 4 1363 ± 6 7.4 ± 0.1 1656 ± 5 1625 ± 9 9.6 ± 0.1 1910 ± 10 1863 ± 9 12.5 ± 0.1 2197 ± 8 2176 ± 8 14.6 ± 0.1 2450 ± 12 2416 ± 10 17.5 ± 0.1 2717 ± 12 2694 ± 14 20.0 ± 0.1 2973 ± 16 2959 ± 8 22.4 ± 0.1 3234 ± 12 3193 ± 14

This data was fit to w = sqrt(w0^2+lambda^2*(x-x0)^2/(pi*w0)^2) with lambda = 532nm with the following results:

For the vertical beam profile:

reduced chi^2 = 3.29

x0 = (-87   ± 1)    mm

w0 = (16.30 ± 0.14) µm

For the horizontal beam profile:

reduced chi^2 = 2.01

x0 = (-82   ± 1)    mm

w0 = (16.12 ± 0.10) µm

Note: These fits were done with the beam diameter instead of the beam radius. The correct fits to the beam radius are here: http://nodus.ligo.caltech.edu:8080/40m/2912

Attachment 1: vbp.jpg
Attachment 2: vbp_residuals.jpg
Attachment 3: hbp.jpg
Attachment 4: hbp_residuals.jpg
2909   Mon May 10 22:25:03 2010 KojiUpdateGreen LockingGreen Laser Beam Profile

Hey, what a quick work!

But, wait...

1) The radius of the beam was measured by the razor blade.

2) The diameter of the beam (13.5% full-width) at each point was measured by Beam Scan. The one at z=~7cm was consistent with 1)

3) The data 2) was fitted by a function w = sqrt(w0^2+lambda^2*(x-x0)^2/(pi*w0)^2). This is defined for the radius, isn't it?

So the fitting must be recalculated with correct radius.
Make sure that you always use radius and write with a explicit word "radius" in the record.

Quote:

Kiwamu and Kevin measured the beam profile of the green laser by the south arm ETM.

The following measurements were made with 1.984A injection current and 39.65°C laser crystal temperature.

Two vertical scans (one up and one down) were taken with a razor blocking light entering a photodiode with the razor 7.2cm from the center of the lens. This data was fit to

b + a*erf(sqrt(2)*(x-x0)/w) with the following results:

scan down: w = (0.908 ± 0.030)mm  chi^2 = 3.8

scan up:      w = (0.853 ± 0.025)mm   chi^2 = 2.9

giving a weighted value of w = (0.876 ± 0.019)mm at this distance.

The beam widths for the profile fits were measured with the beam scanner. The widths are measured as the full width at 13.5% of the maximum. Each measurement was averaged over 100 samples. The distance is measured from the back of the lens mount to the front face of the beam scanner.

 distance (cm) vertical w (µm) horizontal w (µm) 3.2 ± 0.1 1231 ± 8 1186 ± 7 4.7 ± 0.1 1400 ± 4 1363 ± 6 7.4 ± 0.1 1656 ± 5 1625 ± 9 9.6 ± 0.1 1910 ± 10 1863 ± 9 12.5 ± 0.1 2197 ± 8 2176 ± 8 14.6 ± 0.1 2450 ± 12 2416 ± 10 17.5 ± 0.1 2717 ± 12 2694 ± 14 20.0 ± 0.1 2973 ± 16 2959 ± 8 22.4 ± 0.1 3234 ± 12 3193 ± 14

This data was fit to w = sqrt(w0^2+lambda^2*(x-x0)^2/(pi*w0)^2) with lambda = 532nm with the following results:

For the vertical beam profile:

reduced chi^2 = 3.29

x0 = (-87 ± 1)mm

w0 = (16.30 ± 0.14)µm

For the horizontal beam profile:

reduced chi^2 = 2.01

x0 = (-82 ± 1)mm

w0 = (16.12 ± 0.10)µm

2910   Tue May 11 14:39:17 2010 AidanUpdateGreen LockingGreen Laser Beam Profile

Here's a photo of the set-up used. The beam profile is measured relative to the f=-100mm lens.

Attachment 1: P5110057_beams.jpg
2912   Tue May 11 17:02:43 2010 KevinUpdateGreen LockingGreen Laser Beam Profile

 Quote: Hey, what a quick work! But, wait... 1) The radius of the beam was measured by the razor blade. 2) The diameter of the beam (13.5% full-width) at each point was measured by Beam Scan. The one at z=~7cm was consistent with 1) 3) The data 2) was fitted by a function w = sqrt(w0^2+lambda^2*(x-x0)^2/(pi*w0)^2). This is defined for the radius, isn't it? So the fitting must be recalculated with correct radius. Make sure that you always use radius and write with a explicit word "radius" in the record.
I recalculated the fits using the radius of the beam instead of the diameter of the beam at 13.5% full-width with the following results:

For the vertical beam profile:

reduced chi^2 = 3.25

x0 = (-86 ± 1)mm

w0 = (46.01 ± 0.38)µm

For the horizontal beam profile:

reduced chi^2 = 2.05

x0 = (-81 ± 1)mm

w0 = (45.50 ± 0.28)µm

Attachment 1: vbp.jpg
Attachment 2: vbp_residuals.jpg
Attachment 3: hbp.jpg
Attachment 4: hbp_residuals.jpg
ELOG V3.1.3-