40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 83 of 346  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  13574   Wed Jan 24 10:45:14 2018 gautamUpdateALSFiber ALS assay

I was looking into the physics of polarization maintaining fibers, and then I was trying to remember whether the fibers we use are actually polarization maintaining. Looking up the photos I put in the elog of the fibers when I cleaned them some months ago, at least the short length of fiber attached to the PD doesn't show any stress elements that I did see in the Thorlabs fibers. I'm pretty sure the fiber beam splitters also don't have any stress elements (see Attached photo). So at least ~1m of fiber length before the PD sensing element is probably not PM - just something to keep in mind when thinking about mode overlap and how much beat we actually get.  

 

  13583   Thu Jan 25 13:18:41 2018 gautamUpdateALSFiber ALS assay

I was looking at this a little more closely. As I understand it, the purpose of the audio differential IF amplifier is:

  1. To provide desired amplification at DC-audio frequencies
  2. To low pass the 2f component of the mixer output

Attachment #1 shows, the changes to the TF of this stage as a result of changing R19->50ohm, R17->500ohm. For the ALS application, we expect the beat signal to be in the range 20-100MHz, so the 2f frequency component of the mixer output will be between 40-200MHz, where the proposed change preserves >50dB attenuation. The Q of the ~500kHz resonance because of the series LCR at the input is increased as a result of reducing R17, so we have slightly more gain there. 

At the meeting yesterday, Koji suggested incorporating some whitening in the preamp itself, but I don't see a non-hacky way to use the existing PCB footprint and just replace components to get whitening at audio frequencies. I'm going to try and measure the spectrum of the I and Q demodulated outputs with the actual beat signal to see if the lack of whitening is going to limit the ALS noise in some frequency band of interest.

Does this look okay?

Quote:

The demod circuit board is configured to have gain of x100 post demod (conversion loss of the mixer is ~-8dB). This works well for the PDH cavity locking type of demod scheme, where the loop squishes the error signal in lock, so most of the time, the RF signal is tiny, and so a gain of x100 is good. For ALS, the application needs are rather different. So we lowered the gain of the "Audio IF amplifier" stage of the circuit from x100 to x10, by effecting the resistor swaps 10ohms->50ohms, 1kohm->500ohms (more details about this later).

Attachment 1: preampProposed.pdf
preampProposed.pdf
  13586   Thu Jan 25 23:59:14 2018 gautamUpdateALSFiber ALS assay

I tried to couple the PSL pickoff into the fiber today for several hours, but got nowhere really, achieved a maximum coupling efficiency of ~10%. TBC tomorrow... Work done yesterday and today:

  • I changed the collimator from the fixed focal length but adjustable lens position CFC-2X-C to the truly fixed F220-APC-1064 recommended by johannes.
  • Used a pair of irises to level the beam out at 4" with two steering mirrors.
  • Used a connector on the PSL table to couple the EX laser light to the PSL fiber - then measured the mode using the beam-scanner (beam is ~300uW) 
  • Measured the mode of the PSL pickoff beam, also using the beam scanner. 
  • Per specs on the Thorlabs website, the F220-APC-1064 has a divergence angle of 0.032 degrees. So expected waist is ~1200um, and the Rayleigh range is ~4.3m, so this is not a very easy beam to measure and fit. I may be thinking about this wrong?
  • Measured beam 1/e^2 dia over ~0.65m, and found it to be fairly constant around 1800um (so waist of 900um) - beam is also pretty symmetric in x and y directions, but I didn't attempt an M^2 measurement.
  • The pickoff from the PSL also did not yield a very clean beam profile measurement, even though I measured over ~1m z-propagation distance. Nevertheless, this looked more like a Gaussian beam, and I confirmed the fitted waist size/location approximately by placing the beam profiler at the predicted waist location and checking the spot size.
  • Used jammt to calculate a candidate mode-matching solution - the best option seemed to be to use a combination of a f=150mm and f=-75mm lens in front of the collimator. 
  • Despite my best efforts, I couldn't get more than ~500uW of light coupled into the fiber - out of the 8mW available, this is a paltry 12.5% sad
  • Because the mode coming out of the fiber is relatively large, and because I have tons of space available on the PSL table, this shouldn't be a hard mode-matching problem, should be doable without any fast lenses - perhaps I'm doing something stupid and not realizing it. I'm giving up for tonight and will try a fresh assault tomorrow. 
  13587   Fri Jan 26 20:03:09 2018 gautamUpdateALSFiber ALS assay

I think part of the problem was that the rejected beam from the PBS was not really very Gaussian - looking at the spot on the beam profiler, I saw at least 3 local maxima in the intensity profile. So I'm now switching strategies to use a leakage beam from one of the PMC input steering optics- this isn't ideal as it already has the PMC modulation sideband on it, and this field won't be attenuated by the PMC transmission - but at least we can use a pre-doubler pickoff. This beam looks beautifully Gaussian with the beam profiler. Pics to follow shortly...

Quote:

I tried to couple the PSL pickoff into the fiber today for several hours, but got nowhere really, achieved a maximum coupling efficiency of ~10%. TBC tomorrow... Work done yesterday and today

 

  13591   Wed Jan 31 15:45:22 2018 gautamUpdateALSFiber ALS assay

Attachment #1 shows the current situation of the PSL table IR pickoff. It isn't the greatest photo but it's hard to get a good one of this setup. Now there is no need to open the Green PSL shutter for there to be an IR beat note.

  • The key to improving the mode-matching was to abandon my "measurements" of the input mode and the mode from the collimator.
  • The best I could do with these measurements was ~25% coupling, whereas now I have ~78%yes (all powers measured with Ophir power meter).
  • Focusing was done using two f=300mm lenses (see attachment).
  • By moving the second (closer to collimator) lens through ~1inch of its current position, I was able to see a clear maximum of the coupled power.
  • By moving the second lens by ~5mm, and touching up the alignment, I couldn't see any improvement.

All this lead me to conclude that I have reached at least some sort of local maximum. The AR coating of the lens has ~0.5% reflection at 8 degrees AOI according to spec, and EricG mentioned today that the fiber itself probably has ~4% reflection at the interface due to there not being any special AR coating. There is also the fact that the mode of the collimator isn't exactly Gaussian. Anyways I think this is a big improvement from what was the situation before, and I am moving on to debugging the ALS electronics.

There is 3.65mW of power coupled into the fiber - our fiber coupled PDs have a damage threshold of 2mW, and this 3.65mW does get split by 4 before reaching the PDs, but good to keep this number in mind. For a quick measurement of the PMC and X end PDH modulation depth measurements, I used an ND=0.5 filter in the beam path.

 

Attachment 1: IMG_6875.JPG
IMG_6875.JPG
  13254   Fri Aug 25 15:54:14 2017 gautamUpdateALSFiber ALS noise measurement

[Kira, gautam]

Attachment #1 - Photo of the revamped beat setup. The top panel has to be installed. New features include:

  • Regulated power supply via D1000217.
  • Single power switch for both PDs.
  • Power indicator LED.
  • Chassis ground isolated from all other electronic grounds. For this purpose, I installed all the elctronics on a metal plate which is only connected to the chassis via nylon screws. The TO220 package power regulator ICs have been mounted with the TO220 mounting kits that provide a thin piece of plastic that electrically insulates its ground from the chassis ground.
  • PD outputs routed through 20dB coupler on front panel for diagnostic purposes.
  • Fiber routing has been cleaned up a little. I installed a winding fixture I got from Johannes, but perhaps we can install another one of these on top of the existing one to neaten up the fiber layout further.
  • 90-10 light splitter (meant for diagnostic purposes) has been removed because of space constraints. 

Attachment #2 - Power budget inside the box. Some of these FC/APC connectors seem to not offer good coupling between the two fibers. Specifically, the one on the front panel meant to accept the PSL light input fiber seems particularly bad. Right now, the PSL light is entering the box through one of the front panel connectors marked "PSL + X out". I've also indicated the beat amplitude measured with an RF analyzer. Need to do the math now to confirm if these match the expected amplitudes based on the power levels measured.

Attachment #3 - We repeated the measurement detailed here. The X arm (locked to IR) was used for this test. The "X" delay line electronics were connected to the X green beat PD, while the "Y" delay line electronics were connected to the X IR beat PD. I divided the phase tracker Hz calibration factor by 2 to get IR Hz for the Y arm channels. IR beat was at ~38MHz, green beat was at ~76MHz. The broadband excess noise seen in the previous test is no longer present. Indeed, below ~20Hz, the IR beat seems less noisy. So seems like the cleaning / electronics revamp did some good. 

Further characterization needs to be done, but the results of this test are encouraging. If we are able to get this kind of out of loop ALS noise with the IR beat, perhaps we can avoid having to frequently fine-tune the green beat alignment on the PSL table. It would also be ideal to mount this whole 1U setup in an electronics rack instead of leaving it on the PSL table.

Quote:

Photos + power budget + plan of action for using this box to characterize the green PDH locking to follow. 

GV Edit: I've added better photos to the 40m Google Photos page. I've also started a wiki page for this box / the proposed IR ALS  system. For the moment, all that is there is the datasheet to the Fiber Couplers used, I will populate this more as I further characterize the setup.

Attachment 1: IMG_7497.JPG
IMG_7497.JPG
Attachment 2: FOL_schematic.pdf
FOL_schematic.pdf
Attachment 3: 20170825_IR_ALS.pdf
20170825_IR_ALS.pdf
  13255   Fri Aug 25 17:11:07 2017 ranaUpdateALSFiber ALS noise measurement

Is it better to mount the box in the PSL under the existing shelf, or in a nearby PSL rack?

Quote:

 

Further characterization needs to be done, but the results of this test are encouraging. If we are able to get this kind of out of loop ALS noise with the IR beat, perhaps we can avoid having to frequently fine-tune the green beat alignment on the PSL table. It would also be ideal to mount this whole 1U setup in an electronics rack instead of leaving it on the PSL table

 

  13257   Sun Aug 27 11:57:31 2017 ranaUpdateALSFiber ALS noise measurement

It seems like the main contribution to the RMS comes from the high frequency bump. When using the ALS loop to lock the arm to the beat, only the stuff below ~100 Hz will matter. Interesting to see what that noise budget will show. Perhaps the discrepancy between inloop and out of loop will go down.

  13266   Tue Aug 29 02:08:39 2017 gautamUpdateALSFiber ALS noise measurement

I was having a chat with EricQ about this today, just noting some points from our discussion down here so that I remember to look into this tomorrow.

  • I believe that currently, the channels C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ and the Y arm analog read out the frequency of the green beat, in Hz.
  • In the comparison I plotted, I WRONGLY divided the spectrum of the IR beat by 2, instead of multiplying in by 2, which is what should actually be done for an apples-to-apples comparison.
  • The deeper question is, what should this channel actually readout?
  • Looking at my codes from past arm scans etc, I see that I am dividing the downloaded data by 2 in order to convert the X-axis of these scans to "IR Hz". But this should really be all we care about.
  • So I think I will have to re-do the cts-to-Hz calibration in the ALS models. It should be possible to do ~10FSR scans with the IR beat, and then we can use the sideband resonances (presumably the sideband frequencies are known with better precision than the arm length, and hence the FSR) to calibrate the phase tracker.
  • I don't think this changes the fact that the Fiber ALS situation has been improved - but I will have to repeat the measurement to be sure. The improvement may not be as stellar as I tried to sell in my previous elog sad.

    Other thoughts: 

  • Can we make use of the Jetstor raid array for some kind of consolidated 40m CDS backup system? Once we've gotten everything of interest out of it...

  13288   Fri Sep 1 19:15:40 2017 gautamUpdateALSFiber ALS noise measurement

Summary:

I did some work today to see if I could use the IR beat for ALS control. Initial tests were encouraging.

I will now embark on the noise budgeting.

Details:

  • For this test, I used the X arm
  • I hooked up the X-arm + PSL IR beat to the X-arm DFD channel, and used the Y-arm DFD channels to simultaneously monitor the X-arm green beat.
  • I then transitioned to ALS control and used POX as an out-of-loop sensor for the ALS noise.
  • Attachment #1 shows a comparison of the measurements. In red is the IR beat, while the green traces are from the test EricQ and I did a couple of nights ago using the green beat.
  • I also wanted to do some arm cavity scans with the arm under ALS control with the IR beat - but was unsucessful. The motivation was to fix the ALS model counts->Hz calibration factors.
  • I did however manage to do a 10 FSR scan using the green beatnote - however, towards the end of this scan, the green beat frequency (read off the control room analyzer) was ~140MHz, which I believe is outside (or at least on the edge) of the bandwidth of the Green BBPDs. The fiber coupled IR beat photodiodes have a much larger (1GHz) spec'd bandwidth.

I am leaving the green beat electronics on the PSL table in the switched state for further testing...

 

Attachment 1: IR_ALS_noise.pdf
IR_ALS_noise.pdf
  13333   Tue Sep 26 19:10:13 2017 gautamUpdateALSFiber ALS setup neatened

[steve, gautam]

The Fiber ALS box has been installed on the existing shelf on the PSL table. We had to re-arrange some existing cabling to make this possible, but the end result seems okay (to me). The box lid was also re-installed.

Some stuff that still needs to be fixed:

  1. Power supply to ZHL amplifiers - it is coming from a table-top DC supply currently, we should hook these up to the Sorensens.
  2. We should probably extend the corrugated fiber protection tubing for the three fibers all the way up to the shelf. 

Beat spectrum post changes to follow.

Quote:

Is it better to mount the box in the PSL under the existing shelf, or in a nearby PSL rack?

Quote:

 

Further characterization needs to be done, but the results of this test are encouraging. If we are able to get this kind of out of loop ALS noise with the IR beat, perhaps we can avoid having to frequently fine-tune the green beat alignment on the PSL table. It would also be ideal to mount this whole 1U setup in an electronics rack instead of leaving it on the PSL table

 

 

Attachment 1: IMG_7605.JPG
IMG_7605.JPG
  10218   Wed Jul 16 17:34:11 2014 HarryUpdateGeneralFiber Coupled

 Purpose

To couple the spare NPRO into our Panda PM980 fibers, in order to carry out tests to characterize the fibers, in order to use them in FOL.

Design

 Manasa and I spent this morning building the setup to couple NPRO light into the fibers. We used two steering mirrors to precisely guide the beam into the coupler (collimator).

We also attached the lens to a moveable stage (in the z axis), so the setup could be fine tuned to put the beam waist precisely at the photodiode.

The fiber was attached to a fiber-coupled powermeter, so I would be able to tell the coupling efficiency.

fiberTestCouplingSchematic.png

Methods 

During alignment, the NPRO was operating at 1.0 amps, roughly half of nominal current (2.1A).

I first placed the coupler at the distance that I believed the target waist of 231um to be.

Using the steering mirrors and the stage that holds the couple, I aligned the axes of the coupler and the beam.

Finally, I used the variable stage that the lens is attached to to fine tune the location of the target waist.

Results

Once I was getting readings on the powermeter (~0.5nW), the laser was turned up to nominal current of 2.1A.

At this point, I and getting 120nW through the fiber.

While far from "good" coupling, it is enough to start measuring some fiber characteristics.

Moving Forward

Tomorrow, I hope to borrow the beam profiler once again so as to measure the fiber mode.

Beyond this, I will be taking further measurements of the Polarization Extinction Ratio, the Frequency Noise within the fiber, and the effects of a temperature gradient upon the fiber.

Once these measurements are completed, the fiber will have been characterized, and will be ready for implementation in FOL.

  10240   Sat Jul 19 01:59:34 2014 HarryUpdateGeneralFiber Mode Measurement

Purpose 

We wanted to measure the mode coming out of the fibers, so we can later couple it to experimental setups for measuring different noise sources within the fiber. i.e. Polarization Extinction Ratio, Frequency Noise, Temperature Effects.

Methods

I used the beamscan mounted on a micrometer stage in order to measure the spot sizes of the fiber coupled light at different points along the optical axis, in much the same way as in the razorblade setup I used earlier in the summer.

fiberModeMeasurement.png

Analysis

I entered my data (z coordinates, spot size in x, spot size in y) into a la mode to obtain the beam  profile (waist size, location)

 fiberModeMeasurement1.png 

Code is attached in .zip file.

Moving Forward

After I took these measurements, Manasa pointed out that I need points over a longer distance. (These were taken over the range of the micrometer stage, which is 0.5 inches.)

I will be coming in to the 40m early on Monday to make these measurements, since precious beamscan time is so elusive.

Eventually, we will use this measurement to design optical setups to characterize Polarization Extinction Ratio, Frequency Noise, and temperature effects of the fibers, for further use in FOL.

Attachment 3: fiberModeMeasurement1.zip
  10244   Mon Jul 21 10:30:38 2014 HarryUpdateGeneralFiber Mode Measurement

 Purpose

The idea was to measure the profile of the light coming out of the fiber, so we could have knowledge of it for further design of measurement apparatuses, for characterization of the fibers' properties.

Methods

The method was the same as the last time I tried to measure the fiber mode.

This time I moved the beam profiler in a wider range along the z-axis.

Additionally, I adjusted the coupling until it gave ~1mW through the fiber, so the signal was high enough to be reliably detectable.

Measurements were taken in both X and Y transections of the beam.

The range of movement was limited by the aperture of the beam profiler, which cuts off at 9mm. My measurements stop at 8.3mm, as the next possible measurement was beyond the beam profiler's range.

fiberModeMeasurement.png

Analysis

I entered my data into A La Mode, which gave me a waist of 5um, at a location of z = -0.0071 m, that is to say, 7.1mm inside the fiber.

Note that in the plot, data points and fits overlap, and so are sometimes hard to distinguish from each other.

Code is attached.

fiberModeFit2.png

Moving Forward

Using this data, I will begin designing setups to measure fiber characteristics, the first of which being Polarization Extinction Ratio.

Eventually, the data collected from these measurements will be put to use in the frequency offset locking setup.

Attachment 3: fiberModeMeasurement2.zip
  10249   Mon Jul 21 18:08:19 2014 HarryUpdateGeneralFiber Mode Measurement

Quote:

 Purpose

The idea was to measure the profile of the light coming out of the fiber, so we could have knowledge of it for further design of measurement apparatuses, for characterization of the fibers' properties.

Methods

The method was the same as the last time I tried to measure the fiber mode.

This time I moved the beam profiler in a wider range along the z-axis.

Additionally, I adjusted the coupling until it gave ~1mW through the fiber, so the signal was high enough to be reliably detectable.

Measurements were taken in both X and Y transections of the beam.

The range of movement was limited by the aperture of the beam profiler, which cuts off at 9mm. My measurements stop at 8.3mm, as the next possible measurement was beyond the beam profiler's range.

fiberModeMeasurement.png

Analysis

I entered my data into A La Mode, which gave me a waist of 5um, at a location of z = -0.0071 m, that is to say, 7.1mm inside the fiber.

Note that in the plot, data points and fits overlap, and so are sometimes hard to distinguish from each other.

Code is attached.

fiberModeFit2.png

Moving Forward

Using this data, I will begin designing setups to measure fiber characteristics, the first of which being Polarization Extinction Ratio.

Eventually, the data collected from these measurements will be put to use in the frequency offset locking setup.

 Edit

 

 

The previous data were flawed, in that they were taken in groups of three, as I had to move the micrometer stage which held the beamscan between holes in the optical table.

In order to correct for this, I clamped a straightedge (ruler) to the table, so I could more consistently align the profiler with the beam axis.

These data gave a waist w_o = 4um, located 6mm inside the fiber. While these figures are very close to what I would expect (3.3um at the end of the fiber) the fitting still isn't as good as I would like.

The fit given by ALM is below.

fiberModeMeasurement3.png

Moving Forward

I would like to get a stage//rail so I can align the axes of the beam and profiler more consistently.

I would also like to use an aperture the more precisely align the profiler aperture with the beam axis.

Once these measurements have been made, I can begin assembling the setup to measure the Polarization Extinction Ratio of the fiber.

  10255   Tue Jul 22 16:26:04 2014 HarryUpdateGeneralFiber Mode Measurement

I repeated this process once more, this time using the computer controlled stage that the beam profiler is designed to be mounted to.

These data//fitting appears to be within error bars. The range of my measurements was limited when the beam width was near the effective aperture of the profiler.

This latest trial yielded a waist of 4um, located 2.9 mm inside the fiber for the X profile, and 3.0mm inside the fiber for the Y profile.

fiberModeProfile3.png

Code is attached in fiberModeMeasurement4.zip. Note that the z=0 point is defined as the end of the fiber.

Attachment 2: fiberModeMeasurement4.zip
  10282   Mon Jul 28 17:25:32 2014 HarryUpdateGeneralFiber Mode With Collimators

 Purpose

We want a measurement of the fiber modes at either end, with the collimators, because these will be the modes that we'll be trying to match in order to couple light into the fibers, for FOL and/or future projects.

Measurement

In order to measure these modes, I used the beam profiler (Thorlabs BP 209-VIS) to take measurements of the beam diameter (cut off at 13.5% of the amplitude) along the optical axis, for each of the fiber ends.

The ends are arbitrarily labelled End 1 and End 2.

For each measurement, the fibers were coupled to roughly 30%, or 25mW at the output.

Regarding the issue of free rotation in the collimator stages: while End 1 was relatively stable, End 2 tended to move away from its optimal coupling position. In order to correct for this, I chose a position where coupling was good, and repositioned the stage to that coordinate (124 degrees) before taking each measurement.

The data were then entered into A La Mode, which gave waist measurements as follows:

End 1--- X Waist: 197um at Z = 4.8mm       Y Waist: 190um at Z = 13.6mm

End 2--- X Waist: 192um at Z = 7.4mm       Y Waist: 190um at Z = 6.0mm

end1Profiles.pngend2Profiles.png

A La Mode code is attached in .zip file

Moving Forward

These are the types of profiles that we will hopefully be matching the PSL and AUX lasers to, for use in frequency offset locking.

More characterization of the fibers is to follow, including Polarization Extinction Ratio.

We also hope to be testing the overall setup soon.

 

 

Attachment 3: FiberModeWCollimators.zip
  10985   Fri Feb 6 18:06:18 2015 manasaUpdateGeneralFiber Optic module for FOL

I pulled out the Fiber Optic Module for FOL from the rack inside the PSL table enclosure and modified it. The beat PDs were moved into the box to avoid breaking the fiber pigtail input to the PD.

The box has 3 input FC/APC connectors (PSL and AUX lasers) and 2 output FC/APC connectors (10% of the beatnote for the AUX lasers).

Attachment shows what is inside the box. The box will again go back on the rack inside the PSL enclosure.

Attachment 1: FOLfiberModule.png
FOLfiberModule.png
  10403   Fri Aug 15 17:24:44 2014 HarryUpdateGeneralFiber Temp.

 Earlier today Q and I somewhat resurrected my old PER measurement setup so I could run the temperature characterization experiment.

Unfortunately, when I tried to use the fiber illuminator, no light came from the other end, causing me to fail my primary goal for the summer of "don't break anything." The fiber has been re-spooled and labeled appropriately. Also sorry.

In addition to this, Q and I scavenged parts from the telescopes on the PSL and Y End tables, which were either not functional, or needed to have their mode matching adjusted, since we're using the non-PM fibers for FOL, which have a different numerical aperture, and thus slightly different output modes.

Specifically, this is involved removing the rotational mounts, and appropriate beam dumping.

My "calorimeter" still remains intact, in case anyone wants to make this measurement in the future, as this is my last day in the lab.

It's also effective at keeping drinks cold, if you'd rather use it for that.

  10389   Thu Aug 14 18:10:46 2014 HarryUpdateGeneralFiber Temperature Effects Setup

Purpose

We want to characterize the sort of response the fibers have to temperature gradients along them (potentially altering indices of refraction, etc.)

Experimental Setup

I have constructed a sort of two chambered "calorimeter" (by which I mean some coolers and other assorted pieces of recycling.)

The idea is that half of the length of PM fiber resides in one chamber, and the other in the other.

One chamber will remain at an uncontrolled, stable temperature (as measured by thermocouple probe) while the other's temperature is varied using a heat gun.

Using this setup, one can measure losses in power, and effects on polarization within the fiber.

Caveat

This is currently living on the electronics bench until tomorrow morning, and is a little fragile, just in case it needs to be moved.

Attachment 1: tempAffectsSetup.zip
  14643   Wed May 29 18:13:25 2019 gautamUpdateALSFiber beam-splitters are now PM

To maintain PM fibers all the way through to the photodiode, I had ordered some PM versions of the 50/50 fiber beamsplitters from AFW technologies. They arrived some days ago, and today I installed them in the BeatMouth. Before installation, I checked that the ends of the fibers were clean with the fiber microscope. I also did a little cleanup of the NW corner of the PSL table, where the 1um MZ setup was completely disassembled. We now have 4 non-PM fiber beamsplitters which may be useful for non polarizaiton sensitive applications - they are stored in the glass-door cabinet slightly east of the IY chamber along the Y arm, together with all the other fiber-related hardware.

Anjali had changed the coupling of the beam to the slow axis for her experiment but I ordered beamsplitters which have the slow axis blocked (because that was the original config). I need to revert to this config, and then make a measurement of the ALS noise - if things look good, I'll also patch up the Y arm ALS. We made several changes to the proposed timeline for the summer but I'd like to see this ALS thing through to the end while I still have some momentum before embarking on the BHD project. More to follow later in the eve.

Quote:

Get a fiber BS that is capable of maintaining the beam polarization all the way through to the beat photodiode. I've asked AFW technologies (the company that made our existing fiber BS parts) if they supply such a device, and Andrew is looking into a similar component from Thorlabs.

  14503   Sun Mar 31 15:05:53 2019 gautamUpdateALSFiber beam-splitters not PM

I looked into this a little more today.

  1. Looking at the beat signal between the PSL and EX beams from the NF1611 on a scope (50-ohm input), the signal Vpp was ~200 mV.
  2. In the time that I was poking about, the level dropped to ~150mVpp. seemed suspicious.
  3. Thinking that this has to be related to the polarization mismatch between the interfering beams, I moved the input fibers (blue in Attachment #1) around, and saw the signal amplitude went up to 300mVpp, supporting my initial hypothesis.
  4. The question remains as to where the bulk of the polarization drift is happening. I had spent some effort making sure the input coupled beam to the fiber was well-aligned to one of the special axes of the fiber, and I don't think this will have changed since (i.e. the rotational orientation of the fiber axes relative to the input beam was fixed, since we are using the K6XS mounts with a locking screw for the input couplers). So I flexed the patch cables of the fiber beam splitters inside the BeatMouth, and saw the signal go as high as 700mVpp (the expected level given the values reported by the DC monitor).

This is a problem - such large shifts in the signal level means we have to leave sufficient headroom in the choice of RF amplifier gain to prevent saturation, whereas we want to boost the signal as much as possible. Moreover, this kind of operation of tweaking the fiber seating to increase the RF signal level is not repeatable/reliable. Options as I see it:

  1. Get a fiber BS that is capable of maintaining the beam polarization all the way through to the beat photodiode. I've asked AFW technologies (the company that made our existing fiber BS parts) if they supply such a device, and Andrew is looking into a similar component from Thorlabs.
    • These parts could be costly.
  2. Mix the beams in free space. We have the beam coming from EX to the PSL table, so once we mix the two beams, we can use either a fiber or free-space PD to read out the beatnote. 
    • This approach means we lose some of the advantages of the fiber based setup (e.g. frequent alignment of the free-space MM of the two interfering beams may be required).
    • Potentially increases sensitivity to jitter noise at the free-space/fiber coupling points
Quote:
    • An initial RF beat power level measurement yielded -5dBm, which is inconsistent with the DC monitor voltages, but I'm not sure what frequency the beat was at, will make a more careful measurement with a scope or the network analyzer.
Attachment 1: IMG_7384.JPG
IMG_7384.JPG
  11013   Thu Feb 12 12:16:04 2015 manasaUpdateGeneralFiber shielding

[Steve, Manasa]

The fibers around the PSL table were shielded to avoid any tampering.

  20   Fri Oct 26 21:48:40 2007 waldmanConfigurationOMCFiber to 056
I set up a 700 mW NPRO in Rana's lab and launched it onto a 50m fiber. I got a few mW onto the fiber, enough to see with a card before disabling the laser. The fiber now runs along the hallway and terminates in rm 056. Its taped down everywhere someone might trip on it, but don't go out of your way to trip on it or pull on it because you are curious. Tomorrow I will co-run a BNC cable and attenuate the NPRO output so it can only send a few mW and so be laser safe. Then we can try to develop a procedure to align the beam to a suspended OMC and lock our suspended cavity goodness.

Notes to self: items needed from the 40m
  • ND10 and ND20 neutral density filter
  • EOM and mount set for 4 inch beam height
  • Post for fiber launch to get to 4 inch
  • Mode matching lens at 4in
  • 3x steering mirror at 4in
  • RF photodiode at 4in
  • Post for camera to 4in
  • Light sheild for camera
  • Long BNC cable
Some of these exist at 056 already
  3594   Wed Sep 22 16:35:45 2010 josephbUpdateCDSFibers pulled, new FB install tomorrow

[Aidan, Tara, Joe]

We pulled out what used to be the LSC/ASC fiber from the 1Y3 arm rack, and then redirected it to the 1X1 rack.  This will be used as the c1ioo 1PPS timing signal.  So c1ioo is using the old c1iovme fiber for RFM communications back to the bypass switch, and the old LSC fiber for 1PPS.

The c1sus machine will be using the former sosvme fiber for communications to the RFM bypass switch.  It already had a 1 PPS timing fiber.

The c1iscex machine had a new timing fiber already put in, and will be using the c1iscey vme crate's RFM for communication.

We still need to pull up the extra blue fiber which was used to connect c1iscex directly to c1sus, and reuse it as the 1PPS signal to the new front end on the Y arm. 

Alex has said he'll come in tomorrow morning to install the new FB code.

 

  13753   Fri Apr 13 17:56:26 2018 gautamUpdateALSFibers switched out

I swapped the EX fiber for the PSL fiber in the polarization monitoring setup. There is a lot more power in this fiber, and one of the PDs was saturated. I should really have put a PBS to cut the power, but I opted for putting an absorptive ND1.0 filter on the PD instead for this test. I want to monitor the stability in this beam and compare it to the EX beam's polarization wandering.

  13754   Sat Apr 14 14:42:09 2018 gautamUpdateALSFibers switched out

It looks like the drift in polarization content in the PSL pickoff is actually much higher than that in the EX pickoff. Note that to prevent the P-pol diode from saturating, I put an ND filter in front of the PD, so the Y axis actually has to be multiplied by 10 to compare power in S and P polarizations. If this drift is because of the input (linear) polarization being poorly matched to one of the fiber's special axes, then we can improve the situation relatively easily. But if the polarization drift is happening as a result of time-varying stress (due to temp. fluctuations, acoustics etc) on the (PM) fiber from the PSL fiber coupler to the BeatMouth, then I think this is a much more challenging problem to solve.

I'll attempt to quantify the contribution (in Hz/rtHz) of beat amplitude RIN to phase tracker output noise, which will tell us how much of a problem this really is and in which frequency bands. In particular, I'm interested in seeing if the excess noise around 100 Hz is because of beat amplitude fluctuations. But on the evidence thus far, I've seen the beat amplitude drift by ~15 dB (over long timescales) on the control room network analyzer, and this drift seems to be dominated by PSL light amplitude fluctuations.

Attachment 1: PSLdrift.png
PSLdrift.png
  13757   Tue Apr 17 14:08:29 2018 gautamUpdateALSFibers switched out

A follow-up on the discussion from today's lunch meeting - Rana pointed out that rotation of the fiber in the mount by ~5degrees cannot account for such large power fluctuations. Here is a 3 day trend from my polarization monitoring setup. Assuming the output fiber coupler rotates in its mount by 5 degrees, and assuming the input light is aligned to one of the fiber's special axes, then we expect <1% fluctuation in the power. But the attached trend shows much more drastic variations, more like 25% in the p-polarization (which is what I assume we use for the beat, since the majority of light is in this polarization, both for PSL and EX). I want to say that the periodicity in the power fluctuations is ~12hours, and so this fluctuation is somehow being modulated by the lab temperature, but unfortunately, we don't have the PSL enclosure temperature logged in order to compare coherence.

Steve: your  plots look like temperature driven


The "beat length" of the fiber is quoted as <=2.7mm. This means that a linearly polarized beam that is not oriented along one of the special axes of the fiber will be rotated through 180 degrees over 2.7mm of propagation through the fiber. I can't find a number for the coefficient of thermal expansion of the fiber, but if temperature driven fluctuations are changing the length of the fiber by 300um, it would account for ~12% power fluctuation between the two polarizations in the monitoring setup, which is in the ballpark we are seeing...

Attachment 1: PSL_fluctuations.png
PSL_fluctuations.png
  13773   Fri Apr 20 00:26:34 2018 gautamUpdateALSFibers switched out

Summary:

I think the dominant cause for the fact that we were seeing huge swing in the power coupled into the fiber was that the beam being sent in was in fact not linearly polarized, but elliptically polarized. I've rectified this with the help of a PBS. Fiber has been plugged into my polarization monitoring setup. Let's monitor for some long stretch and see if the situation has improved.

Details:

  • The new fiber mount I ordered, K6XS, arrived today. I like it - it has little keys with which all DoFs can be locked. Moreover, it is compatible with the fixed collimators which IMO is the easiest way to achieve good mode-matching into the fiber. It is basically a plug-and-play replacement for the mounts we were using. Anyways, we can evaluate the performance over the coming days.
  • I installed it on the PSL table (started work ~10pm, HEPA turned up to maximum, PSL shutter closed).
  • But even with the new rotational DoF locking feature, I saw that slight disturbances in the fiber caused wild fluctuations in my polarization monitoring setup PD outputs. This was a useful tool through the night of checking the polarization content in the two special axes - Aidan had suggested using a heat gun but shaking the fiber a bit works well too I think.
  • The PM980 fiber has an alignment key that is aligned with the slow axis of the fiber - so it is a useful alignment reference. But even by perturbing the roational alignment about the vertical by +/-15 degrees, I saw no improvement in this behavior. So I began to question my assumption that the input beam itself had clean polarization content.
  • Since my pickoff beam has gone through a QWP and two PBSs, I had assumed that the beam was linearly polarized.
  • But by putting a PBS just upstream of the input fiber coupler, I could see a beam at the S-port with an IR card (while I expected the beam to be P-polarized).
  • OK - so I decided to clean up the input polarization by leaving this PBS installed. With this modification to the setup, I found that me shaking the fiber around on the PSL table didn't affect the output polarization content nearly as dramatically as before!!yes
  • The state I am leaving it in tonight is such that there is ~100x the power in the P-polarization output monitor as the S-polarization (PER ~ 20dB). I didn't try and optimize this too much more for now, I want to observe some long term trend to see if the wild power fluctuations have been mitigated.
  • The output coupler is mounted on the inferior K6X mount, and so there is the possibility that some drift will be attributable to rotation of the output coupler in it's mount. Thermally driven length changes / time varying stresses in the fiber may also lead to some residual power fluctuations. But I don't expect this to be anywhere near the ~25% I reported in the previous elog.
  • The rejected beam from the PBS was measured to be ~300 uW. I haven't dumped this properly, to be done tomorrow.
  • HEPA turned back down to 30%, PSL enclosure closed up, PSL shutter re-opened ~0030am.
  • Note that the EX and EY fiber coupled beams are also likely subject to the same problem. We have to double check. I think it's better to have a PBS in front of the input fiber coupler as this also gives us control over the amount of light coupled into the fiber.

Power budget:

Power in Measured power (Ophir, filter OFF)
@Input coupler, before PBS 4.4 mW
P-pol content @ input coupler 4.06 mW
S-pol (rejected) from PBS 275 uW
@Output coupler 2.6 mW (MM ~65%)

 

  4882   Sat Jun 25 00:00:28 2011 SonaliUpdateGreen LockingFibre Coupling.

 What I did today.

1. I tried to align the IR input beam by aligning the two mirrors, to couple input light into the fibre.

2.I was unsuccessful for a long time even though I tried a lot of tricks.

3. I also tried to use the optical fault locator to superpose the IR beam spot onto the beam spot of the other laser to facilitate effective coupling.

4.But the crucial point was to superpose the input beam path in the perfect direction of the output beam path and not just the beam spot.(the input cone and the output cone are perfectly aligned).

5.After one whole day of trial and thought, I managed to couple light into the fibre, and saw the output beam spot on the screen-camera-monitor set-up which we had arranged. Eurekka !!;)

6.I then used a power meter to measure the input beam power and the output beam power.

7.It was a disappointing 2% . I had read in project reports of many students of a 20% success.

8.After a lot of subtle tweaking of the mirrors using the knobs, I managed to increase the percentage of output beam to 12%.

9. This is a workable level.

10.A day of lot of new learning! Pictures of the setup are attached.:)

 

Attachment 1: Fibre_coupling_successful_24_june.jpg
Fibre_coupling_successful_24_june.jpg
Attachment 2: Beam_output_on_screen.jpg
Beam_output_on_screen.jpg
  3859   Thu Nov 4 03:13:46 2010 SureshUpdateLockingFibre coupling 1064nm light at the south-end table

[Kiwamu, Suresh]

We decided to use the 1064nm beam reflected from the Y1-1037-45-P mirror after the collimation lens following the doubling crystal for coupling into the optical fiber (ref 3843 and 3847 ).

We replaced a beam dump which was blocking this beam with a Y1-1037-45-P mirror and directed the beam into the fiber coupler with another Y1-1037-45-P.  The power in this beam was about 1W.  This has been stepped down to 10mW by introducing a reflective ND filter of OD=2.  The reflected power has been dumped into a blade-stack beam dump.

Steve has ordered the The Visual Fault Locator from Fluke.  It is expected to arrive within a day or two.

 

 

  3865   Thu Nov 4 19:00:57 2010 SureshUpdateLockingFibre coupling 1064nm light at the south-end table

The Fluke Visual Fault locator (Visifault) arrived and I used it to couple 1064nm light into the single mode fibre at the south-end-table.

Procedure used:

When the output end of the fiber is plugged into the Visifault the light emerges from at the south end (input side for 1064nm).  This light is collimated with the fiber coupler at that end and serves as a reference for the optical axis along which the 1064 light must be directed.  Once the two beams (red and 1064) are overlapped with the beam steering mirrors, the Visifault was disconnected from the fiber and the  fibre output ( 1064 at the PSL table) is maximized by walking the beam at the input end and adjusting the collimation at the input.

The output of the fiber has been collimated with a fiber coupler.

7.5mW are incident on the input end and 1.3mW have been measured at the output.    This output power is adequate for the observing the beats with PSL NPRO.

 

 

 

  8183   Wed Feb 27 14:39:59 2013 AnnalisaUpdateLSCFibre laid for RFPD audio

 [Annalisa, Jenne, Rana, Steve]

We installed the fibres on cable trays the 1Y2 and the Control Room.

Still to do: find a power supply for the Fiboxes and plug everything in.

  315   Wed Feb 13 20:37:11 2008 JohnUpdateLSCFibre locking - Fiber
Sam and I observed fringes in the light reflected from the Y arm. These fringes are due to the sidebands and not the carrier. To improve matters we plan to reduce the RF AM and increase our modulation index.
  272   Sat Jan 26 02:08:53 2008 JohnOmnistructureLSCFibres
There is now a fibre running from the SP table to the ISCT at the Y-end. In the coming days I will try to mode match the beam from this fibre into the arm through ETMY. To achieve this I will be altering the optical layout of this table.
  296   Mon Feb 4 22:01:57 2008 JohnSummaryLSCFibres auxiliary locking - Fibers
I managed to couple ~75% of the light transmitted from the y arm, through the fibre, back to the SP table. I hoped that this would be a good way to match the beam from the fibre into the arm. Still no flashes. It looks like the cameras just aren't sensitive enough.
  10860   Wed Jan 7 02:54:09 2015 JenneUpdateLSCFiddling with DARM filters

One of the things that we had talked about last night was the totally tiny amount of phase margin that we have in the CARM and DARM loops.  DARM seemed to be the most obnoxious loop last night, so I focused on that today, although the CARM and DARM loops are pretty much identical.

(Q tells me via email that the phase budget has the same ~14 degree discrepancy between what we expect and what we measure as his estimate last night.  However, the Caltech network issues prevented his posting an elog.)

So, we definitely need to figure out where this 14 deg is going, but for now, I wanted to see if I could recover a couple of extra degrees just by modifying the filters.

The original filters do seem to eat a lot of phase:

DARM_design_orig.pdf

The short version of the story is that I didn't leave the filters changed at all.  I reverted back to the last version of the filter file from Monday night, so currently everything is as it was.

I tried increasing the Q of the zeros on the cyan and brown filters, which would sacrifice some gain at ~20 Hz, but hopefully win us 10+ degrees of phase.  This gave me a dip of about a factor of 2 between the new and old filters (all servo filters combined added up to this factor of 2 in magnitude) between ~20Hz - 70Hz. 

When we were locked using DARM for just the Yarm (for the UGF servo commissioning), I took a spectra of the error signal (which was POY) as a reference, then loaded in my new filters.  For the most part, the spectra didn't change (which is good, since the magnitude of the filter didn't change much.).  The spectra was bigger though between 50-70Hz, in kind of a sharp bandpass-looking shape that I wasn't expecting.    I don't know exactly why that's happening.

Anyhow, we tried the new filters once or twice with the full IFO, but kept losing lock.  Since I clearly haven't put in enough thought yet for these (particularly, how much suppression do we really need? what are our requirements???), I reverted back to the filter file from last night.  We continued locking, and checking out the new UGF servo that Diego is elogging about.

  14703   Wed Jun 26 20:45:03 2019 gautamUpdateCamerasField of view options

For the beam spot position tracking, I am wondering if there is any benefit to going for a wider field of view and getting the OSEMs in the frame? It may provide some "anchor points" against which whatever algorithm can calibrate the spot position against. But there are also several point scatterers visible in the current view, and perhaps the Gaussiam beam profile moving over them and tracking the scattered intensity from these point scatterers serves the same function? I don't know of a good solution to have a "switchable" field of view configuration in the already cramped camera enclosure though.

Also, I think it may be useful to have a cron job take a picture of MC2 and archive it (once a week? or daily?) to have some long term diagnostic of how the scattered light received by the camera changes over several months.

Quote:

The GigE is focused now and I have closed the lid. I'm attaching a picture of the MC2 beam spot, captured using GigE at an exposure time of 400µs

  10474   Tue Sep 9 00:34:34 2014 JenneUpdateLSCFiguring out where to do DARM->AS55

This afternoon, after Q and Manasa finished recovering from the activities of the morning, I aligned the IFO, and went to the Yend to touch up the alignment of the green to the arm.  I don't know if it was the alignment (I didn't do the PSL table), or I happened to have a good combination of laser temperatures, or what, but the Yend ALS noise was super good.  After that, the low frequency noise contribution is different lock-to-lock, and I haven't discerned a pattern yet.

One thing that we want to try is to get DARM to AS55 so that we're entirely off of ALS (assuming we've already gotten CARM to sqrtInvTrans).  However, according to Q's simulations, we have to get past arm power of a few before we are within the AS55 linewidth.  I have a DTT running showing me the phase between AS55 and ALSdiff as I reduce the CARM offset, but I haven't been able to get close enough to see the sign flip when CARM is on sqrtInvTrans.  If I just sweep through with both CARM and DARM on ALS, I see the sign flip.  I've tried a few different things, but I have not successfully gotten a transition to AS55 while the arm powers were above 1.  Empirically,  I think I want them at at least 3 or 4.

Koji suggested locking the DRMI rather than PRMI, to widen the AS55 linewidth, but I haven't tried that tonight.  Maybe tomorrow night.

I have made a ruidimentary lockloss plotting script, that I have put in ..../scripts/LSC/LockLossData, but I'm not satisfied with it yet.  Somehow it's not catching the lockloss, even though it's supposed to run when the ALS watch/down scripts run.  I'll need to look into this when I'm not so sleepy.

Q, can you please work on figuring out the phase tracker gain tracker?  It will be nice to have that functional so we don't have to fret about the phase tracker gains. 

Manasa, can you please estimate what kind of mode matching we have on the PSL table between the arm greens and the PSL green?  We *do not* want to touch any optics at this point.  Just stick in a power meter to see how much power we're getting from each beam, and then think about the peak height we see, and what that might tell us about our mode overlap.  If we determine it is total crap, we can think about measuring the beams that go either toward the camera, or the DC PDs, since neither of those paths require careful alignment, and they are already picked off from the main beatnote path.  But first, what is our current efficiency?  Yarm is first, then Xarm, since Yarm seems worse (peak height is larger for non-00 modes!)

  10478   Tue Sep 9 14:25:46 2014 jamieUpdateLSCFiguring out where to do DARM->AS55

Quote:

I have made a ruidimentary lockloss plotting script, that I have put in ..../scripts/LSC/LockLossData, but I'm not satisfied with it yet.  Somehow it's not catching the lockloss, even though it's supposed to run when the ALS watch/down scripts run.  I'll need to look into this when I'm not so sleepy.

We developed a fairly sophisticated lockloss script at the sites, which you could try using as well.  It's at:

USERAPPS/sys/common/scripts/lockloss

It requires a reasonably up-to-date install of cdsutils, and the tconvert utility.  It uses guardian at the sites to determine when locklosses happen, but you can use it without guardian by just feeding it a specific time to plot.  It also accepts a list of channels to plot, one per line.

  5128   Fri Aug 5 20:44:26 2011 jamieMetaphysicsTreasureFilm crew here Monday morning

Just a reminder that a film crew will be here Monday morning, filming Christian Ott for some Discovery channel show.

They are slated to be here from 8am to 12:30pm or so.  They will take a couple of shots inside the lab, and the rest of the filming should be of Christian in the control room (which they will "clean up" and fit with "sexy lighting").  I will try to be here the whole time to oversee everything.

  7092   Mon Aug 6 17:15:15 2012 JenneUpdateASSFilter banks not working

I was trying to load some filters into the ASS so that I can try it out, but for some reason the filter banks aren't working - clicking the on/off buttons doesn't do anything, filters (which exist in the .txt file generated by foton) don't load.

I've emailed cds-announce to see if anyone has any ideas.

  7099   Tue Aug 7 00:22:10 2012 JenneUpdateASSFilter banks working

Quote:

I was trying to load some filters into the ASS so that I can try it out, but for some reason the filter banks aren't working - clicking the on/off buttons doesn't do anything, filters (which exist in the .txt file generated by foton) don't load.

I've emailed cds-announce to see if anyone has any ideas.

 

When the network / fb went bad this afternoon, I had been working on the ASS model, shortening the names of the filter banks to fix the problem from elog 7092.  I wanted to finish working on that, so the ASS model is now rebuilt with slightly shorter names in the filterbanks (which fixes the problem of the filter banks not working).

------------------------------------------------------------

I mentioned this to Jamie the other day, but here's the error that you get when the GoTo/From tags aren't working:

>>rtcds make c1ass
### building c1ass...
Cleaning c1ass...
Done
Parsing the model c1ass...
IPC 9 8 is C1:LSC-ASS_LSC
IPC 9 8 is ISHME
IPC 10 9 is C1:RFM-LSC_TRX
IPC 10 9 is IPCIE
IPC 11 10 is C1:RFM-LSC_TRY
IPC 11 10 is IPCIE

INPUT XARM_LSC_in is NOT connected

INPUT YARM_LSC_in is NOT connected

***ERROR: Found total of ** 2 ** INPUT parts not connected

make[1]: *** [c1ass] Error 255
make: *** [c1ass] Error 1

I don't know why these tags weren't working, but there was a GoTo tag on the output of the LSC shmem block, and then Froms on each of the XARM_LSC_in and YARM_LSC_in.  The other day I played around with a bunch of different things (grounding inputs, terminating outputs, whatever), but finally replacing the tags with identical ones freshly taken from CDS_PARTS made it happy. 

  5730   Mon Oct 24 19:48:16 2011 MirkoUpdateAdaptive FilteringFilter execution time

Toyed around some more with the adaptive filters.

Execution time:

nTaps    Downsampling factor     Execution time average / max in ca. 3 min [us], (480 us available)
1000     16                                110 / 150
2000     16                                280 / 340
3000     16                                380 / 470
4000     16                                Over limit

Now we are running with Downsampling 32, 4000 Taps => max 410us execution time.

I tried to desynchronize the downsampled operations of the filters of the different DOFs. That however increased execution time by about 10%. So I undid that.

 

  3802   Thu Oct 28 02:01:51 2010 KevinUpdatePSLFilter for 2W Laser

[Rana and Kevin]

I made a low pass filter for the piezo driver for the 2W laser that is now installed. The filter has a pole at 2.9 Hz. The transfer function is shown in attachment 1.

Attachment 2 shows the outside of the filter with the circuit diagram and attachment 2 shows the inside of the filter.

Attachment 1: tf.PDF
tf.PDF
Attachment 2: outside.jpg
outside.jpg
Attachment 3: inside.jpg
inside.jpg
  3707   Wed Oct 13 17:12:33 2010 josephb, yutaUpdateCDSFilter name length problem found and fixed

The missing filter files for ULPOS, URPOS, and so forth for the mode cleaner optics was due to the length of the names of the filters. 

This was not a problem for the c1sus model because it was using its own name as the first 3 letters of its designation.  A filter for the sus model would be called something like BS_TO_COIL_MTRX_0_0, while for the mcs it would be called SUS_MC1_TO_COIL_MTRX_0_0, an extra 4 characters.

However, the c1mcs model used the "top_name" feature which uses a subsystem box within the simlink model to rename all the channels.  Apparently in the filter file, this means it has to add the top name to the front of everything, adding an additional 3 characters.  This pushed things over the length limit.

A hard cap of 18 characters has been added to the FiltMuxMatrix.pm file (located in /cvs/cds/caltech/c1/, so that it will prevent this type of problem in the future by stopping at compile time and presenting a helpful error message.

I also fixed a bug with too many spaces in the feCodeGen.pl file when dealing with top_names and the filtMuxMatrix.pm preventing some .adl files from being generated.

Also of interest, MC3 appears to never have had F2A filters.  For the moment we're running without them, but since they're just a fine tuning it shouldn't affect locking tonight.

 

Improbability factor of mode cleaner suspensions working tonight: ~20

 

  995   Fri Sep 26 00:19:54 2008 JenneUpdatePSLFilter-action with the PMC
Written, but not posted on 24Sept2008:



PMC adventures for this evening



Today's mission was to make more progress on increasing the bandwidth of the PMC servo.



First order of business was to improve the performance of the 14.6kHz notch that Rana put in the PMC servo board a few weeks ago to remove the 14.6kHz body mode resonance of the PMC. Looking at the zoomed in TF that I posted Monday (elog #978), we see that there is still a remnant of a peak near 14.5kHz. A first gut-reaction is that the notch is not tuned properly, that we have just missed the peak. As previously noted in the elog, the peak that we are trying to notch out is at 14.68kHz (elog #874). By unlocking the PMC and measuring the transfer function between FP2 and OutMon (OutMon is the monitor for the high voltage going to the PMC's PZT), I measure the transfer function of the notch, and find that it is notching at 14.63kHz. So we're a teensy bit off, but the Q of the notch is such that we're still getting improvement at the peak frequency. After checking that we are hitting the correct frequency, I put a short (just some wire) around R21, which is the R in the RLC notch filter, to increase the depth of the notch. At the peak frequency of 14.68kHz, we see a 2.5dB improvement of the notch. At the actual notch frequency of 14.63kHz, we see a 3.2dB increase in the depth of the notch. So, shorting R21 helped a little, but not a lot. Also, it's clear that we don't get that much more improvement by being on the resonant frequency, so there's no need to go in and tune the notch on the board.



Second order of business was to investigate the 18.34kHz peak in the transfer function. (Rana spent some time Monday night measuring this peak, and determined that it was at 18.34kHz) We decided that the best plan was to re-implement the Pomona Box notch filter that had previously existed to remove a higher frequency body mode, but tuned for the 18.34kHz mode. I am still not entirely sure what this mode is, but clearly it's a problem by about 20dB (on the TF, the next highest peak is 20dB below the 18.34kHz peak). Unfortunately, while the components should, by Matlab calculations, give me an 18.3kHz notch, I ended up with something like a 21.7kHz notch. This notch is approximately -30dB at 21.7kHz, and -20dB at 18.3kHz. I still need to take transfer functions and power spectra of the PMC servo with this new filter in place to (a) confirm that it did some good, and (b) to determine how important it is that the notch be right-on. More likely than not, I'll take the filter out and fiddle with the capacitors until I get the correct notch frequency.



Third on the list was to lock everything back up (FSS, PMC) after my tinkering, and see what kind of gain we get. Rob and I fiddled with the PMC gain, and it looks like the servo oscillates just before we get up to the max slider gain of 30dB. Looking at the power spectra in DTT, we do not see any significant peaks that suggest oscillation, so it is likely that there is some investigation to be done at frequencies above the 7kHz that we were able to look at with DTT (which isn't surprising, since all of this work has been at 14kHz and higher).



A final note is that we see a feature around 9kHz in the transfer function, and it is not at all clear where it comes from. At this time, it does not seem to be the dominant feature preventing us from increasing the gain, but at some point if we want the bandwidth of the PMC servo to be 10kHz, we'll have to figure this one out.



Still on the PMC todo list:


  • Measure the new transfer function, see if 18.34kHz peak is reduced

  • Tune Pomona Box notch filter to 18.3kHz instead of the current 21.7kHz

  • Retake power spectra of different items on top of PMC, compare to see if there is any one configuration that it obviously better than the others.

  • Find out why the PMC still oscillates when we try to take it up to the max slider gain, and fix it.

PS, is anyone else having trouble getting to the elog from laptops on other parts of the Caltech network (but not LIGO network)? My laptop won't go to the elog, but I can get to the rest of the internet using the Caltech wireless. My computer stopped seeing the elog on Tuesday or so. Joe, do you have any inspiration? Thanks.
  522   Fri Jun 6 11:19:13 2008 CarynSummaryPEMFiltering MC_L and MC_F with PEM:ACC and microphone
Tried to filter MC_L and MC_F with acc/seis data and microphone data using wiener filter (levinson)

-Used get_mic_data.m and miso_filter_lev.m to make SISO filter for 2 minutes of IOO-MC_F data. Used PEM-AS_MIC signal as noise input data. Filters calculated at initial time were applied to later data in 1 hour intervals.
-microphone filter did not seem to filter MC_F very well in high frequency range using this filtering procedure.
-residual is larger than est (see MC_F pdf)
-Used do_all_time_lev.m to make graph of max(rms(residual)) to N(order) for different times.(note for each N, filter was calculated for initial time and then applied to data at other times).
-relation of max(rms(residual)) to N(order) is time sensitive (note-on graph, time interval is 1hour) (see MC_F pdf)
-Presumably, max(rms(residual)) should decrease as N increases and increase as time increases since the filter probably becomes worse with time. I think the reason this isn't always true in this case is that the max(rms(residual)) corresponds to a peak (possibly a 60Hz multiple) and the wiener filter isn't filtering out that peak very well.


-Used get_z_data.m and miso_filter_lev.m to make MISO filter for 2 minutes of IOO-MC_L used the following signals as noise input data
PEM-ACC_MC1_X
PEM-ACC_MC2_X
PEM-ACC_MC1_Y
PEM-ACC_MC2_Y
PEM-ACC_MC1_Z
PEM-ACC_MC2_Z
PEM-SEIS_MC1_Y
-Filter was applied to later data in 2hour intervals.
-Used do_all_time_lev.m to make graph of max(rms(residual)) to N(order) for different times.(note for each N, filter was calculated for initial time and then applied to data at other times).
-acc/seis filter seemed to filter MC_L OK for 128,256,512Hz srates. 64 Hz wasn't ok for certain N's after a period of time.
-residual is smaller than est for srates not 64Hz (see MC_L pdf)
-residual is larger than est for 64Hz at N=1448 for later times (see MC_L pdf)
-relation of max(rms(residual)) to N is not as time sensitive for higher sample rates (note-on graph, time interval is 2hours) (see MC_L pdf). Perhaps the levinson 64Hz sample rate filter doesn't do as well as time passes for these signals. When the filter didn't do well, the max(rms(residual)) seemed to increase with N.
-For 512Hz sample rate filter the max(rms(residual)) decreased with time. If the max(rms(residual)) were an indication of filter performance, it would mean that the 512Hz filter calculated at the initial time was performing better later as hours passed by! Perhaps max(rms(residual)) isn't always great at indicating filter performance.

Programming notes
-I had to modify values in do_all_time_lev.m to get the program to loop over the srates,N's,times I wanted
-do_all_time_lev.m is not as clean as do_all_lev.m
-for making the plots do_all_lev.m (which isn't really a procedure and is messy) has some examples of how to plot things from do_all_time_lev.m.
Attachment 1: MC_F.pdf
MC_F.pdf MC_F.pdf MC_F.pdf
Attachment 2: MC_L.pdf
MC_L.pdf MC_L.pdf MC_L.pdf MC_L.pdf MC_L.pdf MC_L.pdf MC_L.pdf MC_L.pdf
Attachment 3: miso_filter_lev.m
function [s] = miso_filter_lev(N,srate,rat,z)
%MISO_FILTER_LEV(N,srate,z) uses miso_firlev to get levinson
%   FIR Wiener filter of order N-1, using impulse response of 
%   N/srate. z is a structure gotten from the get_data function. 
%   z(end) is the signal which is filtered using z(i) for all i.
%   'rat' is the fraction of z which will be put into filter
%   funtion. The data from z is downsampled using srate and 
%   detrended. Let rat=1. I don't have that part working yet.


... 107 more lines ...
Attachment 4: get_mic_data.m
function[z,t0,duration]=get_mic_data(t,d_t,d)
%get_mic_data gets data for'C1:IOO-MC_F', 'C1:PEM-AS_MIC,
% Example:  z = get_mic_data('now',120,60)
%  start time is 't- d_t' so  d_t should be given in seconds. t should be given
%  as a number like 893714452. d is duration in seconds. get_mic_data saves
%  data to a file in current directory named 'temp_mic'. You will be asked to
%  save file as 'mic_(start_time)_(duration)'.

duration = d;

... 32 more lines ...
Attachment 5: do_all_time_lev.m
function[r] = do_all_time_lev(n,t0,int,duration,N,srate,rat,order,time,MC_L,MC_F,sample_rate)
%do_all_time explores how filter performance changes with time, sample rate,
%and order of filter. Outputs data,noise estimate, structure of max
%rms error and other info. It uses get_data, miso_filter_lev, and miso_filter_int and retrives
%MC_Ldata or MC_Fdata for multiple times, calculates a miso_filter for initial-time data
%file, applies filter to the other data files, and keeps track of the...
%max(rms(residual)) for each filter. n+1 is number of data files. int is time interval between
%data files, t0 is start time, duration is duration of each data file, srate
%is the sample rate for which filter is calculated, n_N is number of orders
%of the filter you want the program to calculate,int_N is interval by which N
... 215 more lines ...
Attachment 6: do_all_lev.m
function[r] = do_all_lev(n,t0,int,duration,n_N,int_N,n_srate,int_srate,rat,MC_L,MC_F)
%do_all_lev explores how filter performance changes with time, sample rate,
%and order of filter. Outputs data,noise estimate, structure of max
%rms error and other info. It uses get_data, miso_filter_lev, and miso_filter_int and retrives
%MC_Ldata or MC_Fdata for multiple times, calculates a miso_filter for initial-time data
%file, applies filter to the other data files, and graphs the rms of the cost
%function vs time. n+1 is number of data files. int is time interval between
%data files, t0 is start time, duration is duration of each data file, srate
%is the sample rate for which filter is calculated, n_N is number of orders
%of the filter you want the program to calculate,int_N is interval by which N
... 283 more lines ...
Attachment 7: do_all_plot.m
function[r] = do_all_plot(r,x,v)
 %do_all_plot plots variables contained in r(structure from
 %do_all_time_lev).Plots error(r.B.y) vs x. x can be
 %'s'(srate),'N'(order),'t'(time),'p'(impulse response). v can be 's','N','t'. 
 %example: do_all_plot(r,'s','t') makes a plot of error vs srate for
 %different times.

kk=1

err_N_srate=0
... 388 more lines ...
Attachment 8: miso_filter_int.m
function [s] = miso_filter_int(s,y)
%miso_filter_int inputs a filter and a structure array of data sets y, applies filter to data, and
%outputs a structure with fields: ppos(signal frequ spectrum),perr(cost
%function frequ spectrum),pest(signal estimate frequency
%spectrum),f(frequency),target(signal),est_darm(noise estimate),t(time).
%data file for which filter has been calculated is s (obtained using miso_filter). 
%y consists of data structures which will be filtered using
%filter from s. Then the power spectrum of the difference between signal and filtered-data is
%graphed for all the data files of y for comparison too see how well filter performs
%over time. Note if you want to create a y, take z1,z2,z3,etc. structures
... 120 more lines ...
  6049   Wed Nov 30 02:04:26 2011 rana, den, jenne, kiwamu, jzweizigUpdateCDSFiltering Noise issue tracked down ???

 You can read through all of our past tests to see what didn't work in tracking things down. As Den mentions, there was actually a lot of evidence that there was some double->single precision action in the filter calculation causing the noise we saw.

However, it turns out that this is NOT the case.

This afternoon I was so confused that I enlisted JZ to help us out. He came over and I tried to replicate the error. When looking at the time series, we noticed that it wasn't random noise; the signals seem to be getting clipped as they crossed zero. Sort of like a stiction problem. JZ left to go replicate the error on an offline system.

This turned out to be the important clue. As we examine the code we find this inside of fm10Gen.c:

if((new_hist < 1e-20) && (new_hist > -1e-20)) new_hist = new_hist<0 ? -1e-20: 1e-20;

this is line is basically trapping the filter history at 1e-20, to prevent some kind of numerical underflow problem (?). Seems reasonable, except that some filters which have higher order low passing in them actually have an overall scale factor which can be small (even as small as 1e-23, as Den pointed out).

So the reason we saw such weird behavior is that the first filter in SUSPOS is an AC coupling filter. This takes the OSEM signal and remove the large mean value. Then the next filter multiplies it by 1e-23 before doing the filtering and you end up with this noise in the filter history.

I looked and this line is commented out in the new BiQuad code, but as far as I can tell this issue has been around in aLIGO, eLIGO, iLIGO, etc. for a long time and could have been causing many cases of excess noise whenever we ended up a tiny gain factor in an IIR filter. At the 40m, there are easily a hundred such cases.

For now, I suppose we can just change this number to 1e-40 or so. I don't know how to calculate what the right number should be. Not sure why this underflow is not an issue for the BiQuad, however.

  6051   Wed Nov 30 11:04:26 2011 josephbUpdateCDSFiltering Noise issue tracked down ???

Quote:

For now, I suppose we can just change this number to 1e-40 or so. I don't know how to calculate what the right number should be. Not sure why this underflow is not an issue for the BiQuad, however.

According to the RCG SVN logs, the reason it was removed was a more general change done to the compiled code, not specific to just the biquad.  Basically, the ability to have an underflow number (subnormal) has been turned off completely by having any number that underflows set to zero. I'm not positive, but from a quick search looks that the smallest number before hitting is an underflow as a double is 2.2250738585072014e-308.

Alex's entry from the SVN log for 2663:

Added new fz_daz() function to turn on two bits in the FPU SSE control register.
Bits FZ (flush underflows to zero) and DOZ (denorms are zeros) are set to
avoid runaway code on float/double denorms (really small numbers).
Ref: http://software.intel.com/en-us/articles/how-to-avoid-performance-penalties-for-gradual-underflow-behavior/

SVN log 2664:

Removed +- 1e-20 limiting code, this is taken care of by setting FZ/DOZ bits
in the CPU SEE control register (see mathInline.h)

SVN log 2665:

Kill the underflows and roll down float denorms to zero,
see fz_doz() in mathInline.h.

ELOG V3.1.3-