40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 257 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  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?

  15532   Mon Aug 17 23:41:50 2020 gautamUpdateBHDWhitening and air BHD dark noise

Summary:

With the chosen transimpedance of 300 ohms, in order to be able to see the shot noise of 10 mW of light in the digitized data streams, we'd need all 3 stages of whitening. If we want to be shot noise limited with 1 mW of LO light, we'd need to increase said transimpedance I think.

Details:

The measurements were taken with

  1. No light incident on the DCPDs.
  2. The flat whitening gain was set to 0 dB.
  3. Whitening engaged sequentially, stage by stage, shown as (Blue, Red, Orange and Green) curves corresponding to (0, 1, 2, 3) stages of whitening.

Of course, it's unlikely we're going to be shot noise limited for any configuration in the short run. But this was also a test of 

  1. My soldering.
  2. Change of whitening corner frequencies.
  3. Test of the overall whitening board assembly.

All 3 tests passed.

Attachment 1: BHD_whitening.pdf
BHD_whitening.pdf
  16972   Tue Jul 5 20:05:06 2022 TomislavUpdateElectronicsWhitening electronics noise

For whitening electronics noise for WFS1, I get (attachment). This doesn't seem right, right?

Attachment 1: whitening_noises.png
whitening_noises.png
  13563   Sat Jan 20 01:20:37 2018 gautamUpdateElectronicsWhitening filter D990694

We use D990694 in various places. Today, Rana alerted me to an important consideration to be kept in mind when we use this board, which I found quite interesting. I still don't understand the problem at the BJT level, but I think one can appreciate the problem without going to the transistor design of the LT1125. I'm attaching an annotated schematic of the whitening section in question. If the following assumptions are valid, then I think my picture is valid.

  1. The switch used to bypass the various whitening gain stages, namely the ADG333ABR, has infinite impedance in the "OFF" state, such that when the 24dB gain stage is bypassed, U28A (or in general one of the 4 quad op-amps) is forced to drive it's output voltage across 1.0665 kohms of resistance.
  2. The individual LT1125 Op Amps can drive a maximum of 30mA of current.

Then, as one can see in the attached schematic, when we set the gain of any input to <24dB, we must ensure that the input voltage is less than approximately 2V. Otherwise, by asking too much of the first stage op-amp in the quad IC LT1125, we may be messign around with all the 4 op amps in the quad! Even the 0dB setting is not immune to this problem, as it uses one of the 4 op amps.

I don't think the usual rules of calculating the gain of a non-inverting amplifier (G = 1 + Rf/Ri) remain valid even when the op-amp is forced to drive more output current than it can, and I don't have a way to quantify the possible interference between the 4 op amps in the quad - but does this seem like a valid conclusion? If so, we must check signal levels of various LSC signals. AS55 signals currently have the 0dB gain setting - I had turned this down from 6dB some months ago, because it seemed like the ADC was saturating at the 6dB gain setting, which suggests that the input voltage is ceratinly > 2V, and AS55_Q is what is used for MICH control in the DRMI. All of my noise budgeting work over the last few months used this setting, I wonder if they are all invalid surprise


Now that I think about this a bit more - this problem shouldn't be significant for the usual LSC degrees of freedom when in lock, as the huge DC gain of the loop should squish large DC values of the error signals, and so there shouldn't be any danger of overloading the LT1125. But I don't know if we are being hurt by this effect when flashing through resonances, when the PDH horn-to-horn voltage can be quite high (which is in principle a good thing?). I don't know if there is any "hysterisis" effect where the overloaded quad IC has some relaxation time before it returns to normal operation, and if we are being limited in our ability to catch lock because if this effect. 

The concerns remain valid for th ALS demodulated error signals though, for which the signals will remain large throughout.

Attachment 1: whiteningBoardLimitations.pdf
whiteningBoardLimitations.pdf
  13564   Sat Jan 20 15:57:11 2018 ranaUpdateElectronicsWhitening filter D990694

this is the note from Hartmut Grote on this topic from 2004

  13568   Tue Jan 23 01:33:23 2018 gautamUpdateElectronicsWhitening filter D990694

After discussing with Koji, we looked at the aLIGO incarnation of this board. Interestingly, it too has a similar topology of 4 switchable gain stages with gains of 24, 12, 6 and 3dB. The main differences are that they use single Op27 ICs instead of the quad LT1125s, and also, they use a different combination of feedback resistors to realize the various gains. 

We considered upping the feedback resistance (R15, R143) on the 24dB gain stage of our boards from (1k, 66.5ohms) to (3k, 200ohms) as on the aLIGO boards - but this doesn't really help? Because KCL demands that the same current flow in R15 and R143, and so the output Vsat of the op amp and its max current driving capabilities in combination determine if the inverting input can follow the non inverting input?

As Hartmut points out in his note, he was able to access the full range of ADC voltages when the gain was set to 3dB, despite the fact that the LT1125 was still getting internally saturated. Operating with minimum 24dB whitening gain doesn't really solve the problem either because the problem just gets shifted to the next gain stage in the chain, and we still have saturation. I also don't have a feeling for how much differential voltage these LT1125s can sustain before they are damaged - I guess the planned THD check will reveal if they are okay or not.

It seems to me like the only way to truly fix this problem of one stage saturating and screwing up the others is to use single Op27s (or equivalent) in place of the quad LT1125s. The aLIGO design also has a series resistance to the non-inverting input - this can help prevent current overdraw from the previous stage (due to a lowered input impedance of the OpAmp - but I wonder how low this can go?).

Quote:

this is the note from Hartmut Grote on this topic from 2004

 

  13572   Wed Jan 24 00:48:47 2018 gautamUpdateElectronicsWhitening filter D990694

I plan to do some characterization of this problem. The plan is to use THD as a metric for whether we are having hidden saturations. Pg 9 of the LT1125 datasheet tells us what fraction of THD to expect. I will use one of the several unused DAC channels available at the LSC rack to drive a 100Hz sine wave into one of the inputs of the whitening chassis, and measure the THD up to a reasonable harmonic number (will probably be set by the ADC noise) for (i) various whitening gain settings and (ii) various input signal amplitudes.

The motivation is to attempt to quantify the problem better:

  1. How bad is it to have one or more of the OpAmps in the quad IC either saturated to its voltage rails, or max output current?
  2. Can we reproduce Hartmut's observations?
  3. Are the OpAmps already irreversibly damaged because of extended abuse?

Then we can decide what, if anything, to do about this issue.

  3790   Tue Oct 26 22:57:37 2010 JenneConfigurationComputersWhy doesn't DTT work?!?

DTT has only SUS and "X02" channels under C1 in the drop down channel selection menu.  Basically, we can't measure any fast channels with DTT.  I keep getting the error: "Unable to select testpoints."  Sadface.

Similar things are true for DataViewer.  The same limited number of fast channels, and no data found:

Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek

Is this a framebuilder problem?  Is this something that the CDS team has on the to-do list?

  3793   Wed Oct 27 10:53:03 2010 josephbConfigurationComputersWhy doesn't DTT work?!?

Test points for the SUS channels should be there.  They have been working previously this week.  Possibly break down points include awgtpman, mx_streams, and the fb itself.  I'll look into that.

As far as other fast channels, there are no other fast front ends running than the suspensions ones we have.  Until additional channels get connected to the front ends and the models updated, those are the channels we have available.  However I am working on getting c1ioo up and running, and we can try connecting in some PEM channels today to the c1sus front end's 4th ADC.

 

Edit:

I tried starting a fresh instance of the frame builder, but when I brought the old copy down, it left a pair of zombie or dead mx_stream processes running on c1sus . Basically c1mcs and c1rms were still running, while c1x02 and c1sus came down.  I tried to kill the processes but this caused the c1sus machine to crash.  In the past I've killed left over mx_stream processes running after the frame builder has gone down, but I've never seen them crash the computer.  I'm unsure why this happened since we haven't done any updates of the code, just updated models and daq configuration files.

Quote:

DTT has only SUS and "X02" channels under C1 in the drop down channel selection menu.  Basically, we can't measure any fast channels with DTT.  I keep getting the error: "Unable to select testpoints."  Sadface.

Similar things are true for DataViewer.  The same limited number of fast channels, and no data found:

Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek

Is this a framebuilder problem?  Is this something that the CDS team has on the to-do list?

 

  4027   Wed Dec 8 14:46:19 2010 josephb, kiwamuUpdateCDSWhy the ETMX daq channels were not recorded last night

When adding the ETMX DAQ channels using the daqconfig gui (located in /opt/rtcds/caltech/c1/scripts/) on C1SCX.ini, we forgot to set the acquire flag to 1 from 0.

So the frame builder was receiving the data, but not recording it.

We have since then added ETMX and the C1SCX.ini file to Yuta's useful "activateDAQ.py" script in /opt/rtcds/caltech/c1/chans/daq/, so that it now sets the sensor and SUSPOS like channels to be acquired at 2k when run.  You still need to restart the frame builder (telnet fb 8087 and then shutdown) for these changes to take effect.

The script now also properly handles files which already have had channels activated, but not acquired.

  14829   Mon Aug 5 17:23:26 2019 gautamSummaryComputersWiFi Settings on asia

The VEA laptop asia was configured to be able to connect to too many WiFi networks - it was getting conflicted in its default position at the vertex and trying to hop between networks, for some reason trying to connect to networks that had poor signal strength. I deleted all options from the known networks except 40MARS. Now the network connection seems much more stable and reliable.

  13905   Thu May 31 19:51:06 2018 KojiUpdateGeneralWiFi router firmware update / rebooting

The model of our martian wifi router (NETGEAR R6400) was found in the FBI router list to be rebooted asociated with the malware "VPNFilter" issue.

I checked the attached devices and found bunch of (legit) devices blocked to access the wifi router. This is not an immediate problem as most of the packets do not go through the wifi router. But potentially a problem in some cases like Wifi enables GPIB adapters. So I marked them to be "allowed".

In this opprtunity, I have updated the firmware of the wifi router and this naturally involved rebooting of the device.

 

  2664   Tue Mar 9 09:32:31 2010 KojiSummaryGeneralWideband measurement of Fast PZT response

I have measured a wideband response of the fast PZT in the LWE NPRO 700mW in the Alberto's setup.
This is a basic measurement to determine how much phase modulation we can obtain by actuating the fast PZT,
primarily for the green locking experiment.

RESULT

  • Above 200kHz, there are many resonances that screws up the phase.
     
  • Modulation of 0.1rad can be easily obtained even at 10MHz if the modulation frequency is scanned.
     
  • Change of the laser frequency in DC was observed depending on the modulation frequency.
    i.e. At the resonance the laser frequency escaped from the RF spectrum analyzer.
    This may induced by the heat dissipation in the PZT causing the temperature change of the crystal.
     
  • Some concerns: Is there any undesired AM by the PZT modulation?

---

METHOD

1. Locked the PLL of for the PSL-NPRO beating at 20MHz.

2. Added the modulation signal to the NPRO PZT input.
I used the output of the network analyzer sweeping from 100kHz to 1MHz.

3. Measured the transfer function from the modulation input to the PLL error signal.
The PLL error is sensitive to the phase fluctuation of the laser. Found that the first resonance is at 200kHz.
The TF is not valid below 3kHz where the PLL suppresses the modulation.

4. Single frequency modulation: Disconnected the PLL setup.
Plug Marconi into the fast PZT input and modulate it at various frequencies.
Observing with the RF spectrum analyzer, I could see strong modulation below 1MHz.
It turned out later that the TF measurement missed the narrow peaks of the resonances due to the poor freq resolution.

Also the modulation depth varies frequency by frequency because of the resonances.
Scanned the frequency to have local maximum of the modulation depth. Adjusted the
modulation amplitude such that the carrier is suppressed
(J0(m)=0 i.e. m~2.4). As I could not obtain
the carrier suppression at above 1MHz, the height of the carrier and the sidebands were measured.

The modulation frequency was swept from 100kHz to 10MHz.

5. Calibration. The TF measured has been calibrated using the modulation depth obtained at 100Hz,
where the resonance does not affect the response yet.

The responce of the PZT was ~10MHz/V below 30kHz. Looks not so strange although this valure is
little bit high from the spec (2MHz/V), and still higher than my previous experience at TAMA (5MHz/V).
Note that this calibration does not effect to the modulation depth of the single freq measurement as they are independent.

Attachment 1: PZT_response.png
PZT_response.png
  1105   Sun Nov 2 20:44:58 2008 ranaUpdateASSWiener Filter performance over 5 hours
I took one 2 hour stretch of data to calculate a MISO Wiener filter to subtract the Ranger seismometer
and the 6 Wilcoxon accelerometers from the IOO-MC_L channel. I then used that static filter to calculate
the residual of the subtraction in 10 minute increments for 5 hours. The filter was calculated based upon
the first 2 hours of the stretch.

The MC lock stretch is from Oct 31 03:00 UTC (I think that we are -8 hours from UTC, but the DST confounds me).
So its from this past Thursday night.

I wrote a script (/users/rana/mat/wiener/mcl_comp.m) which takes the static filter and does a bunch of loops
of subtraction to get a residual power spectrum for each 10 minute interval.

In the attached PNG, you can see the result. The legend is in units of minutes from the initial t0 = 03:00 UTC.

BLACK-DASHED -- MCL spectrum before subtraction

I have also used dashed lines for some of the other traces where there is an excess above the unsubtracted data.
Other than those few times, the rest are all basically the same; this indicates that we can do fine with a very
slow adaptation time for the feed-forward filters
-- a few hours of a time constant is not so bad.

After making the plot I noticed that the Ranger signal was totally railed and junky during this time.
This probably explains the terrible performance below 1 Hz (where are those Guralps?)

The second attached image is the same but in spectrogram form.
Attachment 1: f.png
f.png
Attachment 2: f1.png
f1.png
  1111   Mon Nov 3 22:35:40 2008 ranaUpdateASSWiener Filter performance over 5 hours
To speed up the Wiener filter work I defined a 256 Hz version of the original 16kHz IOO-MC_L signal. The
attached plots show that the FE decimation code works correctly in handling the anti-aliasing and
downsampling as expected.
Attachment 1: DAQ.pdf
DAQ.pdf
  1112   Tue Nov 4 00:47:53 2008 ranaUpdateASSWiener Filter performance over 5 hours
Same as before, but now with a working Ranger seismometer.

In the spectrogram, the color axis is now in dB. This is a whitened spectrogram, so 0 dB corresponds to
the average (median) subtraction. The color scale is adjusted so that the large transients are saturated
since they're not interesting; from the DV trend its some kind of huge glitch in the middle of the
night that saturated the MC1 accelerometers only (maybe a pump?).

The attached trend shows the 5 hours used in the analysis.
Attachment 1: f2.png
f2.png
Attachment 2: f.png
f.png
  5102   Wed Aug 3 02:28:08 2011 Manuel, IshwitaUpdateWienerFilteringWiener Filtering in X-arm

Wiener Filtering was applied on the data collected from the X-arm during the time: GPS time-996380715 (Aug 02, 2011. 21:25:00. PDT) to GPS time-996382215 (Aug 02, 2011. 21:50:00. PDT) for a duration of 1500 seconds. During this time the X-arm was locked, we checked it by acquiring data from channel C1:LSC-TRX_OUT_DQ .

The seismometers were near the beam splitter (guralp2) and near MC2 (guralp1).

Target data was obtained from channel C1:LSC-XARM_IN1_DQ.

Schermata-6.png

Schermata-7.png

Following graphs were obtained after applying the Wiener filter:

 

      1.Seismic data acquired from Guralp1 (X and Y) and Guralp2 (X and Y)                              2.Seismic data acquired from Guralp2 X                                                              3.Seismic data acquired from Guralp2 Y 

WFgur1X1Y2X2YN20000srate2048.pngWFgur2XN20000srate2048.pngWFgur2YN20000srate2048.png

These graphs were obtained with srate = 2048 (sample rate) and N = 20000 (order of the filter).

Graph 1 is the best because the black (residual) line is below the red (target) line for low frequencies since we used seismic data from 4 channels. Graph 3 is the worst because we used seismic data from only one Y channel (Y axis of Guralp2) that is less related with the X-arm mirrors' motion since they are oriented orthogonally.

  854   Tue Aug 19 17:00:19 2008 SharonUpdate Wiener TF calibration - update
This is an update for post 814

I added the calibration gains I got for the accelerometers (I realize I am just calibrating the accelerometers to themselves and this is not m/m exactly since we don't really know which accelerometer is doing exactly what we want it to do. However, since we are talking on relative small numbers, this shouldn't really change much).


I also added another missing gain for the seismometer. Rana has previously installed a 4300 ohm resistor in the seismometer, which changed the gain to 4300/(4300+5000) = 0.46 (this is from the manual). Moreover, there is a gain of 100 on the SR560. This comes up to an extra gain of 46, meaning multiplying the seismometer's counts by 1/46.
Attachment 1: m_per_m.png
m_per_m.png
  6005   Fri Nov 25 12:46:13 2011 MirkoUpdateWienerFilteringWiener filtering tryout

Tried the wiener filter with the TF from p.5900

Tried it out with the TFs from p.5900:

WienerFiltering.pdf

Adding a filter element that compensates the acutator TF makes the MC lose lock.

  1337   Wed Feb 25 11:48:02 2009 JenneUpdatePEMWiener filtering update - work on filtering some S5 DARM_CTRL data

Quick update on my wiener filtering status:

Joe has been helping me get on the GRID, so I now have  a grid certificate, and accounts on most/all of the clusters.

Joe also helped me get menkar to get S5 data so that I can do wiener filtering to the back-data. 

 

I've been running the wiener filtering algorithm, and right now, it doesn't do anything to improve the DARM_CTRL data.  I am confident that this is because something is funky in the wiener filtering algorithm somewhere.  The indicator of this is that the wiener filtering calculation takes the same amount of time (~95 seconds) to calculate a filter for 64 seconds of data as for 1 hour of data (both for N = 2000 taps). 

 

For reference, attached are my plots for the wiener filtering result for (1) 64 seconds of S5 data, and for (2) 3600 seconds of S5 data.

These plots were made using H1:DARM_CTRL as the signal to minimize, with 4 seismometers as the witness channels (EX_SEISX, EY_SEISY, LVEA_SEISX, LVEA_SEISY)

 

I'm working on figuring out what's going on with the filtering algorithm, and why it does work for C1:MC_L minimization, but does not work for H1:DARM_CTRL minimization.

 

 

 

Attachment 1: h1_DARM_64s_4seis_25Feb09.png
h1_DARM_64s_4seis_25Feb09.png
Attachment 2: h1_DARM_3600s_4seis_25Feb09.png
h1_DARM_3600s_4seis_25Feb09.png
  11366   Fri Jun 19 16:54:20 2015 JenneUpdateComputer Scripts / ProgramsWiener scripts in scripts directory

I have put the Wiener filter scripts into  /opt/rtcds/caltech/c1/scripts/Wiener/  .  They are under version control. 

The idea is that you should copy ParameterFile_Example.m into your own directory, and modify parameters at the top of the file, and then when you run that script, it will output fitted filters ready to go into Foton.  (Obviously you must check before actually implementing them that you're happy with the efficacy and fits of the filters). 

Things to be edited in the ParameterFile include:

  • Channel names for the witness sensors (which should each have a corresponding .txt file with the raw data)
  • Channel name for the target
  • Folder where this raw data is saved
  • Folder to save results
  • 1 or 0 to determine if need to load and downsample the raw data, or if can use pre-downsampled data
    • This should probably be changed to just look to see if the pre-downsampled data already exists, and if not, do the downsampling
  • 1 or 0 to determine if should use actuator pre-weighting
  • Data folder for measured actuator TFs (only if using actuator pre-weighting)
    • Actuator TFs can be many different exported text files from DTT, and they will be stitched together to make one set of measurements, where all points have coherence above some quantity (that you set in the ParameterFile)
  • Coherence threshold for actuator data (only use data points with coherence above this amount)
  • Fit order for actuator transfer function's vectfit
  • 1 or 0 to decide if should use preweighting filter
  • zeros and poles for preweighting filters
  • 1 or 0 to decide if should use lowpass after Wiener filters (will be provided corresponding SOS coefficients for this filter, if you say yes)
  • Lowpass filter parameters: cuttoff freq, order and ripple for the Cheby filter
  • New sample rate for the data
  • Number of Wiener filter taps
  • Decide if use brute force matrix inversion or Levinson method
  • Calibrations for witnesses and target
  • Fit order for each of the Wiener filters

I think that's everything that is required.

  •  
  4968   Thu Jul 14 17:34:35 2011 Ishwita, ManuelHowToWienerFilteringWiener-Hopf equations

Since we are using Wiener filtering in our project, we studied the derivation of Wiener-Hopf equations. Whatever we understood we have written it as a pdf document which is attached below...

Attachment 1: derivwf.pdf
derivwf.pdf derivwf.pdf derivwf.pdf derivwf.pdf derivwf.pdf derivwf.pdf
  16346   Mon Sep 20 15:23:08 2021 YehonathanUpdateComputersWifi internet fixed

Over the weekend and today, the wifi was acting bad with frequent disconnections and no internet access. I tried to log into the web interface of the ASUS wifi but with no success.

I pushed the reset button for several seconds to restore factory settings. After that, I was able to log in. I did the automatic setup and defined the wifi passwords to be what they used to be.

Internet access was restored. I also unplugged and plugged back all the wifi extenders in the lab and moved the extender from the vertex inner wall to the outer wall of the lab close to the 1X3.

Now, there seems to be wifi reception both in X and Y arms (according to my android phone).

 

  16350   Mon Sep 20 21:56:07 2021 KojiUpdateComputersWifi internet fixed

Ug, factory resets... Caltech IMSS announced that there was an intermittent network service due to maintenance between Sept 19 and 20. And there seemed some aftermath of it. Check out "Caltech IMSS"

 

  2849   Tue Apr 27 11:16:13 2010 josephbConfigurationCDSWiki page with CDS .mdl names, shared memory allocation

I've added a new page in the wiki which describes the current naming scheme for the .mdl model files used for the real time code generator.  Note, that these model names do not necessarily have to be the names of the channels contained within.  Its still possible to make all suspension related channels start with C1:SUS- for example.  I'm also allocating 1024 8 byte channels for shared memory address space for each controller and each simulated plant.

The wiki page is here

Name suggestions, other front end models that are needed long term (HEPI is listed for example, even though we don't have it here, since in the long run we'd like to port the simulated plant work to the sites) are all welcome.

  11345   Wed Jun 3 17:04:08 2015 ericqUpdatePEMWilcoxon Accelerometer Huddle Test

I've set up the Wilcoxon accelerometers on the SP table for a huddle test, to estimate their noise levels. 

They're clamped down to the table along the same axis, and their housings are in good contact, in hopes to make them as correlated as possible. 

Steve helped me move the DAQ cables from under the BS/PRM oplev table, to dropping from the cable tray above the POX table, so I could get them plugged in at the SP table. This also helps reduce the rats nest by the access connector, and is a fine location for when the accelerometers are attached at MC1 & MC2. 

A quick glance at DTT shows coherence of >0.9 from about 2-100Hz for all six. A three-corner-hat deal will provide an easy estimate of the noise floor of each one. If we feel like being fancy / accounting for possible gain differences, we could try some MISO wiener action, but that is probably overkill. 

Attachment 1: AccHuddle.jpg
AccHuddle.jpg
  11350   Wed Jun 10 02:50:39 2015 ericqUpdatePEMWilcoxon Accelerometer Huddle Test

Here are some results for the 3-corner hat subtraction for the six accelerometers, from ~1 hour of data that didn't look to have any sharp features/glitches from human activity in the lab. 

I used the python uncertainties package to try and get an estimate of the uncertainty in the subtracted noise floor, by taking into account every possible possible combination of 3 sensors and the fluctuations in the spectrograms of the subtracted signals. I've attached the python code if anyone is interested in the implementation. 

I pulled out the accelerometer data sheets to read their slightly varying V/g calibration (which differs on the order of a few percent from unit to unit). This improved the subtraction factor from ~20 to over 100 at some frequencies. I've edited the filter modules such that the OUT_DQ channels are already calibrated into m/s^2.

Attachment 1: hats2Acc.png
hats2Acc.png
Attachment 2: 3hatcode.zip
  11367   Sun Jun 21 13:21:03 2015 ranaUpdatePEMWilcoxon Accelerometer Huddle Test

To improve our sensor noise estimate, the ACC cables should be clamped using a rubber pad and a big dog clamp on the SP tabletop before exiting the table. Also the sensors themselves should be covered with a foam box or a double cardboard box. The high-frequency acoustic noise may limit the 10 Hz performance since piezos are not very linear.

Quote:

I've set up the Wilcoxen accelerometers on the SP table for a huddle test, to estimate their noise levels. 

They're clamped down to the table along the same axis, and their housings are in good contact, in hopes to make them as correlated as possible. 

Wilcoxon. Not Wilconox or Wilco or Wilcoxen. Have some pity on future keyword searchers.

  11391   Sun Jul 5 18:14:13 2015 IgnacioUpdatePEMWilcoxon Accelerometer Huddle Test

Updated: On Thursday/Friday (sorry for late elog) I was messing with Eric's Wilcoxon 731A accelerometer huddle test data that was taken without the box and cables being adjusted properly. Anyways, I performed the three cornered hat analysis as he had done but I also performed a six cornered hat method as well instead of permuting around in pairs of three accelerometers. The following plots of the ASD's show the results,

It is interesting to note the improvement at low frequencies when six accelerometers are used instead of six while at higher frequencies we can clearly see how the results are worst than the three hat results.

I decided to take a mean of all six accelerometers measured ground signal as well as that for their computed selfnoises, this is plotted below,

 

Notice the obvious improvement along the entire frequency band of the measurements when all accelerometers are used in the data analysis.

I also performed some Wiener filtering of this data. There was an obvious improvement in the results,

The mean of the signals is also plotted below, just as I did with the cornered hat methods,

 

I also compared the mean self noise of the accelerometers against the manufacturers calculated selfnoise that Rana put up on Github. Both methods are compared against what the manufacturer claims,

As expected the measured noise curves of the Wilcoxon is not as good as what the manufactures stated. This should improve once we redo the huddle test with a better experimental setup. We have some pretty interesting results with the six cornered hat method at around 5 Hz, it is surprisingly accurate given how rough the calculations seemed to be.

I have attached my code for reference: code_accel.zipselfnoise_allsix.png

SEE attachments for better plots of the six accelerometers...

Attachment 5: code_accel.zip
Attachment 6: selfnoise_allsix_miso.png
selfnoise_allsix_miso.png
Attachment 8: selfnoise_allsix.png
selfnoise_allsix.png
  9013   Thu Aug 15 09:34:12 2013 SteveUpdateGeneralWilcoxon cables rescued

Eric and Steve,

 We removed Wilcoxon Accelerometer PS and Amplifier unit under the BS optical tabel yesterday. The six cabels going to DAQ  were labeled and left in place. Gain setting were 100, except channel 3 was 10.

The ~ 40 m long 2 sets of 3 cables were very happy to get their kinks out. Especially the set going just south of ITMX optical  table.

We have to take better care of these cables! Your data will be useless this way.

Attachment 1: rescuedGraycables.jpg
rescuedGraycables.jpg
Attachment 2: wilconoxOut.jpg
wilconoxOut.jpg
Attachment 3: chanGains.jpg
chanGains.jpg
  2560   Tue Feb 2 15:30:03 2010 AlbertoFrogsTreasureWild Oats
FYI. Sitting on the top shelf of George I found an opened jar of raspberry jam and an opened jar of creamy peanut butter. Both are branded Wild Oats Market.
 
Wikipedia:
"Wild Oats Markets was an operator of natural foods stores and farmers markets in North America... Whole Foods officially completed their buyout of Wild Oats on August 27, 2007 [...]"
  2373   Wed Dec 9 18:01:06 2009 KojiUpdateCOCWiping finished

[Kiwamu, Jenne, Alberto, Steve, Bob, Koji]

We finished wiping of four test masses without any trouble. ITMY looked little bit dusty, but not as much as ITMX did.
We confirmed the surface of the ITMX again as we worked at vertex a lot today. It still looked clean.

We closed the light doors. The suspensions are left free tonight in order to check their behavior.
Tomorrow morning from 9AM, we will replace the door to the heavy ones.

  1101   Thu Oct 30 11:07:25 2008 YoichiUpdateComputersWireless bridges arrived
Five wireless bridges for the GPIB-Ethernet converters arrived.
One of them had a broken AC adapter. We have to send it back.
I configured the rest of the bridges for the 40MARS wireless network.
One of them was installed to the SR785.
I put the remaining ones in the top drawer of the cabinet, on which the label printers are sitting.
You can use those to connect any network device with a LAN port to the 40MARS network.
  2347   Mon Nov 30 11:45:54 2009 JenneUpdateComputersWireless is back

When Alberto was parting the Red Sea this morning, and turning it green, he noticed that the wireless had gone sketchy.

When I checked it out, the ethernet light was definitely blinking, indicating that it was getting signal.  So this was not the usual case of bad cable/connector which is a known problem for our wireless (one of these days we should probably relay that ethernet cable....but not today).  After power cycling and replugging the ethernet cable, the light for the 2.4GHz wireless was blinking, but the 5GHz wasn't.  Since the wireless still wasn't working, I checked the advanced configuration settings, as described by Yoichi's wiki page:  40m Network Page

The settings had the 5GHz disabled, while Yoichi's screenshots of his settings showed it enabled.  Immediately after enabling the 5GHz, I was able to use the laptop at Alberto's length measurement setup to get online.  I don't know how the 5GHz got disabled, unless that happened during the power cycle (which I doubt, since no other settings were lost), but it's all better now.

 

  1668   Thu Jun 11 14:54:18 2009 josephb, albertoUpdateComputersWireless network

After poking around for a few minutes several facts became clear:

1) At least one GPIB interface has a hard ethernet connection (and does not currently go through the wireless).

2) The wireless on the laptop works fine, since it can connect to the router.

3) The rest of the martian network cannot talk to the router.

This led to me replugging the ethernet cord back into the wireless router, which at some point in the past had been unplugged.  The computers now seem to be happy and can talk to each other.

 

  6463   Wed Mar 28 21:15:53 2012 ranaOmnistructureComputersWireless router for GC

I installed a NETGEAR Wireless Router (WPN824N) today on the 131 network. The admin password for it as well as the wireless access password are in the usual places.

The SSID is 40EARTH. I have set it to allow WPA as well as WPA2 access, so the speed is only 54 Mbps for now. In a year or so, we can turn off the WPA support and up the speed.

  6465   Thu Mar 29 13:23:05 2012 JenneOmnistructureComputersWireless router for GC

Quote:

I installed a NETGEAR Wireless Router (WPN824N) today on the 131 network. The admin password for it as well as the wireless access password are in the usual places.

The SSID is 40EARTH. I have set it to allow WPA as well as WPA2 access, so the speed is only 54 Mbps for now. In a year or so, we can turn off the WPA support and up the speed.

 This router was confiscated by the GC guys this morning around ~10am.  They barged in and said that someone at the 40m had connected a new router, and we had magically taken down half of the GC network.  The cable was plugged in to the wrong port on the back of the router. 

Junaid / Christian said that they would "secure" the router, and then reinstall it.  Apparently just having a password didn't satisfy them.  This was the compromise, versus them just taking the router and never bringing it back.

 

Attachment 1: IMG_0079.JPG
IMG_0079.JPG
  6467   Thu Mar 29 19:13:56 2012 JamieOmnistructureComputersWireless router for GC

I retrieved the newly "secured" router from Junaid.  It had apparently been hooked up to the GC network via it's LAN port, but it's LAN services had no been shut off.  It was therefore offering a competing DHCP server, which will totally hose a network.  A definite NONO.

The new SSID is "40mWiFi", it's WPA2, and the password is pasted to the bottom of the unit (the unit is back in it's original spot on the office computer rack.

  12649   Wed Nov 30 11:56:56 2016 LydiaUpdateCDSWiring for Acromag auxex replacement

I've attached a schematic for how we will connect the Acromag mosules to the slow channel I/O curently going to c1auxex. The following changes are made:

  • We are getting rid of the slow readbacks from the Anti-Image and Oplev boards, as Rana says they are unnnecessary.
  • The whitening switching for the QPD is currently done by a Contec "fast" binary I/O module, but can be managed by acromag instead. This alllows CAB_1Y9_34 to  be fed directly into the Acromag box since all of its connections can now be managed slow. 
  • There's no need to change the PD whitening scheme around (since the signals never get huge), so we can set those to always be on and then lose those Contec channels. This means all of the necessary pins on CAB_1Y9_10 can go to Acromag. 
  • All the other backplane cables go the the fast machines only. 

 

Attachment 1: auxex_acromag.pdf
auxex_acromag.pdf
  14287   Fri Nov 9 22:24:22 2018 JonOmnistructure Wiring of Vacuum Acromag Chassis Complete

Wiring of the power, Ethernet, and indicator lights for the vacuum Acromag chassis is complete. Even though this crate will only use +24V DC, I wired the +/-15V connector and indicator lights as well to conform to the LIGO standard. There was no wiring diagram available, so I had to reverse-engineer the wiring from the partially complete c1susaux crate. Attached is a diagram for future use. The crate is ready to begin software developing on Monday. 

Attachment 1: IMG_2987.jpg
IMG_2987.jpg
Attachment 2: IMG_2985.jpg
IMG_2985.jpg
Attachment 3: IMG_2986.jpg
IMG_2986.jpg
  4839   Mon Jun 20 11:04:03 2011 NicoleUpdateSUSWork Plan for Week 2

Here is my work plan for this week:

Current Week Plan (Week 2) (As of 6/17/11)

 

Setting Up for Horizontal Displacement Measurements

1) Help Steve clean small table for experiment

2) Remove aluminum base from TT suspension

3) Mount shaker onto table base

4) Mount horizontal slider onto table base

5) Connect TT suspension, shaker, and horizontal slider

Begin Assembly of Sensors

1) Begin building circuit for displacement photosensors

2) Calibrate photosensor using linear regions of power versus distance curves

3) Circuit box for photosensors?

ELOG V3.1.3-