40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 223 of 346  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  6499   Fri Apr 6 19:04:35 2012 JenneUpdatePEMSTS releveled, GUR2 plugged in

[Den, Jenne]

We were wondering why the STS-2 signal was funny.  When I went to look at it, the X-axis indicator was pointing ~45deg from the x-axis, so that it was pointing between the arms of the IFO.  Also, the bubble in the level was totally stuck on one side.  We locked the masses, and I put the seismometer back to the correct orientation, and then leveled it.  We unlocked the masses and turned the power back on, and hit the auto-zero button a few times.  Right now the X-axis signal is fine, but Y and Z are still railed, but it's been like 24 seconds, not 24 hours since we last hit auto zero, so there's still some time to wait.

Also, GUR2 was unplugged on both ends of the cable.  We plugged it back in.  However, it looks like the *seismometer* labeled #1 is now plugged into *channels* GUR2, and the seismometer labeled #2 is plugged into channels GUR1.  Recall that Den has only modified X, Y, Z for GUR1 channels, not any other channels in the breakout box.

  7080   Thu Aug 2 22:52:23 2012 MashaConfigurationPEMSTS, GUR2, and Trillium in isolation box.

Den and I moved the Streckeisen, Guralp 2, and Trillium seismometers to the isolation box in order to measure the noise of the Streckeisen while we have the Trillium.

  6977   Mon Jul 16 11:50:56 2012 MashaUpdatePEMSTS-1

It seems that the STS-1 ADC channels had the same mismatch issue as the GUR-2 channels. The PEM_MONITOR has STS_1 listed as channels 6, 7, 8 (+1 on the actual ADC) whereas it was plugged into channels 13, 14, 15 (+1 on the actual ADC as well) with nothing in channels 6, 7, 8. Thus, I moved the cables and reset STS_1. The readout, however, is still only a magnitude of ~10 counts (I checked, however, that this is indeed the readout when the seismometer is plugged in vs. when it is unplugged), but hopefully it will stabilize during the day, as did GUR 2.

  5059   Fri Jul 29 12:25:54 2011 Ishwita, ManuelUpdatePEMSTS-2 seismometer box

The 'Bacardi' STS-2 seismometer was tested with the "purple" breakout box and it was found out that all the three axes gave a voltage of 11 V (as shown on the screen of the oscilloscope) before pressing the auto-zero button and after pressing it the voltage shown was 6 V. We tried again the blue box and it was working perfectly after pushing the auto zero button (the auto zero took a few seconds). The power of the purple box is still on, we will wait a few hours, to see if something changes.

  5018   Fri Jul 22 14:22:13 2011 Ishwita, ManuelUpdatePEMSTS-2 seismometer hardware testing

We have two STS-2 seismometer boxes... the blue box & the purple box. Initially we used the blue box for the STS-2 seismometer (named Bacardi by Jenne).

  • Oscilloscope powered on battery was used to test the blue box by observing the velocity output of the three axes (X, Y, Z).  It was found out that the mean value of DC volt of...

X = +10 V

Y = +11 V

Z = -0.1 V

Thus, X and Y axes showed abnormally high DC volt. It was also found out that in AC coupling mode of the oscilloscope... changes were observed in the signal received from Z axis when some seismic wave was generated near the Bacardi by jumping near it. No such changes were observed from signals received from X & Y axes.

  • We removed the blue box and used the purple box for the same Bacardi seismometer & used the oscilloscope powered on battery to test it. It was found out that the mean value of DC volt of...

X = +4.4 V

Y = +4.4 V

Z = +4.4 V

In Ac coupling mode of the oscilloscope... changes were observed in the signals from X, Y, Z axes when someone jumped near Bacardi.

  • The above voltages from the two STS-2 seismometer boxes are unsuitable for the ADC box since it works with voltages ranging from +2 V to -2 V.... meaning it will consider any voltage signal above +2 V as +2 V and any signal below -2 V as -2 V. Hence we need to find out how to use these STS-2seismometer boxes with the ADC box.
  • We also tried measuring the DC volt from the shield and the center of a BNC connector corresponding to Y axis of the purple box (lets call it 'BNC-test') by using BNC-to-banana adaptors and banana wires. Signal from shield of BNC-test was sent to oscilloscope's channel 1 (connected to center of its BNC connector) and signal from center of BNC-test was sent to oscilloscope's channel 2 (connected to center of its BNC connector). On the oscilloscope screen it was observed that both the signals gave the same mean voltage output (-2.2V).
  5033   Mon Jul 25 18:51:38 2011 ManuelUpdatePEMSTS-2 seismometer hardware testing with Jan

[Jan, Manuel, Jenne]

Jenne called Jan to check and figure out why the Streckeisen seismometer (SN #100151) doesn't work, hence we checked the output of the seismometer boxes as we did last friday. (This is the problem of seeing the X and Y channels saturated, when we look at them on a floating 'scope, as in the linked elog entry.)

Jan unplugged and plugged again the orange cable into the seismometer and nothing happened.   Well, what Jan was listening for was "clicks" inside the seismometer indicating that it was receiving power.  We heard these, and moved on to examining the breakout boxes.  Also, we checked that we could hear the "clicks" (one per mass) when we pushed the mass-centering button on the little green companion box.

We weren't sure that the purple box was working properly, so since we had seen the blue box work last time, we changed the purple box with the blue box in rack 1X6.

The Z-channel of the purple box returns a correct signal, that means that all the masses in the seismometer work (because the Z-signal is a linear combination of the three masses U, V, W), the X and Y channel have a DC component of about 10 Volts, Jan said that the recentering of the seismometer masses could need all the night, so we keep the power of the box on. If tomorrow morning the X and Y signal won't  both be zero mean, we will open and check the box.

The power of the box is still on so that the masses can recenter overnight.

Edits by JD

  5213   Fri Aug 12 17:05:22 2011 Manuel, IshwitaConfigurationPEMSTS2 Cable configuration

The WWF_M connector is the end of the STS2 seismometer orange cable and the S1 connector is the end of the gray 26-pin-cable

01050901.PDF

  4484   Mon Apr 4 11:52:13 2011 JenneUpdatePEMSTS2s unpacked

I unpacked the STS2 seismometers that we borrowed from LLO.  They are sitting underneath the Xarm, in the middle of the mode cleaner, near the other seismometer stuff. 

  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.

 

 

  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
  12118   Tue May 17 05:50:43 2016 Varun KelkarUpdateGeneralSURF 2016

Hello, I am Varun Kelkar. I will be working at the 40m lab as a SURF student this summer with Eric Quintero on Audio processing for real time control system signals. This week I will mostly be working on implementing basic DSP C-code offline. Currently I am trying to write a code for noise whitening.

-Varun

  12121   Wed May 18 17:42:52 2016 VarunUpdateGeneralSURF 2016

Finished writing the code on whitening. I have to still test it. uploaded on github noise cancellation repo. @eric could you give me some data of noise power spectral density for testing the code?

-Varun

Quote:

Hello, I am Varun Kelkar. I will be working at the 40m lab as a SURF student this summer with Eric Quintero on Audio processing for real time control system signals. This week I will mostly be working on implementing basic DSP C-code offline. Currently I am trying to write a code for noise whitening.

-Varun

 

  12123   Fri May 20 00:06:19 2016 VarunUpdateGeneralSURF 2016

I have written a basic version of AGC, and have done some tests with a data file. will do tests on whitening and agc today. Also, today I have to go to the SSN office. Hence will be late.

 

-Varun

Quote:

Finished writing the code on whitening. I have to still test it. uploaded on github noise cancellation repo. @eric could you give me some data of noise power spectral density for testing the code?

-Varun

Quote:

Hello, I am Varun Kelkar. I will be working at the 40m lab as a SURF student this summer with Eric Quintero on Audio processing for real time control system signals. This week I will mostly be working on implementing basic DSP C-code offline. Currently I am trying to write a code for noise whitening.

-Varun

 

 

  12127   Mon May 23 17:47:51 2016 VarunUpdateGeneralSURF 2016

Tested the AGC today with LSC cavity transmission signal and error signal. Not in real time still.

Key to attachments:

cav_tr-eps-converted-to.pdf: LSC cavity transmission signal input

cav_tr_out-eps-converted-to.pdf: LSC cavity transmission signal, output of the AGC.

Attachment 1: cav_tr-eps-converted-to.pdf
cav_tr-eps-converted-to.pdf
Attachment 2: cav_tr_out-eps-converted-to.pdf
cav_tr_out-eps-converted-to.pdf
Attachment 3: err-eps-converted-to.pdf
err-eps-converted-to.pdf
Attachment 4: err_out-eps-converted-to.pdf
err_out-eps-converted-to.pdf
  12136   Wed May 25 14:29:31 2016 VarunUpdateGeneralSURF 2016

Edited the AGC to include overlapping frames yesterday. forgot to put an elog on it!

Quote:

Tested the AGC today with LSC cavity transmission signal and error signal. Not in real time still.

Key to attachments:

cav_tr-eps-converted-to.pdf: LSC cavity transmission signal input

cav_tr_out-eps-converted-to.pdf: LSC cavity transmission signal, output of the AGC.

 

  12137   Thu May 26 18:10:48 2016 VarunUpdateGeneralSURF 2016

Wrote and tested a function for downconversion. It contains a mixer with a sinusoidal input for modulation with the desired frequency and a 2nd order butterworth low pass filter to remove the higher frequency-shifted part of the modulated signal. I have tested this with input of 2kHz giving a good output of 200 Hz on the speaker. Codes are uploaded on github, will update the real time document tomorrow.

 

-Varun

Quote:

Edited the AGC to include overlapping frames yesterday. forgot to put an elog on it!

Quote:

Tested the AGC today with LSC cavity transmission signal and error signal. Not in real time still.

Key to attachments:

cav_tr-eps-converted-to.pdf: LSC cavity transmission signal input

cav_tr_out-eps-converted-to.pdf: LSC cavity transmission signal, output of the AGC.

 

 

Attachment 1: input.png
input.png
Attachment 2: output.png
output.png
  12153   Tue Jun 7 17:21:13 2016 AakashUpdateGeneralSURF 2016

Hi!

I am Aakash Patil. I will be working at the 40m lab as a SURF student with Gautam Venugopalan on enclosures for seismometers to shield them from thermal and magnetic fluctuations. This week I will be working on the development of hardware for four probe measurement along with a constant current source. It will effectively help us in accurate temperature measurement throughout the development of enclosure.

 

  12134   Wed May 25 11:51:40 2016 SteveUpdatesafetySURF 2016 safety
Quote:

Hello, I am Varun Kelkar. I will be working at the 40m lab as a SURF student this summer with Eric Quintero on Audio processing for real time control system signals. This week I will mostly be working on implementing basic DSP C-code offline. Currently I am trying to write a code for noise whitening.

-Varun

Varun has received 40m specific basic safety training today.

  12157   Wed Jun 8 10:20:14 2016 SteveUpdatesafetySURF 2016 safety

Aakash Patil received 40m specific basic safety training.

Quote:
Quote:

Hello, I am Varun Kelkar. I will be working at the 40m lab as a SURF student this summer with Eric Quintero on Audio processing for real time control system signals. This week I will mostly be working on implementing basic DSP C-code offline. Currently I am trying to write a code for noise whitening.

-Varun

Varun has received 40m specific basic safety training today.

 

  12228   Wed Jun 29 15:34:00 2016 SteveUpdatesafetySURF 2016 safety

Praful Vasiceddy received 40m specific basic safety training.

Quote:

Aakash Patil received 40m specific basic safety training.

Quote:
Quote:

Hello, I am Varun Kelkar. I will be working at the 40m lab as a SURF student this summer with Eric Quintero on Audio processing for real time control system signals. This week I will mostly be working on implementing basic DSP C-code offline. Currently I am trying to write a code for noise whitening.

-Varun

Varun has received 40m specific basic safety training today.

 

 

  6962   Wed Jul 11 14:22:54 2012 EricSummaryGeneralSURF Update

Here's what I accomplished since my last elog:

I continued working on the beatbox calibration. Instead of using the function generator for an input signal,
I used the network analyzer because it can generate higher frequencies that are of more interest to us. I ran
the network analyzer output into the RF in port, and took voltage measurements from the Q port using the
oscilloscope. The frequency range I focused on was 100 - 200 MHz, and I also took more closely spaced measurements
from 180 - 200 MHz. The data is recorded on the computer now, and I will analyze it more fully in the future.

I also edited the Calibration page on the LIGO 40 m wiki. Rana showed me the page on calibration, but there was
limited information there, so he recommended that I post my work there as well. Right now I haven't posted much,
but I will likely add some information on the Simulink model I'm working on and results of measurements to be
taken as the project progresses.

The majority of my work has been on developing a Simulink model in Matlab of the differential arm length sensing
and control loop
. I am using Figure 6-1 from Rana's thesis as a guide on important components to include in the
model. Some of the details on the transfer functions of components need to be worked out, but a basic framework has
been established. Right now the transfer function of the arm cavity is being approximated as a single pole, but
we may integrate the calibration model I'm working on with Sasha's work on the arm cavity. I have also begun to
implement the length response function in the model
. I believe it is giving correct results at frequencies up to
100 Hz, but is off at higher frequencies. This might be fixed after I continue to fill in the transfer functions
of the digital components; they are currently set to 1 until I find more information on them.

  6990   Wed Jul 18 15:38:05 2012 EricSummarySimulationsSURF Update

Most of my work has been on continuing to develop the Simulink model of the differential arm length control loop.
I have filled in transfer functions for the digital components after looking up the configuration of filters and
gains on the control screens. Filters that were active at the time included 1:50 and 1000:10 on C1LSC_YARM and
C1LSC_POY11 with a gain of 0.1. Jamie also introduced me to foton so that I could obtain the transfer functions
for the necessary filters. I have also continued to work on obtaining the open loop gain and length response
function from the model. The majority of the work now is to refine what I've accomplished so far. Adding details
to the arm cavity and the optics is one potential area for improvement.

I have also spent some time looking at real-time calibration methods from GEO and a proposal for a similar system
on LIGO in P040057-x0 from the DCC. While the work for this project may follow a different path for a real-time
calibration, having a sense for what's been accomplished so far should be helpful in working on a new system.

  7025   Wed Jul 25 11:34:31 2012 EricSummarySimulationsSURF Update

I am continuing work on simulating the DARM control loop. There is now a block for the length response
function
that allows one to recover the h(t) GW input to the model. However, in order to add this
block I had to add some artificial poles to the length response function beacuse Simulink gave me errors
when the transfer function had more zeros than poles. The artificial poles are at 10^6 Hz and higher, so
that they should not affect the response function at the lower frequencies of interest. This approach
appears a bit computationally unstable though because without changing any parameters and re-running
the simulation, a different magnitude for h(t) would be calculated sometimes. A different method may be
necessary to get this working more accurately
.

By looking through the C1LSC Simulink model and the C1LSC control screens, Jenne helped me determine
which digital filters are active while the interferometer is locked
. To do this, open the C1LSC control
screen, then open the trigger matrix. Inside the trigger matrix window there is a button titled Filter
Module Triggers which opens another window that indicates which filters are triggered for a given channel,
and what values trigger them. For the y arm servo filters FM2, 3, 6, 7, 8 are triggered while in lock and
FM4 and 5 are controlled manually; I am including all of these in the model now. 

I have changed the way I manipulate the output from the model for analysis, using Rana's advice. I also
improved the plotting code, now using a custom Bode plot instead.

Attached is a screenshot of the Simulink model as it currently stands, and an older implementation of the
open loop gain
. I am in the process of updating the servo filters now, and what is shown in the plot does
not include all the filter modules for the servo filter.

 

 

Attachment 1: DARM_control_loop_hendries.PNG
DARM_control_loop_hendries.PNG
Attachment 2: OLG_old_hendries2.png
OLG_old_hendries2.png
  7064   Wed Aug 1 10:38:11 2012 EricSummaryGeneralSURF Update

Since my last update I have modified the DARM control loop model to the extent that it resembles the
measured open loop transfer function much more closely
. The phase especially is much more accurate, with
a phase margin of about 35 degrees at the unity gain frequency of 156 Hz. Right now I'm normalizing to
the unity gain frequency still to adjust the gain properly. Using the length response function from the
model, I can calibrate the error signal as well to find the simulated h(t) output. There were a number of
computational problems in calculating the length response function, but I eventually found a work-around.
Attached is an updated plot of the open loop transfer function and the length response function of the model.

This week Jamie showed me around the real-time Simulink models as well. The one specific to my project
is c1cal.mdl
. It takes the output in the form of the error and control signals from c1lsc.mdl as its
input and produces the calibrated signal as output. In order to produce the calibrated signal we need the actuation
function and the inverse of the sensing function for the model as it stands now. We also built, installed,
and restarted the c1cal model because no data was showing up in data viewer, but the problem remained
after this attempt. 

Jamie and I also started on calibrating the interferometer in the traditional way. Jamie aligned the beam
splitter and the input test masses so we could take free-swinging Michelson measurements. However, taking
the data with the nds system appears to be giving different results than what is showing up in data viewer.
The goal of this measurement is to get a value for the peak to peak amplitude of the Michelson error signal.

Attachment 1: OLG_hendries.png
OLG_hendries.png
Attachment 2: Length_response_hendries.png
Length_response_hendries.png
  7119   Wed Aug 8 13:16:58 2012 EricSummaryGeneralSURF Update

This week I spent most of my time learning about how the interferometer is calibrated and working on the calibration itself. I also looked more into the Pound-Drever-Hall technique.

Continuing work on the free-swinging Michelson measurements, I changed the signal that I was using to C1:LSC-ASDC_OUT_DQ. This is a proper power signal so that the peak-to-peak amplitude of this error signal can be directly read off the graph. The motivation to measure this amplitude is that it must be known in order to calibrate the actuation of the input and end test masses.

Next I looked into using DTT to make some measurements. I ran the Michelson restore script in the IFO Configure screen to adjust the optics to be near alignment. Then I tweaked the precise settings in the IFO Align screen of pitch and yaw for the ITMX, ITMY, and BS. The goal with this was to minimize the magnitude of the C1:LSC-ASDC_OUT_DQ signal. After it was well-aligned, back in DTT I sent in a sine wave excitation and used a Triggered Time Response measurement to see the output. As a first test I put the excitation signal in the ASDC channel and I was able to plot the resulting OUT signal in DTT. The amplitude was different than I input due to gains between the excitation and the point of measurement, but this can easily be accounted for by adjusting the amplitude in DTT accordingly.

The next step is to work on measurements of a single arm cavity, introducing excitations there and measuring the response.

  7195   Wed Aug 15 16:29:59 2012 Eric SummaryGeneralSURF Update

This week I took more data for the calibration of YARM. The summary of measurements taken is:

1. Peak-to-peak on Michelson
2. Michelson open loop
3. Excite ITMY and measure on AS55_Q_ERR
4. Excite ITMY and measure on POY11_I_ERR
5. Excite ETMY and measure on POY11_I_ERR
6. YARM open loop

Then I worked on comparing these measurements to the Simulink model of the interferometer control loop. The measured open loop transfer function of the YARM matched well with the model above about 20 Hz, after the gain was scaled properly to fit the data. Next is to fit the length response function of the model and the measurements, and then use DTT to calibrate the arm cavity's power spectrum.

  6881   Wed Jun 27 14:12:44 2012 EricSummaryGeneralSURF Week 1

I started work familiarizing myself with the ELOG and some of the control systems at the 40m. I spent a fair bit of time gaining some general knowledge of the interferometer, control systems, calibration, null instruments, etc. On Friday, June 22 Yaakov and I spent the afternoon pulling cables for the beatbox that Jamie had finished up. We were able to get the cables from the rack containing the beatbox routed to the control room.

Then I started work on calibrating the beatbox. I set up the function generator to send a sine wave into the beatbox, then sent the signal from the beatbox to the oscilloscope. I compared both the input sine wave and the output from the beatbox at many frequencies, taking peak to peak measurements. I'm working on using the data to calibrate the beatbox now.

  1697   Wed Jun 24 12:04:22 2009 ZachUpdateCamerasSURF entry

This week, I've been reading some literature concerning PLL and familiarizing myself with LINUX, MATLAB, and high-pass filter circuits.  In MATLAB, I started constructing matrices to be used for a beam path analysis from the laser output to the ccd camera.  I also built a simple high-pass filter on a bread-board that Joe and I are currently testing with the spectrum analyzer.

  3150   Wed Jun 30 18:16:55 2010 steveUpdateSAFETYSURF safety training 2010

40m SURFs Razib Obaid, Nancy Aggarwal, Unknown Bearded SMURF, Megan Daily, Gopal Nataraj, Katharine Larson and Sharmila Dhevi received 40m specific safety training on June 23, 2010.

Attachment 1: DSC_1902.JPG
DSC_1902.JPG
  6848   Thu Jun 21 15:00:55 2012 steveUpdateSAFETYSURFs 2012 safety training

Masha, Eric, Yaakov, Liz and Sasha received 40m specific basic safety training.

Attachment 1: surfs2012.JPG
surfs2012.JPG
  652   Wed Jul 9 15:04:22 2008 steveMetaphysicsPhotosSURFs helping hands
Surf students are helping out with baffle cleaning.
Attachment 1: surfjob.png
surfjob.png
  4902   Tue Jun 28 21:05:05 2011 JamieUpdateSUSSUS control model updated

I have updated the sus_single_control model, adjusting/cleaning up/simplifying the LSC/POS input signals, and routing new signals to the lockins. Notably one of POS inputs to the part ("lockin_in") was eliminated (see below).

The 6 inputs to the TO_COIL output matrix are now:

LSCPOS + OFFSET + ALT_POS_IN
ASCPIT + OFFSET + SUSPIT + OLPIT
ASCYAW +OFFSET + SUSYAW + OLYAW
SIDE
LOCKIN1
LOCKIN2

The ALT_POS input is used only by the ETMs for the green locking. Just outside of the sus_single_control library part in the ETM models are the green locking controls, consisting of the ETM?_ALS filter bank and the ETM?_GLOCKIN lockin, the outputs from which are summed and fed into the aforementioned ALT_POS input.

As for the SUS lockins (LOCKIN1 and LOCKIN2 in the library model), their input matrix now gets the direct inputs from the OSEMS (before filtering) and the outputs to the coils, after all filtering. These will aid in doing binary output switching tests.

All suspension models (c1sus, c1scx, c1scy) have been rebuild and restarted so that they reflect these changes.

  6623   Tue May 8 09:58:17 2012 DenUpdateCDSSUS -> FB

 [Alex, Den] 

It was in vain to restart mx_stream yesterday as C1SUS did not see FB

controls@c1sus ~ 0$ /opt/open-mx/bin/omx_info 

Open-MX version 1.3.901
 build: root@fb:/root/open-mx-1.3.901 Wed Feb 23 11:13:17 PST 2011
Found 1 boards (32 max) supporting 32 endpoints each:
 c1sus:0 (board #0 name eth1 addr 00:25:90:06:59:f3)
   managed by driver 'igb'
Peer table is ready, mapper is 00:60:dd:46:ea:ec
================================================
  0) 00:25:90:06:59:f3 c1sus:0
  1) 00:60:dd:46:ea:ec fb:0                           // this line was missing
  2) 00:14:4f:40:64:25 c1ioo:0
  3) 00:30:48:be:11:5d c1iscex:0
  4) 00:30:48:bf:69:4f c1lsc:0
  5) 00:30:48:d6:11:17 c1iscey:0
 
At the same time FB saw C1SUS:
 
controls@fb ~ 0$ /opt/mx/bin/mx_info
 
MX Version: 1.2.12
MX Build: root@fb:/root/mx-1.2.12 Mon Nov  1 13:34:38 PDT 2010
1 Myrinet board installed.
The MX driver is configured to support a maximum of:
8 endpoints per NIC, 1024 NICs on the network, 32 NICs per host
===================================================================
Instance #0:  299.8 MHz LANai, PCI-E x8, 2 MB SRAM, on NUMA node 0
Status: Running, P0: Link Up
Network: Ethernet 10G

MAC Address: 00:60:dd:46:ea:ec
Product code: 10G-PCIE-8AL-S
Part number: 09-03916
Serial number: 352143
Mapper: 00:60:dd:46:ea:ec, version = 0x00000000, configured
Mapped hosts: 6

                                                        ROUTE COUNT
INDEX    MAC ADDRESS     HOST NAME                        P0
-----    -----------     ---------                        ---
   0) 00:60:dd:46:ea:ec fb:0                              1,0
   1) 00:30:48:d6:11:17 c1iscey:0                         1,0
   2) 00:30:48:be:11:5d c1iscex:0                         1,0
   3) 00:30:48:bf:69:4f c1lsc:0                           1,0
   4) 00:25:90:06:59:f3 c1sus:0                           1,0
   5) 00:14:4f:40:64:25 c1ioo:0                           1,0
 
For that reason when I restarted mx_stream on c1sus, the script tried to connect to the standard 00:00:00:00:00:00 address, as the true address was not specified.
 
Alex restarted mx on FB. Note, DAQD process will not allow one to do that until it runs, at the same time, you can't just kill it, it will restart automatically. For that reason one should open /etc/inittab and replace respawn to stop in the line
 
daq:345:respawn:/opt/rtcds/caltech/c1/target/fb/start_daqd.inittab
 
then execute inittab using init q and restart mx on the FB
 
controls@fb ~ 0$ sudo /sbin/init q
controls@fb ~ 0$ sudo /etc/init.d/mx restart
 

After that C1SUS started to communicate with FB. But the reason why this happened and how to prevent from this in future Alex does not know.

Restarting DAQD process (or may be C1SUS) also solved the problem with guralp channels, now they are fine. Again, why this happened is unknown.

 

  10934   Fri Jan 23 10:07:15 2015 SteveUpdateSUSSUS Drift ETMX vs ETMY

ETMX YAW stopped drifting Jan 8, 2015

Quote:

I made little scripts to go with the sus driftmon buttons, that will servo the alignment sliders until the susyaw and suspit values match the references on the driftmon screen.

Attachment 1: SUSdrift30d.png
SUSdrift30d.png
  10870   Wed Jan 7 14:35:44 2015 diegoUpdateSUSSUS Drift Monitor

The SUS Drift Monitor screen has been updated:

  • removed the old dead channels from the MEDM screen;
  • updated the SUS models with new 'mute' channels where the expected values should be put;
  • updated the MEDM screen with the new channels
  • values are still 0 since I don't know what these expected values should be, at this time

 150107_SUS_DRIFTMON_screen.png

  10881   Thu Jan 8 23:02:30 2015 diegoUpdateSUSSUS Drift Monitor

The MEDM screen has been updated: the new buttons, one for each optic, call the scripts/general/SUS_DRIFTMON_update_reference.py script, which measures (and averages) for 30s the current values of the POS/PIT/YAW drifts, and then sets the average as the new reference value.

 

  763   Wed Jul 30 01:08:50 2008 ranaSummarySUSSUS Drift Screen
This is a snap of the SUS Drift screen with all of the optics biases set back to their nominal
values except for the MC which Rob aligned and I didn't feel like mis-aligning. The reference
on the screen is from 3/25 when Andrey felt that Rob had a good IFO alignment.

Anything more than a few thousand is significant and more than 10k means something is wrong:



I wailed on the PRM for awhile and was able to loosen it up a little. The LL & LR sensors now
show some life one the dataviewer. The UL & UR are still railed ~1.6 V so that means that the
optic is pitched back. With aggressive pitch wailing I can see the PRM's ULR/UR sensors go
rail to rail so that means that the magnets are still on - although they may be half busted.
If they're OK we should be able to just re-sling this guy.


Did the same on SRM. The OSEM values have shifted on these, but not disastorously. The SIDE,
however, is completely unresponsive. The little signal I see when driving is is probably just
capacitive pickup in the cables. Have to vent to fix this one.


ITMX Has good life in all but the LR & UR channels. They respond, but the signal is very weak.
Seems like these magnets have not fallen off but that they are not between the LED/PD anymore.


ITMY seems ok. Check the spectra to be sure.


BS seems ok as well. Swings freely and no kinks in the swinging sensor waveforms. Check the spectra.
Attachment 1: infection-2.png
infection-2.png
  970   Fri Sep 19 01:55:41 2008 ranaSummarySUSSUS Drift Screen Updated
I wrote 2 matlab scripts to update the SUS DRIFT screen:
- setsval.m   uses mDV to get the minute trend from some specified start time
              and duration in the past. It then writes that 'good' value to the
              .SVAL field of the SUSPOS, SUSPIT, and SUSYAW records for all the
              optics

- setHILO.m   reads the .SVAL field and then sets the alarm levels and severity
              for the same records given a "sigma" as an argument. i.e. 1 sigma = HIGH,
              2 sigma = HIHI.

Attached is the new screen. WE can now use this to judge when the optics have moved alot.

If someone will edit the BURT .req file to have these subfields
(.HIHI .HIGH .LOW .LOLO .HHSV .HSV .LSV .LLSV) then they will come back after a reboot as well.

Below I'm also attaching the matlab code for people at the observatories who don't have
access to the SVN here.
Attachment 1: infection-3.png
infection-3.png
Attachment 2: setsvals.m
function varargout = setsvals(varargin)
% SETSVALS
% sets the SVAL records for the SUS

debug = 0;


if nargin < 2
  error('Needs 2 arguments.')
elseif nargin > 2
... 56 more lines ...
Attachment 3: setHILO.m
function setHILO(varargin)
%  SETHILO 
%  Ex.  setHILO(1000);
%      this sets the SUS alarm levels to be 1000 counts
%      from the nominal

% 1 for debugging
debug_flag = 0;

if nargin == 1
... 62 more lines ...
  10924   Tue Jan 20 19:32:06 2015 JenneUpdateSUSSUS Drift restore scripts

I made little scripts to go with the sus driftmon buttons, that will servo the alignment sliders until the susyaw and suspit values match the references on the driftmon screen. 

  3144   Wed Jun 30 12:01:20 2010 josephbUpdateCDSSUS IO Chassis

I spent this morning populating the SUS IO Chassis and getting it ready for installation into the 1Y4 rack.  I discovered I'm lacking the internal cables to connect the ADC/DAC boards to the AdL adapter boards that also go in the chassis (D0902006 and D0902496).  I'm not sure where Alex got the cables he used for the end IO chassis he had put in.  I'll be going to Downs after the meeting today either to get cables or parts for cables, and get the SUS chassis wired up fully.

I'd also like to confirm with Alex that the OSS-MAX-EXP-ELB-C board that goes in the IO chassis matches the host interface board that goes in the computer (OSS-HIB2-PE1x4-1x4 Re-driver HIB, since we spent half a day the last time we installed an IO chassis determining that one of the pair was bad or didn't match.

 

The SUS chassis has been populated in the following way:

Treton Board

Slot 1 ADC PMC66-16AI6455A-64-50M

Slot 2 DAC PMC66-16AO16-16-F0-OF 

Slot 3-6 BO Contec DIO-1616L-PE Isolated Digital IO board

Slot 7 ADC PMC66-16AI6455A-64-50M

Slot 8-9 DAC PMC66-16AO16-16-F0-OF 

Back  Board

Slot 1 ADC adapter D0902006

Slot 2 DAC adapter D0902496-v1

Slot 7 ADC adapter D0902006

Slot 8-9 DAC adapter D0902496-v1

  13589   Wed Jan 31 15:27:55 2018 gautamUpdateSUSSUS MEDM master screens updated

I've often gotten confused by the labeling on the SUS MEDM screens about the coil "Vmon" fields - they're labelled as "30 Hz HPF", and indeed this is one of the many readbacks available on the coil driver board. But the actual EPICS channel that is being displayed in this field is from the "EPICS VMON" monitor point on the coil driver board. It has a gain of 1/2, so the actual voltage going to the coil is twice the channel value. Today, I fixed the SUS master screen to avoid this confusion - new labeling is shown in Attachment #1.

Attachment 1: NewSUSmaster.png
NewSUSmaster.png
  8919   Wed Jul 24 19:21:56 2013 JamieHowToSUSSUS MEDM screen modernization

I started poking around at what we want for new SUS MEDM screens.  Rana and I decided we'd start with the ASC TIPTILT screens:

newsusmedm.png

It's missing some things (like SIDE OSEMS) but it should provide a good starting point.

I copied the entire <userapps>/asc/common/medm/asctt directory to a new directory in our sus area:

controls@rossa:/opt/rtcds/userapps/release 0$ cp -a asc/common/medm/asctt sus/c1/medm/new

I then removed all the useless file name prefixes.  We still need to go through and sed out all the ASC stuff in the MEDM files themselves.

It makes heavy use of macro substitution, which is good (it's what we're using now).  So once we clean up all the channel names, we should just be able to swap out the pointers in our overview screens to the new screens (or rename things).  In the mean time, during development, you can run:

controls@rossa:/opt/rtcds/userapps/release 0$ medm -x -macro "IFO=C1,ifo=c1,OPTIC=ITMX" sus/c1/medm/new/OVERVIEW.adl 

  14261   Thu Oct 18 00:27:37 2018 KojiUpdateSUSSUS PD Whitening board inspection

[Gautam, Koji]

As a part of the preparation for the replacement of c1susaux with Acromag, I made inspection of the coil-osem transfer function measurements for the vertex SUSs.

The TFs showed typical f^-2 with the whitening on except for ITMY UL (Attachment 1). Gautam told me that this is a known issue for ~5 years.
We made a thorough inspection/replacement of the components and identified the mechanism of the problem.
It turned out that the inputs to MAX333s are as listed below.

  Whitening ON Whitening OFF
UL ~12V ~8.6V
LL 0V 15V
UR 0V 15V
LR 0V 15V
SD 0V 15V

The switching voltage for UL is obviously incorrect. We thought this comes from the broken BIO board and thus swapped the corresponding board. But the issue remained. There are 4 BIO boards in total on c1sus, so maybe we have replaced a wrong board?

Initially, we thought that the BIO can't drive the pull-up resistor of 5KOhm from 15V to 0V (=3mA of current). So I have replaced the pull-up resistor to be 30KOhm. But this did not help. These 30Ks are left on the board.
 

Attachment 1: 43.png
43.png
  16447   Wed Nov 3 16:55:23 2021 Ian MacMillanSummarySUSSUS Plant Plan for New Optics

[Ian, Tega, Raj]

This is the rough plan for the testing of the new suspension models with the created plant model. We will test the suspensions on the plant model before we implement them into the full

  • Get State-space matrices from the surf model for the SOS. Set up simplant model on teststand
    • The state-space model is only 3 degrees of freedom. (even the surf's model)
    • There are filter modules that have the 6 degrees of freedom for the suspensions. We will use these instead. I have implemented them in the same suspension model that would hold the state space model. If we ever get the state space matrices then we can easily substitute them.
  • Load new controller model onto test stand. This new controller will be a copy of an existing suspension controller.
  • Hook up controller to simplant.  These should form a closed loop where the outputs from the controller go into the plant inputs and the plant outputs go to the controller inputs.
  • Do tests on set up.
    • Look at the step response for each degree of freedom. Then compare them to the results from an existing optic. 
      • Also, working with Raj let him do the same model in python then compare the two.
  • Make sure that the data is being written to the local frame handler.

MEDM file location

/opt/rtcds/userapps/release/sus/common/medm/hsss_tega_gautam

run using 

For ITMX display, use:

hsss_tega_gautam>medm -x -macro "site=caltech,ifo=c1,IFO=C1,OPTIC=ITMX,SUSTYPE=IM,DCU_ID=21,FEC=45" SUS_CUST_HSSS_OVERVIEW.adl

  16460   Tue Nov 9 13:40:02 2021 Ian MacMillanSummaryComputer Scripts / ProgramsSUS Plant Plan for New Optics

[Ian, Tega]

After talking with Rana we have an updated plan. We will be working on this plan step by step in this order.

  1. Remove c1sim from the test stand rack and move it to the rack in the office next to the printer. When connecting it we will NOT connect it to the Martian network! This is to make sure that nothing is connected to the 40m system and we can't mess anything up.
  2. Once we have moved the computer over physically, we will need to update anyone who uses it on how to connect to it. The way we connect to it will have changed.
  3. Now that we have the computer moved and everyone can connect to it we will work on the model. Currently, we have the empty models connected.
    1. recompile the model since we moved the computer.
    2. verify that nothing has changed in the move and the model can still operate and compile properly
  4. The model has the proper structure but we need to fill it with the proper filters and such
    1. For the Plant model
      1. To get it up and running quickly we will use the premade plant filters for the plant model. These filters were made for the c1sup.mdl and should work in our modified plant model. This will allow us to verify that everything is working. And allow us to run tests on the system.
      2. We need to update the model and add the state space block. (we are skipping this step for now because we are fast-tracking the testing)  
        1. Check with Chris to make sure that this is the right way to do it. I am pretty sure it is, but I don't know anything
        2. Make the 6 DOF state-space matrix. We only have a three DOF one. The surf never made a 6 DOF. 
        3. Make the block to input into the model
        4. make a switch that will allow us to switch between the state-space model and the filter block
    2. For the controller
      1. Load filter coefficients for the controller model from one of the current optics and use this as a starting point.
      2. Add medm screens for the controller and plant. We are skipping this for now because we want results and we don't care if the screens look nice and are useable at the moment.
  5.  Test the model
    1. we will take an open-loop transfer function of all six of the DOFs to all other DOFs which will leave us with 36 TFs. Many will be zero
      1. If you are looking at this post then we are measuring transfer functions from the blue flags to the green flags across the plant model.
      2. We will want to look at the TFs across the controller

 

ELOG V3.1.3-