40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 18 of 335  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  14093   Fri Jul 20 22:53:15 2018 KojiUpdateASSAttempt to resurrect Yarm ASS

[Koji Gautam]

We managed to realize stable ASS configuration for Yarm. The transmission of 1.06~1.07 was recovered by introducing intentional beam spot offset in the horizontal direction towards the opposite side of the elliptic reflector. The end table optics were adjusted to have the spots about the center of the mirrors, lenses, and PDs/QPDs.


Preparation

- The Y arm was manually aligned with a given input axis. The transmission was ~0.8.
- Then, TT2 was moved in yaw such that it introduced the horizontal beam shift at the end. By moving the spot to the opposite side of the reflector. The transmission ~0.95 was obtained after patient alignment work.

- Went to the end table and checked the spots. The beam was not at the center of the last 1" lens for the Trans PDs. The beam steering was adjusted to have the spot nicely going through the lens and the mirrors. This made the transmission level to be ~1.05.

- The beam centering on the Trans PD was checked and adjusted.
- The beam centering on the RF BBPD for the arm scan was checked. The spot was too big for that PD. The lens was slightly moved away from the PD to make the spot on the BBPD small. Now the PD saw the plateu when the steering was scanned (i.e. the spot is small enough).

- With the Y arm locked with MC2, the servo gain needs to be 0.012 instead of nominal 0.015 with ETMY to prevent from servo oscilating.

ASS tuning

- First of all, only the bottom 4 loops out of total 8 loops were tuned. They are the servos for the beam alignment with regard to the caivty. The linearity and the zero crossings were checked with regard to the reference alignment. All of these 4 showed offsets that causes the servo running away. Don't know the reason of this offset, but it is freq dependent. Therefore the dither freqs were tuned to make the offset zeroed, and tuned the demod phases there. This kept the transmission as high as the reference (~1.05)

- This allowed us to play with the spot position a bit by tuning the caivty alignment. In the end, the transmission of ~1.08 was obtained. Using this alignment, A2L offset for ETMY Yaw was determined to be +17 (to make the error signal -17). This offset produces almost a beam radius (5mm) shifted on the end mirror towards the opposite direction of the reflector.

- The nominal servo setting made the spot servo running away. Gautam pointed out that this could be a gain hierarchy problem (i.e. the spot servos are too fast). We ended up reducing the gain of the servo from 1.0 to 0.3 to make the spot servo stable.

- All the ASS setting was stored in a new snap file "script/ASS/ASS-DITEHR_ON.snap". The previous snap was saved to "script/ASS/ASS_DITHER_ON_preVent201807.snap". This did not save the exc gains of the oscillators. Therefore "DITHER_ASS_ON.py" was modified to have the new exc gains (CLKGAIN). The old values are stored in the comments in this script.


Overall this is not an ideal situation as we don't know what is the actually cause of the offsets in the dither error signals. We expect to correct the beam clipping and the suspension sooner or later. Therefore, we will come back to the ASS again once the other issues are corrected.

Attachment 1: 02.png
02.png
  14132   Fri Aug 3 19:02:11 2018 gautamUpdateASSX arm ASS recovery

[koji, gautam]

After I effected the series resistance change for ETMX, the X arm ASS didn't work (i.e. IR transmission would degrade if the servo was run). Today, we succeeded in recovering a functional ASS servo yes.

So both arms have working dither alignment servos now. But remember that the Y arm ASS gains have been set for locking the Y arm with MC2 as the actuator, not ETMY.

Details:

  • Koji pointed out that the demodulated signals from the ETM dither are only used to center the spot on the ETM, and that we should first run the servo with existing settings with the ETM pitch and yaw spot centering loops disabled.
    • This improved TRX level from ~0.8 to 1.1
  • Next, we tried increasing the LO amplitudes by x5 to account for the reduced actuation of the dither on ETMX
    • We then re-enabled the two loops that were earlier disabled.
    • This resulted in TRX degrading very quickly.
  • So we decided to try going back to the nominal LO gains, and reducing the gain of the two ETM spot centering loops.
    • This did the trick, TRX went from 1.1 --> ~1.23, which is the nominal maximum pre-vent value.
  • The snap file used to recover the correct settings to run the dither alignment servos have been updated, the old one has been backed up with today's datestamp.

We then tried to maximize GTRX using the PZT mirrors, but were only successful in reaching a maximum of 0.41. The value I remember from before the vent was 0.5, and indeed, with the IR alignment not quite optimized before we began this work, I saw GTRX of 0.48. But the IR dither servo signals indicate that the cavity axis may have shifted (spot position on the ITM, which is uncontrolled, seems to have drifred significantly, the Pitch signal doesn't stay on the StripTool scale anymore). So we may have to double check that the transmitted beam isn't falling off the GTRX DC PD.

  14161   Tue Aug 14 00:50:32 2018 gautamUpdateASSX arm ASS still not quite right?

While working on the single arm alignment, I noticed that today, i was able to get the X arm transmission back to ~1.22, and the GTRX to 0.52. These are closer to the values I remember from prior to the vent. Running the dither alignment promptly degrades both the green and IR transmissions. Since the pianosa SL7 upgrade, I can't use the sensoray to capture images, but to me, the spot looks a little off-center in Yaw on ETMX in this configuration, I've tried to show this in the phone grab (Atm #2). Maybe indicative of clipping somewhere upstream of ITMX?

Anyways, I'm pushing onwards for now, something to check out in the daytime.

Quote:

[koji, gautam]

After I effected the series resistance change for ETMX, the X arm ASS didn't work (i.e. IR transmission would degrade if the servo was run). Today, we succeeded in recovering a functional ASS servo yes.

We then tried to maximize GTRX using the PZT mirrors, but were only successful in reaching a maximum of 0.41. The value I remember from before the vent was 0.5, and indeed, with the IR alignment not quite optimized before we began this work, I saw GTRX of 0.48. But the IR dither servo signals indicate that the cavity axis may have shifted (spot position on the ITM, which is uncontrolled, seems to have drifred significantly, the Pitch signal doesn't stay on the StripTool scale anymore). So we may have to double check that the transmitted beam isn't falling off the GTRX DC PD.

Attachment 1: POXPOY.png
POXPOY.png
Attachment 2: IMG_7108.JPG
IMG_7108.JPG
  14466   Tue Feb 19 22:52:17 2019 gautamUpdateASSY arm clipping doubtful

In an earlier elog, I had claimed that the suspected clipping of the cavity axis in the Y arm was not solved even after shifting the heater. I now think that it is extremely unlikely that there is still clipping due to the heater. Nevertheless, the ASS system is not working well. Some notes:

  1. The heater has been shifted nearly 1-inch relative to the cavity axis compared to its old position - see Attachment #1 which compares the overhead shot of the suspension cage before and after the Jan 2019 vent.
  2. On Sunday, I was able to recover TRY ~ 1.0 (but not as high as I was able to get by intentionally setting a yaw offset to the ASS) by hand alignment with the spot on ETMY much closer to the center of the optic, judging by the camera. There are offsets on the dither alignment error signals which depend on the dither frequency, so the A2L signals are not good judges of how well centered we are on the optic.
  3. By calculating the power lost by clipping a Gaussian beam cross-section with a rectangular block from one side (an admittedly naive model of clipping), I find that we'd have to be within 15 mm of the line connecting the centers of ITMY and ETMY to even see ~10 ppm loss, see Attachment #2. So it is hard to believe that this is still a problem. Also, see  Attachment #3 which compares side-by-side the view of ETMY as seen through the EY optical table viewport before and after the Jan 2019 vent.

We have to systematically re-commission the ASS system to get to the bottom of this.

Attachment 1: overheadComparison.pdf
overheadComparison.pdf
Attachment 2: clipping.pdf
clipping.pdf
Attachment 3: rearComparison.pdf
rearComparison.pdf
  14614   Thu May 16 22:58:25 2019 gautamUpdateASSIn air ASS test with green?

We were wondering yesterday if we can somehow test the ASS system in air. Though the arm cavity can be locked with the low power IMC transmission, I think the dither would render the POY lock unstable. But I wonder if we can use the green beam for a test. The steering PZTs installed by Yuki can serve the role of TT1/TT2 and we can dither the arm cavity mirrors while the green TEM00 mode is locked to the arm no problem. This would at least give us confidence that the actuation of ETMY/ITMY are okay (in addition to the other suspension tests). Then on the sensing side, after pumping down, the only thing we'd be foiled by is in-vacuum clipping or some major gunk on ETMY - everything else should be de-buggable even after pumping down?

I think most of the CDS infrastructure for this is already in place.

  14766   Wed Jul 17 03:05:01 2019 KruthiUpdateASSMC spot position measurement scripts

[Kruthi, Gautam, Rana]

Gautam installed Atom text editor on Pianosa yesterday.


MC spot position measurement scripts (these can be found in /scripts/ASS/MC directory)

  • Changed the power threshold for MC2 lock loss check from 15000 to 12000 (volts) in the MeasureSpotPositions.py script. This is because, the C1:I00-MC_TRANS_SUM reads a value, usually, greater than 14000 and with 15000 as the threshold, the script will always say the MC isn't locked even though it is!. Also, to account for additional variation we have a margin of 2000.
  • Issues with datetime: though MeasureSpotPositions.py was creating a .dat file, MC_spotMeasurement_history.py threw an error because the .dat file's name was not in the required format. I fixed this bug.
  • Just running the MeasureSpotPositions.py doesn't enter the results into the log file, instead ./mcassMCdecenter should be run
  • MC_spotMeasurement_history.py just plots the spot positions (in mm) vs days since 2013, using the log file. It still has some bugs
  16282   Wed Aug 18 20:30:12 2021 AnchalUpdateASSFixed runASS scripts

Late elog: Original time of work Tue Aug 17 20:30 2021


I locked the arms yesterday remotely and tried running runASS.py scripts (generally ran by clicking Run ASS buttons on IFO OVERVIEW screen of ASC screen). We have known for few weeks that this script stopped working for some reason. It would start the dithering and would optimize the alignment but then would fail to freeze the state and save the alignment.

I found the caget('C1:LSC-TRX_OUT') or caget('C1:LSC-TRY_OUT') were not working in any of the workstations. This is weird since caget was able to acquire these fast channel values earlier and we have seen this script to work for about a month without any issue.

Anyways, to fix this, I just changed the channel name to 'C1:LSC-TRY_OUT16' when the script checks in the end if the arm has indeed been aligned. It was only this step that was failing. Now the script is working fine and I tested them on both arms. On the Y arm, I misaligned the arm by adding bias in yaw by changing C1:SUS-ITMY_YAW_OFFSET from -8 to 22. The script was able to align the arm back.

  14010   Sat Jun 23 13:08:41 2018 JonUpdateAUXFirst Coherent AUX Scan of PRC Using AM Sidebands

[Jon, Keerthana, Sandrine]

Thu.-Fri. we continued with PRC scans using the AUX laser, but now the "scanned" parameter is the frequency of AM sidebands, rather than the frequency of the AUX carrier itself. The switch to AM (or PM) allows us to coherently measure the cavity transfer as a function of modulation frequency.

In order to make a sentinel measurement, I installed a broadband PDA255 at an unused pickoff behind the first AUX steering mirror on the AS table. The sentinel PD measures the AM actually imprinted on the light going into the IFO, making our measurement independent of the AOM response. This technique removes not only the (non-flat) AOM transfer function, but also any non-linearities from, e.g., overdriving the AOM. The below photo shows the new PD (center) on the AS table.

With the sentinel PD installed, we proceeded as follows.

  • Locked IFO in PRMI on carrier.
  • Locked AUX PLL to PSL.
  • Tuned the frequency of the AUX laser (via the RF offset) to bring the carrier onto resonance with the PRC.
  • Swept the AOM modulation frequency 0-60 MHz while measuring the AUX reflection and injection signals.

The below photo shows the measured transfer function [AUX Reflection / AUX Injection]. The measurement coherence is high to ~55 MHz (the AOM bandwidth is 60 MHz). We clearly resolve two FSRs, visible as Lorentzian dips at which more AUX power couples into the cavity. The SURFs have these data and will be separately posting figures for the measurements.

With the basic system working, we attempted to produce HOMs, first by partially occluding the injected AUX beam with a razor blade, then by placing a thin two-prong fork in the beam path. We also experimented with using a razor blade on the output to partially occlude the reflection beam just before the sensor. We were able to observe an apparent secondary dip indicative of an HOM a few times, as shown below, but could not repeat this deterministically. Besides not having fine control over the occlusion of the beams, there is also large few-Hz angular noise shaking the AS beam position. I suspect from moment to moment the HOM content is varying considerably due to the movement of the AS beam relative to the occluding object. I'm now thinking about more systematic ways to approach this.

 

  14011   Sat Jun 23 20:54:35 2018 KojiUpdateAUXFirst Coherent AUX Scan of PRC Using AM Sidebands

How much was the osc freq of the marconi? And then how much was the resulting freq offset between PSL and AUX?

Are we supposed to see two dips with the separation of an FSR? Or four dips (you have two sidebands)?

And the distance between the dips (28MHz-ish?) seems too large to be the FSR (22MHz-ish).
cf https://wiki-40m.ligo.caltech.edu/IFO_Modeling/RC_lengths

  14017   Tue Jun 26 10:06:39 2018 keerthanaUpdateAUXFirst Coherent AUX Scan of PRC Using AM Sidebands

(Jon, Keerthana, Sandrine)

I am attaching the plots of the Reflected and transmitted AUX beam. In the transmission graph, we are getting peak corresponding to the resonance frequencies, as at that frequency maximum power goes to the cavity. But in the Reflection graph, we are obtaining dips corresponding to the resonance frequency because maximum power goes to the cavity and the reflected beam intensity becomes very less at those points.

 

Attachment 1: TRANS.pdf
TRANS.pdf
Attachment 2: REFL.pdf
REFL.pdf
  14035   Tue Jul 3 11:59:10 2018 JonUpdateAUXAUX Carrier Scan of Y-Arm Cavity

I made the first successful AUX laser scan of a 40m cavity last night.

Attachment #1 shows the measured Y-end transmission signal w.r.t. the Agilent drive signal, which was used to sweep the AUX carrier frequency. This is a distinct approach from before, where the carrier was locked at a fixed offset from the PSL carrier and the frequency of AM sidebands was swept instead. This AUX carrier-only technique appears to be advantageous.

This 6-15 MHz scan resolves three FSR peaks (TEM00 resonances) and at least six other higher-order modes. The raw data are also enclosed (attachment #2). I'll leave it as an excercise for the SURFs to compute the Y-arm cavity Gouy phase.

Attachment 1: yarm_carrier_trans.pdf
yarm_carrier_trans.pdf
Attachment 2: AG4395A_02-07-2018_185504.txt
# AG4395A Measurement - Timestamp: Jul 02 2018 - 18:55:04
#---------- Measurement Parameters ------------
# Start Frequency (Hz): 6000000.0, 6000000.0
# Stop Frequency (Hz): 15000000.0, 15000000.0
# Frequency Points: 801, 801
# Measurement Format: LOGM, PHAS
# Measuremed Input: AR, AR
#---------- Analyzer Settings ----------
# Number of Averages: 16
# Auto Bandwidth: Off, Off
... 807 more lines ...
  14036   Wed Jul 4 19:11:49 2018 JonUpdateAUXMore Testing of AUX-Laser Mode Scanning

More progress on the AUX-laser cavity scans.

Changes to the Setup

  • For scans, the Agilent is now being used as a standalone source of the LO signal provided to the AUX PLL (instead of the Marconi), which sets the RF offset. We discovered that when the sweep is "held" in network analyzer mode, it does not turn off the RF drive signal, but rather continues outputting a constant signal at the hold frequency. This eliminates the need to use the more complicated double-deomdulation previously in use. The procedure is to start and immediately hold the sweep, then lock the PLL, then restart the sweep. The PLL is able to reliably remain locked for frequency steps of up to ~30 kHz. The SURFs are preparing schematics of both the double- and single-demodulation techniques.
  • Both the Marconi and Agilent are now phase-locked to the 10 MHz time reference provided by the rabidium clock. This did noticeably shift the measured resonance frequencies.
  • I raised the PI controller gain setting to 4.5, which seems to better suppress the extra noise being injected.
  • I've procured a set of surgical needles for occluding the beam to produce HOMs. However, I have not needed to use them so far, as the TEM00 purity of the AUX beam appears to already be low. The below scans show only the intrinisic mode content.

New Results

  • YARM scan at 70 uW injection power (Attachment #1). The previously reported YARM scan was measured with 9 mW of injected AUX power, 100x larger than the power available from the SQZ laser at the sites. This scan repeats the measurement with the AUX power attenuated to uW. It still resolves the FSR and at least three HOMs.
  • PRC scan (Attachment #2) at 9 mW injection power. It appears to resolve the FSR and at least three HOMs. Angular injection noise was found to cause large fluctuations in the measured signal power. This dominates the error bars shown below, but affects only the overall signal amplitude (not the peak frequency locations). The SQZ angular alignment loops should mitigate this issue at the sites.

Both data sets are attached.

Attachment 1: yarm_trans_70uW.pdf
yarm_trans_70uW.pdf
Attachment 2: prc_trans_9mW.pdf
prc_trans_9mW.pdf
Attachment 3: yarm_carrier_trans_70uW.tar.gz
Attachment 4: prc_carrier_trans_9mW.tar.gz
  14044   Sun Jul 8 12:20:12 2018 JonSummaryAUXGouy Phase Measurements from AUX-Laser Scans

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

Y-Arm Scan

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

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

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

PRC Scan

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

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

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

SRC Scan

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

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

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

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

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

Lessons Learned

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

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

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

 

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

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

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

FSR = Free spectral Range

L = Lenth of the arm

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

Quote:

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

Y-Arm Scan

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

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

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

 

 

  14062   Fri Jul 13 00:15:13 2018 Annalisa, TerraConfigurationAUXY arm cavity scan

[Annalisa, Terra, Koji, Gautam]

Summary: We find a configuration for arm scans which significantly reduces phase noise. We run several arm scans and we were able to resolve several HOM peaks; analysis to come.

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

As first, we made a measurement with the already established setup and, as Jon already pointed out, we found lots of phase noise. We hypothesized that it could either come from the PLL or from the motion of the optics between the AUX injection point (AS port) and the Y arm. 

  • We first characterized the PLL loop phase noise by comparing the beat signal against the Agilent reference signal, and we found that the beat had lots of phase noise with respect to the reference. Decreasing the PLL gain, we got rid of the phase noise in the beat signal.
  • Next, for the optical path length induced phase noise, we took the transfer function between TransMon and REFL signal rather than TransMon and Agilent reference signal. This takes advatage of the fact that the TransMon and REFL both see optical path length phase noise, which therefore gets canceled out in the transfer function. 

In this configuration, we were able to do arm scans where the phase variation at each peak was pretty clear and well defined. We took several 10MHz scan, we also zoomed around some specific HOM peak, and we were able to resolve some frequency split. 

We add some pictures of the setup and of the scan.

The data are saved in users/OLD/annalisa/Yscans. More analysis and plots will follow tomorrow. 

Attachment 1: IMG_6492.JPG
IMG_6492.JPG
Attachment 2: IMG_6494.JPG
IMG_6494.JPG
  14091   Fri Jul 20 18:30:47 2018 JonConfigurationAUXRecommend to install AUX PZT driver

I recently realized that the PLL is only using about 20% of the available actuation range of the AUX PZT. The +/-10 V control signal from the LB1005 is being directly inputted into the fast AUX PZT channel, which has an input range of +/-50 V.

I recommend to install a PZT driver (amplifier) between the controller and laser to use the full available actuator range. For cavity scans, this will increase the available sweep range from +/-50 MHz to +/-250MHz. This has a unique advantage even if slow temperature feedback is also implemented. To sample faster than the timescale of most of the angular noise,  scans generally need to be made with a total sweep time <1 sec. This is faster than the PLL offset can be offloaded via the slow temperature control, so the only way to scan more than 100 MHz in one measurement is with a larger dynamic range.

  14501   Fri Mar 29 15:47:58 2019 gautamUpdateAUXAUX laser fiber moved from AS table to PSL table

[anjali, gautam]

To facilitate the 1um MZ frequency stabilization project, I decided that the AUX laser was a better candidate than any of the other 3 active NPROs in the lab as (i) it is already coupled into a ~60m long fiber, (ii) the PSL table has the most room available to set up the readout optics for the delayed/non-delayed beams and (iii) this way I can keep working on the IR ALS system in parallel. So we moved the end of the fiber from the AS table to the SE corner of the PSL table. None of the optics mode-matching the AUX beam to the interferometer were touched, and we do not anticipate disturbing the input coupling into the fiber either, so it should be possible to recover the AUX beam injection into the IFO relatively easily.

Anjali is going to post detailed photos, beam layout, and her proposed layout/MM solutions later today. The plan is to use free space components for everything except the fiber delay line, as we have these available readily. It is not necessarily the most low-noise option, but for a first pass, maybe this is sufficient and we can start building up a noise budget and identify possible improvements.

The AUX laser remians in STANDBY mode for now. HEPA was turned up while working at the PSL table, and remains on high while Anjali works on the layout.

  14504   Sun Mar 31 18:39:45 2019 AnjaliUpdateAUXAUX laser fiber moved from AS table to PSL table
  • Attachment #1 shows the schematic of the experimental setup for the frequency noise measurement of 1 um laser source.

  • AUX laser will be used as the seed source and it is already coupled to a 60 m fiber (PM980). The other end of the fiber was at the AS table and we have now removed it and placed in the PSL table.

  • Attachment # 2 shows the photograph of the experimental setup. The orange line shows the beam that is coupled to the delayed arm of MZI and the red dotted line shows the undelayed path.

  • As mentioned, AUX is already coupled to the 60 m fiber and the other end of the fiber is now moved to the PSL table. This end needs to be collimated. We are planning to take the same collimator from AS table where it was coupled into before. The position where the collimator to be installed is shown in attachment #2. Also, we need to rotate the mirror (as indicated in attachment #2) to get the delayed beam along with the undelayed beam and then to combine them. As indicated in attachment #2, we can install one more photo diode to perform  balanced detection.

  • We need to decide on which photodetector to be used. It could be NF1801 or PDA255.

  • We also performed the power measurement at different locations in the beam path. The different locations at which power measurement is done is shown attachment #3

  • There is an AOM in the beam path that coupled to the delayed arm of MZI. The output beam after AOM was coupled to the zero-order port during this measurement. That is the input voltage to the AOM was at 0 V, which essentially says that the beam after the AOM is not deflected and it is coupled to the zero-order port. The power levels measured at different locations in this condition are as follows. A)282 mW B)276 mW C)274 mW D)274 mW E)273 mW F)278 mW G)278 mW H)261 mW I)263 mW J)260 mW K)131 mW L)128 mW M)127 mW N)130 mW

  • It can be seen that the power is halved from J to K. This because of a neutral density filter in the path of the beam

  • In this case, we measured a power of 55 mW at the output of the delayed fiber. We then adjusted the input voltage to the AOM driver to 1 V such that the output of AOM is coupled to the first order port. This reduced the power level in the zero-order port of AOM that is coupled to the delayed arm of the MZI. In this case we measured a power of 0.8 mW at the output of delayed fiber.

  •  We must be careful about the power level that is reaching the photodetector such that it should not exceed the damage threshold of the detector.

  • The power measured at the output of undelayed path is 0.8 mW.

  • We also must place the QWP and HWP in the beam path to align the polarisation.

Quote:

[anjali, gautam]

To facilitate the 1um MZ frequency stabilization project, I decided that the AUX laser was a better candidate than any of the other 3 active NPROs in the lab as (i) it is already coupled into a ~60m long fiber, (ii) the PSL table has the most room available to set up the readout optics for the delayed/non-delayed beams and (iii) this way I can keep working on the IR ALS system in parallel. So we moved the end of the fiber from the AS table to the SE corner of the PSL table. None of the optics mode-matching the AUX beam to the interferometer were touched, and we do not anticipate disturbing the input coupling into the fiber either, so it should be possible to recover the AUX beam injection into the IFO relatively easily.

Anjali is going to post detailed photos, beam layout, and her proposed layout/MM solutions later today. The plan is to use free space components for everything except the fiber delay line, as we have these available readily. It is not necessarily the most low-noise option, but for a first pass, maybe this is sufficient and we can start building up a noise budget and identify possible improvements.

The AUX laser remians in STANDBY mode for now. HEPA was turned up while working at the PSL table, and remains on high while Anjali works on the layout.

 

Attachment 1: Schematic_of_experimental_setup_for_frequency_stabilisation_of_1_micron_source.png
Schematic_of_experimental_setup_for_frequency_stabilisation_of_1_micron_source.png
Attachment 2: 1_micron_setup_for_frequency_noise_measurement.JPG
1_micron_setup_for_frequency_noise_measurement.JPG
Attachment 3: 1_micron_setup_for_frequency_noise_measurement_power_levels.png
1_micron_setup_for_frequency_noise_measurement_power_levels.png
  16194   Wed Jun 9 11:46:01 2021 Anchal, PacoSummaryAUXXend Green Laser PDH OLTF measurement

We measured the Xend green laser PDH Open loop transfer function by following method:

  • We first measured the feedback transfer function 'K' directly.
    • See attachment 2 for this measurement. We measured Out2/exc here.
  • Then, we closed the loop as shown in attachment 1with SR560 as a summing juntion at error point.
    • We injected excitation through B channel in SR560 and measured transfer function Out1/Out2.
    • This measurement should give us G_{OL} / K by loop alegbra.
  • Then we multiplied the two transfer function measurements to get open loop transfer function.

Result:

  • Our measurement gives the same UGF of 10kHz and phase margin of 53.5 degrees as reported in 13238.
  • The shape of measurement also follows 1/f above 10 Hz atleast.
  • Our measurement might not be correct below 10 Hz but we did not see any saturation or loss of lock in 1Hz to 10 Hz measurement.
  • This OLTF is different from the modelled OLTF here even though the UGF matches.
  • The feedback gain is supposed to roll-off faster than 1/f in 30Hz to 1kHz region but it does not seem to in our measurement.
  • This suggests that the actual uPDH box is shaping the loop different from what schematic suggests. This might mean that the gain is much lower in the low frequency region than we would like it to be.
  • We will investigate the reason of difference between model and measurement unless someone has a better explaination for the descripancy.
Attachment 1: image-6f2923a3-01ce-4d04-bc53-d8db0238e195.jpg
image-6f2923a3-01ce-4d04-bc53-d8db0238e195.jpg
Attachment 2: image-72223f4b-3b74-4574-a7ad-de6628a2c5e9.jpg
image-72223f4b-3b74-4574-a7ad-de6628a2c5e9.jpg
Attachment 3: X_Green_ARM_PDH_OLTF.pdf
X_Green_ARM_PDH_OLTF.pdf
  16197   Thu Jun 10 14:01:36 2021 AnchalSummaryAUXXend Green Laser PDH OLTF measurement loop algebra

Attachment 1 shows the closed loop of Xend Green laser Arm PDH lock loop. Free running laser noise gets injected at laser head after the PZT actuation as \eta. The PDH error signal at output of miser is fed to a gain 1 SR560 used as summing junction here. Used in 'A-B mode', the B port is used for sending in excitation \nu_e e^{st} where s = i\omega.

We have access to three ports for measurement, marked \alpha at output of mixer, \beta at output of SR560, and \gamma at PZT out monitor port in uPDH box. From loop algebra, we get following:

\large \left[ (\alpha - \nu_e) K(s)A(s) + \eta \right ]C(s)D(s) = \alpha

\large \Rightarrow (\alpha - \nu_e) G_{OL}(s) + \eta C(s)D(s) = \alpha, where \large G_{OL}(s) = C(s) D(s) K(s) A(s) is the open loop transfer function of the loop.

\large \Rightarrow \alpha = \eta \frac{C(s) D(s)}{1 - G_{OL}(s)} \quad -\quad \nu_e\frac{G_{OL}(s)}{1 - G_{OL}(s)}

\large \Rightarrow \beta = \eta \frac{C(s) D(s)}{1 - G_{OL}(s)} \quad -\quad \nu_e\frac{1}{1 - G_{OL}(s)}

\large \Rightarrow \gamma = \eta \frac{1}{K(s)} \frac{G_{OL}(s)}{1 - G_{OL}(s)} \quad -\quad \nu_e\frac{K(s)}{1 - G_{OL}(s)}

So measurement of \large G_{OL}(s) can be done in following two ways (not a complete set):

  1. \large G_{OL}(s) \approx \frac{\alpha}{\beta} = \frac{G_{OL}(s) - \frac{\eta C(s)D(s)}{\nu_e}}{1 - \frac{\eta C(s)D(s)}{\nu_e}}, if excitation amplitude is large enough such that \large \frac{\eta C(s)D(s)}{\nu_e} \ll 1over all frequencies.
    • In this method however, note that SR785 would be taking ratio of unsuppresed excitation at \large \alpha with suppressed excitation at \large \beta.
    • If the closed loop gain (suppression) \large 1/(1 - G_{OL}(s))is too much, the excitation signal might drop below noise floor of SR785 while measuring \large \beta.
    • This would then appear as a flat response in the transfer function.
    • This happened with us when we tried to measure this transfer function using this method. Below few hundered Hz, the measurement will become flat at around 40 dB.
    • Increasing the excitation amplitude where suppression is large should ideally work. We even tried to use Auto level reference option in SR785.
    • But the PDH loop gets unlocked as soon as we put exciation above 35 mV at this point in this loop.
  2. \large \frac{G_{OL}(s)}{K(s)} \approx \frac{\alpha}{\gamma} = \frac{G_{OL}(s) - \frac{\eta C(s)D(s)}{\nu_e}}{K(s)\left(1 - \frac{\eta C(s)D(s)}{\nu_e}\right )}, if excitation amplitude is large enough such that \large \frac{\eta C(s)D(s)}{\nu_e} \ll 1over all frequencies.
    • In this method, channel 1 (denominator) on SR785 would remain high in amplitude throughout the measurement avoiding the above issue of suppression below noise floor.
    • We can easily measure the feedback transfer funciton \large K(s) with the loop open. Then multiplying the two measurements should give us estimate of open loop transfer function.
    • This is waht we did in 16194. But we still could not increase the excitation amplitude beyond 35 mV at injection point and got a noisy measurement.
    • We checked yesterday coherence of excitation signal with the three measurment points \large \alpha, \beta, \gamma and it was 1 throughout the frequency region of measurement for excitation amplitudes above 20 mV.
    • So as of now, we are not sure why our signal to noise was so poor in lower frequency measurement.
Attachment 1: AUX_PDH_LOOP.pdf
AUX_PDH_LOOP.pdf
  16200   Mon Jun 14 18:57:49 2021 AnchalUpdateAUXXend is unbearably hot. Green laser is loosing lock in 10's of seconds

Working in Xend with mask on has become unbearable. It is very hot there and I would really like if we fix this issue.


Today, the Xend Green laser was just unable to hold lock for longer than 10's of seconds. The longest I could see it hold lock was for about 2 minutes. I couldn't find anything obviously wrong with it. Attached are noise spectrums of error and control points. The control point spectrum shows good matching with typical free running laser noise.

Are the few peaks above 10 kHz in error point spectrum worrysome? I need to think more about it in a cooler place to make sure.

I wanted to take a high frequency spectrum of error point to make sure that higher harmonics of 250 kHz modulation frequency are not leaking into the PDH box after demodulation. However, the lock could not be maintained long enough to take this final measurement. I'll try again tomorrow morning. It is generally cooler in the mornings.


This post is just an update on what's happening. I need to work more to get some meaningful inferences about this loop.

Attachment 1: XAUX_PDH_Err_In_ASD.pdf
XAUX_PDH_Err_In_ASD.pdf
Attachment 2: XAUX_PZT_Out_Mon_ASD.pdf
XAUX_PZT_Out_Mon_ASD.pdf
  16202   Tue Jun 15 15:26:43 2021 Anchal, PacoSummaryAUXXend Green Laser PDH OLTF measurement loop algebra, excitation at control point

Attachment 1 shows the case when excitation is sent at control point i.e. the PZT output. As before, free running laser noise \eta in units of Hz/rtHz is added after the actuator and I've also shown shot noise being added just before the detector.

Again, we have a access to three output points for measurement. \alpha right at the output of mixer (the PDH error signal), \beta the feedback signal to be applied by uPDH box (PZT Mon) and \gamma the output of the summing box SR560.

Doing loop algebra as before, we get:

\large \alpha = \frac{\eta}{K(s) A(s)} \frac{G_{OL}(s)}{1 - G_{OL}(s)} + \frac{\chi}{C(s) K(s) A(s)} \frac{G_{OL}(s)}{1 - G_{OL}(s)} - \frac{\nu_e}{K(s) } \frac{G_{OL}(s)}{1 - G_{OL}(s)}

\large \beta = \frac{\eta}{A(s)} \frac{G_{OL}(s)}{1 - G_{OL}(s)} + \frac{\chi}{C(s) A(s)} \frac{G_{OL}(s)}{1 - G_{OL}(s)} - \nu_e \frac{G_{OL}(s)}{1 - G_{OL}(s)}

\large \gamma= \frac{\eta}{A(s)} \frac{G_{OL}(s)}{1 - G_{OL}(s)} + \frac{\chi}{C(s) A(s)} \frac{G_{OL}(s)}{1 - G_{OL}(s)} - \nu_e \frac{1}{1 - G_{OL}(s)}

So measurement of \large G_{OL}(s) can be done by

\large G_{OL}(s) \approx \frac{\beta}{\gamma}

  • For frequencies, where \large G_{OL}(s) is large enough, to have an SNR of 100, we need that ratio of \large \nu_e to integrated noise is 100.
  • Assuming you are averaging for 'm' number of cycles in your swept sine measurement, time of integration for the noise signal would be \large \frac{m}{f}where f is the frequency point of the seeping sine wave.
    • This means, the amplitude of integrated laser frequency noise at either \large \beta or \large \gamma would be \large \sqrt{\left(\frac{\eta(f)}{A(f)}\right)^2\frac{f}{m}} = \frac{\eta(f) \sqrt{f}}{A(f)\sqrt{m}}
    • Therefore, signal to laser free running noise ratio at f would be \large S = \frac{\nu_eA(f)\sqrt{m}}{\eta(f) \sqrt{f}}.
    • This means to keep a constant SNR of S, we need to shape the excitation amplitude as \large \nu_e \sim S \frac{\eta(f) \sqrt{f}}{A(f)\sqrt{m}}
    • Putting in numbers for X end Green PDH loop, laser free-running frequency noise ASD is 1e4/f Hz/rtHz, laser PZT actuation is 1MHz/V, then for 10 integration cycles and SNR of 100, we get: \large \nu_e \sim 100 \times \frac{10^4 \sqrt{f}}{f \times10^6 \sqrt{10}} = \frac{30\, mV}{\sqrt{f}}
  • Assuming you are averaging for a constant time \large \tau in swept sine measurement, then the amplitude of integrated laser free noise would be \large \sqrt{\left(\frac{\eta(f)}{A(f)}\right)^2 \frac{1}{\tau}} = \frac{\eta(f) }{A(f)\sqrt{\tau}}
    • In this case, signal to laser free-running noise ratio at f would be \large S = \frac{\nu_eA(f)\sqrt{\tau}}{\eta(f)}
    • This means to keep a constant SNR of S, we need to shape the excitation amplitude as \large \nu_e \sim S\frac{\eta(f)}{A(f)\sqrt{\tau}}
    • Again putting in numbers as above and integration time of 1s, we need an excitation amplitude shape \large \nu_e \sim 100 \times \frac{10^4 }{f \times10^6 \sqrt{1}} = \frac{1\, V}{f}

This means at 100 Hz, with 10 integration cycles, we should have needed only 3 mV of excitation signal to get an SNR of 100. However, we have been unable to get good measurements with even 25 mV of excitation. We tried increasing the cycles, that did not work either.

This post is to summarize this analysis. We need more tests to get any conclusions.

Attachment 1: AuxPDHloop.pdf
AuxPDHloop.pdf
  16213   Fri Jun 18 10:07:23 2021 Anchal, PacoSummaryAUXXend Green Laser PDH OLTF with coherence

We did the measurement of OLTF for Xend green laser PDH loop with excitation added at control point using a SR560 as shown in attachment 1 of 16202. We also measured coherence in our measurement, see attachment 1.


Measurement details:

  • We took the \beta/\gamma measurement as per 16202.
  • We did measurement in two pieces. First in High frequency region, from 1 kHz to 100 kHz.
    • In this setup, the excitation amplitude was kept constant to 5 mV.
    • In this region, the OLTF is small enough that signal to noise ratio is maintained in \gamma (SR560 sum output, measured on CH1). The coherence can be seen to be constant 1 throughout for CH1 in this region.
    • But for \beta (PZT Mon, measured on CH2), the low OLTF actually starts damping both signal and noise and to elevate it above SR785 noise floor, we had a high pass (z:0Hz, p:100kHz, k:1000) SR560 amplifying \beta before measurement (see attachment 2). This amplification has been corrected in Attachment 1. This allowed us to improve the coherence on CH2 to above 0.5 mostly.
  • Second region is from 3 Hz to 1 kHz.
    • In this setup, the excitation was shaped with a low pass (p: 1Hz, k:5) SR560 filter with SR785 source amplitude as 1V.
    • We took 40 averaging cycles in this measurement to improve the coherence further.
    • In this freqeuency region, \beta is mostly coherent as we shaped the excitation as 1/f and due to constant cycle number averaging, the integrated noise goes as 1/\sqrt{f}(see 16202 for math).
    • We still lost coherence in \gamma (CH1) for frequencyes below 100 Hz. the reason is that the excitation is suppressed by OLTF while the noise is not for this channel. So the 1/f shaping of excitation only helps fight against the suppression of OLTF somewhat and not against the noise.
      \gamma = \left( \frac{\eta}{A(s)} - \frac{\nu_e}{G_{OL}(s)} + \frac{\chi}{A(s) C(s)} \right)\frac{G_{OL}(s)}{1-G_{OL}(s)}
    • We need 1/f^2 shaping for this purpose but we were loosing lock with that shaping so we shifted back to 1/f shaping and captured whatever we could.
    • It is clear that the noise takes over below 100 Hz and coherence in CH1 is lost there.

Inferences:

  • Yes, the OLTF does not look how it should look but:
  • The green region in attachment 1 shows the data points where coherence on both CH1 and CH2 was higher than 0.75.  So the saturation measured below 1 kHz, particularly in 100 Hz to 500 Hz (where coherence on both channels is almost 1) is real.
  • This brings the question, what is saturating. As has been suggested before, our excitation signal is probably saturating some internal stage in the uPDH box. We need to investigate this next.
    • It is however very non-intuitive to why this saturation is so non-uniform (zig-zaggy) in both magnitude and phase.
    • In past experiences, whenever I saw somehting saturating, it would cause a flat top response in transfer function.
  • Another interesting thing to note is the reduced UGF in this measurement.
  • UGF is about 40-45 kHz. This we believe is due to reduced mode matching of the green light to the XARM when temperature of the end increases too much. We took the measurement at 6 pm and Koji posted the Xend's temperature to be 30 C at 7 pm in 16206. It certainly becomes harder to lock at hot temperatures, probably due to reduced phase margin and loop gain.
Attachment 1: XEND_PDH_OLTF_with_Coherence.pdf
XEND_PDH_OLTF_with_Coherence.pdf
Attachment 2: Beta_Amp.pdf
Beta_Amp.pdf
  1984   Fri Sep 11 17:07:45 2009 JenneUpdateAdaptive FilteringMinor changes to ASS_TOP_PEM screen.

There was some uncertainty as to which channels were being input into the Adaptive Filtering screen, so I checked it out to confirm.  As expected, the rows on the ASS_TOP_PEM screen directly correspond to the BNC inputs on the PEM_ADCU board in the 1Y6 (I think it's 6...) rack.  So C1:ASS-TOP_PEM_1_INMON corresponds to the first BNC (#1) on the ADCU, etc. 

After checking this out, I put text tags next to all the inputs on the ASS_TOP_PEM screen for all of the seismometers (which had not been there previously).  Now it's nice and easy to select which witness channels you want to use for the adaptation.

  1988   Wed Sep 16 11:58:11 2009 JenneUpdateAdaptive FilteringNew Filters for Adaptive Filtering

When Sanjit and I were looking at the adaptive filtering system on Monday and Friday, we noticed that turning on the Accelerometers (which had been used in the past) seemed to do good things, but that turning on the seismometers (which I just put into the system last week) made the OAF output integrate up.  Rana pointed out that this is an indication of a missing high pass filter.  And indeed, when I put the seismometers in, I neglected to copy the high pass filter at low frequencies, and the low pass at 64Hz from the accelerometer path to the seismometer path.  The accelerometers had a HP at 1Hz, which is okay since they don't really do useful things down to the mHz level.  I gave all of the seismometers HP at 1mHz.  These are now in the filter banks in the ASS_TOP_PEM screen.  The accelerometers are on channels 15, 16, 17, 18, 19, 20 and the seismometers are on channels 2, 3, 4, 10, 11, 12, 24.

I now need to modify the upass script to turn these filters on before doing adaptive filtering.

  2001   Fri Sep 25 16:10:17 2009 JenneUpdateAdaptive FilteringSome progress on OAF, but more still to be done

[Jenne, Sanjit]

It seems now that we are able to get the OAF system to do a pretty good job of approximating the MC_L signal, but we can't get it to actually do any subtracting.  I think that we're not correctly setting the phase delay between the witness and the MC_L channels or something (I'm not sure though why we get a good filter match if the delay is set incorrectly, but we do get a good filter match for very different delay settings: 1, 5, 100, 1000 all seem to do equally well at adjusting the filter to match MC_L). 

The Matt Evans document in elog 395 suggests measuring the phase at the Nyquist frequency, and calculating the appropriate delay from that.  The sticking point with this is that we can't get test points for any channel which starts with C1:ASS.  I've emailed Alex to see what he can do about this.  Elog 1982 has a few words about how we're perhaps using a different awgtpman on the ass machine than we used to, which may be part of the problem. 

The golden plan, which in my head will work perfectly, is as follows: Alex will fix the testpoint problem, then Sanjit and I will be able to measure the phase between our OAF signal and the incoming MC_L signal, we will be able to match them as prescribed in the Matt Evans document, and then suddenly the Adaptive Filtering system will do some actual subtracting!

The plot below shows the Reference MC_L without any OAF system (black), the output of the OAF (green), and the 'reduced' MC_L (red).  As you can see, the green trace is doing a pretty good job of matching the black one, but the red trace isn't getting reduced at all.

Attachment 1: OAF_Running_25Sept2009.jpg
OAF_Running_25Sept2009.jpg
  2004   Fri Sep 25 19:55:59 2009 JenneUpdateAdaptive FilteringSubtraction of the microseism using Adaptive Filtering!

[Rana, Jenne]

The OAF system did something useful today!  Attached is a plot.  Black is the reference (13 averages) with the OAF off.  Blue is the output of the OAF, and red is the reduced MC_L signal (13 averages).  If you turn tau and mu both to 0, it "pauses" the filter, but keeps the feedforward system working, so that you can take a long average to get a better idea of how well things are working. If you ramp down the output of the CORR filter bank, that lets you take a long average with the OAF "off", but doesn't mess up your nicely adapted filter.  The cyan and gold traces in the upper plot are 2 of the Guralp channels, so you can see the real seismic motion.

In the lower plot, you can see that the cyan and light green seismic channels have good coherence with IOO-MC_L (the names don't really mean anything right now...these 2 seismometer channels are the 2 Guralps' channels, one per end of the MC, which are aligned with the MC.)  The dark blue trace is the coherence between IOO-MC_L and the output of the OAF.

500 taps, delay=5, 2 Guralp channels (the ones aligned with the MC), tau~0.00001 (probably), and mu~0.01 or 0.005

Attachment 1: OAF_running_WORKING_25Sept2009.png
OAF_running_WORKING_25Sept2009.png
  2029   Wed Sep 30 17:49:21 2009 JenneUpdateAdaptive FilteringNew UP/DOWN scripts for OAF

[Sanjit, Jenne]

The up and down scripts accessible from the OAF (still C1:ASS-TOP) screen are now totally functional and awesome.  They are under the blue ! button.  The up script can either be for the Seismometers, or the Accelerometers at this time.  The only difference between these 2 is which burt restore file they look at:  the seismometer version puts all 7 seismometer channels in the PEM selecting matrix, while the accelerometer version puts the 6 accelerometer channels in that matrix.  Both scripts also turn on HP_1mHz filters in the ERR_EMPH filter bank and all of the witness filter banks, and the AA32 and AI32 filters in ERR_EMPH, CORR and PEM filter banks.  This makes all of the starting filters the same between the witness paths and the error path.

If you want to use a different combination of sensors, run one of the up scripts, then change the PEM matrix by hand. 

The down script disables the output to the optics, and resets the adapted filter coefficients.  DO NOT use this script if you're trying to "pause" the filter to take some nice long averages.

  2054   Mon Oct 5 18:34:26 2009 JenneUpdateAdaptive FilteringAttempts to take a TF of the OAF system

[Jenne, Sanjit]

As per Matt's instructions in his OAF document (elog 395) in the Tuning section, Sanjit and I took a transfer function measurement from the output of the OAF system, to the input.  i.e. we're trying to measure what happens out in the real world when we push on MC1, and how that is fed back to the input of our filter as MC_L.  The game plan is to measure this transfer function, and read off the phase at the nyquist frequency, and use this value to calculate the appropriate sample-and-hold delay to be used in the OAF.  The downsample rate for the OAF is 32, so that we're running at 64Hz instead of the 2048Hz of the front-end.  Thus, our Nyquist frequency is 32Hz.

                            DownSampleRate

Phase@Nyquist * ------------------------

                                    180

In the attached figure we do a swept sine from CORR_EXC to ERR_EMPH_OUT to determine the transfer function.  Here, we turn off all of the filters in both the CORR and EXC banks, because those are already matched/taken into account in the PEM filter banks. 

Using the cursor on DTT, we find that the phase at 29.85Hz is -228.8deg, and at 37.06Hz is -246.0deg.  Extrapolating, this means that at 32Hz, we expect about -234deg phase.  Using our handy-dandy formula, this means that we should try a delay of 41 or 42 (41.6 is between these two...) 

We'll give this a shot!

Attachment 1: OAF_TF_CORRexc_EMPHout_2.png
OAF_TF_CORRexc_EMPHout_2.png
  2058   Tue Oct 6 11:13:53 2009 JenneUpdateAdaptive FilteringAttempts to take a TF of the OAF system

Quote:

[Jenne, Sanjit]

As per Matt's instructions in his OAF document (elog 395) in the Tuning section, Sanjit and I took a transfer function measurement from the output of the OAF system, to the input.  i.e. we're trying to measure what happens out in the real world when we push on MC1, and how that is fed back to the input of our filter as MC_L.  The game plan is to measure this transfer function, and read off the phase at the nyquist frequency, and use this value to calculate the appropriate sample-and-hold delay to be used in the OAF.  The downsample rate for the OAF is 32, so that we're running at 64Hz instead of the 2048Hz of the front-end.  Thus, our Nyquist frequency is 32Hz.

                            DownSampleRate

Phase@Nyquist * ------------------------  =  Delay

                                    180

In the attached figure we do a swept sine from CORR_EXC to ERR_EMPH_OUT to determine the transfer function.  Here, we turn off all of the filters in both the CORR and EXC banks, because those are already matched/taken into account in the PEM filter banks. 

Using the cursor on DTT, we find that the phase at 29.85Hz is -228.8deg, and at 37.06Hz is -246.0deg.  Extrapolating, this means that at 32Hz, we expect about -234deg phase.  Using our handy-dandy formula, this means that we should try a delay of 41 or 42 (41.6 is between these two...) 

We'll give this a shot!

 As Rana pointed out to me last night, I was using continuous phase, which is not good.  When using regular phase, I find: (29.85Hz, 131.216deg), (37.06Hz, 113.963deg), so extrapolating gives (32Hz, 126.07deg).  Plugging this in to our handy-dandy formula, we get a delay of 22.4, so we should try both 22 and 23.

  2061   Wed Oct 7 03:49:49 2009 ranaUpdateAdaptive FilteringAttempts to take a TF of the OAF system

 Here's a plot of the spectra of the seismometers and MCL. The coherence shows which axes are aligned right now: MC1_X is coherent with GUR_NS which means that its mis-oriented.

I've now swapped the "MC1" cables: so the old "NS" now goes into EW and the old EW now goes into NS. VERT is unchanged.

Also fixed the channel names - the Guralp previously named MC1 is now GUR1 and the other one is GUR2. Also no more EW, NS, & VERT. Its all XYZ.

DAQD restarted with the new channel names.

Attachment 1: Untitled.png
Untitled.png
  2063   Wed Oct 7 07:42:55 2009 ranaUpdateAdaptive FilteringAttempts to take a TF of the OAF system

I remeasured the OAF time delay using the OAF-TF template from the Templates/ directory.

Troublingly, I found the MC1 dewhitening switches set OFF - please make sure that the MC1 dewhitening is back ON after each OAF tuning so that the interferometer locking is not hosed.

The OAF-TF template had the excitation amplitude set ~20x too high. I reduced it and the coherence was still > 0.95. The phase at 32 Hz was still ~126 deg as Jenne had measured, but since the phase at DC is 180 deg, the overall phase lag is just 180-126 = 54 deg. So the delay should be 54/180 * 32 = 9.7 => 10. Luckily, Jenne is working on an instructional manual for OAF that will make all of this crystal clear.

  2065   Wed Oct 7 19:23:49 2009 JenneUpdateAdaptive Filtering(Final?) PEM cabling changes

Quote:

 Here's a plot of the spectra of the seismometers and MCL. The coherence shows which axes are aligned right now: MC1_X is coherent with GUR_NS which means that its mis-oriented.

I've now swapped the "MC1" cables: so the old "NS" now goes into EW and the old EW now goes into NS. VERT is unchanged.

Also fixed the channel names - the Guralp previously named MC1 is now GUR1 and the other one is GUR2. Also no more EW, NS, & VERT. Its all XYZ.

DAQD restarted with the new channel names.

 I spiffed up the order of the cables / sensors plugged into the PEM ADCU.  Now all of the seismometers are labeled as Rana left them, and the 2 Guralp's have their sets of 3 channels next to eachother in channel-number-land.  None of the accelerometer names/cabling have changed recently.  In the table, Cable-label refers to the physical tag tied to the end of the cables plugged into the ADCU...they are meant to be descriptive of what seismometer channels they are hooked up to, and then the names change to something useful for us when they come into the DAQ system.  Also, the labels of input channels on the ASS_TOP_PEM screen have been updated accordingly.

 

Channel Name Channel Number on ADCU and OAF PEM list Cable-label .ini channel number
C1:SEIS-GUR2_X 2 Gur2 EW 15001
C1:SEIS-GUR2_Y 3 Gur2 NS 15002
C1:SEIS-GUR2_Z 4 Gur2 Vert 15003
C1:SEIS-GUR1_X 10 Gur1 EW 15009
C1:SEIS-GUR1_Y 11 Gur1 NS 15010
C1:SEIS-GUR1_Z 12 Gur1 Vert 15011
C1:SEIS-RANGER_Y 24 Ranger

15023

 

  2066   Wed Oct 7 20:32:21 2009 ranaUpdateAdaptive Filteringextra delay and noise in PEM -> ASS/OAF system

[Rana, Jenne]

There is some craziness going on with the delay in the PEM path for the OAF.  We plot the difference between the C1:PEM-SEIS_GUR1_X and C1:ASS-TOP_PEM_10.  These are physically the same channel, plugged into the PEM ADCU, and then the signal is used as a regular PEM channel, and is also sent to the ASS computer and used there for the OAF system.  As you can see in the blue trace on the bottom plot, there is a huge amount of delay, and it's very noisy.  We also plot the _GUR2_X / ASS-TOP_PEM_2 pair (red), and it has a similar amount of delay, but it is not nearly as fuzzy and noisy.  For comparison, we plot the SUS-MC2_MCL (which is identical to IOO-MC_L) and ASS-TOP_ERR_MCL pair (green), and they don't have any big overall delay problems, so it's not totally a problem with the signals getting to the ASS computer.

This problem was present during/after all of the following attempts to fix it:

* The sample rate on the ASS computer is 2048.  The PEM channels were being acquired the ADCU at 512.  We changed the ADCU sampling rate to 2048 to match.

* We soft rebooted the ASS computer, in case it was a timing problem.

* Doing a "sudo shutdown -r now" while logged in as controls.

We might also try resetting/power cycling c0dcu in the morning.  Alex has been emailed to help us try to figure this out.

 

In other news, the time delay that we measure from the plot gives us 180degrees in ~210Hz.  This corresponds to a little more than 2msec of delay, with the C1:ASS version lagging behind the C1:PEM version.  (2 samples at 840Hz) Converting to the 2048 sampling rate, we have a delay of 4.8, so 5 front-end cycles.  Since Rana measured this morning that the delay indicated by the transfer function is 10 cycles, and this delay shows that the ASS lags the actual seismometer signal by 5 cycles, we should subtract this 5 from the 10 from the transfer function, giving us a final sample-and-hold delay of 5.  Coincidentally(?), 5 is the delay that was found in the C1:ASS-TOP screen, after it's one year of dormancy.  The point of the delay feature in the code is to help match the delay in the two signal paths: the PEM path and the output path of the filter.  Since the output has a lag of 10, and the PEM path has a lag of 5, to make them match, we artificially put in a delay of 5.

Attachment 1: a.gif
a.gif
  2074   Fri Oct 9 03:53:56 2009 JenneUpdateAdaptive FilteringRemaking the ASS

The c1ass computer, which is now used for the OAF system, has many remnants from the days when it was actually used as an ASS.  These PIT and YAW filter banks and other things were taking up a lot of unnecessary space, so I deleted them in the ass.mdl file.  These files are all backed up, so we can always revert back to an older version when we want some Alignment Stabilization again someday.  I then did a make ass, following the instructions on the 40m Wiki -> Computers and Scripts -> Simulink to Front-End Code page.  Rana moved some things around, most notably all of the things (like the ASS screens) which were only in ...../users/alex/.... are now in ....../caltech/cds/advLigo/..... .  This required a few restarts of the c1ass machine (after a couple different versions of the simulink diagram....one to make sure we knew how to do it, and then again actually deleting the unused portions).

The big lesson of the night was that there are 2 signal paths for the PEM channels.  As is shown in Figure 3 in the mevans document, the PEM channels get the matching filters when they go to the adaptation algorithm, but when they go to the FIR filter, they do not get the matching filters. This is implemented by taking the output of the giant PEM matrix, and having a duplicate of each of the channels "selected for adaptation", one which gets filtered through the PEM_N_ADPT banks, and one which goes straight (in code-land) to the FIR filter.  So, it seems like all the filters which we had been including in the input side of the matrix for matching purposes need to be put in the output side.  One of the AA32 filters needs to stay in the input side, for actual anti imaging of the PEM channels, then we put the AA32 and AI32 which are for matching the ERR_EMPH and CORR filter banks up in the PEM_N_ADAPT banks.  Rana and I made these filters, and they are now turned on appropriately with the OAF down script (so that all the filters are ready and waiting for the OAF to be turned on).

A little success with getting the 3Hz peak reduced, but not a lot beyond that.  Tomorrow I'll put the accelerometers back where they used to be to see if they help out at all.

  2116   Mon Oct 19 11:31:55 2009 JenneUpdateAdaptive Filteringextra delay and noise in PEM -> ASS/OAF system

Quote:

[Rana, Jenne]

There is some craziness going on with the delay in the PEM path for the OAF.  We plot the difference between the C1:PEM-SEIS_GUR1_X and C1:ASS-TOP_PEM_10.  These are physically the same channel, plugged into the PEM ADCU, and then the signal is used as a regular PEM channel, and is also sent to the ASS computer and used there for the OAF system.  As you can see in the blue trace on the bottom plot, there is a huge amount of delay, and it's very noisy.  We also plot the _GUR2_X / ASS-TOP_PEM_2 pair (red), and it has a similar amount of delay, but it is not nearly as fuzzy and noisy.  For comparison, we plot the SUS-MC2_MCL (which is identical to IOO-MC_L) and ASS-TOP_ERR_MCL pair (green), and they don't have any big overall delay problems, so it's not totally a problem with the signals getting to the ASS computer.

This problem was present during/after all of the following attempts to fix it:

* The sample rate on the ASS computer is 2048.  The PEM channels were being acquired the ADCU at 512.  We changed the ADCU sampling rate to 2048 to match.

* We soft rebooted the ASS computer, in case it was a timing problem.

* Doing a "sudo shutdown -r now" while logged in as controls.

We might also try resetting/power cycling c0dcu in the morning.  Alex has been emailed to help us try to figure this out.

 

In other news, the time delay that we measure from the plot gives us 180degrees in ~210Hz.  This corresponds to a little more than 2msec of delay, with the C1:ASS version lagging behind the C1:PEM version.  (2 samples at 840Hz) Converting to the 2048 sampling rate, we have a delay of 4.8, so 5 front-end cycles.  Since Rana measured this morning that the delay indicated by the transfer function is 10 cycles, and this delay shows that the ASS lags the actual seismometer signal by 5 cycles, we should subtract this 5 from the 10 from the transfer function, giving us a final sample-and-hold delay of 5.  Coincidentally(?), 5 is the delay that was found in the C1:ASS-TOP screen, after it's one year of dormancy.  The point of the delay feature in the code is to help match the delay in the two signal paths: the PEM path and the output path of the filter.  Since the output has a lag of 10, and the PEM path has a lag of 5, to make them match, we artificially put in a delay of 5.

 Alex came in a week ago Friday to help figure this timing problem out, and some progress was made, although there's more to be done. 

Here are the (meager) notes that I took while he was working:

we can rename the tpchn_C1_new back to tpchn_C1, but the _new one works right now, so why change it?

need to find dcuDma.c source code...this is (?) what sends the PEM channels over to ASS.  Found:  source code is dcu.c, th
en the binary is dcuDma.o  Trying to recompile/remake dcuDma to make everything (maybe) good again.

Possibility: maybe having so many channels written to the RFM takes too long? shouldn't be  a problem, but maybe it is.  I
n the startup.cmd (or similar?) change the number of ISC modules to 1, instead of 2, since we only have one physical board
 to plug BNCs into, even though we have 2 isc boards.  c0dcu1 rebooted fine with the one isc board.  now can't get ass tes
tpoints to try the DTT timing measurement again.  rebooting fb40m to see if that helps.  fb40m is back, but we still don't
 have ASS testpoints.  Alex had to leave suddenly, so maybe more later.

Also, next possibility is that c0dcu and c1ass are not synched together properly....we should look at the timing of the AS
S machine.

 

After these adventures, the noisy trace in the timing delay (in the plot in elog 2066) has become quiet, as shown below (The blue trace, which was noisy in 2066 is now hiding behind the red trace).  However, the overall timing delay problem still exists, and we don't quite understand it.  Alex and I are meeting tomorrow morning at the 40m to try and suss this out.  Our first plan of attack is to look at the ASS code, to see if it puts any weird delays in.

Attachment 1: PEM-timing_19Oct2009.png
PEM-timing_19Oct2009.png
  2121   Mon Oct 19 19:37:39 2009 Sanjit, JenneUpdateAdaptive Filteringextra delay and noise in PEM -> ASS/OAF system

Rana pointed out that the delay may be caused by the 110B DAQ, as it integrates over 2ms (5 clock cycles at 2048Hz on the fe computer), to make low noise measurement. However, the C0DCU knows about this delay and corrects it by fudging the time stamp, before sending it to the frame builder, so that the time stamps match the actual measurement time. But, the ASS computer is not aware of such an integration time, so it does not adjust the time. We verified that it is indeed the case. This is what we did (as suggested by Rana):

We split the signal from the MODE cleaner board "OUT" port using a T-splitter to the original PENTEK board (C1:SUS-MC2-MCL-IN) and the PEM ADCU channel #2. Then measured the mutual delays between the signals that are processed by C0DCU and the ASS computer for both the MC_L signal and the corresponding output through the PEM channel. We clearly see the same delay (compare red and brown in the bottom panel) between the signals that are going through 110B and the PENTEK DAQ. This delay is a bit noisy, possibly because the PENTEK is not as low noise as the 110B is.

There is some delay (pink curve in the bottom panel) between the PENTEK DAQ and the frame builder corrected 110B output, much smaller than 2ms, could be ~200-400 u sec. Which should correspond to the 1 or 1/2 cycle delay caused by the PENTEK DAQ.

So, once we have the planned advLIGO DAQ system, there should not be any long delay. Perhaps, to solve the problem and make OAF functional soon, we will upgrade the PEM DAQ asap, rather than waiting for the rest of the upgrades...

 

Attachment 1: PEM_timingDealy_19OCT09_MCL2PEM2.png
PEM_timingDealy_19OCT09_MCL2PEM2.png
  2125   Tue Oct 20 11:38:10 2009 rana, rolfUpdateAdaptive Filteringextra delay and noise in PEM -> ASS/OAF system

An email from Rolf about the delay in the 110Bs:

"...we do take the ~2msec pipeline delay into account when we send the data to DAQ. If I remember correctly, the delay is about 39 samples. On startup, the first 39 samples are 'thrown away', such that, from then on, data lines up with the correct time (just read 2msec later then Penteks)."

  2143   Mon Oct 26 17:45:34 2009 JenneUpdateAdaptive FilteringNew changes to the OAF fe code

[Alex, Jenne, Sanjit]

Alex came to the 40m today, and did several awesome things in OAF-land.

We discovered that there is, in fact, an ADC board connected to the ASS machine.  The tricky bit is that it only has a ribbon cable connector, so before we can use this ADC, we need to figure out how to make a breakout board/cable/something to connect the seismometer/accelerometer/microphone BNCs to this little board.  This is the same little board that connects the timing slave to the ASS machine.  For good or for ill, the timing slave is connected to this board via clip-doodles.  Potentially we can connect an ADC tester board to this board, and go from seismometer BNCs to clipdoodles to the tester board, but I'm not in love with the idea of utilizing clipdoodles as a semi-permanent solution until the upgrade.  I emailed Ben to see if he has a better idea, or (better yet) some spare hardware now that's the same as we'll use after the upgrade.  If we can use this ADC, it may solve our timing problem which is caused by the 110B ADC used by the PEM computer. Alex showed Sanjit and I how to connect the ASS's ADC card to the simulink diagram, when we're ready for that.

We also poked around in the code, and it seems that we can now save and restore OAF coefficients at will.  I added buttons to the OAF (ASS) screen, and Alex made it so the OAF coefficients are saved in RFM shared memory whenever you click the "save coeffs" button, and are restored when you click the "restore coeffs" button.  The buttons are the same as the 'Reset' button which has been there for a long time, so they seem to maybe have a similar problem in that you have to hold the button for a while in order for the code to realize that the button has been depressed.  We couldn't fix this easily, because it looks like our SimuLink cds stuff is a little out of date.  Some day (before/when Joe and Peter make new screens for the new 40m), we need to update these things.  Alex was concerned that it might take a while to do this, if the update broke some of the blocks that we're currently using.  Also, Sanjit and I now need to check that the coefficient-saving is going as planned.  When I have DTT open, and the OAF running, I see a certain shape to the signal which is sent to MC1 to correct for the seismic motion.  This shape includes at least several peaks at resonant frequencies that exist in our stacks/suspensions.  I can then save the coefficients, reset the active filter, and then restore the coefficients.  When I do this while watching DTT, it seems as though the general shape of the filter is restored, but none of the detailed features are.  The reason for this is still under investigation. 

The code-modifications involved a few iterations of 'remaking the ass'.

  2159   Thu Oct 29 18:04:02 2009 JenneUpdateAdaptive FilteringMore work on saving coeffs on the OAF screen

[Sanjit,Jenne]

Sanjit has been working today on trying to get the OAF coefficients to save properly.  Alex got us most of the way, but right now it's looking like the filter that is being saved is totally constant (all the values are the same).  We're poking around trying to figure out why this is. 

Also, we're starting again (as we should have been for the last week or so since Alex came in to help us) to check in the TOP_XFCODE whenever we make changes to it, and when we recompile the front end code. 

  2160   Thu Oct 29 18:25:33 2009 SanjitUpdateAdaptive FilteringMore work on saving coeffs on the OAF screen

Quote:

[Sanjit,Jenne]

Sanjit has been working today on trying to get the OAF coefficients to save properly.  Alex got us most of the way, but right now it's looking like the filter that is being saved is totally constant (all the values are the same).  We're poking around trying to figure out why this is. 

Also, we're starting again (as we should have been for the last week or so since Alex came in to help us) to check in the TOP_XFCODE whenever we make changes to it, and when we recompile the front end code. 

 

We are manually restarting assepics, but the terminal logs us out after sometime and ass may crash. I set autologout=0 in the terminal for the time being. Once the testing process is over, assepics will start automatically when the computer is turned on, so we wont have to worry about this.

(if ass crashes tonight, it is not unexpected!)

 

  2171   Mon Nov 2 21:09:15 2009 SanjitUpdateAdaptive FilteringMore work on saving coeffs on the OAF screen

 

I made some changes in the code (all commented in the installed and SVN version) to print the filter coefficients. I got crazy output. Sometimes memory bugs lead to such crazy behavior. So far I could not find any bugs, but will have to spend more time on it.

 

  2199   Fri Nov 6 19:25:31 2009 Sanjit, Jenne, JoeUpdateAdaptive FilteringMore work on saving coeffs on the OAF screen

Quote:

 I made some changes in the code (all commented in the installed and SVN version) to print the filter coefficients. I got crazy output. Sometimes memory bugs lead to such crazy behavior. So far I could not find any bugs, but will have to spend more time on it 

 

Something strange was going on in the OAF code, printf would print a double precision number in %f format but not in %lf or %e format!

Since we know this problem now, we can move forward, but it will be important to know why printf was restricted and if there are other such constraints which we should remember while making changes in the codes.

 

  2232   Wed Nov 11 00:55:47 2009 JenneUpdateAdaptive FilteringTerms put on some ADC inputs

Mostly a note to self:  I have put terminators on the ADC inputs which are usually the PEM-SEIS-GUR2_(XYZ) channels.  Since these 3 signals are currently going into the ASS ADC, these PEM ADC inputs are open, and have predefined channel names.  I'll collect the data and put it as the ADC noise level in my nifty plot which will show the noise limits of all things which affect Wiener Filtering.

  2310   Fri Nov 20 17:44:38 2009 JenneUpdateAdaptive FilteringSome svn shenanigans

[Sanjit, Jenne]

Sanjit and I are trying to put names to some signals which exist in SimuLink land, but which don't (yet) exist in EPICS land.  The deelio is that for each of the chosen SEIS signals in the ASS_TOP_PEM screen, the signal is split.  One part of the signal is used to decide how the adaptive filter should look, and the other part is actually used when doing the on-line subtraction.  Previously only the part of the signal which is used to decide on the Adaptive Filter could be seen on the screens, and had names. 

Before touching anything on the Simulink ASS.mdl, I did an svn check in, which put things at revision 36639. 

To try to make the desired signals exist, I put cdsFilt boxes (to create filter modules for each of these signals), and gave each of them a name (kind of like the Neverending Story....once they have a name, they'll exist).  My new names are C1:ASS-TOP_PEM_#_APPLY, which correspond to the previously-existing C1:ASS-TOP_PEM_#_ADPT (these are the ones that are along the top of the ASS_TOP_PEM matrix screen).  This version of the simulink model was checked in, and the svn is now at revision 36640.

We then did some "make clean", "make ass" and "make install-ass" action, and burt restored c1assepics, but nothing seems to be happening.  The screen doesn't have white boxes all over the place, and we didn't get any errors when we did the makes, and I'm sure we burt restored correctly (made sure the ASS GDS screen had a 1 in the lower left box etc), but all the values on the screen are still zero.  

When we ran the ass front end in terminal on the c1ass machine, we did see an error: "Invalid chan num found 2 = 30624" "DAQ init failed -- exiting".  I think this means that we need to have told some file somewhere that I was going to be adding 8 new channels. (maybe an .ini file?) Hopefully the Joe & Peter team can help us out with this, since they've been doing this kind of thing for the new system.

Moral of the story is, the new (non-working) simulink file has been svn checked in as revision 36640, and we're reverting to revision 36639, which was before I touched anything today.

  2316   Mon Nov 23 19:36:28 2009 JenneUpdateAdaptive FilteringHow to add ASS channels, so that they're saved to frames

[Jenne, Sanjit]

We would like several channels from the OAF/ASS screen to be saved to frames, so that we can use the channels for our OAF model.  In theory, this should involve uncommenting the desired channels in the .ini file (.../caltech/chans/daq/C1ASS.ini), and restart the frame builder.  Since this .ini file was generated a long time ago, and things have been changed since then, the chnnums in the .ini file and the corresponding .par file don't match up.  We need to go through the .par file (/cvs/cds/gds/param/tpchn_c3.par), and look up the chnnums for our channels, and copy those numbers into the .ini file.  Figuring out what was going on involved many fb40m restarts, but on the last one of the night, I restarted the backup script, so it should (hopefully) run tonight, and get all of the frames that we've been missing.

Notes to self: 

*  When adding channels to other front ends, the end of the process is to click the blue button on the C0DAQ_DETAIL screen next to your computer.  C1ASS isn't on that screen.  Instead, in the C1ASS_GDS screen, click DAQ Reload.

*  The channel names for the Test Points and the .ini files must be different.  That's why there's a '_2048' suffix at the end of every channel in our .ini file.

*  tpchn_C1 is all of the old-style system test points.  tpchn_C2 is the C1OMC, and tpchn_C3 is for the C1ASS testpoints.

*  When uncommenting channels in the C1ASS.ini file, make sure acquire is set to 1 for every channel we want saved.  The default in this .ini file is set to acquire = 0.

  2323   Tue Nov 24 18:24:54 2009 SanjitConfigurationAdaptive FilteringASS channels added to framebuilder

 

[Sanjit, Jenne, Rob, Joe]

 

We added and tested the following channels from "/cvs/cds/gds/param/tpchn_C3.par" to "/cvs/cds/caltech/chans/daq/C1ASS.ini" appending a "_2048" extension to the channel name (as the name of a channel in .ini and .par files must be different):

[C1:ASS-TOP_CORR_IN1_2048]
[C1:ASS-TOP_ERR_EMPH_IN1_2048]
[C1:ASS-TOP_PEM_10_IN1_2048]
[C1:ASS-TOP_PEM_11_IN1_2048]
[C1:ASS-TOP_PEM_12_IN1_2048]
[C1:ASS-TOP_PEM_15_IN1_2048]
[C1:ASS-TOP_PEM_16_IN1_2048]
[C1:ASS-TOP_PEM_17_IN1_2048]
[C1:ASS-TOP_PEM_18_IN1_2048]
[C1:ASS-TOP_PEM_19_IN1_2048]
[C1:ASS-TOP_PEM_20_IN1_2048]
[C1:ASS-TOP_PEM_24_IN1_2048]
[C1:ASS-TOP_PEM_2_IN1_2048]
[C1:ASS-TOP_PEM_3_IN1_2048]
[C1:ASS-TOP_PEM_4_IN1_2048]
 

These five-line entries for each channels in the .par file were manually copy pasted from the .ini file, should think about a smarter way...

The old .par file is kept as: /cvs/cds/caltech/chans/daq/C1ASS.ini.20Nov2009

The current one is also saved as: /cvs/cds/caltech/chans/daq/C1ASS.ini.24Nov2009

And, the current one is committed to the svn.

 

NOTE: In the first attempt, the channel names were mistakenly kept the same in both the .ini and .par files and this caused DAQ daemon to crash badly. It could only be recovered by hard reboot of the frame builder.  Important info here: Jenne's elog 2316

  2447   Tue Dec 22 18:42:40 2009 Sanjit, KojiConfigurationAdaptive FilteringReadded DAQ channels to active list

Sometimes back we modified /cvs/cds/caltech/chans/daq/C1ASS.ini to save some of the channels. The file was reverted to default after the recent changes in ASS.

We again uncommented and made acquire=1 to save the following three channels using daqconfig:

C1:ASS-TOP_ERR_MCL_IN1_2048

C1:ASS-TOP_PEM_15_IN1_2048

C1:ASS-TOP_PEM_18_IN1_2048

The script automatically created a back up in /cvs/cds/caltech/chans/daq/archive

 

  2516   Fri Jan 15 12:04:26 2010 Sanjit, mevansUpdateAdaptive FilteringCanceling noise again!

 

OAF is successfully canceling noise again, thanks to Matt!

Here is a plot showing more than a factor of 10 noise reduction around 3Hz (similar to what we saw in the simulations)

The changes that has made it work are:

  • use of RANGER channel (with ACC_MC1_X and/or ACC_MC2_X)
  • mu = 0.01, tau = 1.0e-6, ntaps = 2000, nDown = 16
  • nDelay = 5 and nDelay = 7 both work (may not be so sensitive on delay at low frequencies)
  • Main changes: filter bank on the PEM channels (ASS_TOP_PEM_## filters: 0.1:0, 1:, Notch24, AA32)
  • Added the AI800 filter for upsampling in MC1 (should not matter)

 Matt suggested playing with the emphasis (EMPH) filters to cancel noise in different frequency bands.

 

Attachment 1: OAF_15JAN2010.png
OAF_15JAN2010.png
  2548   Tue Jan 26 19:51:44 2010 Sanjit, ranaUpdateAdaptive FilteringOAF details

We turned on the OAF again to make sure it works. We got it to work well with the Ranger as well as the Guralp channels. The previous problem with the ACC is that Sanjit and Matt were using the "X" channels which are aligned the "Y" arm. Another casualty of our ridiculous and nonsensical coordinate system. Long live the Right Hand Rule!!

The changes that were made are:

  • use of RANGER channel (with ACC_MC1_X and/or ACC_MC2_X)
  • mu = 0.01, tau = 1.0e-6, ntaps = 2000, nDown = 16
  • nDelay = 5 and nDelay = 7 both work (may not be so sensitive on delay at low frequencies)
  • Main changes: filter bank on the PEM channels - ASS_TOP_PEM_## filters: 0.1:0, 1:, Notch24, AA32, gain 1
  • Added the AI800 filter for upsampling in MC1 (should not matter)

Other parameters which were kept at usual setting:

  • CORR: AI32, gain = 1
  • EMPH: 0.001:0, AA32, gain = 1
  • ERR_MCL: no filters, gain = 1
  • SUS_MC1: no filter, gain = 1
  • PEM Matrix: All zero except: (24,1), (15,2), (18,3)
  • ADAPT path filter: union of CORR and EMPH filters, gain 1
  • XYCOM switches # 16-19 (last four on the right) OFF 

Screenshots are attached.

Burt snapshot is kept as: /cvs/cds/caltech/scripts/OAF/snaps/ass_burt_100126_211330.snap

taken using the script: /cvs/cds/caltech/scripts/OAF/saveOAF

we should put this in ASS screen.


ERROR Detected in filter ASS_TOP_PEM_24 (RANGER): 1: was actually typed as a 1Hz high pass filter!

(Correcting this one seems to spoil the adaptation)

Possibly this makes sense, we may not want to block witness signals in the 0.1-20 Hz range.


  11:40 PM: Leaving the lab with the OAF running on 5 PEM channels (Ranger + Guralp 1&2  Y & Z). There's a terminal open on op440m which will disable the OAF in ~2.8 hours. Feel free to disable sooner if you need the MC/IFO.

Attachment 1: C1ASS_TOP.png
C1ASS_TOP.png
Attachment 2: C1SUS_SRM_XYCOM1.png
C1SUS_SRM_XYCOM1.png
Attachment 3: Untitled.png
Untitled.png
ELOG V3.1.3-