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

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

, where is the open loop transfer function of the loop.

So measurement of can be done in following two ways (not a complete set):

1. , if excitation amplitude is large enough such that over all frequencies.
   • In this method however, note that SR785 would be taking ratio of unsuppresed excitation at with suppressed excitation at
   • If the closed loop gain (suppression) is too much, the excitation signal might drop below noise floor of SR785 while measuring .
   • This would then appear as a flat response in the transfer function.
   • This happened with us when we tried to measure this transfer function using this method. Below few hundered Hz, the measurement will become flat at around 40 dB.
   • Increasing the excitation amplitude where suppression is large should ideally work. We even tried to use Auto level reference option in SR785.
   • But the PDH loop gets unlocked as soon as we put exciation above 35 mV at this point in this loop.
2. , if excitation amplitude is large enough such that over all frequencies.
   • In this method, channel 1 (denominator) on SR785 would remain high in amplitude throughout the measurement avoiding the above issue of suppression below noise floor.
   • We can easily measure the feedback transfer funciton with the loop open. Then multiplying the two measurements should give us estimate of open loop transfer function.
   • This is waht we did in 16194. But we still could not increase the excitation amplitude beyond 35 mV at injection point and got a noisy measurement.
   • We checked yesterday coherence of excitation signal with the three measurment points and it was 1 throughout the frequency region of measurement for excitation amplitudes above 20 mV.
   • So as of now, we are not sure why our signal to noise was so poor in lower frequency measurement.

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

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

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

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

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

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

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

Doing loop algebra as before, we get:

So measurement of can be done by

• For frequencies, where is large enough, to have an SNR of 100, we need that ratio of to integrated noise is 100.
• Assuming you are averaging for 'm' number of cycles in your swept sine measurement, time of integration for the noise signal would be where f is the frequency point of the seeping sine wave.
  • This means, the amplitude of integrated laser frequency noise at either or would be
  • Therefore, signal to laser free running noise ratio at f would be .
  • This means to keep a constant SNR of S, we need to shape the excitation amplitude as
  • Putting in numbers for X end Green PDH loop, laser free-running frequency noise ASD is 1e4/f Hz/rtHz, laser PZT actuation is 1MHz/V, then for 10 integration cycles and SNR of 100, we get:
• Assuming you are averaging for a constant time  in swept sine measurement, then the amplitude of integrated laser free noise would be
  • In this case, signal to laser free-running noise ratio at f would be
  • This means to keep a constant SNR of S, we need to shape the excitation amplitude as
  • Again putting in numbers as above and integration time of 1s, we need an excitation amplitude shape

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

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

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

Measurement details:

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

Inferences:

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

Here I describe efforts to cancel the AUX laser PZT mechanical resonances from ~200 kHz-400kHz. While these may not be the resonances we end up wanting to suppress, I chose this region as an exercise because it contains the most significant peaks.

The PZT transfer measurement was taken on 09/06 by myself and Anchal. The Moku:Go outputted a swept-sine (1kHz - 1MHz) I sent to the AUX laser PZT. The beat note between the AUX and frequency-doubled PSL was sent to the DFD, and the I and Q channels were routed back as input to the Moku:Go. We also took a calibration transfer function of the Moku:Go, sending output 1 to inputs 1 and 2. 

Almost all of the signal was present in the I channel, so I proceeded to use the I data for fitting/next steps. After normalizing the measured frequency response by the calibration measurement (and adjusting for the calculated time delays in the loop - see [17131]), I fit the resulting data using vectfit [Attachment 1]. I supplied the function with n_poles=16, which in reality fit for 16 complex pairs of poles. This complexity of fit was not necessary to capture the 3 prominent peaks, but would likely be needed to fit any of the more heavily-damped resonances. 

I chose to invert all fitted poles between 200 kHz and 367 kHz and the corresponding fitted zeros. The result of this filter applied to the original frequency response data can be seen in Attachment 2, where the blue-shaded region contains the inverted poles/zeros. In total, 9 pairs of poles and 9 pairs of zeros were inverted. 

Next steps:

This looks really good to me. Rather than fully invert the plant, what we would like to do is now design a filter which allow this loop to have a high UGF and a high gain below 1 kHz. Anchal and Paco probably have gain requirements for this loop in the ALS-CAL paper they are writing. The loop would have the cavity transfer function, as well as the demod electronics for the green PDH loop.

In addition to the gain requirements, we would also like to have a phase margin > 30 deg, and a gain margin of > 10 dB.

Moku:Go used for full locking of green laser - OLTF to come

Picking up from where Reuben left off, I used the Moku:Go in multi-instrument mode to replace the signal generator and uPDH box entirely (Moku:Go setup shown in Attachments 1+2). The lock-in amplifier sourced the modulation for the PZT: 210.5 kHz, 1.4 Vpp amplitude (consistent with 7dBm used by the uPDH box) This LO was used to demodulate the REFL signal input. I coarsely tuned the demodulation phase to 90 degrees until the PDH error signal looked reasonable. The PDH error signal was passed to the digital filter box using the same filter as before. After slightly adjusting the gain knob in the filter module (-8 dB), the lock seemed reasonably stable - transmission screenshot in Attachment 3. I got transmission to ~0.8 with the analog loop today, so it was exciting to see this level maintained with the Moku:Go lock (ignoring oscillations from test mass motion). The system remains locked to TEM00 for 5-10 minutes before mode hopping, which is qualitatively comparable to the analog loop as well.

An OLTF of the Moku:Go loop still needs to be taken. Since the loop error point isn't outputted from the Moku (passed direclty between instruments), I'll need to inject an excitation at the control point. When I fed the control signal to input A of the SR560 and tried to lock with the direct output, the lock would repeatedly break. I noticed that the BATT light of the SR560 was on - I'll repeat this with another SR560, but the lock might be breaking due to an offset. Once this is debugged, I can inject an excitation and measure the loop OLTF.

[Radhika, Yuta, Hiroki, Paco]

During YAUX noise measurements, we also locked IR and green lasers in xarm (using Moku:Go lock-in amplifier + digital controller) to look at ALS noise in XARM. I adjusted the controller gain until green transmission looked tightly controlled (less fuzzy). We measured the out-of-loop ALS X beat note fluctuations at 2 gain levels: -12 dB and -14 dB down from the uPDH box fitted response. These are Attachments 1 and 2 respectively.

Note that there was some mirror motion at 1 Hz that is reflected in the spectral densities (coil balancing of ETMX had just been taking place). The -12dB gain adjustment causes frequency noise ~3x higher than the reference above ~70Hz. The -14dB gain adjustment has higher noise from 70-400 Hz, but has slightly suppressed noise above 1 kHz (relative to -12dB gain).

Moku:Go delay measurements will help clarify if this excess noise is a fundamental limitation of the device, or if there is room for improvement by optimizing the controller or further tweaking the gain/offset.

[Jenne & Sanjit]

Good news: We could successfully send filtered output to MC1 @ SUS.

We used 7 channels (different combinations of 3 seismometer and six accelerometer)

We tried some values of \mu (0.001-0.005) & gain on SUS_MC1_POSITION:MCL and C1ASS_TOP_SUS_MC1 (0.1-1).

C1:ASS-TOP_SUS_MC1_INMON is huge (soon goes up to few times 10000), so ~0.1 gains at two places bring it down to a reasonable value.

Bad news: no difference between reference and filtered IOO-MC_L power spectra so far.

Plan of action: figure out the right values of the parameters (\mu, \tau, different gains, and may be some delays), to make some improvement to the spectra.

 ** Rana: there's no reason to adjust any of the MCL gains. We are not supposed to be a part of the adaptive algorithm.

After a lot of headache, I got the OAF working again - read on for details.....................

Sometime last week, Jenne, Kiwamu, and I tried to update the OAF model to include the IIR "feed-around" path.

This path is in parallel to the existing FIR-based adaptive FXLMS stuff that Matt put in earlier. The reason for the

new path is that we want to try emulating the same FF technology which has been successful lately at LLO.

However, we were unable to make the ASS work after this work. Mostly, the build stuff worked fine, but we couldn't get DTT

to make a transfer function. The excitation channels could be selected and the excitation would actually start and get all the

way into MC1, but DTT would just hang on the first swep-sine measurement with no time-out error. Clearly our ASS building

documentation is no good. We tried using the instructions that Koji gave us for AAA, but that didn't completely work.

In particular, the 'make-uninstall-daq-ass' command gave this command:

[controls@c1ass advLigo]$ make uninstall-daq-ass
grep: target/assepics/assepics*.cmd: No such file or directory
Please make ass first
make: *** [uninstall-daq-ass] Error 1

re-arranging the order to do 'make-ass' first fixes this issue and so I have fixed this in the OAF Wiki.

The there's the whole issue with the tpchn_C3.par file. This contains all the test point definitions for the ASS/OAF machine. The main

IFO numbers are all in tpchn_C1.par and the OMC is all in tpchn_C2.par. When we do the usual build, in the 'make install-daq-ass' part:

[controls@c1ass advLigo]$ make install-daq-ass
Installing GDS node 3 configuration file
/cvs/cds/caltech/target/gds/param/tpchn_C3.par
Updating DAQ configuration file
/cvs/cds/caltech/chans/daq/C1ASS.ini
we get this .par file installed in the target area. The ACTUAL param file seems to actually be in /cvs/cds/caltech/gds/param  !!

Of course, it still doesn't work. That's because the standard build likes to point to /cvs/cds/caltech/gds/bin/awgtpman and the one that runs on

linux is actually /opt/gds/awgtpman. So I've now made a file called startup_ass.cmd.good which runs the correct one. However, the default build

will try to start the wrong one and we have to fix the 'startass' script to point to the correct one on each build. Running the correct awgtpman

allows us to get the TP data using tools like tdsdata, so far no luck with DTT.\

UPDATE (23:33): It turns out that it was my old nemesis, NTPD. c1ass had a /etc/ntp.conf file that was pointing at an ntp server called rana113. I

am not an NTP server; I don't even know what time it is. I have fixed the ntp.conf file by making it the same ass c1omc (it now points to nodus). After

this I set the date and time manually (sudo date -s "20 DEC 2009 23:27:45") and then restarted NTPD. It should now be fine even when

we reboot c1ass.

After all of this nonsense, I am able to get TP data from c1ass and take transfer functions between it and the rest of the world !

This allowed measuring the MC1 -> MCL TF finally. Its mostly flat. Data saved as Templates/OAF/OAF-MCLTF.xml

 What does OAF stand for? The entry doesn't say that. Also the acronym is not in the abbreviation page of the wiki.

Can anyone please explain that?

I fit the MC1 -> MCL TF using vectfit4.m (from mDV). The wrapper file is mDV/extra/C1/ fitMC12MCL.m.

Plotted here are the data (RED), the fit (BLUE), and the residual x10 (GREEN).

For the magnitude plot, residual is defined as ------   res = 1 - fit / data

For the phase plot the residual is defined as -------    res =  phase(data)-phase(fit)

You can see that the agreement is very good. The phase match is better than 5 deg everywhere below 10 Hz.

This TF is so smooth that we could have probably done without using this, but its good to excercise the method anyway.

Kiwamu made the OAF screen functional today - screenshot attached.

After this, I used the measured TF of the MC1 to MCL to filter the signals from the Wilcoxon accelerometers and feed them into the MC.

The noise at 3 Hz went down by a factor of ~3. There's a little excess created at 100 Hz. Its good to see that our intuition about feed-forward is OK.

I did all of the filter calculations by adapting the scripts that Haixing, Valera, and I got going at LLO. They're all in the mDV/extra/C1 SVN.

The Wiener code predicts much better performance from using more than just 2 horizontal accelerometers, but I was too lazy to do more channels today.

I also added the Rai box to the Ranger readout today - the noise at 0.1 Hz went down by a factor of 10 and the noise at 1 Hz is close to 10^-11 m/rHz.

The Rai box ran out of batteries a couple of days ago and so the data is no good. I've put the Ranger back on the SR560 for now (but with the damping resistor removed, so the gain is 2x more than before).

This is what was done in past two days:

- The ETMY and ITMY pitch and yaw dofs are modulated at 40, 44, 42, 46 Hz respectively (oscillator A=30). The c1ass lockin numbers are 12, 14, 27, 29.

- The NAS55I signal is demodulated at the above frequencies. The demodulated I/Q signal phase is set to shift all signal into I-phase. The lockin inputs are bandpassed around respective frequency f with butter("Bandpass",2,f-0.5,f+0.5). The demod signals are then additionally low passed with butter ("Lowpass",4,0.5) so the servo ugf has to be below 0.5 Hz. The servo filter is p:z 0.0001:0.1.

- The ETMY demodulated signal is fed back to ITMY and visa versa.

- With the above 2x2 servo running we moved the input beam PZTs by hand to follow the cavity.

- At the end we offloaded the servo control signals to the SUS biases again by hand.

- The beam spot centering was estimated by unbalancing the ETMY/ITMY pitch/yaw coil combinations intentionally by 5%, which produces 1.3 mm shift of the node, and comparing the response to the residual signals.

- The dof set up currently is: ETMY pitch lockin 12 -> dof2, ITMY pitch lockin 14 -> dof4, ETMY yaw lockin 27 -> dof7, ITMY yaw lockin 29 -> dof9

- The next step is to demodulate the TRY(X) and servo the input beam PZTs

Here the status of the dither alignment or c1ass:

- Both pitch and yaw centering on ETMY/ITMY were closed simultatenously with ugf of ~1/30 Hz.

- I made a medm screen with beam positions as measured by the dither system.The snapshot is attached. There are visual perimeter alarms (red box around the display) to warn about arm power being low or the dither lines not being on. The screen has a pull down menu with 4 scripts:

. assUp - sets up the gains, phases and matricies for the dither system (both the spot centering and the input beam alignment)

. assOn - turns on the dithers and servo - just the Y-arm centering part at the moment

. assOff - turns off the servo and dither lines

. assDitherOn - turns on the dither lines but does not turn on the servo

- All scripts are in scripts/ASS and the medm screen is in medm/c1ass/master/

Still to do:

- Commission the input beam and X-arm servos

- Make scripts for X-arm

The medm screen for c1ass started being modified to be more user-friendly.

The modification is still ongoing, but the goal is to make a screen which anyone can easily understand and play with.

Still to do : ( need a volunteer )

- Modification of the screens

- Commission the input beam and X-arm servos

- Make scripts for X-arm

- Measure the PZT mirrors' matrix for the translation and angle

 The current status of the dither alignment system:

- Both Xarm and Yarm alignment are working. The scripts are: scripts/autoDither/alignX(Y). Each script sets up the respective arm, turns on the dither lines and servos for 66 sec, offloads the control signals to TM alignment biases and PZT sliders in case of  Yarm, and to TM and BS alignment biases in case of Xarm, and finally turns off and clears the servo filters and turns off the dither lines.

- Jammie witnessed the final tests of both scripts - both X and Y arm power went up from 0.6-0.7 to close to 1 and the AS beam became symmetric. Also Jammie wanted me to leave the ETMY oplev in its current non-nominal but more stable state i.e. the oplev signals go to the ADC from the D010033 card not the D020432 one. The scripts can now run from the CONFIGURE medm screen.

- Both arms use signals derived from modulating ITM and ETM in pitch and yaw dofs and demodulating the arm power (TRX or TRY) and the cavity length signal (AS55I). The Yarm actuation has 8 dofs - pitch and yaw of the ITM, ETM, and two input beam PZTs so all the sensed dofs are controlled. The Xarm actuation has only 6 dofs - pitch and yaw of the ITM, ETM, and BS. The Xarm servo is set up to servo the beam position on the ETMX and the relative alignment of the cavity and the input beam. The ITMX spot position is unconstrained and provides the null test. The residual displacement on the ITMX is 0.2-0.3 mm in yaw and 0.9-1.0 mm in pitch. The I phases of the beam centering lockins, which are also the error points of corresponding DOF filters, are calibrated in mm by unbalancing the TM coils by known amount. The attached snap shot of the medm screen now has both X and Y arm calibrated beam spot positions and uncalibrated input beam indicators. The input beam angle and position signals can/should be calibrated by tapping the signals digitally and applying the proper matrix transformation - this will require the model change.

- Currently there is no lock loss catching in the model. We should add a trigger on arm power (or an equivalent mechanism) to turn off the inputs to prevent the spurious inputs.

I was looking a little at ASS, while Yuta was doing some Green transmitted DC PD work, and I find that the output of some filters is totally insane with no deliberate input or excitation signals.

Note in the figure that the filter (which is a 2nd order butter bandpass in the C1:ASS-LOCKIN29_SIG filter bank) is ringing a lot - this needs fixing.  But, more disconcertingly, sometimes (not every time) the arm flashes, the input to the filter bank gets a ~1 sample long spike that is ~9,000,000 counts.  9 million is a lot of counts.  This is then making the filter go crazy.

Any ideas on how this can happen, and how we can stop / fix it?  It's certainly a CDS issue, but I'm not sure where or how.

The names of the DoF filters in the ASS loop were wrong.  The filters themselves were correct (low pass filters at super low freq, for the Lock-in), but the names were backward.

Our convention is to name filters "poles:zeros", but they had been "z:p".  The names of FM1 in all the DoF filter banks are now fixed.

I wanted to check that the calibration of the MC ASS lockins was sensible, before trusting them forevermore.

To measure the calibration, I took a 30sec average of C1:IOO-MC_ASS_LOCKIN(1-6)_I_OUT with no misalignment. 

Then step MC1 pitch by 10% (add 0.1 to the coil output gains).  Remeasure the lockin outputs.

2.63 / (Lockin1noStep - Lockin1withStep) = calibration.

Repeat, with Lockin2 = MC2 pit, lockin3 = MC3 pit, and lockins 4-6 are MC1-3 yaw.

The number 2.63 comes from: half the side of the square between all 4 magnets.  Since our offsets are in pitch and yaw, we want the distance between the line connecting the lower magnets and the center line of the optic, and similar for yaw.  Presumably if all of the magnets are in the correct place, this number is the same for all magnets.  The optics are 3 inches in diameter.  I assume that the center of each magnet is 0.9mm from the edge of the optic, since the magnets and dumbbells are 1.9mm in diameter. Actually, I should probably assume that they're farther than that from the edge of the optic, since the edge of the dumbbell ~touches the edge of the flat surface, but there's the bevel which is ~1mm wide, looking normal to the surface of the optic.  Anyhow, what I haven't done yet (planned for tomorrow...) is to figure out how well we need to know all of these numbers.

We shouldn't care more than ~100um, since the spots on the optics move by about that much anyway.

For now, I get the following #'s for the calibration:

Lockin1 = 7.83

Lockin2 = 9.29

Lockin3 = 8.06

Lockin4 = 8.21

Lockin5 = 10.15

Lockin6 = 6.39

The old values were:

C1:IOO-MC_ASS_LOCKIN1_SIG_GAIN = 7
C1:IOO-MC_ASS_LOCKIN2_SIG_GAIN = 9.6
C1:IOO-MC_ASS_LOCKIN3_SIG_GAIN = 8.3
C1:IOO-MC_ASS_LOCKIN4_SIG_GAIN = 7.8
C1:IOO-MC_ASS_LOCKIN5_SIG_GAIN = 9.5
C1:IOO-MC_ASS_LOCKIN6_SIG_GAIN = 8.5

The new values measured tonight are pretty far from the old values, so perhaps it is in fact useful to re-calibrate the lockins every time we try to measure the spot positions?

As part of trying to figure out what is going on with the ASS, I wanted to figure out what filters are installed on which lockins.

Each "DoF"(1-6) has a zpk(0.1,0.0001,1)gain(1000), which is a lowpass with 60dB of gain at DC, and unity gain at high frequencies.

For the lockins, since there are so many, I made a spreadsheet to keep track of them (attached). 

So, what's the point?  The point is, I think that all of the LOCKIN_I filter modules should be the same, with a single low pass filter.  The Q filter banks don't matter, since we don't use those signals, and the signals are grounded inside the model.  The phase of each lockin was / should be tuned such that all of the interesting signal goes to I, and nothing goes to Q.  The SIG filter modules seem okay, in that they're all the same, except for their band pass frequency.  I just need to check to see what frequency the ASS scripts are trying to actuate at, to make sure we're bandpassing the correct things.

[Jamie, Jenne]

We are trying to figure out what the story is with the ASS, and in order to make it more human parse-able, we cleaned up the c1ass.mdl. 

So far, we have made no changes to how the signals are routed.  The local oscillators from each lockin still get summed, and go directly to the individual optics, and the demodulated signals from each lockin go through the sensing matrix, the DoF filters, then the control output matrix, and then on to the individual optics.  So far, so good.

Much of the cleanup work involved making a big library part, which is then called once for PIT and once for YAW in the ass top level, rather than have 2 code-copies, which give Jamie conniptions.  Inside the library part GoTo and From tags were used, rather than having all the lines cross over one another in a big spaghetti mess.

One of the big actual changes to the ass was some name changes. Rather than having mysterious "ASS-LOCKIN(1-30)", they are now named something like "ASS-PIT_LOCKIN_ETMY_TRY", indicating that this is in the pitch set, actuating on ETMY, and looking at TRY for the demodulated signal.  The "DOF" channels are similar to what they were, although we would like to change them in the future.....more on this potential change later.  Previously they were "ASS-DOF(1-10)", but now they are "ASS-PIT_DOF(1-5)" and "ASS-YAW_DOF(1-5)". This channel naming, while it makes things make more sense, and is easier to understand, means that all of the ASS scripts need to be fixed.  However, they all needed updating / upgrading anyway, so this isn't the end of the world.

This channel name fixing also included updating names of IPC (shmem/dolphin/rfm things) blocks, which required matching changes in the SUS, RFM and LSC models.  All 4 models (ASS, SUS, RFM, LSC) were recompiled and installed.  They all seem fine, except there appears to be a dolphin naming mismatch between OAF and SUS that showed up when the SUS was recompiled, which presumably it hadn't been in a while.  We need to figure this out, but maybe not tonight.  Den, if you have time, it would be cool if you could take a look at the OAF and SUS models to make sure the names match when sending signals back and forth.

______________________

We also had a long chat about the deeper meaning of the ASS. 

What should we be actuating on, and what should we be sensing?  A potential thought is to rename our DOF channels to actual DoF names: input axis translation, input axis angle, cavity axis translation, cavity axis angle.  Then actuate the dither lines on a cavity degree of freedom, sense the influence on TRX, TRY and an LSC PD (as is currently done), then actuate on the cavity degree of freedom.

Right now, it looks like the actuation is for individual optics, the sensing is the influence on TRX, TRY and an LSC PD, then actuate on a cavity degree of freedom.  So the only change with the new idea is that we actuate in the DoF basis, not the optics basis.  So the Lockin local oscillators would go through the control output matrix.  This makes more sense in my head, but Jamie and I wanted to involve more people in the conversation before we commit. 

The next question would be: how do we populate the control output matricies?  Valera (or someone) put something in there, but I couldn't find anything on the elog about how those values were measured/calculated/came-to-be.  Any ideas?  If we want to dither and then push on isolated degrees of freedom, we need to know how much moving of which optics affects each DoF.  Is this something we should do using only geometry, and our knowledge of optic placements and relative distances, or is this measurable?

Jamie re-redid the ASS model a few hours ago.

I have just compiled it, and restarted c1ass.  (The model from last night is currently called c1ass3.mdl)  I had to delete and re-put inthe goto and from tags for the LSC signal coming in from the shmem.  For some reason, it kept claiming that the inputs using the from tags were not connected, even when I redid the connections.  Finally deleting and dragging in new goto and from tags made the model happy enough to compile.  Whatever.  I'm going to let Jamie do the svn-ing, since he's the one who made the changes.  Before I had figured out that it was the tags, I was concerned that the shmem was unhappy, so there was no signal connecting to the input of the goto tag, and that was somehow bad....anyhow, I recompiled the LSC model to re-create the shmem sender, but that had no effect, since that wasn't the problem.

The change from last night is that now the library parts are by DoF.  There is only one matrix in each library part, before the servo filters. Now we can DC-actuate on a single mode (ETM or ITM, pitch or yaw), and see how it affects all 4 sensors (the demodulated signals from the lockins). We need to measure the sensing matrix to go from the several sensors to the servo input.

I wanted to try out the ASS tonight, but I wanted some kinds of screens thrown together so I would know what I was doing.  Turns out screens take longer than I thought.  Am I surprised? Not really. 

They're probably at the ~85% mark now, but I should be able to try out the ASS tomorrow I think.

I was trying to load some filters into the ASS so that I can try it out, but for some reason the filter banks aren't working - clicking the on/off buttons doesn't do anything, filters (which exist in the .txt file generated by foton) don't load.

I've emailed cds-announce to see if anyone has any ideas.

When the network / fb went bad this afternoon, I had been working on the ASS model, shortening the names of the filter banks to fix the problem from elog 7092.  I wanted to finish working on that, so the ASS model is now rebuilt with slightly shorter names in the filterbanks (which fixes the problem of the filter banks not working).

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

I mentioned this to Jamie the other day, but here's the error that you get when the GoTo/From tags aren't working:

>>rtcds make c1ass
### building c1ass...
Cleaning c1ass...
Done
Parsing the model c1ass...
IPC 9 8 is C1:LSC-ASS_LSC
IPC 9 8 is ISHME
IPC 10 9 is C1:RFM-LSC_TRX
IPC 10 9 is IPCIE
IPC 11 10 is C1:RFM-LSC_TRY
IPC 11 10 is IPCIE

INPUT XARM_LSC_in is NOT connected

INPUT YARM_LSC_in is NOT connected

***ERROR: Found total of ** 2 ** INPUT parts not connected

make[1]: *** [c1ass] Error 255
make: *** [c1ass] Error 1

I don't know why these tags weren't working, but there was a GoTo tag on the output of the LSC shmem block, and then Froms on each of the XARM_LSC_in and YARM_LSC_in.  The other day I played around with a bunch of different things (grounding inputs, terminating outputs, whatever), but finally replacing the tags with identical ones freshly taken from CDS_PARTS made it happy. 

I wrote new setup, on and off scripts for the arm ass.  They take the arm as an argument, so it's the same script for both arms.  Scripts are in ...../scripts/ASS/ , and have been checked in to the 40m svn.

So far the on script doesn't really do anything, since I haven't chosen values for the CLKGAINs of the lockins.  The old values were 30 for lockins 12, 14, 27, 29 and 250 for lockins 7, 9, 22, 24.  Unfortunately, I have no memory of which lockin means what in the old numbered system.  I'll have to look that up somehow.  Or, just dither the optics using some value and look at the spectrum to see the resulting SNR and just pick something that gives me reasonable SNR.

I modified the ASS model slightly:

* Added an overall gain to the ASS_DOF2 library part, between the matrix and the servo inputs so we can do soft startups.  Self - remember that the main ASS screen needs to be modified to reflect this!

* Rearranged the order that the demodulated signals go into the matrix.  I hadn't paid attention, and the old ordering had the transmission (TRX/TRY) demod signals interleaved with the LSC demod signals.  I've changed it to be all the TR signals, then all the LSC signals.  I think this makes more sense, since we will use these inputs separately, so now they're on different halves of the matrix.

I turned on the ASS, without closing the loops, to try to measure the sensing matrix. 

The Yarm was locked (Eric did a nice job earlier - he'll ELOG ABOUT IT before he goes home!), and I used an LO CLKGAIN of 300 on all of the TRY Lockins.  Then I put on and took away a 10% offset in pitch, but it's almost impossible to see the difference. 

The attached is a truly awful screenshot, but you can kind of see what's going on.  The big steps are me increasing the LO gain, but around "0" on the x-axis I changed the pitch offset from 10% away to nominal.  Since there are such big oscillations, the change is basically non-existent.  Grrrr. I'll look at it again tomorrow, since I have an exiting bike ride home ahead of me....

From the log, I couldn't understand what has been done.

The procedure we should perform is

1. Dither total 4 dofs of the two mirrors with different frequencies. Some fluctuation of TRY is even visible in dataviewer.
2. The cavity is aligned at the beginning. These 4 peaks in TRY in DTT is small or invisible. Some 2nd harmonics are visible.
3. Misalign one of the dofs. Some peaks get bigger.
4. Correspoding lockin output becomes bigger.

Then you can start measuring the sensing matrix. At which part did the attempt fail?

 Cavity started out aligned pretty well, but not 100%.  Transmission was ~0.8 . Perhaps this was part of the problem.

I realize now that you mention it, it was totally amateur hour of me to only look at the lockin outputs on StripTool (plus POY and TRY on Dataviewer), and not look at TRY on DTT...or any spectra at all.  Not so intelligent.  I could see some fluctuation of TRY on Dataviewer that corresponded to me turning on the oscillators, as well as the spot wiggling on the camera view of ETMYT a teeny bit.

When applying a 10% misalignment to ETMY Pit (by adding 0.1 to the Pit components of the output matrix, as is done in the MC spot position calibration), I could see that there was a small jump in the StripTool trace, but it was much smaller than the ambient fluctuations of the output. 

I just looked back and realized that I must have forgotten to add my screenshot, but it's saved on a desktop on Rossa.  It would be better if I had attached the data, but from that you see that the average of the lockin output signal didn't change very much in the last several minutes of the measurement, but the fluctuations (no misalignment offsets) are pretty big, maybe ~10% or 15% the size of the signal.  Then when I added the misalignment to one mirror (ETMY PIT), there is a very small jump in the lockin signal, but it is much, much smaller than the size of the ambient fluctuations.  Perhaps a long average would result in a "real" value, but by looking by eye, I can't see a discernible difference in the average value of the lockin outputs.

My plan is to do as you say, dithering all 4 optics, and misaligning a single optic's single DoF (Pit or Yaw), and seeing how that misalignment affected each of the sensors (the lockin outputs).  Then put that DoF back to nominal, and misalign a different DoF, rinse and repeat.

Okay, so this is a little stream-of-consciousness-y, and you're going to think I'm really dumb, but I just realized that I haven't set the phase of the lockin demodulators yet.  So I think I need to dither the optics, and go through each of the sensors, and adjust the phase until the peak in TRY in DTT is maximized for the I phase, and minimized for the Q phase (since we use the I-output).  Bah.  Bad Jenne.

That's a good point, but I suspect that you end up with the in-phase (0deg) as the response of the IFO is immediate compared with the dithering frequency
as long as the whitening/dewhitening are properly compensated in the digital realm.

Koji pointed out that I was being silly, and rather than actually misaligning the optics (by, say, changing their IFO Align sliders) I was changing the location of the actuation node by changing the coil output gains.  Now I see nice signals at the I_OUT of each of the demodulators (so far I've only looked at the YARM).

I've measured and inverted the matrix by taking the nominal values of the demodulator outputs when the optics are all by-hand optimally aligned, then one-by-one misaligning an optic's angle (pitch or yaw), and looking at the demod outputs that result.  Repeat with each misalignment DoF for each of the 4 rows of the matrix.  Then I set the pit/yaw coupling elements of the matrix to zero.  Then invert the matrix, put it in, and see what happens.  So far, the yaw DoFs converged to zero, but the pitch ones didn't.  I'll play with it more and think some more tomorrow.

I am putting a little bit of brain power into reviving the ASS, and I want to write down what the motivation is, and what the short and long-term plans are.

Why?

The IFO IR is not optimally aligned right now.  While we were at atmosphere, we should have taken the time to align the green beams to the arms until the greens were both resonating TEM00.  We were lazy, and excited to pump down, so we decided that locking on higher order modes was good enough to ensure the beams came out of vacuum.  Once we were pumped down, ITMY and ETMY were aligned to the green beam axis.  Then, the IR was aligned to this new Yarm cavity axis.  This would have been okay, and pretty close, if we had aligned the green beam all the way (used only the outside steering mirrors to resonate TEM00, after the cavity mirrors were aligned for flashing IR).  After the IR was aligned to the Ygreen axis, the rest of the IFO was aligned to this slightly-incorrect input pointing.  We want to measure the IR spot positions on ITMY and ETMY so that we can tweak the input pointing until we hit the center of both ITMY and ETMY.  Then we will align Ygreen's input pointing to this proper IR cavity axis.  The rest of the IFO alignment will also have to be redone.  This calls for a functioning A2L system, so the measurement part of the ASS.

The immediate motivation for measuring the spot positions is that the current Xarm IR axis is not at all very close to the Xgreen axis.  The other day while we were fixing up the Xend table (note in elog 8162), we found that the TRX beam to the TRX PD and the trans camera was clipped on the 2" harmonic separator (which is the first optic that the transmitted IR beam sees on the end tables).  It was clipping on the left side of the optic, if you are looking at the face of the optic.  This is the more east-erly side of the optic.  We moved that optic to the side so that we were not clipping.  Then, today when Manasa was trying to align the Xgreen beam, she found that it was clipping on the right side of the harmonic separator, the more west-erly side.  I remember seeing that the green beam was roughly centered on the harmonic separator when we were at atmosphere, so this clipping is certainly due to Yuta, Evan and my moving of the harmonic separator.  Since the end green steering optics are not very orthogonal in angle/translation, it is very difficult to translate the beam by a significant amount.  If we keep the current IR alignment, which surely isn't good anyway (you can see on the ETMXF camera that the beam isn't centered), we would probably have to move the Xgreen steering optics, which would be a total pain.  It seems that the better plan is to leave them where they are, and get the IR pointing in the correct direction, and move the harmonic separator back to where it was originally.

Short term (< few days):

Write the arm section of the existing MeasureSpotPositions.py script (in ....../scripts/ASS).  Write a wrapper script that, like ...../scripts/ASS/MC/mcassMCdecenter, calls sets up the lockins, runs MeasureSpotPositions.py, and calculates the calibrated spot positions.  Use this information to hand tweak the input pointing, then realign the cavities to the new IR, and the greens to the new cavity axes.

All of the infrastructure for this is already in place in the c1ass model.   The only drawback to the current situation is the LSC output matrix only has one row for ASS, and so only one cavity can be measured at a time.  To make things faster, we could consider increasing the size of the LSC output matrix so that the 2 arms could be measured simultaneously.  This change is low priority for now.

Long term:

Make the full ASS system work. 

A major change from the current situation is that the current ASS cannot actuate on the input pointing (TT1 and TT2 for Yarm, BS for Xarm).  We want a low bandwidth servo to force the input beam to follow the cavity axis.  Implementing this will require some changes to the ASS model. 

Remeasure sensing matrix, test system.

I have modified the MeasureSpotPositions.py script to accept the arms as valid cavities (it used to give an error "Sorry, this only works for MC right now").

There is still no wrapper script to turn on lockins and turn them off after the measurement, so I have not tested the arm A2L yet.  But I should be able to tomorrow, or whenever the IFO is next available.

To-do:

* Write the wrapper script (analog of mcassMCdecenter).

* Fix arm assOff, assDown, assOn, assUp scripts to match the current channel names (which were changed long ago to be human-readable, versus mysterious numbers).

* Test.

I haven't finished debugging the scripts so that the measurement is fully automatic, like the MC, but I did measure the arm spot positions just now. 

These numbers aren't especially precise....I just picked numbers off of a StripTool plot, but they give us a good idea of how very far off we are.  Also, I don't know yet which way the signs go...I have to think about that in terms of the direction I mis-balanced the coils.  It's the same convention as the MC though.  You can see in the attached quad camera image (quadrants match the corners of the table) that these numbers aren't unreasonable.

EDIT: It occurs to me now, a little later, that it had been at least half an hour since I last realigned the cavities, so some of this apparent miscentering is due to the input pointing drift. That doesn't account for all of it though. Even when the cavities have very high transmitted power, the spots are visibly miscentered.

 Early morning drift in pitch. This plot is meaningless because there is no real  light on IP-Ang

The beam is clipping on the pick off mirror at ETMY chamber. The beam is half beam size too high. Yaw is perfect

 IP-ANG  is coming out of ETMY without clipping. The beam is very high on the pick off mirror at the end table but it is still missing the qpd .

In either .../scripts/XARM or ...../scripts/YARM run either A2L_XARM or A2L_YARM.

The wrapper script will, like the MC script, open a striptool so you can monitor the lockin outputs, setup the measurement, run the measurement, including misbalancing coils on the optics for calibration, and then calculates the spot positions.  It records the measurement in a log file in /data_spotMeasurements under each arm's directory.  The wrapper script then runs the plotting script which reads the logfile, and plots all past measurements.

Here is that plot for the Yarm:

The first two points were measured within a few minutes of eachother, the third set of points was after input pointing adjustment during IFO alignment.  Clearly the pointing that optimized the cavity transmission (trying to leave the test mass mirrors alone, and only moving TT1 and TT2) does not also give the best spot centering.  I claim that this is a result of the arm being aligned to the green beam, which was never locked to the 00 mode when we were at air.  This is a lesson learned....take the time to deal with the green beams.