40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 246 of 329  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  5045   Wed Jul 27 12:31:47 2011 Manuel, IshwitaSummaryPEMWeekly summary

We kept reading about digital filtering

We tested the seismometer last friday

Jan came and tested again the seismometer last monday

We wrote a simulation of the stacks transfer functions, and of the distance between the mirrors.

 

  5106   Wed Aug 3 12:24:08 2011 Manuel, IshwitaUpdateWienerFilteringWeekly summary

Last Friday (Jul 29) we reinstalled the blue breakout box, and changed the names of the C1:PEM channels. Elog Reference

We continued the work on the simulation ad applied wiener filter on the simulated ground motion, but the result is unsatisfactory, yet. We will post reasonable results soon.

We did wiener filtering for the first time on real data from the Xarm while it was locked. Elog Reference

  5170   Wed Aug 10 12:33:34 2011 Manuel, IshwitaSummaryPEMWeekly summary

We got the results of the wiener filtering simulations (Elog Entry)

We got the power spectra and coherence of the seismic noise measurements from GURALPs and STS seismometers (Elog Entry)

We tried to whiten the target and the input signal for the computation of the wiener filter for the real data, but the results are unsatisfactory. We should not care about high frequencies in wiener filter computation so we will just filter them off in the filter output with a low pass filter.

We just found the right gain for the system seismometer-AAboard-ADC (Elog Entry)

  7118   Wed Aug 8 11:47:52 2012 YaakovSummarySTACISWeekly summary

As Rana pointed out (http://nodus.ligo.caltech.edu:8080/40m/7112), the geophone/accelerometer noise lines from my last eLog (http://nodus.ligo.caltech.edu:8080/40m/7109) were dominated by ADC noise. I checked this today by terminating the ADC channels with 50 Ohm terminators and measuring the noise. The ADC noise line is included on the plot below, and it is clearly dominating the sensor noise data.

budget_with_adc.pngbudget_with_adc.fig

I set the accelerometer gain to 100, and will hook up the geophones to the SR560 pre-amp today- this should put both signals above the ADC noise, and I can calculate the sensor noises without the ADC noise being significant.

I have also begun to make some progress in understanding the pre-amp circuitry, and I will post a schematic when I've sketched it all.

Another issue that seems increasingly relevant to me is the power supply to the high voltage amplifier. It appears to go into the high voltage board from the power supply, then into the geophone pre-amp, then back into the high voltage board (see block diagram below). I tested this by inputting a signal after the pre-amp, with the geophones disconnected- the signal only drives the PZT if the pre-amp is plugged in, so the power that returns from the pre-amp must be powering some chips on the high voltage amplifier.

 

Power flow through the STACIS :

power_diagram.png

This is somewhat inconvenient, because it means if I want to provide external feedback (with accelerometers, for example) or actuation (such as feedforward), which I want to input after the geophone pre-amp, the pre-amp still needs to be plugged in for the high voltage amplifier to work and drive the PZTs.  I am cataloging all of the pins on the high voltage amplifier and pre-amp so I can figure out how to reroute the power and cut out the geophone pre-amp entirely if necessary. I'll include a pin diagram with the pre-amp circuit sketch.

  720   Wed Jul 23 10:47:05 2008 SharonUpdate Weekly update
This week I spent some time with Alex who updated the adaptive code to save the filter's coeffs all the time, stop when I open the loop, and reload the latest coeffs. when I start it again.
The point was to minimize the adaptation rate. Unfortunately, seems it is making some filters go wild, so it is not in use yet.
After taking some more measurements with the adaptive filter running, I have noticed a new peak in the signal around 22-23 Hz. My first assumption was that this is caused due to internal resonance of MC1 (which is driven when the adaptive code is running, and not when it's not). Therefore, I drove MC1 without the adaptive filter looking for the same peak... which wasn't there.
This sent me back to the adaptive code... Seems there is a matrix in the simulink file of the adaptive filter which doesn't have an MEDM screen. I am now working on making this screen. Once I am done with that, and make sure there is correlation between simulink and MEDM, I'll keep on chasing the peak in the code.
  765   Wed Jul 30 12:36:19 2008 SharonUpdate Weekly update
This week included many computer's issues. I tested Alex's new C code (the one that saves the FIR coefficients and restores them when you start running the code again). Seems there is an improvement in the adaptation time, but not a significant one (more details on the coming report). I had to recompile simulink and the FB whenever I wanted to find a solution for taking the record of those coefficients. This is so I could simulate the adaptive filter with a regular IIR filter and compare the two.
After Rob tried to help and it seems to be an impossible to a huge hassle mission, we thought of a different method to do this. I re-compiled the old simulink file and restored the .ini file and all should be back in place. Instead of finding the FIR coefficients, I am going to use one noise source in the adaptive filter, stop the adaptation (by setting mu and tau to 0), and put excitation instead of the noise signal. The transfer function I will get between the exc. and MC1_IN1 is the filter I am looking for.

Also seems that whenever I get the MC unstable, and the adaptive code stops itself, it doesn't come back. Setting the reset flag to a different number (anything other than 0) and pressing the reset button will get it working again, but the CPU will always flip and the ASS computer needed a restart. Still haven't found a problem in the C code, but that's the plan. Moreover, I want to change Alex's code, so that instead of starting from zero like in Matt's code, or starting from the old coefficients like in Alex's, it is going to calculate a Wiener Filter as the first set of coefficients. This will hopefully reduce the adaptation time.

I have also been working on my progress report, and stood in line for the MC... Still standing...
  3146   Wed Jun 30 12:20:49 2010 RazibUpdatePhase CameraWeekly update

This week I have completed following tasks:

1. Worked out the analytical expressions for the amount of power of the DC and oscillatory part going into the camera.

2. Realigned the He-Ne PhaseCam setup as we had to replace the first steering mirror after the laser with a silvered mirror ( one without a dielectric coating for 1064 nm).

3. Gone through the code written by a previous surfer (Zach Cummings).

4. Read the paper 'Real-time phase-front detector for heterodyne interferometers'- F. Cervantes et. el. where they talk about constructing a phase detector for LISA pathfinder mission. One interesting fact I found was that, they used InGaAs chip for their CCD Cam which has a amazing QE of 80% @ 1064 nm. Unfortunately, the one we are using (Micro MT9V022 CMOS) has only ~5% QE for 1064 nm and 50% for 633 nm. One top of it MT9V022 has a built-in infra-red filter infront of it to make it more insenstive to 1064. In such limitations, we may have to find a work-around for this issue. Any idea?

5. Read about the EOM and AOM and their vibrating (!) way to add on and alter the incident light on them. (Source: Intro to Optical Electronics-Yariv)

 

One task that we couldn't accomplish even though I planned on doing is:

1. Move,if possible, to the Nd:YAG setup.

 

Task for this week:

1. Produce breathtaking calibration of the camera at He-Ne setup.

2. Read 'Fringe Analysis'-Y.Surrel and 'Phase Lock Technique'-Gardner.

3. Modify the phasecam code.

4. Produce an alternate triggerbox using diodes instead of Op-Amp as op-amp is suspected to fail at some point driving the camera due to impedance mismatch.

5. Answer Koji's question at Aidan's ELOG .

  3167   Wed Jul 7 12:17:36 2010 RazibUpdatePhase CameraWeekly update

I have completed the following tasks:

1. Find a simplified calibration of the exposure time for the current He-Ne setup. Basically, I triggered the camera to take 20 snapshots with a 20 Hz driving signal at different exposure time beginning from 100 us (microsecond) upto 4000 us with an increment of 200 us.

    Result: The current power allows the camera to have an exposure time of ~500 us before the DC level begans to saturate.

2. Aidan and I did some alignment and connected the AOM and corrected the driving frequency of its PZT to 40 Mhz(which apparently was disconnected which in turn gets the credit of NO beat signal for me until Tuesday 07/06/2010 5:30 PST) .

    Result: I got the beat signal of 1 Hz and 5 Hz. Image follows (the colormap shows the power in arbitrary units).

3. Finished writing my Progress Report 1 .

DC_1Hz_beat_sig.jpgDC_5Hz_beat_sig.jpg

Attachment 1: DC_1Hz_beat_sig.jpg
DC_1Hz_beat_sig.jpg
  3187   Fri Jul 9 12:07:26 2010 RazibUpdatePhase CameraWeekly update

Here are some more details about the current phasecam setup. We are using a He-Ne laser setup

phase_cam_setup_09_08_10.jpg

A crude snap shot of the setup....

mod_setup_(copy)_annotated.jpg

 

We sent light through SM2 (Steering Mirror 2)  to BS1(Beam-Splitter 1) where the laser light is split into two parts, one going to the AOM and the other to the EOM. The EOM adds 40 MHz sidebands to the incoming carrier light after SM3, and the AOM shifts the frequency of the incident light on it to 40.000 005 MHz. The purpose for doing this juggling is to intentionally create a beat signal off the reference beam from the AOM with the sidebands added at the EOM. Note that, we are driving the AOM at 7dBm and the EOM at 13 dBm with 0 (nil) modulation. The two lights are combined at the BS2 and sent off through SM5 to the camera. The CMOS of the camera contains silicon based Micro MT9V022 chip which has a quantum efficiency of 50% at 633 nm. Thus we expected a fairly good response to this He-Ne setup from the camera. 

Using a trigger circuit, we triggered the camera at 20 Hz by sending a 20Hz sinusoidal signal to it. The trigger circuit converts this to a positive square waves. Then I roughly figured out the optimum exposure time for the camera before the DC levels saturates it by writing a code for taking a series of 25 images at different exposure time. I found that 500µs seems to be a reasonable exposure time. So, using this data, I took 20 consecutive images and sent them through a short Fourier Transform segment using Matlab to see the beat signal. Note that the DC component from these processing of the images have some fringe pattern which is due to the ND 2.5 filter that we were using to reduce the light power incident on the camera. The FT method also gave us the presence of the beat signal at the corresponding bin of the FT (for example: for 5Hz beat signal, I got the DC at bin 1 of the FT and 5Hz component at bin 6 as expected). Then I changed the AOM driving frequency to 40.000 001 MHz in order to see a 1 Hz beat signal. The results for both is in my previous post. 

Quote:

I have completed the following tasks:

1. Find a simplified calibration of the exposure time for the current He-Ne setup. Basically, I triggered the camera to take 20 snapshots with a 20 Hz driving signal at different exposure time beginning from 100 us (microsecond) upto 4000 us with an increment of 200 us.

    Result: The current power allows the camera to have an exposure time of ~500 us before the DC level begans to saturate.

2. Aidan and I did some alignment and connected the AOM and corrected the driving frequency of its PZT to 40 Mhz(which apparently was disconnected which in turn gets the credit of NO beat signal for me until Tuesday 07/06/2010 5:30 PST) .

    Result: I got the beat signal of 1 Hz and 5 Hz. Image follows (the colormap shows the power in arbitrary units).

3. Finished writing my Progress Report 1 .

DC_1Hz_beat_sig.jpgDC_5Hz_beat_sig.jpg

 

  3217   Wed Jul 14 12:12:03 2010 RazibSummaryPhase CameraWeekly update

This week I was mainly interested in investigating the noise source at the phase camera. So having this issue in mind, my activities are the following:

1. I worked on producing multiple beat signal (1Hz and 5Hz). Elog entry.

2. I altered the setup so that instead of triggering the camera from the signal generator, we are now triggering it from the beat signal from the reference beam and sideband.

3. I made the nice little aluminium table for all the amplifiers, mixer and splitters to sit at one place instead of floating around.

4. I talked with Aidan and Joe and verified my calculation and extended it to further investigation of the noise source in the setup.

 

Plan for the upcoming week:

1. Measure and calibrate the camera w.r.t the power incident on it.

2. Investigate the noise source.

  3258   Wed Jul 21 12:20:58 2010 RazibUpdatePhase CameraWeekly update

This past week I have worked on the following:

1. Setting up the infrastructure to do noise analysis: We added a temporary channel on the DAQ to connect to the PD 55 which we are using to take the power measurement. Before that, I connected the PD55 to an oscilloscope and recorded the power.

    phase_cam_setup_21_07_2010.jpg

The power at PD55 as measured using the oscilloscope = 600 µV.

Then I tried to calibrate the channel by sending up a signal from the function generator and measuring up the offset.. However, the channels seems noisy enough, especially due to electronics noise as suggested by the measurements and FFT calculation.

2. I worked on trying to sync the data acquisition of the PD and the CAM. After sometime spent on fiddling with the software method such as taking images at stamped time and then lining them up with the daq timestamps, I found a hardware method as suggested by Aidan. It was putting up a shutter (Uniblitz shutter and driver VMMD1) in the setup. I synced the shutter with the camera for which I had to tear apart the previously made trigger box and add a sync output from the camera (took a while as I also had to make a new cable).

3. I worked (still working) on making a differential amplifier to blow up the signal from the PD.

 

 

 

  6988   Wed Jul 18 13:53:34 2012 YaakovUpdateSTACISWeekly update

I have been working on substituting the internal geophones in the STACIS with accelerometers, and this week specifically I have been trying to modify the accelerometer signal so the STACIS PZTs respond properly.

The major problem was that the high signal amplitude caused the STACIS to oscillate uncontrollably, so I lowered all of the pots (for the z direction) and placed several BNC attenuators before the accelerometer signal enters the first amplifier board. The accelerometers now successfully provide feedback without making the STACIS unstable, as shown by this transfer function (the higher and flatter line is open loop, the lower is closed loop with accelerometers providing feedback):

really_accelFeed.GIF

The next step is to optimize the accelerometer feedback so it provides good isolation from 0.1 to 3 Hz, a span that the geophones introduced a lot of noise into. The accelerometers definitely don't introduce as much noise in that region, but don't seem to be doing much isolation either. I will also make some more quantitative plots of the platform motion (using the calibration value for the Wilcoxon accelerometers in the velocity setting with a gain of 1).

Some random discoveries I made this week which are relevant for STACIS testing:

1) Placing weight on the STACIS platform improves stability, but NOT if several blocks are placed on top of each other (they rub against each other, causing lots of vibrations).

2) The accelerometer that is providing feedback must be VERY securely fastened to the STACIS platform; even with three clamps there was extra motion that caused instability. Luckily, there's a convenient steel flange Steve showed me which has a hole that perfectly accommodates the accelerometer and doubles as a weight for the platform. Here is said flange, clamped to the STACIS platform with the accelerometer sitting in the center:

flange.JPG

 3) Using the shaker next to the STACIS (all on one platform) improves coherence between the base and platform accelerometers above around 10 Hz, but does nothing lower than that, which unfortunately is the region I'm most concerned with.

  7027   Wed Jul 25 12:00:21 2012 YaakovUpdateSTACISWeekly update

The past few days I've been working on making a noise budget for the STACIS that incorporates all the different noises that might be contributing.

The noises I am concentrating on are accelerometer noise, geophone noise, electrical noise, and ground noise. Noise from the PZT stacks themselves should be tiny according to various PZT spec sheets, but I haven't actually found a value for it (they all just say it's negligible), so I'll keep it in mind as a potential contributor.

Here's how I am determining accelerometer noise: I take two vertical accelerometers side by side, sitting on a granite block and covered in a foam box, and take the time series of both. Then I take the difference of the time series and calculate the PSD of that, which with the calibration factor of the accelerometers (the V/m/s sensitivity) I am able to find the noise in m/s/rtHz. The noise agreed with the accelerometer specs I found at low frequencies but was higher than expected at high frequencies, so I'm still investigating. If I can't find an obvious problem with my measurements I'll try the three-corner hat method (as per Jenne's recommendation), which would allow me to determine the noises of the independent accelereometers.

I tried a similar method for the geophone noise, but the value I came up with was actually higher than the accelerometer noise, which seems very fishy. I realized that the geophones were still connected to the STACIS circuitry when I took the measurements ,which was probably part of the problem. So this morning I disconnected the STACIS entirely and am looking at just the geophone signals which should give a more accurate noise estimate.

Once I have all the noises characterized, the next step is seeing how those noises affect the closed loop performance of the STACIS. I've been working on a block model that incorporates the different noises and transfer functions involved, and when I have the noises characterized I can test a prediction about how a certain noise affects the platform motion.

 

  7251   Wed Aug 22 18:58:12 2012 JenneUpdatePEMWeird BLRMS increase

It seems as though there is something funny going on around ~1.5 Hz, starting a little over an hour ago.

We see it in the BLRMS channels, the raw seismometer time series, as well as in various suspensions and LSC control signals.  It's also pretty easy to see on the camera views of all the spots (MC, arms, transmissions....AS is a little harder to tell since it's flashing, but it's there too).

The plots I'm attaching are only for ~10min after the jump happened, but there has been no change in the BLRMS since it started.  Usually, we'd see an earthquake in all the channels, and even big ones ring down after a little while.  This is concentrated at a pretty narrow frequency (some of Den's plots for later have this peak), and it's not ringing down, so it's not clear what is going on.

Here is a whole pile of plots.  Recall that the T-240 is plugged into the "STS_3" channels, and we don't have BLRMS for it, so you can look at the time series, but not any frequency specific stuff.

Attachment 1: All_seis_time_series.png
All_seis_time_series.png
Attachment 2: Gur1X.png
Gur1X.png
Attachment 3: Gur1Y.png
Gur1Y.png
Attachment 4: Gur1Z.png
Gur1Z.png
Attachment 5: Gur2X.png
Gur2X.png
Attachment 6: Gur2Y.png
Gur2Y.png
Attachment 7: Gur2Z.png
Gur2Z.png
Attachment 8: STS1X.png
STS1X.png
Attachment 9: STS1Y.png
STS1Y.png
Attachment 10: STS1Z.png
STS1Z.png
  7253   Thu Aug 23 00:18:54 2012 JenneUpdatePEMWeird BLRMS increase
While I was gone for dinner break, the BLRMS went back to normal. Then, almost 2 hours later, another peak appeared, this time closer to 1Hz. Den noticed that it was hard to maintain any lock, since the optics were ringing up so much.

The MC was moving pretty significantly, and just to check, I turned off the WFS for a moment. The MC transmitted power was fluctuating by almost 50% until I turned the WFS back on.

Attached is a spectrum of the BS OSEM sensors. The higher frequency peak around 1.65Hz is from the time I posted the time series about earlier. The lower frequency peak around 1.15Hz is from the second interval of noise.

Now, the noise is gone, and things are back to normal (for now....)
Attachment 1: BS_OSEMsensors_higherFreqPeakIsOlder_LowerFreqPeakIsMoreRecent.pdf
BS_OSEMsensors_higherFreqPeakIsOlder_LowerFreqPeakIsMoreRecent.pdf
  8598   Fri May 17 18:58:58 2013 Jamie, KojiSummaryCDSWeird DAC bit flipping at half integer output values

While looking at the DAC anti-imaging filters, Koji noticed an odd feature of the DAC output:

sweep.pdf

What you see here is 16kHz double data from a model right before the DAC part ('C1:SUS-PRM_ULCOIL_OUT', blue), and the full 64kHz int data sent to the physical DAC as reported by the IOP ('C1:X02-MDAC0_TP_CH0', green).  The balls are the actual sample values (as expected there are four green balls for every blue).  The output data is being ramped continuously between 0 and 1.

As the output data crosses the half-count level, the integer DAC output oscillates continuously at every 64kHz sample between the bounding integer values (in this case 0 and 1).

Here's the data as we hold the output continuously at the half-count level; the integer DAC output just oscillates continuously:

const.pdf

After some probing I found that the oscillation happens between [-0.003 +0.004] of the half-count level.

The result of this is a fairly strong 32 kHz line in the DAC analog output.

We looked in the controller.c and couldn't identify anything that would be doing this.  This is the output procedure as I can see it (controller.c lines): 

  1. The double from the model is passed to the IOP
  2. The IOP applies a sample-and-hold or zero-pad if the model is running at a slower speed than the IOP (1799)
  3. The data is then anti-image filtered (1801)
  4. A half-integer is added/subtracted before casting such that the cast is a round instead of a floor (1817)
  5. The data double is cast to an int (1819)
  6. The data is written to the DAC (1873)

There's nothing there that would indicate this sort of bit flipping.

  8599   Fri May 17 19:56:52 2013 KojiSummaryCDSWeird DAC bit flipping at half integer output values

Let me make a complimentary comment on this effect.

Because of this oscillation feature, we have a 32kHz peak in the DAC spectrum rather than a 64kHz peak.

For advanced LIGO, the universal AI (D070081) was made to have 3rd-order 10kHz LPF with 64kHz notch.
If we have a higher peak at 32kHz (where the rejection is not enough) than at 64kHz, the filter does not provide
enough filtering of the DAC artifacts.

For the 40m, the original filter had the cut off of 7kHz as the sampling rate was 16kHz.
If we want to extend the frequency range by 4times, the correspoding cut off should be 28kHz.
The rejection is again not enough at 32kHz.

If this peak is an avoidable feature by using simple sample&hold the peak freq is pushed up to
64kHz and we can use the AI filters as planned.

  8613   Wed May 22 11:09:33 2013 JamieSummaryCDSWeird DAC bit flipping at half integer output values

After querying CDS folks about this issue, I got some responses that indicated the problems was likely limit-cycle oscillations due to zero-padding of the data when upsampling.  Tobin ran some Matlab tests to confirm this issue.

Starting in RCG 2.5 there is a new "no_zero_pad=1" cdsParameters option turns zero padding OFF.  I tried enabling this option c1scy to see how the behavior changed.  Sure enough, the 32 kHz oscillations mostly went away.  There are no oscillations for outputs held at the half-count value, and the oscillations around the half-count transitions went away as well.

The only thing I could see is a bit of oscillation when converging on a constant half-count value that went away after a couple of milliseconds:

nopad.pdf

So we might consider adding the no_zero_pad=1 option to all of our coil driver outputs, which might eliminate the need to add notches at the Nyquist in the analog anti-image filters

  8614   Wed May 22 11:21:28 2013 KojiSummaryCDSWeird DAC bit flipping at half integer output values

Is this limit cycle caused by the residual of the digital AI filtering at the half sampling freq and that his the threshold?
Or is this some nonlinear effect? If this is a linear effect associated with the zero-padding, the absolute
value of the DC may affect the amplitude of the oscillation. (Or equivalently the range of the DC where we get this oscillation.)

Anyway, it seems that we should use no-zero-padding.

You pointed out the ringdown of the digital AI filter in the sample-hold case (i.e. no-zero-padding case).
How does it look like in the conventional zero-padding case?

  8615   Wed May 22 11:35:06 2013 JamieSummaryCDSWeird DAC bit flipping at half integer output values

Quote:

Is this limit cycle caused by the residual of the digital AI filtering at the half sampling freq and that his the threshold?
Or is this some nonlinear effect? If this is a linear effect associated with the zero-padding, the absolute
value of the DC may affect the amplitude of the oscillation. (Or equivalently the range of the DC where we get this oscillation.)

This is a good question.  We may be able to test if it's a linear effect if we have enough DAC range to get the oscillation to be more than a single sample.

Quote:

You pointed out the ringdown of the digital AI filter in the sample-hold case (i.e. no-zero-padding case).
How does it look like in the conventional zero-padding case?

 In the zero-pad case the oscillation just continues indefinitely at the half-count value, so it never dies out (at least as far as I can tell).

  8616   Wed May 22 15:08:37 2013 KojiSummaryCDSWeird DAC bit flipping at half integer output values

It seems that the effect is from the (linear) residual fluctuation of the digital AI filter for the zero-padded signal.

Namely, if we give the larger constant number, we get more oscillation.

Attachment 1: Screenshot.png
Screenshot.png
  11682   Fri Oct 9 16:43:50 2015 ericqUpdateIOOWeird IMC behavior

A few minutes ago, Gautam and I were poking around the IOO rack, looking at where he should power his frequency divider box, and what ADC innputs to use. 

Looking at the mode cleaner signals, it looks like we may have jostled something in a good way. Weird. 

  16113   Mon May 3 18:59:58 2021 AnchalSummaryGeneralWeird gas leakagr kind of noise in 40m control room

For past few days, a weird sound of decaying gas leakage comes in the 40m control room from the south west corner of ceiling. Attached is an audio capture. This comes about every 10 min or so. 

Attachment 1: 40mNoiseFinal.mp3
  16115   Mon May 3 23:28:56 2021 KojiSummaryGeneralWeird gas leakagr kind of noise in 40m control room

I also noticed some sound in the control room. (didn't open the MP3 yet)

I'm afraid that the hard disk in the control room iMac is dying.

 

  13207   Mon Aug 14 20:12:09 2017 Jamie, GautumUpdateCDSWeird problem with GPS receiver

Today we saw a weird issue with the GPS receiver (EndRun Technologies Tempus LX).  GPS timing on fb1 (which is handled via IRIG-B connection to the receiver with a spectracom card) was off by +18 seconds.  We tried resetting the GPS receiver and it still came up with +18 second offset.  To be clear, the GPS receiver unit itself was showing a time on it's front panel that looked close enough to 24-hour UTC, but was off by +18s.  The time also said "GPS" vertically to the right of the time.

We started exploring the settings on the GPS receiver and found this menu item:

Clock -> "Time Mode" -> "UTC"/"GPS"/"Local"

The setting when we found it was "GPS", which seems logical enough.  However, when we switched it to "UTC" the time as shown on the front panel was correct, now with "UTC" vertically to the right of the time, and fb1 was then showing the correct GPS time.

From the manual:

Time Mode
Time mode defines the time format used for the front-panel time display and, if installed, the optional
time code or Serial Time output. The time mode does not affect the NTP output, which is always
UTC. Possible values for the time mode are GPS, UTC, and local time. GPS time is derived from
the GPS satellite system. UTC is GPS time minus the current leap second correction. Local time is
UTC plus local offset and Daylight Savings Time. The local offset and daylight savings time displays
are described below.

The fact that moving to "UTC" fixed the problem, even though that is supposed to remove the leap second correction, might indicate that there's another bug in the symmetricom driver...

  10945   Tue Jan 27 17:58:21 2015 JenneConfigurationTreasureWelcome, Donatella!

Welcome to your new abode, Donatella!

Attachment 1: IMG_1806.JPG
IMG_1806.JPG
  5585   Fri Sep 30 15:22:17 2011 KatrinUpdateGreen LockingWhat happened on green YARM?

 

This is a kind of summary of what I have worked on this week.

After all the changes made last week, I could not manage to lock the green light to the cavity, but the PDH error signal looks nicer.....at least something.

 

Alignment of the light to the cavity:

  • DC level of green PD when light is non-resonating 100%
  • DC level of green PD when light resonates 75%
  • --> Not sure if this alignment is good enough
  • In comparision to last week the cavity mirrors seem to move more or my alignment is way worse than last week. The bright spot on ETMY could not be observed for more than let's say a second in the unlocked configuration.

 

Low-pass filter (LPF)

  • The PDH error signal was covered with oscillations of 3.3 kHz, 7.1 kHz and 35 kHz.
  • Measured cut-off frequency of the LPF used so far is 35 kHz
  • Designed and build a new LPF: second order, cut of frequency of 1.1 kHz (this is just the design value, haven't measured that so far)
  • With the new LPF the PDH error signal is free of the above mentioned oscillations.
  • Impedance should be checked

 

PDH error signal

  • Signal-to-noise ratio (SNR) could be improved to values between 7.8 and 11.1 (old SNR was 5 to 7)
  • Looks more like a PDH signal than with the old LPF (now just derivative of the carrier and the first order sidebands show up)
  • Amplitude of the first order sidebands are smaller than the zero order, but are still too high (about 80% of the first order), need to work on the proper value of the LO amplitude an the voltage averager

 

Phase shift between green PD signal and LO

  • Phase shift is about 1MHz
  • Tried to find a capacity that compensates the phase shift. This was not successful since the PD frequency changed every now and than by +/- 20 kHz
  15080   Fri Dec 6 00:02:48 2019 gautamUpdateLSCWhat is the correct way to set the 3f offsets?

Summary:

I made it to 0 CARM offset, PRMI locked a bunch of times today. However, I could not successfully engage the AO path.

Details:

Much of the procedure is scripted, here is the rough set of steps:

  • Transition control of the arms from IR signals to ALS signals.
  • DC couple the ITM oplev servos
  • Burt-restore the settings for PRMI locking with REFL165I-->PRCL, REFL165Q-->MICH, and then enable the MICH_B / PRCL_B locking servos.
  • Add some POPDC to the PRMI triggering (nominally only POP22_I) to let these loops be locked while POP22_I fluctuates wildly when we are near the CARM=0 point.
  • Zero the CARM offset.
  • Adjust the CARM_A/DARM_A offsets such that CARM_B/DARM_B are fluctuating symmetrically about 0.
  • CARM_B gain --> 1.0, to begin the RF blend.
  • Prepare to hand the DC control authority to ALS by turning off FM1 in the CARM filter bank, and turning ON an integrator in the CARM_B filter.

As I type this out, I realized that I was incorrectly setting offsets to maximize the arm powers by adjusting CARM/DARM offsets as opposed to CARM_A / DARM_A offsets. Tried another round of locking, but this time, I can't even turn the integrator on to get the arms to click into somewhat stable powers. 

One thing I noticed is that depending on the offsets I put into the 3f locking loops, the mean value of REFL11 and AS55 when the ALS CARM/DARM offsets are zeroed changes quite significantly. What is the correct condition to set these offsets? They are different when locking the PRC without arm cavities, and also seem to change continuously with CARM offset. I am wondering if I have too much offset in one of the vertex locking loops?

  15419   Fri Jun 19 17:06:50 2020 gautamUpdateLSCWhat should the short-term commissioning goals be?

Summary:

I want some input about what the short-term (next two weeks) commissioning goals should be.

Details:

Before the vacuum fracas, the locking was pretty robust. With some human servoing of the input beam, I could maintain locks for ~1 hour. My primary goals were:

  1. Transition the vertex length DoF control from 3f signals to 1f signals.
  2. Turn on some MICH-->DARM feedforward cancellation, because the noise between ~100 Hz and ~1kHz is dominated by this cross-coupling.

I didn't succeed in either so far.

  1. I find that there is poor separation of the length DoFs in the 1f sensors, which makes this transition hopeless.
    • Why should this be? I can't get any sensing matrix in Finesse to line up with what I measure in-lock.
    • One hypothesis I came up with (but haven't yet tested) is that the offsets from the 3f photodiodes are changing from time to time, which somehow changes the projection of the various DoFs onto the photodiode quadratures. 
    • The attached GIF shows the variation in the measured sensing matrix on two days - while the sensing of MICH/PRCL in the 3f photodiodes have hardly changed, they are significantly different in the 1f photodiodes. Note that the I and Q have changed for REFL11 and REFL55 between the two days because I changed the demod phase.
    • I also thought that maybe the CARM suppression isn't sufficient for REFL11 to be used as a PRCL sensor - but even after engaging a CM board SuperBoost, I was unable to realize the PRCL 3f-->1f transition, even though the CARM-->REFL11 coupling did get smaller in the measured sensing matrix (red line in the GIF). I don't think we can juice up the CARM gain much more without modifying the CM board boosts, see Attachment #1.
  2. I was able to measure the MICH CTRL --> DARM ERR transfer function with somewhat high coherence (~0.98).
    • I then used the infrastructure available in the LSC model to try and implement some cancellation, but didn't really see any effect.
    • Perhaps the TF needs to be measured with higher coherence.
    • It may also be that if I am able to successfully execute the 3f-->1f transition, the coupling gets smaller because the 1f sensing noise is lower?

I guess apart from this, we want to run the ALS scan to try and infer something about the absorption-induced thermal lens. I guess at this point, the costs outweigh the benefits in trying to bring in the SRC as well, since we will be changing the SRC config?

Attachment 1: CARM_superBoost.pdf
CARM_superBoost.pdf
  15427   Wed Jun 24 17:20:16 2020 gautamUpdateLSCWhat should the short-term commissioning goals be?

Per the discussion at the meeting today, the plan of action is:

  1. Lock the PRMI on carrier and measure the sensing matrix, see if the MICH and PRCL signals look sensible in 1f and 3f photodiodes.
  2. Try locking CARM on POP55 (since there is currently no POP55 photodiode, can we use POX/POY as an intermediary?).
  3. For the ASC, can we hijack one of the IMC WFS heads to study what the AS port WFS signals would look like, and maybe close a feedback loop on the ETMs?
    • My guess is no, because currently, the L2A is so poorly tuned on MC2 that the CARM length control messes with the alignment of the IMC significantly.
    • So we need the IMC WFS loops to maintain the pointing.
    • Of course, the MC2 L2A can be tuned to mitigate this problem. 
    • I also believe there is something funky going on with the WFS heads. More to follow on that in a later elog.
    • Apart from these issues, for this scheme to be tested, some mods to the c1ioo model will have to be made so that we can route the servo output to the ETMs (as opposed to the IMC mirrors as is the usual case).

If I missed something, please add here.

Quote:

Summary:

I want some input about what the short-term (next two weeks) commissioning goals should be.

  16017   Mon Apr 12 10:07:35 2021 AnchalUpdateSUSWhat's F2A??

I'm not sure I understand what F2A is? I couldn't find a description of this filter anywhere and don't remember if you have already explained it. Can you describe what is needed to be done again, please? We would keep SUS state space model and seismic transfer functions calculation ready meanwhile.

Quote:

Next we wanna get the F2A filters made since most of the IMC control happens at f < 3 Hz. Once you have the SUS state space model, you should be able to see how this can be done using only the free'swinging eigenfrequencies. Then you should get the closed loop model including the F2A filters and the damping filters to see what the closed loop behavior is like.

 

  16020   Tue Apr 13 09:51:22 2021 ranaUpdateSUSWhat's F2A??

Force to Angle. It just means the filters that are in the POS OUTPUT matrix. I think in the past sometimes they are called F2P or F2A.

These filters account for the frequency dependent coupling of the DOFs around the suspension resonance. Take a look at what Bhavini is doing for the plots.

 

  11851   Sat Dec 5 12:02:25 2015 yutaroHowToCamerasWhen image capture does not work...

Today image capture did not work again, though it had worked 3 days before. I also found that red indicator light on the front pannel of SENSORAY was not turned on, which had been turned on 3 days before (you can find SENSORAY on the floor near Pianosa). Possible reason that it did not work again was I restarted Pianosa last night. Anyway, it works now. Here I report what I did to make it work.

 

I ran thes commands in shell, following the instruction of the manual of SENSORAY 2253 (Page 5; link or you can find the manual in /users/sensoray; I put it there). 

> cd /users/sensoray/sdk_2253_1.2.2_linux

> make all

> sudo make install

> modprobe s2253

Then the red light got turned on, and image capture worked.

 

If you recieve an error like "No such file or directory: /dev/video0" at the beginning of the error message when you run image capture scripts from the medm screen, or if you notice that the red indicator light of SENSORAY is not on, this procedure could help you. 

  11852   Sat Dec 5 21:28:33 2015 KojiHowToCamerasWhen image capture does not work...

Do we need "make" everytime? Do you mean just running "modprobe" didn't work?

  11853   Sat Dec 5 21:57:32 2015 yutaroHowToCamerasWhen image capture does not work...

I don't know if just running "modprobe" will work or not, because I didn't try it...  When the same problem happens again, we can try just running "modprobe" first.

  2786   Sun Apr 11 13:51:04 2010 AlbertoOmnistructureComputersWhere are the laptops?

I can't find the DELL laptop anywhere in the lab. Does anyone know where it is?

Also one of the two netbooks is missing.

  2787   Sun Apr 11 19:05:34 2010 KojiOmnistructureComputersWhere are the laptops?

One dell is in the clean room for the suspension work.

Quote:

I can't find the DELL laptop anywhere in the lab. Does anyone know where it is?

Also one of the two netbooks is missing.

 

  5714   Thu Oct 20 18:01:17 2011 JenneUpdateComputer Scripts / ProgramsWhere should the "Update Snapshots" of screens live?

While trying to implement the regular yellow shell script button in MEDM for my new OAF screen, I noticed that the update snapshot stuff in all of the buttons that I checked (including IFO Align and LSC Overview) are pointing to folders in the old /cvs/cds/caltech/ area.  Also, I think some of the folders that it's looking for don't exist anymore, even in the old system.  So.  Has anyone thought about where the snapshots should live in the new world order?  Previously they were in ...../medm/c1/subsystem/ .  Maybe we should make a snapshots folder in each subsystem's medm folder, at the same level as the 'master' folder for the custom screens?  This is my current proposal.

Unless someone objects / has a better plan / knows why they're still pointing to the old place, I'll do this in the morning, and work on changing all the buttons to point to the new place.

  5715   Thu Oct 20 18:42:47 2011 KojiUpdateComputer Scripts / ProgramsWhere should the "Update Snapshots" of screens live?

The following directory exists. We can apply this convention to all of the models.

/cvs/cds/rtcds/caltech/c1/medm/c1lsc/snap

Quote:

While trying to implement the regular yellow shell script button in MEDM for my new OAF screen, I noticed that the update snapshot stuff in all of the buttons that I checked (including IFO Align and LSC Overview) are pointing to folders in the old /cvs/cds/caltech/ area.  Also, I think some of the folders that it's looking for don't exist anymore, even in the old system.  So.  Has anyone thought about where the snapshots should live in the new world order?  Previously they were in ...../medm/c1/subsystem/ .  Maybe we should make a snapshots folder in each subsystem's medm folder, at the same level as the 'master' folder for the custom screens?  This is my current proposal.

Unless someone objects / has a better plan / knows why they're still pointing to the old place, I'll do this in the morning, and work on changing all the buttons to point to the new place.

 

  2305   Fri Nov 20 11:01:58 2009 josephb, alexConfigurationComputersWhere to find RFM offsets

Alex checked out the old rts (which he is no longer sure how to compile) from CVS to megatron, to the directory:

/home/controls/cds/rts/

In /home/controls/cds/rts/src/include you can find the various h files used.  Similarly, /fe has the c files.

In the h files, you can work out the memory offset by noting the primary offset in iscNetDsc40m.h

A line like suscomms.pCoilDriver.extData[0] determines an offset to look for.

0x108000 (from suscomms )

Then pCoilDriver.extData[#] determines a further offset.

sizeof(extData[0]) = 8240  (for the 40m - you need to watch the ifdefs, we were looking at the wrong structure for awhile, which was much smaller).

DSC_CD_PPY is the structure you need to look in to find the final offset to add to get any particular channel you want to look at.

The number for ETMX is 8, ETMY 9 (this is in extData), so the extData offset from 0x108000 for ETMY should be 9 * 82400.  These numbers (i.e. 8 =ETMX, 9=ETMY) can be found in losLinux.c in /home/controls/cds/rts/src/fe/40m/.  There's a bunch of #ifdef and #endif which define ETMX, ETMY, RMBS, ITM, etc.  You're looking for the offset in those.

So for ETMY LSC channel (which is a double) you add 0x108000 (a hex number) + (9 * 82400 + 24) (not in hex, need to convert) to get the final value of 0x11a160 (in hex).

-----------

A useful program to interact with the RFM network can be found on fb40m.  If you log in and go to:

/usr/install/rfm2g_solaris/vmipci/sw-rfm2g-abc-005/util/diag

you can then run rfm2g_util, give it a 3, then type help.

You can use this to read data.  Just type help read.  We had played around with some offsets and various channels until we were sure we had the offsets right.  For example, we fixed an offset into the ETMY LSC input, and saw the corresponding memory location change to that value.  This utility may also be useful for when we do the RFM test to check the integrity of the ring, as there are some diagnostic options available inside it.

  10595   Fri Oct 10 03:25:11 2014 JenneUpdateLSCWhich side of optical spring are we on (simulation)

I have a simulated version of the differences that we expect to see between the 2 different sides of the CARM resonance.  The point is that we can try to compare these results with Q's measured results (elog 10594) to see if we know if we are on the spring or antispring side.


I calculated the same transfer functions vs CARM offset again, although tonight I do it in steps of 20pm because I was getting bored of waiting forever.  Anyhow, this is important because my previous post (elog 10591) didn't have spring side calculations all the way down to 1pm.

This is similarly true for that elog 10591, but here are some notes on how I am currently getting the W/N units out of Optickle.  First of all, I am still using old Optickle1.  I don't know if there are significant units ramifications for that, but just in case I'll write it down.  Nic tells me that to get [W/N] out of Optickle1, I need to multiply sigAC (units of [W/m]) by my simple pendulum (units of [m/N]).  Both of these "meters" in the last sentence are "mevans meters", which are the meters you would get per actuation if radiation pressure didn't exist.  So, I guess they're supposed to cancel out?  I need to camp out in Nic's office until I figure this out and get it untangled in my head.

Plots of transfer functions for both sides of CARM resonance (same as prev. elog), as well as the ratio between the spring and antispring transfer functions at each CARM offset:

TFs_TRX_vsCARMoffset_PRFPMI_antispring.pngTFs_TRX_vsCARMoffset_PRFPMI_spring.pngTFs_TRX_vsCARMoffset_PRFPMI_differentials.png

 

TFs_REFLDC_vsCARMoffset_PRFPMI_antispring.pngTFs_REFLDC_vsCARMoffset_PRFPMI_spring.pngTFs_REFLDC_vsCARMoffset_PRFPMI_differentials.png

TFs_REFL11I_vsCARMoffset_PRFPMI_antispring.pngTFs_REFL11I_vsCARMoffset_PRFPMI_spring.pngTFs_REFL11_vsCARMoffset_PRFPMI_differentials.png

The take-away message from the 3rd column is that other than a sign flip, we don't expect to see very much difference between the 2 sides of the CARM resonance, particularly above a few hundred Hz.  (Note that we do not see the sign flip in Q's measurements because he is looking at CARM_IN1, which is after the input matrix, and the input matrix elements have opposite signs between the signs of the CARM offsets.  So, the sign flip between spring and antispring around the UGF is implied in the measurements, just not explicit).

Also, something that Rana pointed out to me, and I still don't know why it's true:  The antispring transfer functions (at least for the transmission) don't have all the phase features that we expect to see based on their magnitudes.  If you look at the TRX antispring plot, blue trace (which is about 500pm from resonance), you'll see that the magnitude starts flat at DC, has some slope in an intermediate region, and then at high frequencies has 1/f^2.  However, the phase seems to not know about this intermediate region, and magically waits until the 1kHz resonance to flip the full 180 degrees. 

Attachment 10: ForElog_9Oct2014.zip
  10594   Fri Oct 10 03:05:09 2014 ericqUpdateLSCWhich side of optical spring are we on?

 I made some measurements to try and see if any difference could be seen with different CARM offset signs. 

Specifically, at various offsets, I used a spare DAC channel to drive IN1 of the CM board, as an "AO Exciter." I used CM_SLOW to monitor the signal that was actually on the board. I used the CARM_IN1 error signal to see how the optical plant responded to the AO excitation. Rather than a swept sine, I used a noise injection kind of TF measurement. 

Here are plots of CARM_IN1 / CM_SLOW at different CARM FM offsets; I chose to plot this in an attempt to divide out some of the common things like AA and delays and make the detuned CARM pole more evident). The offsets chosen correspond roughly to powers of 2, 2.5, and 3. I tried to go higher than that, but didn't remain locked for long enough to measure the TF. 

comparison.pdf

By eye, I don't see much of a difference. We can zpk fit the data, and see what happens. 

 

  10598   Mon Oct 13 12:01:28 2014 ericqUpdateLSCWhich side of optical spring are we on?

 I went back into the DQ channels to look at the TF from AO injection to REFLDC (which is easy to do with this kind of noise injection TF).  

AOInjection_SqrtInv_REFLDC.png

I fear that REFL does not seem to have as much phase under the resonance as we have modeled, lacking about 10-20 degrees. This could result from the zero in the REFL DC response that we've modeled at ~200ish Hz is actually higher. I'll look into what affects the frequency of that feature. 

It is, of course, possible, that this measurement doesn't properly cancel out the various digital effects, but the REFLDC phase curves do seem to settle to (+/-) 90 after the pole as expected. 

DTT XML file is attached. 

Attachment 2: AOinjection_SqrtInv_REFLDC.xml.zip
  10607   Wed Oct 15 02:58:03 2014 JenneUpdateLSCWhich side of optical spring are we on?

Some measurements.  Unclear meaning.  

We tried both positive and negative numbers in the CARM offset, and then looked at transfer functions at various arm powers. The hope is to be able to compare these with some simulation to figure out which side of the CARM resonance we are on.

The biggest empirical take-away is that we repeatedly (3 times in a row) lost lock when holding at arm powers of about 5 with negative CARM offsets.  However, we were repeatedly (2+ times tonight) able to sit and hold at arm powers of 10+ with positive CARM offsets.

 

 

 

I am not sure that we get enough information out of these plots to tell us which side of the CARM resonance we are really on.  Q is working on taking some open loop CARM measurements (actuating and measuring at SUS-MC2_LSC) to see if we can compare those more directly to Rana's plots.

Positive number in the digital CARM offset:

PRFPMI_MC2injection_PosCARMoffset_REFLDC_TRX_response_14Oct2014_TRX.pdf

PRFPMI_MC2injection_PosCARMoffset_REFLDC_TRX_response_14Oct2014_REFLDC.pdf

Negative numbers in digital CARM offset:

PRFPMI_MC2injection_NegCARMoffset_REFLDC_TRX_response_14Oct2014_TRX.pdf

PRFPMI_MC2injection_NegCARMoffset_REFLDC_TRX_response_14Oct2014_REFLDC.pdf

  10603   Mon Oct 13 21:20:56 2014 JenneUpdateLSCWhich side of optical spring are we on? (No progress)

[Jenne, Diego]

In order to distinguish between the spring and antispring sides of the CARM resonance, we need to have transfer function measurements down to at least 100 Hz (although lower is better). 

We tried to get some transfer functions the same way Q did, but noticed that (a) we couldn't get any low frequency coherence, and (b) that when we increased the amplitude of the white (well, lowpass at 5kHz) noise, the coherence between the AO injection and REFL DC went down.  Not clear why this is.

Anyhow, we tried taking good ol' fashioned swept sine transfer functions, although eventually the lightbulb came on that the AO path has a highpass in it.  Duh, Jenne.  So, we started trying to actuate on MC2 position rather than the AO path laser frequency.  We didn't get too far though before El Salvadore decided to have a few 7.4 earthquakes.  We're bored of aftershocks knocking us out of lock, so we're going to come back to this tomorrow.

 

  10604   Mon Oct 13 21:59:47 2014 ranaUpdateComputer Scripts / ProgramsWhich side of optical spring are we on? (No progress)

 

 Since no one was here, I started the Ubuntu 10 - 12 upgrade on Rossa. It didn't run at first because it wanted to remove 'update-manager-kde' even though it was on the blacklist. I removed it from the command line and now its running. Allegra, OTOH, refuses to upgrade. Someone please ask Diego to wipe it and then install Ubuntu 12 LTS on there in the morning...its a good way to learn the Martian CDS setup.

  10612   Wed Oct 15 19:56:38 2014 JenneUpdateLSCWhich side of optical spring are we on? Meas vs Model

 I have plotted measured data from last night (elog 10607) with a version of the result from Rana's simulink CARM loop model (elog 10593).

The measured data that was taken last night (open circles in plots) is with an injection into MC2 position, and I'm reading out TRX.  This is for the negative side of the digital CARM offset, which is the one that we can only get to arm powers of 5ish.

The modeled data (solid lines in plots) is derived from what Rana has been plotting the last few days, but it's not quite identical.  I added another excitation point to the simulink model at the same place as the "CARM OUT" measurement point.  This is to match the fact that the measured transfer functions were taken by driving MC2.  I then asked matlab to give me the transfer function between this new excitation point (CARM CTRL point) and the IN1 point of the loop, which should be equivalent to our TRX_OUT.  So, I believe that what I'm plotting is equivalent to TRX/MC2.  The difference between the 2 plots is just that one uses the modeled spring-side optical response, and the other uses the modeled antispring-side response.

AntispringModel_NegOffsetMeas_comparison.pdf

SpringModel_NegOffsetMeas_comparison.pdf

I have zoomed the X-axis of these plots to be between 30 Hz - 3 kHz, which is the range that we had coherence of better than 0.8ish last night in the measurements.  The modeled data is all given the same scale factor (even between plots), and is set so that the lowest arm power traces (pink) line up around 150 Hz. 

I conclude from these plots that we still don't know what side of the CARM resonance we are on. 

 I have not plotted the measurements from the positive side of the digital CARM offset, because those transfer functions were to sqrtInvTRX, not plain TRX, whereas the model only is for plain TRX. There should only be an overall gain difference between them though, no phase difference.  If you look at last night's data, you'll see that the positive side of the CARM offset measured phase has similar characteristics to the negative offset, i.e. the phase is not flat, but it is roughly flat in both modeled cases, so even with that data, I still say that we don't know what side of the CARM resonance we are on.

 

 

  14759   Mon Jul 15 03:30:47 2019 KruthiUpdateCalibration-RepairWhite paper as a Lambertian scatterer

I made some rough measurements, using the setup I had used for CCD calibration, to get an idea of how good of a Lambertian scatterer the white paper is. Following are the values I got:

Angle (degrees) Photodiode reading (V)  Ps (W) BRDF (per str) % error
12 0.864 2.54E-06 0.334 20.5
24 0.926 2.72E-06 0.439 19.0
30 1.581 4.65E-06 0.528 19.0
41 0.94 2.76E-06 0.473 19.8
49 0.545 1.60E-06 0.423 22.5
63 0.371 1.09E-06 0.475 28

Note: All the measurements are just rough ones and are prone to larger errors than estimated.

I also measured the transmittance of the white paper sample being used (it consists of 2 white papers wrapped together). It was around 0.002

Attachment 1: BRDF_paper.png
BRDF_paper.png
  15531   Mon Aug 17 23:36:10 2020 gautamUpdateALSWhitening and ALS noise

finally managed to install a differential-receiving whitening board in 1Y2 - 4 channels are available at the moment. As I claimed, one stage of 15:150 Hz z:p whitening does improve the ALS noise a little, see Attachment #1. While the RMS (from 1kHz-0.5 Hz) does go down by ~10 Hz, this isn't really going to make any dramatic improvement to the 40m lock acquisiton. Now we're really sitting on the unsuppressed EX laser noise above ~30 Hz. This measurement was taken with the arm cavities locked with POX/POY, and end lasers locked to the arm cavities with uPDH boxes as usual. This was just a test to confirm my suspicion, the whitening board is to be used for the air BHD channels, but when we get a few more stuffed, we can install it for the ALS channels too.

Attachment 1: ALSimprovement.pdf
ALSimprovement.pdf
  15533   Tue Aug 18 13:55:23 2020 ranaUpdateALSWhitening and ALS noise

No, there should be no unscheduled visits from any inspector, marshal, tech, or vendor. They all have to be escorted or they don't get in. If they have a problem with that, please give them my cell #.

 

For the ALS, in addition to the beat note spectrum, I think we need to know the loop gain use to feedback to the ETM to determine the true cavity length fluctuation. w/o ALS, the noise would be only due to the seismic noise, OSEM damping noise, and the IR-PDH residual. Those are all suppressed by the ALS loop, but then the ALS loop puts its sensing noise onto the cavity. So, if I'm thinking about this right, the ALS beat noise > 200 Hz doesn't matter so much to the CARM RMS. So the whitening seems to be doing good in the right spot, but we would like to have another boost in the green PDH to up the gain below ~300 Hz?

ELOG V3.1.3-