40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 142 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  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.

 

  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
  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.

 

  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

 

  3517   Thu Sep 2 21:22:31 2010 Sanjit, KojiConfigurationComputersrossa nvidia driver and dual monitor configuration

 

Simple steps (but don't try these on a working computer without getting some experience on a spare one, you may find it difficult to restore the system if something goes wrong):

  1. download the appropriate driver from NVIDIA website for this computer
    • we did: NVIDIA GeForce 310 64bit Linux, version: 256.53, release date 2010.08.31
  2. keep/move the driver in /root (use "sudo" or "su")
  3. reboot the computer in "single user" mode
    • in the GRUB screen edit the boot command by pressing the appropriate key listed in the screen
    • in the boot command-line put " single" in the end (no other change is normally needed), don't save
    • press ENTER and the system will reboot to a root shell (# prompt)
  4. cd /root
  5. run the NVIDIA driver script
  6. exit the shell (ctrl-d), let the system reboot
    • it should flash (mostly green) "nvidia" screen before starting X
    • in case of problems run system-config-display and revert to vesa driver
  7. login as "root" and run "nvidia-settings" from command line or GUI menu to add/configure display

 

  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
  6880   Wed Jun 27 11:35:06 2012 SashaSummaryComputer Scripts / ProgramsSURF - Week 1 - Summary

I started playing with matlab for the first time, accurately simulated a coupled harmonic oscillator (starting from the basic differential equations, if anyone's curious), wrote a program to get a bode plot out of any simulation (regardless of the number of inputs/outputs), and read a lot.

I'm currently going through the first stage of simulating an ideal Fabry-Perot cavity (I technically started yesterday, but yesterday's work turned out to be wrong, so fresh start!), and other than yesterday's setback, its going okay.

I attached a screenshot of my simulation of the pitch/pendulum motion of one of the mirrors LIGO uses. The bode plots for this one are turning out a little weird, but I'm fairly certain its just a computational error and can be ignored (as the simulation matlab rendered without the coupling was really accurate - down to a floating point error). I have also attached these bode plots. The first bode is based on the force input, while the second is based on the torque input. It makes sense that there are two resonant frequencies, since there ought to be one per input.

 

Attachment 1: Screen_Shot_2012-06-27_at_11.27.10_AM.png
Screen_Shot_2012-06-27_at_11.27.10_AM.png
Attachment 2: Screen_Shot_2012-06-27_at_11.26.57_AM.png
Screen_Shot_2012-06-27_at_11.26.57_AM.png
Attachment 3: Screen_Shot_2012-06-27_at_11.27.29_AM.png
Screen_Shot_2012-06-27_at_11.27.29_AM.png
  6957   Wed Jul 11 10:17:18 2012 SashaSummarySimulationsSURF - Week 2 and 3 - Summary

These past two weeks, I've been working on simulating a basic Fabry-Perot cavity.  I finished up a simulation involving static, non-suspension mirrors last week. It was supposed to output the electric field in the cavities given a certain shaking (of the mirrors), and the interesting thing was that it outputted the real and imaginary components seperately, so I ended up with six different bode plots. Since we're only interested in the real part, bodes 2, 4, and 6 can be discarded (see attachment 1). There was a LOT of split-peak behavior, and I think it has to do either with matlab overloading or with the modes of the cavity being very close together (I actually think the first is more likely since a smaller value of T_1 resulted in actual peaks instead of split ones).

At any rate, there really wasn't much I could improve on that simulation (neither was there any point), but I attach the subsystem governing the electric field in the cavity as a matter of academic interest (see attachment 2). So I moved onto simulations where the mirrors are actually suspended pendulums as they are in reality.

 

A basic simulation of the suspended mirrors gave me fairly good results (see attachment 3). A negative Q resulted in a phase flip, detuning the resonance from the wrong side resulted in a complete loss of the resonance peak, and the peak looked fairly consistent with what it should be. The simulation itself is pretty bare bones, and relies on the two transfer functions P(s) and K(s); P(s) is the transfer function for translating the force of the shaking of the two test masses (lumped together into one transfer function) into actual displacement. Note that s = i*w, where w is the frequency of the force being applied. K(s), on the other hand, is the transfer function that feeds displacement back into the original applied force-based shaking. Like I said, pretty bare bones, but working (see attachment 4 for a bode plot of a standard detuning value and positive Q). Tweaking the restoring (or anti restoring, depending on the sign of the detuning) force constant (K_0 for short) results in some interesting behavior. The most realistic results are produced for K_0 = 1e4, when the gain is much lower overall but the peak in resonance gets you a gain of 100 in dB.  For those curious as to where I got P(s) and K(s), see "Measurement of radiation-pressure-induced optomechanical dynamics in a suspended Fabry-Perot cavity" by Thomas Corbitt, et. al.

I'm currently working on a more realistic simulation, with frequency and force noise as well as electronic feedback (via transfer functions, see attachment 5). The biggest thing so far has been trying to get the electronic transfer functions right. Corbitt's group gave some really interesting transfer functions (H_f(s) and H_l(s) for short; H_f(s) gives the frequency-based electronic transfer function, while H_l(s) gives the length-based electronic transfer function), which I've been trying to copy so that I can reproduce their results (see attachment 6). It looks like H_l(s) is a lowpass Butterworth filter, while H_f(s) is a Bessel filter (order TBD). Once that is successful, I'll figure out what H_f(s) and H_l(s) are for us (they might be the same!), add in degrees of freedom, and my first shot at the OSEM system of figuring out where the mirror's position is.

 

Attachment 1: Screen_Shot_2012-07-11_at_9.44.34_AM.png
Screen_Shot_2012-07-11_at_9.44.34_AM.png
Attachment 2: Screen_Shot_2012-07-05_at_2.15.33_PM.png
Screen_Shot_2012-07-05_at_2.15.33_PM.png
Attachment 3: Screen_Shot_2012-07-11_at_9.56.27_AM.png
Screen_Shot_2012-07-11_at_9.56.27_AM.png
Attachment 4: Screen_Shot_2012-07-11_at_9.56.15_AM.png
Screen_Shot_2012-07-11_at_9.56.15_AM.png
Attachment 5: Screen_Shot_2012-07-11_at_10.12.15_AM.png
Screen_Shot_2012-07-11_at_10.12.15_AM.png
Attachment 6: Screen_Shot_2012-07-11_at_10.09.13_AM.png
Screen_Shot_2012-07-11_at_10.09.13_AM.png
  6985   Wed Jul 18 09:53:20 2012 SashaSummarySimulationsSURF - Week 4 - Summary

This past week, I've been working on moving forward with the basic cavity model I developed last week (for future reference, that model was FP_3, and I am now working on FP_4) and refining the suspensions. I added three degrees of freedom to my simulation (such that it now consists of yaw, pitch, displacement, and side-to-side motion) and am attempting to integrate them with the OSEMS. I have also added mechanical damping for all degrees of freedom, and am adding electric damping and feedback. Concerning that, are all of the degrees of freedom locally damped in addition to being actuated on by the control system? Or does the control system do all of the damping itself? The first is the way I'm working on setting it up, but can easily change this if needed.

The next iteration of FP (FP_5) will replace my complicated OSEM --> Degrees of Freedom and vice versa system with the matrix system (see the poster Jenne and Jamie made, "Advanced Suspension Diagnostic Procedure"), as well as adding bounce/roll, yaw/y coupling, various non-damping filters as needed (i.e. the a2f filters), and noise sources. However, I'll only move on to that once I'm sure I have FP_4 working reasonably well. For now at least, the inputs/outputs look fine, and some of the DOF show resonance peaks. I'll become more concerned about where these resonance peaks actually are once I add damping.

Attached is a screenshot my work in progress. Only one of the suspensions has a basic feedback/damping loop going (as a prototype). It looks complicated now, but will simplify dramatically once I have damping worked out. Pink inputs are noises (will probably replace those with noise generators in FP_5) and green inputs are the OSEMS. The red output is the displacement of the cavity from resonance. The blue boxes are suspensions.

Attachment 1: Screen_Shot_2012-07-18_at_9.50.26_AM.png
Screen_Shot_2012-07-18_at_9.50.26_AM.png
  7022   Wed Jul 25 10:31:33 2012 SashaSummarySimulationsSURF - Week 5 - Summary

This week I've been working on refining my simulation and getting it ready to be plugged into the control system. In particular, I've added a first attempt at a PDH control system, matrix conversion from OSEMs to DOF and back, and all necessary DAC/ADC/AA/AI/whitening/dewhitening filters. Most of these work well, but the whitening filters have been giving me trouble. At one point, they were amplifying the signal instead of flatting it out, such that my simulation started outputting NaN (again).

This was wholeheartedly depressing, but switching out the whitening filters for flat ones seemed to make the problem go away, but brought another problem to light. The output to input ratio is minuscule (as in 10^-300/10^243, see Attachment 3 for the resulting bode plot between a force on the suspension pt in the x-direction and my two outputs - error signal and length signal, which is pretty much what you would expect it to be). I suspect that its related to the whitening filter problem (perhaps the dewhitening filter is flattening the signal instead of amplifying?). If that is the case, then switching the whitening/dewhitening filters ought to work. I'll try today and see what happens. The white/dewhite filters together result in a total gain of 1, which is a good fundamental test, but could mean absolutely nothing (i.e. they could both be wrong!). Judging from the fact that we want to flatten out low frequency signal when it goes through the whitening filter, the filters don't look switched (see Attachment 4 for a bode plot of white and dewhite).

The only other source of problems (given that the suspensions/local damping have been debugged extensively throughout this process - though they could bug out in conjunction with the cavity controls?) is the PDH system. However, separating each of the components showed that the error signal generated is not absurd (I haven't tested whether it makes sense or not, but at any rate it doesn't result in an output on the order of 10^-300).

In summary, I've made progress this week, but there is still far to go. Attachment 1 is my simulation from last week, Attachment 2 is my simulation from this week. A talk with Jamie about the "big picture" behind my project helped tremendously.

Attachment 1: Screen_Shot_2012-07-24_at_10.46.05_AM.png
Screen_Shot_2012-07-24_at_10.46.05_AM.png
Attachment 2: Screen_Shot_2012-07-24_at_10.45.43_AM.png
Screen_Shot_2012-07-24_at_10.45.43_AM.png
Attachment 3: Screen_Shot_2012-07-25_at_10.16.58_AM.png
Screen_Shot_2012-07-25_at_10.16.58_AM.png
Attachment 4: Screen_Shot_2012-07-25_at_10.25.27_AM.png
Screen_Shot_2012-07-25_at_10.25.27_AM.png
  7028   Wed Jul 25 14:35:45 2012 SashaSummarySimulationsSURF - Week 5 - Summary

Quote:

This week I've been working on refining my simulation and getting it ready to be plugged into the control system. In particular, I've added a first attempt at a PDH control system, matrix conversion from OSEMs to DOF and back, and all necessary DAC/ADC/AA/AI/whitening/dewhitening filters. Most of these work well, but the whitening filters have been giving me trouble. At one point, they were amplifying the signal instead of flatting it out, such that my simulation started outputting NaN (again).

This was wholeheartedly depressing, but switching out the whitening filters for flat ones seemed to make the problem go away, but brought another problem to light. The output to input ratio is minuscule (as in 10^-300/10^243, see Attachment 3 for the resulting bode plot between a force on the suspension pt in the x-direction and my two outputs - error signal and length signal, which is pretty much what you would expect it to be). I suspect that its related to the whitening filter problem (perhaps the dewhitening filter is flattening the signal instead of amplifying?). If that is the case, then switching the whitening/dewhitening filters ought to work. I'll try today and see what happens. The white/dewhite filters together result in a total gain of 1, which is a good fundamental test, but could mean absolutely nothing (i.e. they could both be wrong!). Judging from the fact that we want to flatten out low frequency signal when it goes through the whitening filter, the filters don't look switched (see Attachment 4 for a bode plot of white and dewhite).

The only other source of problems (given that the suspensions/local damping have been debugged extensively throughout this process - though they could bug out in conjunction with the cavity controls?) is the PDH system. However, separating each of the components showed that the error signal generated is not absurd (I haven't tested whether it makes sense or not, but at any rate it doesn't result in an output on the order of 10^-300).

In summary, I've made progress this week, but there is still far to go. Attachment 1 is my simulation from last week, Attachment 2 is my simulation from this week. A talk with Jamie about the "big picture" behind my project helped tremendously.

 Here's a screenshot of what's going on inside the cavity (Attachment 1). The PDH/mixer system outputs 0 for pretty much everything except really high numbers, which is the problem I'm trying to solve now. I assumed that the sidebands were anti-resonant, calculated reflection coefficient F(dL) = Z * 4pi * i/(lambda), where Z = (-r_1 + r_2*(r_1^2 + t_1^2)/(1 - r_1*r_3)), then calculated P_ref = 2*P_s - 4sqrt(P_c*P_s) * Im(F(dL)) * sin(12.5 MHz * t) (this is pictured in Attachment 2), then mixed it with a sin(12.5MHz * t) and low-passed it to get rid of everything but the DC term (this is pictured in Attachment 3), which is the term that then gets whitened/anti-aliased/passed through the loop.

 

Attachment 1: Screen_Shot_2012-07-25_at_2.20.01_PM.png
Screen_Shot_2012-07-25_at_2.20.01_PM.png
Attachment 2: Screen_Shot_2012-07-25_at_2.20.15_PM.png
Screen_Shot_2012-07-25_at_2.20.15_PM.png
Attachment 3: Screen_Shot_2012-07-25_at_2.20.29_PM.png
Screen_Shot_2012-07-25_at_2.20.29_PM.png
Attachment 4: Screen_Shot_2012-07-25_at_2.23.05_PM.png
Screen_Shot_2012-07-25_at_2.23.05_PM.png
  7065   Wed Aug 1 10:45:38 2012 SashaSummarySimulationsSURF - Week 6 - Summary

This week, I worked on transferring my Simulink simulation to the RCG. I made all relevant library parts, now under "SASHA library" in the main Simulink library browser. My main concern has been noises - I've added some rudimentry shot noise, amplitude noise, phase noise, and intensity noise. I have yet to add local oscillator noise, and plan to upgrade the existing noises to actually have the PSD they should (using equations from Rana's and Robb Ward's theses). I'm fairly certain this can be achieved by applying the correct transfer function to white noise (a technique I learned from Masha this week!), so the RCG should be able to handle it (theoretically).

I've also been tweaking my main simulation. After a brief (but scary) attempt at adding optical levers, I decided to shelve it in order to focus on noises/RCG simulating. This is not permanent, and I plan to return to them at some point this week or next. My main problem with them was that I knew how to get from optical lever input to pitch/yaw, but had no idea how to get from pitch/yaw to optical lever input. If I had a complete basis for one in terms of the other, I'd be able to, but I don't think this is the way to go. I'm sure there is a good way to do it (it was done SOMEHOW in the original simulation of the suspensions), I just don't know it yet.

In the aftermath of the optical lever semi-disaster, my simulation is once again not really outputting anything, but since it actually worked before adding the optical levers, I'm pretty sure I can get it to work again (this is why its important to use either git or BACKUPS, >.< (or both)).

We also wrote our progress reports this week. Mine includes some discussion on the basics of cavities/the mechanics of the suspensions/brief intro to PDH, and I'll add a section on noises in the next draft. Maybe this'll be of some use to someone someday? One can only hope.

 

 

  7076   Thu Aug 2 03:06:57 2012 SashaUpdateSimulationsLS Plant (LSP) is officially ONLINE

My ls plant compiled!! The RCG code can now be found in /opt/rtcds/rtscore/tags/advLigoRTS-2.5. I uploaded a copy of c1lsp.mdl onto the svn.

The weird "failed to connect" error was due to the fact that I named my inputs the same thing as my goto/from tags, so the RCG got confused. Once I renamed my inputs, it worked! I'm not sure what happened to the original "not enough parts" error; it didn't appear a single time during the rebuilding process. Anyway, I made the PDH block much neater, though the lines between PDH and ADC are looking wonky (this is purely an aesthetic problem, not a "oh god my simulation will DIE right now if I don't fix it" problem). I'll fix it in the morning; screenshot attached!

The original c1lsp was kind of sad. I updated it extensively and brought it into the modern era with color. The original c1lsp.mdl should also be on the svn. Tommorow, I'll get started on figuring out how to get LIGO specific noises from white noise.

Attachment 1: Screenshot-1.png
Screenshot-1.png
  7116   Wed Aug 8 11:16:06 2012 SashaSummarySimulationsSURF - Week 7 - Summary

This week, I brought my c1lsp model online and fixed up some the medm screens for c1spx. Along the way, I ran into a few interesting problems (and learned a bit about bash scripting and emacs! :D). The screens for the main TM_RESP matrix are not generating automatically, and the medm screens don't want to link to the channels, for some reason. I don't have this problem with the other matrices (i.e. C2DOF and SEN_OUT), so I think it has something to do with TM_RESP being a filter matrix (which the others are not). In addition, the noise overview medm screens for c1spx are practically nonexistent - someone just copied the file for the SUS-ETMX screens into the master directory for c1spx, so they need a complete overhaul. I am willing to do this, but Jamie told me to focus my attentions elsewhere.

So I went back to noise generation. I've been using Matlab to figure out how to recreate the various noise sources (laser amplitude noise, local oscillator phase/amplitude noise, and 60 Hz/ADC. Frequency noise will be added some time this week and seismic noise should be already covered in Jamie's suspension model) in my c1lsp model. I'm doing it the way the RCG does it - by applying a filter to white noise. I'm generating white noise by just using a random number generator and pwelch-ing it to get the power spectral density.

For the filters themselves, I picked z, p, k such that it shaped the white noise PSD to look like the PSD of the noise in question. This was fairly straightforward once I figured out how zeroes and poles affected PSD. Once I'd picked zpk, I applied a bilinear transform to get a discrete zpk out, then converted to a second order section to make computation faster. I then applied that to the white noise (matlab has a convenient "sosfilt" function) and pwelch-ed/graphed it to get the result.

Attached is my attempt at filtering white noise to look like 60 Hz. noise. I can't seem to find a way to pick z and p such that the peak is more narrow (i.e. other than having two complex conjugated poles at 60 Hz.). I took the spectrum of 60 Hz. noise from a terminated ADC channel (Masha kindly let me borrow one of her GURALP channels).

EDIT: I also remembered that I've been looking for how to get a good power spectrum for the rest of the noises. Jenne referred me to Kiwamu's work on this, and I'm mostly going off elog #6133. If you have any other good elogs/data on noises, please feel free to send them my way.

I then measured the PSD of the sensors on the real suspended optics and a PSD of the suspension model. It looks like the OSEMs on the suspension model are only reading white noise, which probably means a lost connection somewhere (Attachment 2 is what the model SHOULD produce, Attachment 3 is what the model ACTUALLY produces). I perused Jamie's model, but couldn't find anything. Not sure where else to check, but I'll continue thinking about it/trying to fix it.

Attachment 1: Screen_Shot_2012-08-06_at_9.20.02_PM.png
Screen_Shot_2012-08-06_at_9.20.02_PM.png
Attachment 2: Screen_Shot_2012-08-08_at_11.13.55_AM.png
Screen_Shot_2012-08-08_at_11.13.55_AM.png
Attachment 3: Screen_Shot_2012-08-08_at_11.08.23_AM.png
Screen_Shot_2012-08-08_at_11.08.23_AM.png
  7132   Thu Aug 9 04:26:51 2012 SashaUpdateSimulationsAll c1spx screens working

As the subject states, all screens are working (including the noise screens), so we can keep track of everything in our model! :D I figured out that I was just getting nonsense (i.e. white noise) out of the sim plant cause the filter matrix (TM_RESP) that controlled the response of the optics to a force (i.e. outputted the position of the optic DOF given a force on that DOF and a force on the suspension point) was empty, so it was just passing on whatever values it got based on the coefficients of the matrix without DOING anything to them. In effect, all we had was a feedback loop without any mechanics.

I've been working on getting the mechanics of the suspensions into a filter/transfer function form; I added something resembling that into foton and turned the resulting filter on using the shiny new MEDM screens. However, the transfer functions are a tad wonky (particularly the one for pitch), so I shall continue working on them. It had a dramatic effect on the power spectrum (i.e. it looks a lot more like it should), but it still looks weird.

Still haven't found the e-log Jamie and Rana referred me to, concerning the injection of seismic noise into the simulation. I'm not terribly worried though, and will continue looking in the morning. Worst case scenario, I'll use the filters Masha made at the beginning of the summer.

Masha and I ate some of Jamie's popcorn. It was good.

  7133   Thu Aug 9 07:24:58 2012 SashaUpdateSimulationsAll c1spx screens working

Quote:

As the subject states, all screens are working (including the noise screens), so we can keep track of everything in our model! :D I figured out that I was just getting nonsense (i.e. white noise) out of the sim plant cause the filter matrix (TM_RESP) that controlled the response of the optics to a force (i.e. outputted the position of the optic DOF given a force on that DOF and a force on the suspension point) was empty, so it was just passing on whatever values it got based on the coefficients of the matrix without DOING anything to them. In effect, all we had was a feedback loop without any mechanics.

I've been working on getting the mechanics of the suspensions into a filter/transfer function form; I added something resembling that into foton and turned the resulting filter on using the shiny new MEDM screens. However, the transfer functions are a tad wonky (particularly the one for pitch), so I shall continue working on them. It had a dramatic effect on the power spectrum (i.e. it looks a lot more like it should), but it still looks weird.

Still haven't found the e-log Jamie and Rana referred me to, concerning the injection of seismic noise into the simulation. I'm not terribly worried though, and will continue looking in the morning. Worst case scenario, I'll use the filters Masha made at the beginning of the summer.

Masha and I ate some of Jamie's popcorn. It was good.

 Okay! Attached are two power spectra. The first is a power spectrum of reality, the second is a power spectrum of the simPlant. Its looking much better (as in, no longer obviously white noise!), but there seems to be a gain problem somewhere (and it doesn't have seismic noise). I'll see if I can fix the first problem then move on to trying to find the seismic noise filters.

Attachment 1: Screenshot.png
Screenshot.png
Attachment 2: Screenshot-1.png
Screenshot-1.png
  7141   Fri Aug 10 11:00:52 2012 SashaUpdateSimulationsMessing with ETMX

I've been trying to get the simPlant model to work, and my main method of testing is switching between the real ETMX and the simulated ETMX and comparing the resulting power spectrum (the closer the two are, the more our simulation works). While the simPlant is on, ETMX is NOT BEING DAMPED. I started this ~Wednesday, and the testing will continue today, then hopefully we'll get a similiar simPlant up for ITMX (at which point, testing will continue for both ITMX and ETMX).

TL;DR: ETMX is not being continuously damped, XARM will likely be exhibiting some wonky behavior next week.

  7151   Sat Aug 11 01:10:26 2012 SashaUpdateSimulationsSim_Plant Working!

Sim_Plant going okay. Adding seismic noise tomorrow - we'll see what happens. The gain is still semi-off, but I know how to fix it - its just nice to have it gained up while I play with noise.

P.S. JAMIE DO YOU NOTICE HOW PRETTY MY GRAPH IS?

Attachment 1: Plant_sen.jpg
Plant_sen.jpg
  7152   Sat Aug 11 18:05:49 2012 SashaUpdateSimulationsSim_Plant Working!

Quote:

Sim_Plant going okay. Adding seismic noise tomorrow - we'll see what happens. The gain is still semi-off, but I know how to fix it - its just nice to have it gained up while I play with noise.

P.S. JAMIE DO YOU NOTICE HOW PRETTY MY GRAPH IS?

Developed some seismic noise. I adapted the seismic noise filters we used for the MC model way back when.  They looked questionable to begin with, but I added some poles/zeroes to make it more accurate (see Attached).

Attachment 1: seismic_noise1.jpg
seismic_noise1.jpg
  7181   Tue Aug 14 16:33:51 2012 SashaUpdateComputer Scripts / ProgramsSimPlant indicator added

I added an indicator to the watch dog screen so that a little "SP" icon appears whenever the SimPlant is on. Since we only have one simplant (ETMX), only ETMX has the simPlant indicator. However, since assymetry is ugly, I moved all of the OL icons over so that they're in a line and so that there is room for future SP icons.

I also fixed the link to the Watchdogs on the main SUS screens (it was dead, but now it is ALIVE).

  7212   Fri Aug 17 04:13:45 2012 SashaUpdateSimulationsThe SimPlant Saga CONTINUES

THE GOOD: SimPlants ITMX and ETMX are officially ONLINE. Damping has been instituted in both, with varying degrees of success (see Attachment 1). An overview screen for the SimPlants is up (under XARM_Overview in the sitemap - you can ignore the seperate screens for ETMX and ITMX for now, I'll remove them later), C1LSP will be online/functional by Monday.

The super high low-frequency noise in my simPlant is from seismic noise and having a DC response of 1, so that the seismic noise at low frequencies is just passed as is and then amplified along with everything else in the m --> counts conversion. Not quite sure how to deal with this except by NOT having a DC response of 1 (which it technically doesn't have when you do the algebra - Rana said that "it made sense" for the optic to have unity gain at low frequencies, but the behavior is not matching up with reality).

THE BAD: It looks like the ITMX Switch from Reality to simPlant doesn't work (or some of the signals aren't getting switched). When switching from reality to simulation, it looks like the control system is receiving signals from the SimPlant, but is transmitting them to the real thing. As a result, when you flip the switch from reality to sim, ITMX goes seriously crazy and starts slamming back and forth against the stop. REALLY NOT GOOD. As soon as I saw what was going on, I turned back to reality and flipped the watch dogs on (YES THEY WERE OFF). I'll investigate the connections between the plant and control system some more in the morning (i.e. later today) (this is also probably what is causing the "lost connections" in c1sup/sus we can see in the machine status screen).

Attachment 1: plantvreality.jpg
plantvreality.jpg
  7218   Fri Aug 17 12:47:30 2012 SashaUpdateSimulationsThe SimPlant Saga CONTINUES

Quote:

THE GOOD: SimPlants ITMX and ETMX are officially ONLINE. Damping has been instituted in both, with varying degrees of success (see Attachment 1). An overview screen for the SimPlants is up (under XARM_Overview in the sitemap - you can ignore the seperate screens for ETMX and ITMX for now, I'll remove them later), C1LSP will be online/functional by Monday.

The super high low-frequency noise in my simPlant is from seismic noise and having a DC response of 1, so that the seismic noise at low frequencies is just passed as is and then amplified along with everything else in the m --> counts conversion. Not quite sure how to deal with this except by NOT having a DC response of 1 (which it technically doesn't have when you do the algebra - Rana said that "it made sense" for the optic to have unity gain at low frequencies, but the behavior is not matching up with reality).

THE BAD: It looks like the ITMX Switch from Reality to simPlant doesn't work (or some of the signals aren't getting switched). When switching from reality to simulation, it looks like the control system is receiving signals from the SimPlant, but is transmitting them to the real thing. As a result, when you flip the switch from reality to sim, ITMX goes seriously crazy and starts slamming back and forth against the stop. REALLY NOT GOOD. As soon as I saw what was going on, I turned back to reality and flipped the watch dogs on (YES THEY WERE OFF). I'll investigate the connections between the plant and control system some more in the morning (i.e. later today) (this is also probably what is causing the "lost connections" in c1sup/sus we can see in the machine status screen).

 Problem with ITMX solved! The ITMX block in c1sup hadn't been tagged as "top_names". I rebuilt and installed the model, and there are no longer lost connections, :D

  7225   Sat Aug 18 17:09:01 2012 SashaUpdateSimulationsC1LSP MEDM Screens Added

C1LSP has been added to the site map. I'll work on filling in the structure some more today and tomorrow (as well as putting up PDH and REFL/AS MEDM screens).

NOTE: Does anyone know how to access channels (or if they're even there) for straight Simulink inputs and outputs (i.e. I have some sort of input, do something to it in the simulink model, then get some output)? I've been trying to add ADC MEDM screens to c1lsp, but channels along the lines of C1LSP-ADC0_0_Analog_Input or C1LSP-ADC0_A0 don't seem to exist.

  7227   Sat Aug 18 19:40:47 2012 SashaUpdateSimulationsC1LSP MEDM Screens Added

Quote:

C1LSP has been added to the site map. I'll work on filling in the structure some more today and tomorrow (as well as putting up PDH and REFL/AS MEDM screens).

NOTE: Does anyone know how to access channels (or if they're even there) for straight Simulink inputs and outputs (i.e. I have some sort of input, do something to it in the simulink model, then get some output)? I've been trying to add ADC MEDM screens to c1lsp, but channels along the lines of C1LSP-ADC0_0_Analog_Input or C1LSP-ADC0_A0 don't seem to exist.

 NVM. Figured out that I can just look in dataviewer for the channels. It looks like there aren't any channels for ADC0...I'll try reinstalling the model and restarting the framebuilder.

  8101   Mon Feb 18 23:41:15 2013 SendhilUpdateAlignmentAligned IPPOS, IPANG and OPLEVS

[Yuta, Sendhil]

We aligned IPPOS, IPANG and all OPLEVs (except for ETMX and SRM).

 

1. First aligned the IPPOS by tweeking the steering mirrors inside the BS chamber.

2. Aligned the IPANG by tweeking the steering mirrors inside the BS chamber and ETMY chamber.

3. Aligned the OPLEVS for the BS and PRM was done by tweeking the steering mirrors inside the BS chamber and checked that OPLEV beams were not clipped. 

4. Centred the OPLEV beams for the ITMY and ETMY.

5. For the OPLEV of ITMX the alignment was done by tweeking the steering mirrors inside the ITMX chamber.

 

Attachment 1: IPANGIPPOSoplevs.png
IPANGIPPOSoplevs.png
  3145   Wed Jun 30 12:13:39 2010 Sharmila, KatharineUpdateWIKI-40M Updateweekly update

Weekly Project Update:

We are studying Haixing's circuit diagram for the quadrant maglev control circuit.  We have analyzed several of the sub-circuits and plotted transfer functions for these in MatLab.  To check the circuit, we will compare the calculated transfer functions with those obtained from the HP control systems analyzer.

To learn how to use the control systems analyzer, we are reading App Note 243 as well as an online manual (477 pages in the first volume).  We are beginning with a simple test circuit, and are comparing its measured frequencyresponse with calculated transfer functions.  We currently have obtained a response graph beginning at 100 Hz (which we have not yet figured out how to print), and we are planning to investigate behavior at lower frequencies.

We also have been continuing our reading on control systems after a failed attempt at magnetic levitation. 

  3165   Wed Jul 7 11:23:08 2010 Sharmila, KatharineUpdateWIKI-40M Update 

Weekly Update:

Last Weds-Thurs, we wrote and edited our progress reports.

Tuesday (and Weds morning):  Continued circuit analysis of Haixing's circuit and plotting transfer functions (almost have one for entire circuit).  Hooked up OSEM and circuit to power supply, but the LED didn't appear to light up in IR.  Now we are going to hook the OSEM directly to the power supply, sans circuit, to see if the problem is with the circuit or OSEM.

  3214   Wed Jul 14 11:32:36 2010 Sharmila, KatharineUpdateWIKI-40M Update 

Weekly update:

We correctly connected our circuit to power source to verify that it was functional and that our LED in the shadow sensor turned on.  It did, but we also noticed a funky signal from the LED driver.  We continued to attempt 1x1 levitation, but determined that the temporary flag we were using out of convenience (a long, thin cylindrical magnet) was weakly attracted to residually magnetized OSEM components.  We then switched to an aluminum screw as our flag.

We resoldered and applied heat shrink to the wires connecting our coil to the BNC terminal, since they were falling apart.

We sat down with Rana and removed circuit components in the LED drive part by part to determine what was tripping up the circuit.  We determined a rogue capacitor to be at fault and removed it from the circuit.

We used a spectrum analyzer to measure the frequency response of our circuit (see details in last elog).  We are currently making a Simulink block diagram so we can check the stability of our setup, but are temporarily set back because our plotted calculation of the transfer function clearly doesn't match the measured one.

  3114   Thu Jun 24 11:16:32 2010 Sharmila, Rana and KiwamuHowToVACInspection of the BS (sorry, no sounds)
  3212   Wed Jul 14 01:05:27 2010 Sharmila,KatharineSummaryelogMaglev

Yesterday we hooked up the Quadrant Maglev control to the power supply to test the components in the Input/Output part of the circuit.

The output from the buffer was an unexpected high noise signal which was caused by some circuit components.

Consequently these were replaced/removed after confirming the source of noise.

The following is a story of how it was done.


To test the components of input/output, we measured the output across TP_PD3(Test Point -Photo Diode 3).
We got a high noise signal with a frequency of several kHz.

We tested the values of various electronic components. The resistances R5 and R6 did not measure as mentioned(each had a value of 50 K in the schematic). The value of R6 was 10 K and we replaced R5 with a 10 K resistor. We still got the noise signal at 5.760 kHz with a Pk-Pk voltage of 2.6 V. The resistors in R-LED measured 1.5 K instead of the marked 2.2 K.

P7120278.JPG
We had three suspects in hand:

  • BUF634P : A buffer from the Sallen-Key filter to the LED.
  • C24 : A capacitor which is a part of the Sallen-Key filter.
  • C23 : A capacitor in the feedback circuit of the Sallen-Key filter.


BUF634P : The data sheet for the BUF634P instructed a short across the 1-4 terminals in the presence of capacitive load.  We followed this to overcome the effect(if any) of the extra-long BNC cables which we were using. The oscilloscope still waved 'Hi!' at a few kHz. We removed the buffer and also the feedback resistor R42 from the circuit, what we were testing boiled down to measuring the output of the Sallen-Key filter. The output still contained the funny yet properly periodic signal at a few kHz.      

.P7120284.JPG    


C24: Removing C24 did not do any good.

C23: As a final step C23 was removed. And ... We got a stable DC at 9.86 V(almost stable DC with a low noise at a few MHz). C24 and the buffer were replaced and output seemed fine. The output was a high frequency sine wave which was riding on a DC of 9.96 V.

 

P7120281.JPG


We rechecked if the LED was on and the infrared viewer gave a positive signal.



We went ahead obtaining the transfer function of the feedback control for which we used a spectrum analyzer.

The input for feedback system is a photo current whereas the spectrum analyzer tests the circuit with a voltage impulse.  Hence the voltage input from the spectrum analyzer needs to be converted into current of suitable amplitude(few microamps) for testing the spectrum analyzer.  Similarly the output which is a coil current needs to be changed to a voltage output through a load for feeding into the channel of the spectrum analyzer. We used a suitable resistance box with BNC receiving ends to do this. We obtained a plot for the transfer function which is shown below.

P7140292.JPG


Future plans:

- Check the calculated transfer functions with the plot of the spectrum analyzer

- Model the entire(OSEM, magnet, actuators etc.) system in Simulink and calculate the overall transfer function

- Stable levitation of the 1X1 system

  3250   Tue Jul 20 11:55:15 2010 Sharmila,KatharineUpdateelogMaglev

We plotted the transfer functions for the maglev control circuit and compared them with the plots from the spectrum
analyzer. We were stuck for sometime because

1) we had wrongly entered the value of one of the resistors which was off by a factor of 2000.
2) The plots were not done in right units. So we couldn't figure out differences quite well.

The two plots are shown below. We are still off by a factor of 3 which we'll figure out soon.

P7140292.JPG

  3305   Wed Jul 28 12:09:06 2010 Sharmila,KatharineUpdateWIKI-40M UpdateMaglev

We have modeled our maglev setup in simulink but we have a few corrections to make since the system goes into undamped oscillations for an impulse in the input.

We have made a stable mount for the system and started to work on the 2X2 system using this mount. We have to figure out a way to match the magnets with the gain. We have attached the simulink block.

Picture_1.png

  3112   Thu Jun 24 01:02:34 2010 Sharmilla, Rana and KiwamuUpdateGreen Lockinga channel for PPKTP temperature

We added a channel on c1psl in order to monitor the temperature of the PPKTP sitting on the PSL table.

To take continuous data of the temperature we added the channel by editing the file: target/c1psl/c1psl.db

We named the channel "C1:PSL-PPKTP_TEMP".

To reflect this change we physically rebooted c1psl by keying the crate.

  563   Wed Jun 25 09:46:45 2008 SharonUpdate Adaptive Filters
I have been learning about different methods for applying adaptive filters to improve the Mode Cleaner lock in specific, and other LIGO systems in general.
Finding the exact number of coeffs we would like to apply for our FIR adaptive filter is very important to the efficiency of the filter. Getting this number higher might improve the accuracy of the filter, but costs time we do not have. Another important number to find is the step size. The step size is the variable that controls how far back we want to look into our data for finding the new coeffs. To understand more about the step size it is necessary to learn about the standard deviation of our input and output signals. By getting the step size too big, we are considering long term behavior, but might be missing out on a short term one.
In the near future I will be learning about the meanings of these variables and their contribution to the over all accuracy of our filters.
Results will be posted.
  704   Mon Jul 21 09:52:05 2008 SharonUpdate Adaptive code changes
Thanks to Alex, we now save the coefficients of the adaptive filter every cycle. When we choose ENABLE: OFF on the MEDM screen, suppressing the signal to the MC1, we stop and save the last coefficients. When enabling it again, it starts from the last coefficients saved. I will take some measurements today to check how this contributes to the adaptation rate. If you change the number of taps or the number of AUX channels, the coefficients are again set to zero.
  709   Mon Jul 21 19:48:57 2008 SharonUpdate how tp restart C1ASS
How to restart C1ASS:

1. reboot
2. as root: caltech/target/c1ass:> ./startass
3. no need for root: burtgooey

that's it...
  720   Wed Jul 23 10:47:05 2008 SharonUpdate Weekly update
This week I spent some time with Alex who updated the adaptive code to save the filter's coeffs all the time, stop when I open the loop, and reload the latest coeffs. when I start it again.
The point was to minimize the adaptation rate. Unfortunately, seems it is making some filters go wild, so it is not in use yet.
After taking some more measurements with the adaptive filter running, I have noticed a new peak in the signal around 22-23 Hz. My first assumption was that this is caused due to internal resonance of MC1 (which is driven when the adaptive code is running, and not when it's not). Therefore, I drove MC1 without the adaptive filter looking for the same peak... which wasn't there.
This sent me back to the adaptive code... Seems there is a matrix in the simulink file of the adaptive filter which doesn't have an MEDM screen. I am now working on making this screen. Once I am done with that, and make sure there is correlation between simulink and MEDM, I'll keep on chasing the peak in the code.
  723   Wed Jul 23 13:52:26 2008 SharonUpdate MEDM changes
There is a new MEDM screen now when you go from c1ass>top>pem.
Instead of having 12 "mini filters" screens go to 8 outputs (with the wrong correlation impression from the table), we have a 24X8 matrix.
This matrix is there so you could choose which noise signals you want to send to the adaptive code. When you indicate the number of noise channels you are going to use
on the nAUX option on the screen top, you are choosing the channels 1 to nAUX. Channels 15-22 are the seismic and accelerometers we are now using. (you can see the order in Jenne's post 673).
Hope this will make things clearer.
Attachment 1: matrix
  739   Fri Jul 25 13:30:53 2008 SharonUpdate Changes in ASS computer
I editted the simulink diagram of the ASS computer so it now has 2 more channels reading 2 sets of the FIR coefficients to match Alex's changes in the C code.
The new simulink has already been compiled and can be found in /cvs/cds/caltech/users/alex/cds/advLigo/src/epics/simLink/ass.mdl
I backed up the old file and it's also in that folder under ass_BAK_24_jul.mdl

There is also a backup of the old ASS.ini file in caltech/chans/daq/C1ASS_BAK_24_jul.ini

Will update once it's all set and running
  740   Fri Jul 25 17:32:46 2008 SharonUpdate ASS computer
So, it seems a bit too complicated getting the coefficients the way I wanted it to happen (simulink-.ini...).
I returned everything to the way it was and it's all working. The new plan is to choose the specific channel I want to find its instantanous coefficients, let the adaptive code run for a while, setting mu and tau to zero (freezing the coefficients), and exciting the noise signal channel taking the transfer function. This way I can find the filter I want to simulate with an IIR filter.
Once I have the mode cleaner to myself, I'll start posting results.
  747   Mon Jul 28 12:02:32 2008 SharonUpdate accelerometers settings
Jenne, Sharon


We looked again at the channels of the accelerometers and there are some updates. Last time when we reported, we crossed the ADAP channels and the accelerometer. Now that there is a new MEDM screen, with which you can control which channels goes to which adaptive channels, this has no meaning...
Therefore, the channels that go with the noise source channels are:

PEM 15 MC1_X
PEM 16 MC1_Y
PEM 17 MC1_Z
PEM 18 MC2_X
PEM 19 MC2_Y
PEM 20 MC2_Z
PEM 21 SEIS

disregard the last post regarding these channels by Jenne, since I am changing the ADAP channels all the time...
  750   Mon Jul 28 17:58:05 2008 SharonUpdate TOP screen changes
I wanted to test the adaptive code with a downsampling rate of 32 instead of 16. To do this I entered a 32 Hz ((2048/32)/2 - match Nyquist Freq.) low pass filter on the ERROR EMPH, MC1 and the relevant PEM channels.
  760   Tue Jul 29 21:04:55 2008 SharonUpdate OSEM's Power Spectrum
From 16:30 this afternoon
Attachment 1: ITMY2.JPEG
ITMY2.JPEG
Attachment 2: ITMY.JPEG
ITMY.JPEG
Attachment 3: ITMX2.JPEG
ITMX2.JPEG
Attachment 4: ITMX.JPEG
ITMX.JPEG
Attachment 5: ETMY2.JPEG
ETMY2.JPEG
Attachment 6: ETMY.JPEG
ETMY.JPEG
Attachment 7: ETMX2.JPEG
ETMX2.JPEG
Attachment 8: ETMX.JPEG
ETMX.JPEG
  765   Wed Jul 30 12:36:19 2008 SharonUpdate Weekly update
This week included many computer's issues. I tested Alex's new C code (the one that saves the FIR coefficients and restores them when you start running the code again). Seems there is an improvement in the adaptation time, but not a significant one (more details on the coming report). I had to recompile simulink and the FB whenever I wanted to find a solution for taking the record of those coefficients. This is so I could simulate the adaptive filter with a regular IIR filter and compare the two.
After Rob tried to help and it seems to be an impossible to a huge hassle mission, we thought of a different method to do this. I re-compiled the old simulink file and restored the .ini file and all should be back in place. Instead of finding the FIR coefficients, I am going to use one noise source in the adaptive filter, stop the adaptation (by setting mu and tau to 0), and put excitation instead of the noise signal. The transfer function I will get between the exc. and MC1_IN1 is the filter I am looking for.

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

I have also been working on my progress report, and stood in line for the MC... Still standing...
  814   Fri Aug 8 11:04:34 2008 SharonUpdate MCL Wiener filter
I took some old data from Rana and converted the units of the Weiner filter to m/m so to make the effect of the seismometer and accelerometers more obvious.

The data is in counts, and so to convert to m this is what I did:

%%% MC_L calibration
v_per_counts = 5/32768;
v_per_v = 3;
amp_per_N = 1/0.064;

%%% Accelerometers calibration
v_per_counts_acc = 61.045e-6;
g_per_v = 9.8/100;

%%% Seismometer calibration
v_per_counts_seis = 61.045e-6;
m_per_s_per_s_per_volt = 9.8/100;
m_per_v_per_s = 1/345;



for jj=1:6
hfmatm(:,jj)=hfmat(:,jj).*(v_per_counts.*v_per_v.*amp_per_N.*f)./(v_per_counts_acc*g_per_v); %%% accelerometers' data
end
hfmatm(:,7)=hfmat(:,7).*(v_per_counts.*v_per_v.*amp_per_N)./(v_per_counts_seis*m_per_v_per_s); %%% Seismometer data
Attachment 1: m_per_m.png
m_per_m.png
ELOG V3.1.3-