[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

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

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. 

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.

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.

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.

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.

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.

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.

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

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

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

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.

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

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

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.

Varun has received 40m specific basic safety training today.

Aakash Patil received 40m specific basic safety training.

Praful Vasiceddy received 40m specific basic safety training.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

 [Alex, Den] 

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

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.

ETMX YAW stopped drifting Jan 8, 2015

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

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.

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

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. 

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

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.

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:

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 

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

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.
 

[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

[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

[Ian, Tega]

We have moved c1sim computer from the test stand to the server rack in the office area. (see picture)

It is connected to the general campus network. Through the network switch at the top of the rack. This switch seeds the entire Martian network.

Test to show that I am not lying:

1. you can ping it or ssh into it at
   controls@131.215.114.116
   Using the same password as before. Notice this is not going through the nodus network.
2. It also has a different beginning of the IP addresses. Martian network IP addresses start with 191.168.113

c1sim is now as connected to the 40m network as my mom's 10-year-old laptop.

unfortunately, I have not been able to get the x2go client to connect to it. I will have to investigate further. It is nice to have access to the GUI of c1sim occasionally.

[Ian, Tega]

Now that the computer is in its new rack I have copied over the filter two files that I will use in the plant and the controller from pianosa:/opt/rtcds/caltech/c1/chans to the docker system in c1sim:/home/controls/docker-cymac/chans. That is to say, C1SUP.txt -> X1SUP.txt and C1SUS.txt -> X1SUS_CP.txt, where we have updated the names of the plant and controller inside the txt files to match our testing system, e.g. ITMX -> OPT_PLANT in plant model and ITMX -> OPT_CTRL in the controller and the remaining optics (BS, ITMY, PRM, SRM) are stripped out of C1SUS.txt in order to make X1SUS_CP.txt. 

Once the filter files were copied over need to add them to the filters that are in my models to do this I run the commands:

see this post for more detail

Unfortunately, the graphics forwarding from the docker is not working and is giving the errors:

This means that the easiest way to add the filters to the model is through the GUI that can be opened through X2go client. It is probably easiest to get that working. graphics forwarding from inside the docker is most likely very hard. 

unfortunately again x2go client won't connect even with updated IP and routing. It gives me the error: unable to execute: startkde. Going into the files on c1sim:/usr/bin and trying to start startkde by myself also did not work, telling me that there was no such thing even though it was right in front of me.

[Ian, Tega]

We are working on three fronts for the suspension plant model:

1. Filters
   1. We now have the state-space matrices as given at the end of this post. From these matrices, we can derive transfer functions that can be used as filter inputs. For a procedure see HERE. We accomplish this using Matlab's built-in ss(A,B,C,D); function. then we make it discrete using c2d(sys, 1/f); this gives us our discrete system running at the right frequency. We can get the transfer functions of either of these systems using tf(sys);
   2. from there we can copy the transfer functions into our photon filters.  Tega is working on this right now.
2. State-Space
   1. We have our matrices as listed at the end of this post. With those compiled into a discrete system in MatLab we can use the code Chris made called rtss.m to convert this system into a .c file and a .h file.
   2. from there we have moved those files under the userapps folder in the docker system. then we added a c-code block to our .mdl model for the plant and pointed it at the custom c file we made. See section 7.2 of T080135-v10
   3. We have done all this and this should implement a custom state-space function into our .mdl file. the downside of this is that to change our SS model we have to edit the matrices we can't edit this from an medm screen. We have to recompile every time.
3. Python Check
   1. This python check is run by Raj and will take in the state-space matrices which are given then will take transfer functions along all inputs and outputs and will compare them to what we have from the CDS model.

Here are the State-space matrices:

A few notes: If you want the values for these parameters see the .yml file or the State-space model file. I also haven't been able to find what exactly this s is in the matrices.

UPDATE [11/16/21 4:26pm]: I updated the matrices to make them more general and eliminate the "s" that I couldn't identify. 

The input vector will take the form:

where x is the position, theta is the pitch, phi is the yaw, and y is the y-direction displacement

[Ian, Tega]

Updated A, B, C, D matrices for the state-space model to remove bugs in the previous estimate of the system dynamics. Updated the last post to represent the current matrixes.

We used MatLab to get the correct time-series filter coefficients in ZPK format and added them to the filters running in the TM_RESP filter matrix.

Get the pos-pos transfer function from the CDS model. Strangely, this seems to take a lot longer than anticipated to generate the transfer function, even though we are mainly probing the low-frequency behavior of the system.  

For example, a test that should be taking approximately 6 minutes is taking well over an hour to complete. This swept sine (results below) was on the low settings to get a fast answer and it looks bad. This is a VERY basic system it shouldn't be taking this long to complete a Swept sine TF.

Noticed that we need to run eval $(./env_cymac) every time we open a new terminal otherwise CDS doesn't work as expected. Since this has been the source of quite a few errors already, we have decided to put it in the startup .bashrc script.  

[Ian, Raj, Tega]

Here is the comparison between the results of Raj's python model and the transfer function measurement done on the plant model by Tega and me.

As You can see in the graphs there are a few small spots of disagreement but it doesn't look too serious. Next we will measure the signals flowing through the entire plant and controller.

For a nicer (and printable) version of these plots look in the zipped folder under Plots/Plant_TF_Individuals.pdf