40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 19 of 341  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  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
  2555   Mon Feb 1 18:31:00 2010 SanjitUpdateAdaptive FilteringOAF details

  I tried downsampling value 32 (instead of 16), to see if it has any effect on OAF. Last week I encountered some stability issue - adaptation started to work, but the mode cleaner was suddenly unlocked, it could be due to some other effect too.

One point to note is that different downsampling did not have any effect on the CPU meter (I tried clicking the "RESET" button few times, but no change).

  2557   Mon Feb 1 21:51:12 2010 SanjitUpdateAdaptive FilteringOAF details

 I tried some combination of PEM channels and filters to improve OAF performance at other frequencies, where we do not have any improvement so far. There is progress, but still no success.

Here are the main things I tried:

For the ACC channels replaced the 0.1 Hz high pass filters by 3Hz high pass and turned off the 1: filter.

Then I tried to incorporate the Z ACC/GUR channels, with some reasonable combination of the others.

The Z axis Guralp and Accelerometers were making OAF unstable, so I put a 0.1 gain in all four of those.

Following the PEM  noise curves Rana has put up, we should probably use

  • two ACC_Y channels (3:0, Notch24, AA32)
  • two GUR_Z channels (filters: 0.1:0, 1:, AA32, gain 0,1)
  • one RANGER_Y, just because it works (0.1:0, 1:, Notch24, AA32)

In the end I tried this combination, it was stable after I reduced the GUR_Z gain, but looked very similar to what we got before, no improvement at 5Hz or 0.5Hz. But there was a stable hint of better performance at > 40Hz.

Possibly we need to increase the GUR_Z gain (but not 1) and try to use ACC_Z channels also. Since we can not handle many channels, possibly using one GUR_Z and one ACC_Z would be worth checking.

  2571   Fri Feb 5 00:52:55 2010 SanjitUpdateAdaptive FilteringOAF at 0.1-1.0 Hz

 

At 0.1-1.0Hz, there is some coherence between MC_L and RANGER_Y & GUR_Y, see the first figure. Also GUR_Z has low noise there. So I used all five of them, increased the gains of GUR_Z from 0.1 to 0.5. Some improvement near 0.5Hz. We possibly can not do any better with these PEM measurement, as the coherence of the adapted error signal and the PEM channels is almost zero, see the second figure. May be we need to think about placing the seismometers at different places/orientations.

However, there is lot more scope at higher frequencies, lot of coherence at 5-100Hz.

 

Attachment 1: OAF_04FEB2010_noOAF.png
OAF_04FEB2010_noOAF.png
Attachment 2: OAF_04FEB2010.png
OAF_04FEB2010.png
  2572   Fri Feb 5 01:04:58 2010 SanjitUpdateAdaptive FilteringOAF at > 5Hz

 

There is lot of coherence between the error signal and PEM channels at 5-100Hz. We had been applying a 1Hz low pass filter to all the GUR and RANGER channels for stability. I turned those off and OAF still works with mu=0.0025, this will give us some more freedom. Kind of annoying for testing though, it takes about 45min to adapt!

In any case, there is no significant improvement at high frequencies as compared to our usual OAF performance. Also, the low frequency improvement (see previous e-log) is lost in this set up. I think, we have to adjust the number of taps and channels to do better at high frequencies. Also, delay can be important at these frequencies, needs some testing.

 

Attachment 1: OAF_04FEB2010_highFreq.png
OAF_04FEB2010_highFreq.png
  2575   Sat Feb 6 00:10:08 2010 SanjitUpdateAdaptive FilteringOAF at > 5Hz

 

Did some more test to get better performance at higher frequencies.

Increased # taps to 4000 and reduced downsampling to 4, without changing the AA32 filters, from CORR, EMPH and the matching ADPT channels. But for testing I turned off AA32 from the input PEM channels. So that high frequency still gets blocked at CORR, but the adaptive filters have access to higher frequencies. Once we fix some reasonable downsampling, we should create corresponding AA filters.

I used only two channels, RANGER/GUR2_Y and GUR1_Z, and basically they had only one filter 0.1:0

This set up gave little better performance (more reduction at more frequencies), at some point even the 16HZ peak was reduced by a factor of 3. The 24Hz peak was a bit unstable, but became stable after I removed the Notch24 filters from PEM channels, to ensure that OAF is aware of those lines. There was some improvement also at the 24Hz peak.

 

  4854   Wed Jun 22 12:29:57 2011 IshwitaSummaryAdaptive FilteringWeekly summary

I started on the 16th with a very intense lab tour & was fed with a large amount of data (I can't guarantee that I remember everything....)

Then... did some (not much) reading on filters since I'm dealing with seismic noise cancellation this summer with Jenne at the 40m lab.

I'll be using the Streckeisen STS-2 seismometers & I need to use the anti aliasing filter board that has the 4 pin lemo connectors with the seismometers & its boxes that require BNC connectors. I spent most of the time trying to solder the wires properly into the connectors. I was very slow in this as this is the first time I'm soldering anything.... & till now I've soldered 59 wires in the BNC connectors....

 

 

  5402   Wed Sep 14 01:21:17 2011 JenneUpdateAdaptive FilteringModifications to LSC, RFM models, added OAF model

[Jenne, Mirko, with supervision from Jamie]

We are starting to create the new OAF model, so that it works with the new CDS system. 

I created (and did an "svn add" for) a new c1oaf.mdl, in the same place as the current c1lsc.mdl . Since the oaf will kind of be working with ISC things, I decided to put it in that folder.  So far this new OAF model just has SHMEM/PCIE memory sharing things to get info from the LSC and PEM models.  The OAF model has dcuid=22 (the same as in the old system), and lives on the LSC machine with specific_cpu=4.  This is the CPU number that Yoichi was going to use, but he ended up putting his FF stuff directly into the LSC model for delay reasons.

I modified the c1rfm.mdl to take seismometer and accelerometer info from the PEM model, and give it to the "rfm" via shmem, and then using PCIE (dolphin) to get the channel to the OAF model.

I modified the c1lsc model to have shmem outputs that go from the degrees of freedom to the OAF, and shmem inputs from the OAF's output to sum into the DoFs, just like Yoichi's FF stuff.  I also removed the old OAF_OUT, because it would only allow me to select one DoF at a time, and I will eventually want the ability to do multiple amounts of OAFing at the same time.  Hopefully.

All of the above changes have been svn'ed with nice log messages into the cds svn.

I have not yet modified the PEM model to give the seis/acc information to the RFM model.

I will need to acquire the PSL's PZT input as a representation of the mode cleaner's length if I want to apply the OAF to the MC to recreate past work.

  5404   Wed Sep 14 12:01:05 2011 ranaUpdateAdaptive FilteringModifications to LSC, RFM models, added OAF model

For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

  5449   Sun Sep 18 15:34:09 2011 KojiUpdateAdaptive FilteringModifications to LSC, RFM models, added OAF model

[Koji Kiwamu]

This modification of the LSC model made the rows of the LSC output matrix shifted. This caused the ASS scripts nonfunctional.

Kiwamu fixed the channel names in the ASS script.

Quote:

[Jenne, Mirko, with supervision from Jamie]

I modified the c1lsc model to have shmem outputs that go from the degrees of freedom to the OAF, and shmem inputs from the OAF's output to sum into the DoFs, just like Yoichi's FF stuff.  I also removed the old OAF_OUT, because it would only allow me to select one DoF at a time, and I will eventually want the ability to do multiple amounts of OAFing at the same time.  Hopefully.

 

  5550   Mon Sep 26 18:59:11 2011 JenneUpdateAdaptive FilteringPlan for making MC_F

Quote:

For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

 [Jenne, Den]

Suresh tells us that he already has this channel physically plugged in.  Probably as a result of Valera's MCASS work.  Neat.  We just have to make the channel.  Right now the signal goes straight into some lockin stuff, so there is no actual "C1:IOO-MC_F" channel.

We don't want to make the new channel right now, since it is nighttime, and Kiwamu and Suresh are working on things.  So.  Tomorrow.  In the morning:

We will add a fast test point to the C1IOO model, and call it "C1:IOO-MC_F".  We will also route this signal via memory stuff over to the OAF model so that we can do adaptive filtering on the MC.  Then we will compile all the things.  Or at least all the things that we touched.  This will go hand-in-hand with the compling of Mirko's sweet new OAF model, which we were planning on compiling in the morning anyway.  Neat.

Things to compile tomorrow:  c1ioo and c1rfm, because of channel routing.  c1oaf because of all the new stuff.  That should be all.

  5555   Tue Sep 27 09:47:52 2011 SureshUpdateAdaptive FilteringPlan for making MC_F

Quote:

Quote:

For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

 [Jenne, Den]

Suresh tells us that he already has this channel physically plugged in.  Probably as a result of Valera's MCASS work.  Neat.  We just have to make the channel.  Right now the signal goes straight into some lockin stuff, so there is no actual "C1:IOO-MC_F" channel.

We don't want to make the new channel right now, since it is nighttime, and Kiwamu and Suresh are working on things.  So.  Tomorrow.  In the morning:

We will add a fast test point to the C1IOO model, and call it "C1:IOO-MC_F".  We will also route this signal via memory stuff over to the OAF model so that we can do adaptive filtering on the MC.  Then we will compile all the things.  Or at least all the things that we touched.  This will go hand-in-hand with the compling of Mirko's sweet new OAF model, which we were planning on compiling in the morning anyway.  Neat.

Things to compile tomorrow:  c1ioo and c1rfm, because of channel routing.  c1oaf because of all the new stuff.  That should be all.

 

Is it okay to have two names for the same signal?  We would have both MCS_MCL and MC_F referring to MC length signal.  This signal is picked up from the MC-Servo (analog) and brought into the CDS through the adc_0_0 channel in C1IOO.   Then this signal is sent from C1IOO to C1MCS model without going through the c1rfm model.  This seems to break the current protocol that signals passed between machines have to go through the c1rfm model.  It should be sufficient to send this signal to c1rfm once and from there redirect to MCS and OAF from there, with an appropriate name.

  5557   Tue Sep 27 11:52:33 2011 JenneUpdateAdaptive FilteringPlan for making MC_F

Quote:

Quote:

Quote:

For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

 [Jenne, Den]

Suresh tells us that he already has this channel physically plugged in.  Probably as a result of Valera's MCASS work.  Neat.  We just have to make the channel.  Right now the signal goes straight into some lockin stuff, so there is no actual "C1:IOO-MC_F" channel.

We don't want to make the new channel right now, since it is nighttime, and Kiwamu and Suresh are working on things.  So.  Tomorrow.  In the morning:

We will add a fast test point to the C1IOO model, and call it "C1:IOO-MC_F".  We will also route this signal via memory stuff over to the OAF model so that we can do adaptive filtering on the MC.  Then we will compile all the things.  Or at least all the things that we touched.  This will go hand-in-hand with the compling of Mirko's sweet new OAF model, which we were planning on compiling in the morning anyway.  Neat.

Things to compile tomorrow:  c1ioo and c1rfm, because of channel routing.  c1oaf because of all the new stuff.  That should be all.

 

Is it okay to have two names for the same signal?  We would have both MCS_MCL and MC_F referring to MC length signal.  This signal is picked up from the MC-Servo (analog) and brought into the CDS through the adc_0_0 channel in C1IOO.   Then this signal is sent from C1IOO to C1MCS model without going through the c1rfm model.  This seems to break the current protocol that signals passed between machines have to go through the c1rfm model.  It should be sufficient to send this signal to c1rfm once and from there redirect to MCS and OAF from there, with an appropriate name.

 Suresh makes a fine point.  I think the channel between c1ioo and c1mcs should always have had to go through the c1rfm model.  I don't know why it wasn't.  Anyhow, I have changed things so that there is one signal passing from c1ioo to c1rfm, and that signal is split in two, and goes to both c1oaf and c1mcs.  The naming convention I used last night is the one I kept:  C1:IOO-RFM_MCL goes from c1ioo to c1rfm, and then C1:RFM-OAF_MCL goes from c1rfm to c1oaf, and C1:RFM-MCS_MCL goes from c1rfm to c1mcs. 

We can't compile until Mirko and I figure out what to do with the OAF model though.  Mirko, Den and I were looking at the c1oaf model, to make sure it is ready to compile, and I'm not sure that it is.  And we need everything with common channel names to be compiled at the same time, so I can't compile any of the models today, until we get this figured out.

The problem is thus:  The old TOP_XFCODE that mevans wrote back in 2008 takes in a certain number of inputs, calculates the new filter coefficients, and spits out the filtered signals.  Back in those days, we only ever gave the adaptive system one control (target) signal at a time.  Now, we want to be able to do multiple, if we so desire.  I don't know exactly how to do this yet.  Either we need to modify the code to make it a super-code, or we can have one copy of the code for each control signal (MC_F, XARM, YARM, DARM, MICH, etc...).  Do we want to have one code adapt everything at once, and have a giant MIMO system, or do we want to have many SISO-like systems in parallel (SISO-like, because each one would take in one control signal, and many seismometer signals, and output many filtered seis signals, but it wouldn't be combining control signals together)? 

Either one of these options could be waaay to computationally tough for the computer.  The old computer was basically railed when we had one adaptive block, with one control signal and 7 seismometers.  7 was the max number of auxiliary channels we could use.  So, how much faster are the new computers?? Do we need to have one OAF per DoF that we want to filter? 

  5572   Wed Sep 28 22:30:01 2011 JenneUpdateAdaptive FilteringOAF is disabled

I am leaving the OAF disabled, so there should be nothing that goes to the suspensions from the OAF. 

Disabled for the OAF means all the outputs are multiplied by 0 just before the signals are sent back over to the LSC system to be summed in and sent to the suspensions.  So 0 times anything should mean that the OAF isn't injecting signals.

In other news, while Mirko was trying to figure out the c-code, I began making a new OAF screen.  It is still in progress, but it's in c1oaf/master/C1OAF_OVERVIEW.adl  If you open it up, you can see for yourself that the OAF is disabled.  (Eventually I'll put an enable/disable button on the LSC screen also, but that hasn't happened yet.)

  5575   Thu Sep 29 11:25:55 2011 JenneUpdateAdaptive FilteringTried new c-code, Fail.

[Mirko, Jenne]

Mirko edited the c-code to use Den's stuff that he put in the elog last night.  We then tried to compile and install, but it crashed c1lsc again.  We reverted to the simple, working c-code, pushed the physical reset button on c1lsc, and things started getting better.  The suspensions had the same problem as last night...we had to do a soft shutdown of c1sus to get things better again. 

I did a by-hand burt restore for all of the models on c1lsc and c1sus, since the auto burt restore isn't working.

  5576   Thu Sep 29 12:56:27 2011 JenneUpdateAdaptive FilteringMeditations on the OAF

[Mirko, Den, Jenne]

We're modifying the c1oaf model, and we got to talking about the "Fx" part of "FxLMS".  In the past, we put in a guess for the filter.  What if we use the static wiener filter as the F, and send the wiener filtered witness channels to the adaptation algorithm? 

Are the wiener filter and the plant compensation filter ("Fx") the same?  Will this work?  Or is there some reason that they must be different?

Also:  Notes to self:  Put in filtered witness channels as well as regular into Adapt block.  Make sure that the order/number of inputs is correct.

  5602   Mon Oct 3 16:18:05 2011 JenneUpdateAdaptive FilteringMeditations on the OAF

Quote:

[Mirko, Den, Jenne]

We're modifying the c1oaf model, and we got to talking about the "Fx" part of "FxLMS".  In the past, we put in a guess for the filter.  What if we use the static wiener filter as the F, and send the wiener filtered witness channels to the adaptation algorithm? 

Are the wiener filter and the plant compensation filter ("Fx") the same?  Will this work?  Or is there some reason that they must be different?

Also:  Notes to self:  Put in filtered witness channels as well as regular into Adapt block.  Make sure that the order/number of inputs is correct.

 More meditations...

Mirko and I were talking about the tunability required for each DoF.  For right now, we're going to give each DoF its own mu and tau (adaptation gain and adaptation decay), but we're leaving all of the other things (number of taps, number of witnesses, delay, downsample rate) the same for each DoF's adaptation.  This may need to change later, but we'll get there when we get there. 

The one I'm most concerned about is the number of witnesses...  Mirko is suggesting that we give each adaptation algorithm all witnesses, and unused ones should converge to ~0.  I agree in principle, but I'm not sure that it's actually going to work that way.  I think we may need to be able to tell the algorithm which witnesses to look at for which DoF. 

Also, the Delay.... we may need to adjust it for each DoF.  In Matt's OAF "manual" in elog 395, he mentions the need to calculate the delay based on a plant TF.  Presumably since (except for the MC) all the witnesses come in together, and all the DoFs come in together, the delay should be about the same for all?  We'll have to see...

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

Toyed around some more with the adaptive filters.

Execution time:

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

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

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

 

  5738   Tue Oct 25 20:04:40 2011 MirkoUpdateAdaptive FilteringAdaptive filter witness and EP SNR

We currently have the code running for all DOFs using all witness channels. By default nothing is applied. C-Code parameters can be changed via the respective EPICS variables. Sanity checks in the C-Code make sure the code doesn't crash when nothing / zeros are fed to the code. Let's look into applying FF to one DOF only as a starting point. We start with MCL.

Remember there are two possible signals to look into MC-F and MC-Servo. See page 5695 http://nodus.ligo.caltech.edu:8080/40m/5695

Dark noise: MC-F over MC-Servo which is unconnected in this measurement:
MC-F_SNR_to_Dark_noise.png

=> At least 20dB SNR. ADC noise should not be an issue. Of course more is always better.

Coherence of seismometers to MCL:


STS1 is located at the vertex. x-axis along the x arm.
GUR1 is located at the IMC MC2 mirror. Same orientation.
Coherence.png

=> 1. Only the x-direction has good coherence (to be expected)
     2. Only good coherence at 1.5-4Hz (huh?)

So probably other noise sources are dominating. Let's look into noise projections. Remember IMC autoalignment is off.

A quick adaptive filter run with only the GUR1 and STS1 witnesses applied only to MCL didn't really do anything. Some more thought needs to be invested into the AA and shaping filters.

  5740   Tue Oct 25 21:49:13 2011 DenUpdateAdaptive FilteringAdaptive filter witness and EP SNR

Quote

Coherence of seismometers to MCL:


STS1 is located at the vertex. x-axis along the x arm.
GUR1 is located at the IMC MC2 mirror. Same orientation.
Coherence.png

=> 1. Only the x-direction has good coherence (to be expected)
     2. Only good coherence at 1.5-4Hz (huh?)

So probably other noise sources are dominating. Let's look into noise projections. Remember IMC autoalignment is off.

A quick adaptive filter run with only the GUR1 and STS1 witnesses applied only to MCL didn't really do anything. Some more thought needs to be invested into the AA and shaping filters.

Indeed, only GUR1_X is reasonable. Static Wiener filtering (length = 2500) of MCL with witness channels GUR_1_X, GUR_1_Y, GUR_1_Z proves your measurements.

We need to callibrate seimometers. I think that now we see velocity, not displacement. It might be useful to amplify the seimometer singal before ADC to make sure that our signal is not ADC noise.

Attachment 1: gur1_x.jpg
gur1_x.jpg
Attachment 2: gur1_y.jpg
gur1_y.jpg
Attachment 3: gur1_z.jpg
gur1_z.jpg
  5772   Mon Oct 31 19:39:00 2011 JenneUpdateAdaptive FilteringScreens, code, computers

[Mirko, Jenne]

I finished (mostly? maybe?) the OAF screens.  They're pretty awesome. 

While we were playing with the OAF, trying to do some oafing, the output of the code decided to just be zeros.  We did a test, and in the c-code set the output to be a constant value, and that worked.  But when we put it back to normal (being adaptive) and recompiled, it still only outputs zeros.  The code is receiving both witness and error signals, so we don't know what's going on.

In the course of trying to make things work again, we did a complete reboot of c1lsc and c1sus.  Did a burt restore.  Everything (except our weird code problem) should be fine again.  Optics are damping happily.

  5777   Tue Nov 1 18:16:50 2011 DenUpdateAdaptive FilteringAdaptive filter witness and EP SNR

Quote:

 

Coherence of seismometers to MCL:


STS1 is located at the vertex. x-axis along the x arm.
GUR1 is located at the IMC MC2 mirror. Same orientation.
Coherence.png

=> 1. Only the x-direction has good coherence (to be expected)
     2. Only good coherence at 1.5-4Hz (huh?)

So probably other noise sources are dominating. Let's look into noise projections. Remember IMC autoalignment is off.

A quick adaptive filter run with only the GUR1 and STS1 witnesses applied only to MCL didn't really do anything. Some more thought needs to be invested into the AA and shaping filters.

The possible explanation to this effect is the following:

Seismic noise mainly consists of the Love and Rayleigh surface waves. In the simulations we've taken 2 perpendicular Love waves and 2 perpendicular Rayleigh waves that interfere under the test mirrors. This interference produces both translational and tilt movements. Then we can see the coherence between translational motion and cavity length.

translation_length.jpg

1. The coherence at big frequencies is small due to the passive isolation.

2. The coherence at 1 Hz is 0 due to the wire resonance.

3. The coherence between 1 and 10 Hz is reasonable. At the real 40m's measurements we can see only good coherence for gur1_x and sts1_x but this is the matter of adjusting seismic waves amplitude and direction. In the simulation we've assumed that all waves are of the same amplitude. The really interesting thing is that

4. The coherence below 0.8 Hz began to grow. We don't see this in real measurements.

But let's simulate the seismometer measurements. It measures not only translational motion but also tilt and with amplitude proportional to g / omega^2. On the Figure below the spectrum of translation motion, tilt and tilt as seen by seismometer is presented. We can see that at low frequencies tilt begins to dominate over the translational motion. We assumed the speed of waves in the region 30 - 60 m/sec.

trans_tilt.jpg

Let's now plot the coherence between the cavity length and seismometer signal.

seismic_length.jpg

We can see that the coherence between seismic signal from measured by seismometer and cavity length is gone below 1 Hz where tilt becomes important.

Now let's try to filter out the seismic noise from the cavity length using both static Wiener filtering and adaptive Mfxlms algorithm. For both filters we've used AA filter before the filters and also AI filter after adaptive filter. The downsampling ratio was 4, the sample frequency 256. We can see that nothing is really subtracted due to the pollution of the seismometer signal due to tilt motion.

tilt_filtering.jpg

Assume we do the same computational experiment but with the seismometers that measure only ground translational motion and tilt do not affect on them. Then we have a reasonable subraction of seismic noise at low frequencies even with the filters of the length 100 as shown on the figure below.

filtering.jpg

Let's look through an order of magnitude analysis. Assume ground motion consists of only one wave with amplitude A and only vertical movement:  z(t) = A*sin(2 pi 0.1 t). So the frequency of the wave is 0.1 Hz. If A = 10-6 m => the amplitude of the suspended mirror motion is also approximately 10-6 m, as we have no isolation at low frequencies. The tilt angle has the amplitude alpha = 2*pi*A/lambda, where lambda - wavelength of the ground wave, lambda = v/f = 40/0.1 = 400 m, v - speed of the wave, f - frequency. Then alpha = 10-8 rad. If the distance between ground and mirror suspension point is 1 m, then mirror motion amplitude due to tilt is B = 10-8 m << A. 
It turns out that tilt does not effect much on the cavity length compared to the ground translational motion, but it affects a lot on the seismometer signals, that are used as witness signals in the filtering. For that reason we need tiltmeters to filter seismometer signals in order to obtain pure translational ground motion.
  5810   Fri Nov 4 14:18:24 2011 MIrkoUpdateAdaptive FilteringCoherence between seismometers and MC length

Looking into the coherence between the seismometers and IMC length (MC_F):

FIrst with the seismometers only AC filtered at around 0.003 Hz and AA30Hz:
Coherence_without_compensation.pngWith_Pend_compensation.mat

Ignore the increase in coherence at very low frequencies. That is an artefact.

Then with an additional filter single complex pole @1Hz Q=1000 (giving 20dB per decade in attenuation above 1Hz) , only for GUR1X:
Coherence_with_compensation.png

  5811   Fri Nov 4 15:24:13 2011 MirkoUpdateAdaptive FilteringAdaptive FF on the MC doesn't make sense

[Den, Jenne, Mirko]

DSC_3585.JPG

Here is the story:

1. High gain
The control loop has a high gain at the interesting frequencies. The error point (EP) before the servo is approx. zero and the information how much the mirror would move is in the feedback point (FB) behind the servo. The mirror doesn’t actually move because of the high gain. This is the case of the grav. wave detectors and medium frequencies (> approx. 50Hz, <<1kHz). Adding feed-forward (FF) to this doesn’t actually keep the mirror quieter. In fact if you look into the FB and subtract the seismic you make the mirror move more. Yes this is the case we have for the mode cleaner, doesn’t make sense.
In a real GW detector FF however isn’t totally useless. The FB tells you how much the mirror moves, due to GWs, seismic etc. When you record the FB and subtract (offline) the seismic you get closer to the real GW signal.

2. Low gain
When you, for technical reasons, can’t have a high gain in your control loop the EP contains information of how the mirror actually moves. You can then feed this into the adaptive filter and add its output to the FB. This will minimize the EP reducing the actual mirror motion. This is the case we will have for most or all other degrees of freedom in the 40m.

The reason we have so much gain in the mode cleaner length control is that we don’t actually move mirrors around. We change the frequency of the incoming laser light. You can do that crazy fast with a big amplitude. This gives us a high UGF and lots of gain in the 1Hz range we are interested in.

We now change the adaptive filter to look at the EP for all DOFs except for the MC. We calculate the effect of the FF on the MC length signal without ever applying the FF to the MC length control.

  5816   Fri Nov 4 21:52:58 2011 DenUpdateAdaptive Filteringcoherence

[Mirko, Den]

We still think about the coherence between seismic noise and mode cleaner length. We beleive that

1. Below ~0.1 Hz tilt affects on the seismometers as was simulated http://nodus.ligo.caltech.edu:8080/40m/5777

2. From 0.1 to 1 Hz is an interesting region. We try to figure out why we do not see any coherence here. Tilt does not seem to dominate.

At 1 Hz coherence might be lost because of the sharp resonance. For example, if the mirror is suspended to the platform by wires with f = 1 Hz and Q = 1000, then the coherence between platform motion and mirror motion will be lost as shown on the figure below.

mirror_platform.jpg

For this reason we tried to "help" to the adaptive filter to guess transfer function between the ground motion and mirror motion by multiplying seimometer signal by the platform -> mirror transfer function. As we do not know exactly eigen frequency and Q of the wires, we did a parametric simulation as shown on the figure below

coherence.jpg

The maximum coherence that we could achieve with treak was 0.074 compared to 0.056 without. This was achieved at f=1.0011 Hz but with surprisingly high Q = 330. And though this did not help, we should keep in mind the tecnique of "helping" the adaptive filter to guess the transfer function if we partly know it.

Another unexpected thing is that we see come coherence between gur1_x and mode cleaner WFS pitch signal at frequencies 0.1 - 1 Hz

Screenshot-4.png

 

 

 From this we can suggest that either mode MC_F channel does not completely reflect the mc length at low frequencies or WFS2 shows weard signal.

  5825   Sun Nov 6 21:09:03 2011 ranaUpdateAdaptive Filteringcoherence

Quote:

[Mirko, Den]

We still think about the coherence between seismic noise and mode cleaner length. We beleive that

The 'helping' trick is a good one: we should use our best guess for the stackTF and the pendulumTF and put it into the IIR filter bank to pre-filter the seismometer signals before they get to the MC mirrors. Also should remember that the signal we send to suppress the seismic motion is applied to the pendulum as a force, not a displacement.

The 3 Hz fast cutoff in the MC_F signal is a good clue. It means that at low frequencies, perhaps the noise source is going through a digital 3 Hz elliptic or Chebychev filter.

  5835   Mon Nov 7 16:42:56 2011 JenneUpdateAdaptive FilteringBLRMS's to monitor OAF channels

I copied Mirko's PEM BLRMS block, and made it a library part.  I don't know where such things should live, so I just left it in isc/c1/models.  Probably it should move to cds/common/models.  To make the oaf compile, you have to put a link in /opt/rtcds/caltech/c1/core/branches/branch-2.1/src/epics/simLink , and point to wherever the model is living. 

I then put BLRMSs on the control signals coming into the OAF, and after the Correction filter bank in the Adapt blocks, so we can check out what we're sending to the optics.

  5842   Tue Nov 8 18:06:43 2011 MirkoUpdateAdaptive FilteringNoise injections to MC1-3 PIT & YAW

With fancy analysis tools approaching usability I looked some more into noise projections from PIT,YAW motion of the MC mirrors to MC length.

Injection channels are: C1:IOO-MC1-PIT_EXC. Actual injection signal is recorded in C1:IOO-MC1-PIT_OUT and similar.
Source channels for the projection are C1:IOO-WFS1_I_PIT_OUT_DQ and similar.
Response channel is C1:OAF-MCL_IN_IN1 or C1:IOO-MC_F_DQ.
MC auto-alignment was off.

1. Fixed sine injection @ 0.5Hz

Every injection lasted 4mins.

Start time DOF Amplitude [counts_pk] rough SNR in ASD BW 0.04Hz
16:09 MC1PIT 25 -
16:14 MC1YAW 40 12
16:21 MC2PIT 35 5
16:26 MC2YAW 35 5
16:34 MC3PIT 45 5
16:39 MC3YAW 45 -

2. Filtered white noise injection

Generated white noise from 0.5Hz-20Hz, then filtered that in the C1:IOO-MC1-PIT and similar filters by the following TF, (Notch 1Hz, Q=3, 40dB &  2 zeros @ 1.1Hz)

INJ_filter.png

All injections lasted 4mins. I left the filters in the first filter bank but disabled them. 

Start time DOF Amp. @ 0.5Hz [counts_pk (?)]
17:01 MC1PIT 250
17:10 MC1YAW 400
17:16 MC2PIT 400
17:21 MC2YAW 400
17:26 MC3PIT 500
17:31 MC3YAW 500

 

Attachment 2: MC1PIT_Noise_inj.png
MC1PIT_Noise_inj.png
Attachment 3: Noise_Inj_MC2PIT.png
Noise_Inj_MC2PIT.png
Attachment 4: Noise_Inj_MC2YAW.png
Noise_Inj_MC2YAW.png
Attachment 5: Noise_Inj_MC3PIT.png
Noise_Inj_MC3PIT.png
Attachment 6: Inj_Noise_MC3YAW.png
Inj_Noise_MC3YAW.png
Attachment 7: Inj_Noise_MC1YAW.png
Inj_Noise_MC1YAW.png
  5848   Wed Nov 9 14:23:35 2011 JenneUpdateAdaptive FilteringOAF MC Delay Measurement

As described in elog 2063 and the mevans document, we need to measure the TF of the OAF's plant, to find the delay.

At DC, the phase is 2.5deg, and at 32Hz, the delay is -4.6Hz (extrapolated from the points at ~30deg and ~38deg).  The DTT file is in /users/Templates/OAF/OAF-MCL-Delay-9Nov2011.xml . 

This gives a phase lag of 7.1deg at the Nyquist freq.

7.1 / 180 * 32 = 1.26, so ~1 cycle delay.  Not so much.  The new ADCs are waaaay faster than the old 110Bs.  Yay!

Attachment 1: OAF-MCL-Delay-9Nov2011.pdf
OAF-MCL-Delay-9Nov2011.pdf
  5856   Wed Nov 9 20:35:58 2011 MirkoUpdateAdaptive FilteringSeismic noise injection into the MC

Very elaborated measurement ;-)

On 11-11-08:
18:40 Stomp near STS1 for 2mins
18:47 Jump near GUR1 for 2mins
18:52 Walk from MC2 approx. half-way to vertex for 2mins


Tried to see if jumping / stomping the ground near STS1 / vertex or GUR1 / MC2 would show up in the seismometer or MC length data.
In GUR1 jumping / stomping clearly shows up in the timeseries. Also it clearly shows up as a low frequency signal if you walk to a position near MC2. E.g. walk from the vertex to MC2. Stop near the cones. Gives a big dip on GUR1X, that recovers in 10-20sec if you remain stationary. Big "hill" if you come from x-arm end and stop on the x side of MC2. So probably lots of tilt to GUR1X coupling at low frequencies.

Nothing was really visible in spectra (see below).

Resonances:

There appear to be a lot of resonances in the 10-20Hz range, see e.g. 1st attached pic.

Coherence:

Looking at the coherence of difference axis of the seismometers. Kind of dirty measurement, could have all kinds of reasons.
Quite a bit of coherence in STS1 at 5-6Hz. Possibly limiting the STS1X to MC-F coherence to up to 4Hz?

Coherence_GUR.png

Coherence_STS1.png

Attachment 1: Inj_spectra_at_GUR1_all_DOFs.fig
Attachment 2: Inj_spectra_at_GUR1_all_DOFs.png
Inj_spectra_at_GUR1_all_DOFs.png
Attachment 3: Inj_spectra_at_STS1_all_DOFs.fig
Attachment 4: Inj_spectra_at_STS1_all_DOFs.png
Inj_spectra_at_STS1_all_DOFs.png
Attachment 7: Coherence_GUR.fig
Attachment 8: Coherence_STS1.fig
  5858   Wed Nov 9 21:32:38 2011 MirkoUpdateAdaptive FilteringPut accelerometers 4-6 on top of MC2 tank

Put the accelerometers on top of MC2. Orientated as the arms,GUR1 and STS1:
09112011069.jpg

Should be fixed a bit more rigidly.

 

Looking into the signals at a quiet time:

Coherence_quiet_time.png

Hmm. Either the acc. are mislabeled or there is really bad x-y coupling. The connectors in the back of the acc. power supply / amplifier box are in ascending order.

Attachment 3: Coherence_quiet_time.fig
  5864   Thu Nov 10 16:44:54 2011 MirkoUpdateAdaptive FilteringLooking into MC_F & PSL misalignment

 [Den, Mirko]

While doing the things below we accidentally misaligned the PSL laser. Thanks to Suresh and Jenne for realigning!!

There are a lot of strange features in MC_F (see for example http://nodus.ligo.caltech.edu:8080/40m/5738 )
To get some better understanding of the signals in the control loop we looked some more into what happens to the MC feedback signal after it exits the MC servo board (D040180 see DCC).

10112011076.jpg
The MC_F signal is actually the servo signal: http://nodus.ligo.caltech.edu:8080/40m/5695
The Thorlabs temperature controller is actually used in the PZT path!

 We measured the LP filter in the PZT path (that is kind of mislabeled as temp.)

10112011073.jpg

 

  5867   Thu Nov 10 22:00:38 2011 MirkoUpdateAdaptive FilteringLooking into MC_F & PSL misalignment

Quote:

 [Den, Mirko]

While doing the things below we accidentally misaligned the PSL laser. Thanks to Suresh and Jenne for realigning!!

There are a lot of strange features in MC_F (see for example http://nodus.ligo.caltech.edu:8080/40m/5738 )
To get some better understanding of the signals in the control loop we looked some more into what happens to the MC feedback signal after it exits the MC servo board (D040180 see DCC).

10112011076.jpg
The MC_F signal is actually the servo signal: http://nodus.ligo.caltech.edu:8080/40m/5695
The Thorlabs temperature controller is actually used in the PZT path!

 We measured the LP filter in the PZT path (that is kind of mislabeled as temp.)

10112011073.jpg

 

 

We looked into the signal from the MC servo board at different position at the PSL table.


We looked into the FB going into the temp. and PZT parts of the FB.
Temp.:
Screenshot.png

PZT:

Screenshot-1.png
We also looked at the signal in just in front of the FSS box No idea why the elog doesn't preview these pdfs.

Signal_at_MC_servo_board_and_PSL_table_2_1.pdf

Signal_at_MC_servo_board_and_PSL_table_2_2.pdf

Signal_at_MC_servo_board_and_PSL_table_2_3.pdf

Signal_at_MC_servo_board_and_PSL_table_2_4.pdf
Lots of extra noise there. We will check out where that comes from.

ELOG V3.1.3-