The Matlab NDS1 access seems to only work for some channels. With other channels it just hangs 'Busy' and does nothing.
Below you can see some channels that make matlab hang. Everyting happened on allegra. I tried compiling the NDS1 sources (from https://www.gravity.phy.syr.edu/dokuwiki/doku.php?id=ligodv:nds1_ligodv_install ) into mex files myself. Same result. I
 

a=NDS_GetChannels('fb:8088'); %/cvs/cds/caltech/apps/linux64/share/matlab/NDS_GetChannels.m
%data=NDS_GetData({'C1:IOO-MC_F_DQ'},1004826500,100,'fb:8088',a)     %Works
%data=NDS_GetData({'C1:IOO-WFS1_PIT_IN1_DQ'},1004826500,100,'fb:8088',a)     %Works
data=NDS_GetData({'C1:LSC-AS11_I_OUT'},1004826500,100,'fb:8088',a)         %Doesn't work, hangs
%%%which NDS_GetData.m: /cvs/cds/caltech/apps/linux64/share/matlab/NDS_GetData.m

Very elaborated measurement ;-)

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

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

Nothing was really visible in spectra (see below).

Resonances:

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

Coherence:

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

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

Should be fixed a bit more rigidly.

Looking into the signals at a quiet time:

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

Had to restart the elog many times. For some reason firefox 8 on Win 7 kills the elog pretty consistently when trying to make a new entry. IE9 works fine ....

 [Den, Mirko]

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

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

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

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

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

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

PZT:

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

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

Regarding http://nodus.ligo.caltech.edu:8080/40m/5867 and http://nodus.ligo.caltech.edu:8080/40m/5869 :

MC_F signal:

The measurements on p. 5867 were done using the ADC attached to the PEM computer. There was a big difference between the MC_F signal recorded directly after the server board and the signal just before the FSS board as recorded by a PEM channel.
To understand how this happens we measured the signal at different places with a spec. analyzer:

1. WIth a locked MC measuring the signal just before the PEM ADCs (meaning after a 60ft BNC cable)
2. Same position, but unlocked and seemingly dark MC
3. Locked MC, signal just before the FSS box
4. MC_F signal that is usually going into the Pentek Generic board and is recorded in C1:IOO

=> The 60ft BNC cable adds a considerable amount of noise, but doesn't fundamentally change the signal. It is weird that the signal is white from approx. 4Hz on.
Due to Jenne's measurement ( http://nodus.ligo.caltech.edu:8080/40m/5848 ) we know the TF from MCL through PD, mixer Pentek and into C1:IOO looks like this:

This is with the double HP from 15Hz on that should be in the Pentek. So one might expect a less white signal going into the FSS board...

 PEM ADCs

The dark noise in the PEM ADCs is actually a factor 10 higher than in the IOO ADCs. Still ok wrt the the seismometers.
We also tried to measure essentially the dark noise of the whole seismometer readout (seismometer box, then ADC). That seemed ok, but is of limited value since the seismometer electronics behave a bit strange when there is no seismometer connected.

[Jenne, Mirko]

1. We should help the OAF by compensating for the actuator TF:

The actuator TF, from adaptive filter output to MC2, through PD, mixer, Pentek and into C1:IOO looks like this:

If we assume a white-ish error signal that the adaptive code tries to compensate for its job gets extra complicated because it has to invert this TF. So we really should compensate for that. Easiest place for that is the CORR filter directly behind the adaptive code block.

Using the TF measurement from above I used the vectfit (" /cvs/cds/caltech/apps/mDV/extra/firfit_forFotonMirkoComplex.m" ) to get fit a corresponding digital filter:

If we invert swap the zeros and poles in the digital filter we get the inverted TF.
(Todo: Figure out how to invert the TF. Just switching the poles and zeros doesn't work).

2. Wiener filtering

The idea was to use the adaptive filtering only for small corrections to the wiener filtering. So we really should try to get the wiener filtering going.

Howto:

1. Get data for STS1X and GUR1X and MC_F in matlab. E.g. via ligodv
2. Check the MC was in lock the entire time.
3, Filter MC_F with the actuator TF, so the wiener filter knows about that and compensates for it
4. Calculate the wiener filter " h1winolevLigoDV.m "
5. Export the data to the workspace. It is also saved to the disc as "h1filtcoeffTS.mat". Make sure there are first the witnesses, then MC_F
6. Execute " /cvs/cds/caltech/apps/mDV/extras/LHO/firfit_for_FotonMirko.m" while one directory higher. 
7. Copy the digital filter in SOS form that is printed into the matlab command line and put it into the corresponding filter in the OAF model via foton.

With data from 11-11-15 04:00 to 05:45. Sampling freq. 256Hz. 8000 Taps => length = 30.2s. Prefiltered to notch the 60Hz line in MC_F, but not compensation the actuator TF. This results in the following wiener filter and corresponding SOS filter to be copied into foton.
STS1X:

GUR1X:

Earlier this evening C1:LSC died then I hit the DAQ reload after adding an OAF channel to be recorded. No change to any model. Had to restart C1:SUS too. Reloaded burts from this morning 5am, except for C1:IOO, which I loaded from 16:07.

MC fell out of lock and was then quite badly misaligned. Mostly in pitch. I realigned it and it locked ok.

Turns out the MC falls often out of lock when the WFS servo comes on. I think the MC2_Trans history is not cleared on lockloss. I cleared it manually and realigned. Seems fine for now.

[Rana, Den, Mirko]

Updated the MC noise projection to include the longitudinal motion of the MC mirrors.

=> Lots of OSEM - local dampling noise!

Consistent with static wiener filter showing only benefits in the 1 - 4Hz region.

Some more info on this:
 

f > 1 Hz:

At these frequencies the pendulum should be quieter than the stacks. By quite a bit actually since there is the stack resonance at a couple Hz. 'Glueing' them together via the local control is not wise. We put an elliptic LP ( 2.5Hz, 4th order 6dB) into the C1:SUS-MC?_SUSPOS pathes and MC-F got better above 1Hz

Added an extra LP @ 10 Hz afterwards. Doesn't make a visible difference.

f < 1 Hz:

Now here is more stuff to consider.

1. The OSEMs glue the MC mirrors to the stacks
2. The pendulum TF should be 1
3. It shouldn't matter if the OSEMs do or do not act on the mirror at these frequencies, assuming they don't add extra noise.
4. Page http://nodus.ligo.caltech.edu:8080/40m/5547 seems to indicate OSEM sensor noise is so low it can be neglected.

Reduced OSEM gain below 1Hz:

If we reduce the gain in the OSEMs by adding additional HP filters ( cheby2, HP 0.3Hz, 6dB 4th order ) the happens:

1. MC length gets a bit more noisy at low frequencies - should be looked into some more
2. Coherence between the GUR1 seismometer and MC length goes up between 1E-2 and 1E-1 Hz:

( Ref is with low OSEM gain )

Possible explanation:

The stacks might be more correlatedly moving together than the pendulums. This would be not so nice for OAF test, but really fine for actually using the MC.
Todo: Measure the OSEM to seismometer coherences with high and low OSEM gains.

For reference the seismometer coherence with one another:

 The measurement was done with the MC in lock and the OSEMS active.

1. I injected noise into MC1-3 SUSPOS_EXC at a level that domiated the SUSPOS output.
2. Then I calculated the coupling coefficients of the SUSPOS outputs to MC_F during the time the noise is injected.
3. Without noise injection I projected the SUSPOS outputs to MC_F by multiplying the coupling coefficients with the SUSPOS outputs.

All on 11-11-18. White noise inj. from 0.1Hz to 20Hz. Duration 4mins each.

DOF      Amplitude(counts)     Time(UTC)
MC1      200                           22:08
MC2      25                             22:25
MC3      25                             22:50

Some thoughts on this, bare with me:

As you say this does not show the dark / bright noise of the OSEMs. It shows the influence of the OSEMS output onto MC_F in normal operation of the MC. I would have expected that to be very low everywhere except at the pendulum resonance. Reason for that not to be true could either be the OSEMs having considerable gain off of the resonance, or noise intrinsic to the OSEMs knocking the mirrors around. Since we know the OSEM signal to MC_F TF we only need to compare the OSEM signal to OSEM noise to see the noise contribution to MC_F. We know from http://nodus.ligo.caltech.edu:8080/40m/5547 that the OSEM sensor bright noise is considerably below the OSEM signal above 0.1Hz in actual operation. We checked that the MC OSEM signals are above the noise in the reference above 0.1Hz by a factor 3-10.

We actually measured the cost function with the noise projection (valid to 10Hz). It's just the coupling coefficient, right?

[Den, Mirko]

We looked some more into the the OSEM signals and their coherence to the seismometer signals.

We were able to verify that the coherence OSEM sensor <-> seismometer signal goes down with increasing the OSEM gain. This seems to indicate that the OSEM FB add noise to the distance mirror <-> frame. We injected some noise into the OSEMs to see how the coherence behaves.

MC2 SUSPOS, 0.1Hz - 0.8Hz, 3mins each

Inj. amplitude   Time(UTC) Note

-                     21:35          Free swinging
-                     21:42          Big LF OSEM gain
-                     21:48          Small LF OSEM gain
150                     21:56          -"-
300                     22:00          -"-
900                     22:05          -"-

Free swinging:

High OSEM gain:

Low OSEM gain:

We left the filters that lower the OSEM gain below 0.3Hz on.

[Jenne, Mirko]

To reiterate: We changed the OSEM loop shape for MC1-MC3. Below in black is the old loop shape, which simulated pendulum response in there. In red is the new loop shape.

The differences are due to extra filter in C1:SUS-MC?_SUSPOS module 6,7,9

6: Elliptical LP @ 2.5Hz
7: Inverse Chebychev HP @0.3Hz
8: 1st order LP @ 10Hz

This has the potential to be unstable, but is not. At some point these filters should be tuned further.

For some reason C1PEM doesn't seem to work anymore after a recompilation. It did recompile fine. We just changed some channel / subsystem names.

Tried reverting to the svn version. Doesn't work. Reboot C1SUS also no good.

 It is fine again. Thanks Jamie.

Tried measuring the actuator matrix for MC1.

With the watchdogs tripped I cut the loops for pos, pitch and yaw open just before the servos. Then I injected a fixed sine at 0.4Hz into the three DOFs (suspos, suspit, susyaw) one by one, while looking into the error signal just before the servos.

                                                         Response DOF

                                     pos                 pit             yaw

Injection DOF pos          0.008417       0.00301        0.004975
                     pit            0.01295         0.01959        0.0158
                     yaw         0.007188        0.002152     0.0144

Inverting that and dividing by the norm gives us

 0.8322   -0.1096   -0.1669
-0.2456    0.2869   -0.2293
-0.3777    0.0118    0.4211

Somehow putting this into the 'To coil' matrix has an effect even with the watchdog tripped!?!?

The Striptool for the BLRMS seismic channels is running now. Channels are ( still ) recorded as slow EPICS channels.

A big peak in the 0.1 - 0.3Hz seismic region in both GUR1 and STS1 irritated us for a while. I added an extra LP filter @ 0.05Hz to the RMS_LP modules.

I calculated the F2A filters for the input mode cleaner optics as described in T010140-01-D eq (4). On Ranas recommendation I added an s/ ( w_0 * Q ) term to the numerator.

The used values are:

w_0 = 2pi / s
h= 0.0009
D= 2.46957E-2
Q=10

I put theses filters into C1:SUS-MC1_TO_COIL_1_1 to _4_1 . For convenience split in Z and P. Well it doesn't work. After a few seconds the optic begins to swing wildly.

Tried the wiener filter with the TF from p.5900

Tried it out with the TFs from p.5900:

Adding a filter element that compensates the acutator TF makes the MC lose lock.

[Rana, Den, Mirko]

It seems you can shoot yourself in the foot if your filter modules are too complex.

Den discovered this when looking into the C1:SUS-MC?_SUSPOS filter module named Cheby, consisting of cheby1("LowPass",6,1,12)cheby1("LowPass",2,0.1,3)gain(1.13501) by noticing that the coherence between input and output of the filter is low.

Cheby filter:

This is most likely due to the filter spanning more than the 16 orders of precision that the double data type spans.

The coherence is fine when one splits the filter in two, giving every cheby1 filter its own module. The coherence is also fine when you use the Cheby filter in a 2kHz system, although the freq. response looks very odd

Black: 16kHz, Red 2kHz (yes the filter was converted correctly, no text file editing there)

The problem occurs on c1lsc as well as c1sus computer.

Looking into the foton files actually points to a precision problem, with the huge range of scale covered in there:

C1:MCS 16kHz (Cheby: Original filter with low coherence. CHbyTST & ChebyTST: Original filter split amongst two filter modules)
################################################################################
### SUS_MC3_LSC                                                              ###
################################################################################
# DESIGN   SUS_MC3_LSC 0 zpk([0],[30],0.333333,"n")
# DESIGN   SUS_MC3_LSC 1 cheby1("LowPass",6,1,12)
# DESIGN   SUS_MC3_LSC 2 cheby1("LowPass",2,0.1,3)gain(1.13501) \
#                       
# DESIGN   SUS_MC3_LSC 3 cheby1("LowPass",2,0.1,3)gain(1.13501)cheby1("LowPass",6,1,12)
# DESIGN   SUS_MC3_LSC 4 ellip("BandStop",4,1,40,16.1,16.9)ellip("BandStop",4,1,40,23.7,24.5)gain(1.25871)
###                                                                          ###
SUS_MC3_LSC 0 12 1  32768      0 30:0.0          9.942903833923793  -0.9885608209680459   0.0000000000000000  -1.0000000000000000   0.0000000000000000
SUS_MC3_LSC 1 21 3      0      0 CHbyTST     9.095012702673064e-18  -1.9978637592754149   0.9978663974923444   2.0000000000000000   1.0000000000000000
                                                                 -1.9984258494490537   0.9984376515442090   2.0000000000000000   1.0000000000000000
                                                                 -1.9994068831713223   0.9994278587363880   2.0000000000000000   1.0000000000000000
SUS_MC3_LSC 2 12 1  32768      0 ChebyTST    1.228759186937126e-06  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000
SUS_MC3_LSC 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000
                                                                 -1.9978637592754149   0.9978663974923444   2.0000000000000000   1.0000000000000000
                                                                 -1.9984258494490537   0.9984376515442090   2.0000000000000000   1.0000000000000000
                                                                 -1.9994068831713223   0.9994278587363880   2.0000000000000000   1.0000000000000000
SUS_MC3_LSC 4 12 8  32768      0 BounceRoll     0.9991466189294013  -1.9996634951844035   0.9997010181703262  -1.9999611719719754   0.9999999999999997
                                                                 -1.9999303040590390   0.9999684339228864  -1.9999605309876360   0.9999999999999999
                                                                 -1.9999248796830529   0.9999668732412945  -1.9999594299327190   1.0000000000000002
                                                                 -1.9996385459838455   0.9996812069238987  -1.9999587601905868   1.0000000000000000
                                                                 -1.9996161812709703   0.9996978939989944  -1.9999163485656493   0.9999999999999999
                                                                 -1.9998855694973159   0.9999681878303275  -1.9999154056705493   0.9999999999999998
                                                                 -1.9998788577090287   0.9999671193335300  -1.9999137972442669   1.0000000000000000
                                                                 -1.9995951159123118   0.9996843310430819  -1.9999128255920269   1.0000000000000000

C1:OAF 2kHz
###############################################################################
### YARM_IN                                                                  ###
################################################################################
# DESIGN   YARM_IN 0 zpk([0],[30],0.333333,"n")
# DESIGN   YARM_IN 3 cheby1("LowPass",6,1,12)cheby1("LowPass",2,0.1,3)gain(1.13501)
# DESIGN   YARM_IN 4 ellip("BandStop",4,1,40,16.1,16.9)ellip("BandStop",4,1,40,23.7,24.5)gain(1.25871)
# DESIGN   YARM_IN 8 cheby1("LowPass",6,1,12)cheby1("LowPass",2,0.1,3)gain(1.13501)zpk([],[10],1,"n")
###                                                                          ###
YARM_IN  0 12 1   4096      0 30:0.0           9.56649943398763  -0.9119509539166185   0.0000000000000000  -1.0000000000000000   0.0000000000000000
YARM_IN  3 12 4   4096      0 Cheby       1.829878084970283e-16  -1.9828889048300398   0.9830565293861987   2.0000000000000000   1.0000000000000000
                                                                 -1.9868188576622443   0.9875701115261976   2.0000000000000000   1.0000000000000000
                                                                 -1.9940934073784453   0.9954330165532327   2.0000000000000000   1.0000000000000000
                                                                 -1.9781245722853238   0.9784022621062476   2.0000000000000000   1.0000000000000000

 [Rana, Mirko]

I redid this calculation. The idea behind it is to get rid on any pitch that is introduced by applying longitudinal feedback to the mirrors. This coupling happens because the center of percussion for pitch , which is identical with the point where the wires lift off of the mirror, is above the center of mass.

With the same values as before, just less faulty math and Q = 2 instead of 10 we end up with the following filters:

For the lower coils (red), compared to corresponding preexisting BS filters (black):

The upper coils' TF is just mirrored at the 0dB magnitude axis, and have a corresponding frequency response.

I switched the F2a filters on for all MC mirrors. For convenience they are split into F2aZeros and F2aPoles. Everything seems fine. The F2a filters seem to be off for ( all ?) other mirrors.

We replaced the complicated Cheby filter module with three separate filter modules. Probably the filter doesn't need to be so complicated, but rather not change too many things at once. The new filter modules are called:
Ch1, Ch2, Ch3 and are in filter module 3,9, and 10 of the C1:SUS-MC?_SUSPOS filters. The coherence with these filters is fine. Someone should look into the possibility of simplifying these filters.

It would be good to check for numerical problems in other filters!

[Rana, Mirko]

I tried out the virtual pendulum idea today. The idea is to compensate the physical pendulum via the control system, and then add a virtual pendulum formed in the control system. We know the actuator TF from p. 5900 and apply its inverse to the C1:SUS-MC?_SUSPOS filters. Also we add an pendulum Q=3 with a resonance frequency of 0.1Hz to the POS control loops.

The result is pretty awesome!

1. Black: Standard config. Wfs on. New Cheby filter in place ( p. 6031 )
2. Red: With virtual pendulum. Extra eliptic LP filter @ 2.5Hz

Filter shape:

This is stable for 5-10minutes, at which point it falls out of lock, swinging in yaw.

In the above entry MC_f  signal is improved off of resonance by the implementation of the pendulum compensation. It should be checked if this is actually due to the implementation of the virtual pendulum at 0.1Hz. A way to check that might be to implement a simple double LP at 0.1Hz instead and look at the resulting MC_f signal. A projection of the OSEM FB noises with the compensation active might be interesting.
The physical resonance at 1Hz is clearly not compensated correctly, which is probably the reason for the lock losses after a few minutes. It might be a good start to measure the residual resonance with the compensation in place. The filters in bank 7 of C1:SUS-MC?_SUSPOS have both the compensation of the 1Hz resonance( really the inverse actuator TF ) and the virtual pendulum in them. The ‘pure’ compensation can be found in the InvTF module in the C1:OAF-ADAPT_MCL_CORR filter.
The fact that the beam swings in yaw at lock loss indicates that the separation of the DOFs might not be perfect. One should have a look into the yaw and pitch DOFs with the compensation active.

I have gotten the hang of the procedure for measuring phase noise on the AOMs. 

Koji suggested I right up a short guide (wiki page?) on how to do this. 

I will finish up here, then go measure the AOMs at the other lab (may have to be tomorrow, after laser safety), and then write up the instructions.

Here is the result for the measurement of the phase noise.  We used the marconi function generator and compared it with an Isomet AOM driver (model 232A-1), so this is really a measure of the relative phase between them.  We used a 5x gain and a frequency response of 13 Hz/V for the modulation.  In all the attached plots, the blue is the data and the red is the measurement limit (as determined by the noise in the SRS785).  Also note that the units on the yaxis of the Phase noise plot are incorrect, they should be dB/Sqrt(Hz), I will fix this and edit as soon as possible.

I have made some measurements of the R value for some coatings we are interested in.  The plots have statistical error bars from repeated measurements, but I would suspect that these do not dominate the noise, and would guess these should be trusted to plus or minus 5% or so.  They still should give some indication of how useful these coatings will be for the green light.  I plan to measure for the ITM as soon as possible, but with the venting and finals this may not be until late this week.

EDIT (12/9/09): I fixed the label on the y axis of the plots, and changed them to png format.

Attached are updated plots of the T&R Measurements for a variety of mirrors, and diagrams for the setup used to make the measurements.

T is plotted for the 1064 nm measurement, since these mirrors are highly reflective at 1064, and either R or R&T are plotted for the 532 nm measurement, depending on how larger the R signal is.

As with the previous set of plots, the error bars here are purely statistical, and there are certainly other sources of error not accounted for in these plots.  In general, the T measurement was quite stable, and the additional errors
are probably not enormous, perhaps a few percent.

The mirrors are:

Y1-1037-00.50CC

Y1-2037-45S

Y1-2037-45P

Y1S-1025-0

Y1S-1025-45

The most up-to-date T and R plots for the Y1 and Y1S mirrors, as well as a T measurement for the ETM, can be found on:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/Optics/RTmeasurement

 It looks like the PLL drifted alot over the weekend, and we couldn't get it back to 9 dBm.  We switched back to the new focus wideband PD to make it easier to find the beat signal.  I replaced all the electronics with the newly fixed UPDH box (#17) and we aligned it to the biggest beat frequency we could get, which ended up being -27 dBm with a -6.3V DC signal from the PD.  

Locking was still elusive, so we calculated the loop gain and found the UGF is about 45 kHz, which is too high.  We added a 20 dB attenuator to the RF input to suppress the gain and we think we may have locked at 0 gain.  I am going to add another attenuator (~6 dB) so that we can tune the gain using the gain knob on the UPDH box.  

Finally, attached is a picture of the cable that served as the smb - BNC adaptor for the DC output of the PD.  The signal was dependent on the angle of the cable into the scope or multimeter.  It has been destroyed so that it can never harm another innocent experiment again!

We have managed to lock the PLL to reasonable stability. The RF input is attenuated by 26 dBm and the beat signal locks very close to the carrier of the marconi (the steps on the markers of the spectrum analyzer are coarse).  We can use the marconi and the local boost of the pdh box to catch the lock at 0 gain.  Once the lock is on, the gain can be increased to stabilize the lock.  The locked signals are shown in the first photo (the yellow is the output of the mixer and the blue is the output to the fast input of the laser.  If the gain is increased too high, the error signal enters an oscillatory regime, which probably indicates we are overloading the piezo.  This is shown in the second photo, the gain is being increased in time and we enter the non-constant regime around mid-way through.

Tomorrow I will use this locked system to measure the PZT response (finally!).

 After realigning and getting the lock today, I tried to add in the SR785 to measure the transfer function.  As soon as I turn on the piezo input on the PDH box, however, the lock breaks and I cannot reacquire it.  We are using an SR650 to add in the signal from the network analyzer and that has worked. We also swapped the 20 dB attenuator for a box which mimics the boost functionality (-20 dB above 100 Hz, 0 dB below 6Hz).  I took some spectra with the SR750, and will get some more with the network analyzer once Alberto has finished with it. 

The SR750 spectra is posted below.  The SR750 only goes up to 100 kHz, so I will have to use the network analyzer to get the full range. 

I just put a script in the /cvs/cds/caltech/scripts/general/netgpibdata/ directory to control the network analyzer called AG4395A_Run.py .   A section has been added to the wiki with the other GPIB script sections (http://lhocds.ligo-wa.caltech.edu:8000/40m/netgpib_package#AG4395A_Run.py)

I took data for the 2 NPRO PLL using the script I wrote for the AG4395, but it is very noisy above about 1 MHz.  I assume this is something to do with the script (since I am fairly confident we don't have 600 dB response in the PZT), so I will go in tomorrow to more carefully understand what is going on, I may need to include a bit more latency in the script to allow the NA to settle a bit more.  I am attaching the spectrum just to show the incredibly high noise level, 

Kiwamu and I measure the PZT response of the Innolight this evening from 24 kHz to 2MHz.  

We locked the PLL at ~50 MHz offset using the Lightwave NPRO and and swept the Innolight with the network analyzer (using the script I made; it has one peculiar property, but it does work correctly).  

We will post the plot of the Lightwave PZT response tomorrow morning.

**EDIT**: As Koji pointed out, the calibration factor on this plot is WRONG.  See my more recent update for the correctly calibrated plot.

 Koji is absolutely right.  I just double checked my matlab code, and saw that I divided when I should have multiplied.  The correctly calibrated plots are attached here for the Innolight and the lightwave.  Kiwamu and I will measure the amplitude and the jitter today.

 We realized that we had measured the wrong calibration value; we were using the free-running error signal with the marconi far from the beat frequency, which was very small.  When we put the Marconi right at the beat, the signal increased by a factor of ~12 (turning our original calibration of 10 mV/rad into 120 mV/rad).  The re-calibrated plots are attached. 

 We measured the Amplitude Modulation response of the PZTs, to find regions with large phase modulation but small amplitude modulation.

We did this by blocking 1 arm of the PLL, feeding the source output of the Network Analyzer into the PZT input of the laser in question, and reading the output of the PD on the NA.  We calibrated by dividing by the DC voltage of the PD (scaled by the ratio of the AC gain to DC gain of the New Focus PD).

The AM response of the Innolight looks fairly smooth up to ~1MHz, and it is significantly below the PM response for most of its range.  The region between 20 and 30 kHz shows very good separation of about 10^3 rad/RIN (and up to 10^5 rad/RIN at ~21.88 kHz, where there is the negative spike in the AM response). The region between 1.5 MHz and 2MHz also looks viable if it is desirable to actuate at higher frequencies.

The Lightwave offers very good AM/PM separation up to about 500 kHz, but becomes quite noisy about 1MHz.

 I redid the PZT Phase Modulation measurement out to 5 MHz for both the Innolight and the Lightwave.  The previous measurement stopped at 2MHz, and we wanted to see if there were any sweet spots above 2MHz.  I also reduced the sweep bandwidth and increased the source amplitude at high frequency to reduce the noise (the Lighwave measurement, especially, was noise dominated above 1MHz).  I also plotted the ratio of PM/AM in rad/RIN, since this is the ultimate criterion on which we want to make a determination.

It looks like there is nothing extremely useful above 2MHz for either laser.  There are several candidates for the lightwave at about 140 kHz and again at about 1.4 MHz.  The most compelling peak, however, is in the innolight at 216 kHz, where the peak is about 2.3e5 rad/RIN.

Below about 30kHz, the loop suppresses the measurement, so one should focus on the region above there.

You guys must work harder.

dB(A) (A-weighted) scale and the Noise Criterion (NC) scale are popularly used in the United States for creating the spectrum. 

dB(A) Explanation: https://www.engineeringtoolbox.com/decibel-d_59.html

NC Explanation: https://www.engineeringtoolbox.com/nc-noise-criterion-d_725.html

(tldr: dBA applies an A-weighted filter to the dB scale to account for relative loudness that humans perceive at different frequencies. NC scale assigns a number, eg NC-55 such that at no frequency does the noise go beyond 55dB)

To capture this coherently, engineers usually use a SPL (Sound Pressure Level) Meter which is in essence, just another microphone. It is calibrated using a SPL Calibration Device which plays sound at a given loudness (usually 94dB, 114dB) and at a set frequency (usually 1kHz). You latch it on your SPL meter and make sure it is reading the output. 

The good thing about an SPL meter is, you don’t need to worry about the internal gains and so forth, it does all of that under the hood and gives you the measurement straight in decibels (A/B/C weighted if required).

The alternative to this suggested was using a UMIK 1 (a microphone that has a low noise floor - needs to be measured, online blogs mention it as ~30dbA). The suggested softwares are REW and Dirac Live (this one is paid).

UMIK 1 can be used in a couple of ways:

1. UMIK 1 + REW has a fair amount of documentation online for setting up. You can calibrate the microphone by pressing some keys which brings you in the green zone which the software likes (hopefully). This video explains it well.
   https://www.youtube.com/watch?v=3mOn6_3j5DU.
   UMIK-1 also comes with a calibration file, however one of the blogs mentions that it does not make a huge difference. This calibration file can be used directly in the REW software. This old graph does not show a huge difference in the bandwidth of interest between the factory settings and the calibrated settings. Additionally, it has a Sens Factor which I don't fully understand. (explained in this blog).
   The two REW features that may get the job done are the SPL Meter and the RTA (Real Time Analyzer). However, the issues with both are as described in this question I posted on their forum. https://www.avnirvana.com/threads/rew-umik-1-measurements-dba-nc.12420/#post-94154 (Update: There was a reply on the post needs to be checked out).

2. The signal can be read directly into something like Audacity and the time series can then be analyzed manually. However, the specification sheet for UMIK 1 does not provide it’s sensitivity so it’s difficult to know what it’s actually reading (have contacted the tech support, they said they’ll get back on Monday posted on a forum as well). A couple of recordings that were done on Audacity were of extremely low level using the UMIK 1 which probably means there’s some gain configurations that need to be figured out to get a good signal.

(Another microphone, the YETI Nano Blue may be used with Audacity, have requested for the specifications sheet. Update: 4.5mV/Pa at 1kHz).

This is an update for 17794.

The UMIK 1 + REW combination gave satisfactory results for creating the acoustic noise spectrum for various spaces. This combination was corroborated using the NIOSH app on iOS (by OSHA) and the real time readings were usually in the +-2dB range of each other. dBA scale (reference values)  and NC scale (reference values) were used for measurement. Since the microphone is omnidirectional, the data was collected in the upright position. About 300 averages were taken for each reading and for open spaces, the data was collected with minimal activity (a few people walked by while collecting the stairwell data but they tried to be discreet). For closed spaces, readings were taken at 2/3 positions depending on the size of the room.

HIGHLY SUGGEST GETTING A CALIBRATION DEVICE IN THE FUTURE TO MAKE FAITHFUL MEASUREMENTS.

This is the Noise Floor of the UMIK-1 for reference (it was taken by covering it in a multiple layers of a bedsheet). The remaining readings can be found in ANS_Script_Data_Images.zip

The zip file contains the following:
Acoustic Noise Spectrum.pdf - This contains the keywords and spectrums consolidated in one pdf document
ANS_Positions.pdf - This contains images of the mic position while collecting the data
NC_Data_points.txt - This contains the data points used to generate the NC curves (Spline fit)
Spectrum Data - This folder contains the text files with the raw data to create the spectrum as well as some additional information about the recordings (source, date, etc)
Spectrum Images - This folder contains individual images for all the spaces
Final_Analyze_Signal.ipynb - Notebook used to create the spectrum from the text data

Update: Added spectrums for Downs-Lauritsen Rooms (226, 314, Sub Basement Corridor)
Update: Superimposed noise floor on each spectrum

Koji suggested going through the following steps to check the ETMX suspension:

1. Do a free swing test to obtain the input matrix
2. Run the coil balancing script to change the gains on the them
3. Do the ring down test without closing the loop with the OPLEV and just with the OSEM to get Q~5
4. Tune the OPLEV servo gains

Suggestions welcome.
Tuning the ASC would make more sense once ETMX has been calibrated. Will run the free swing test tonight.

Update to 17809. The free swing test for ETMX took quite some time, here's a brief summary of what was going wrong and a small update on it.

tldr: The scripts haven't been too helpful to obtain the resonant frequencies. Paco (to the rescue) suggested pulling up the raw data from the channels and get a spectrum manually. From the free swing test that was run on Wednesday (1:00am, was ended abruptly), there was enough data to be able to obtain the resonant frequencies for the Position (0.9524Hz) and Pitch (0.7238Hz) DOFs. The resonant frequencies for Yaw (0.8334Hz) and Side (1.0001Hz) were obtained as well (Aug_Res_Freqs.png).
The percent change in resonant frequencies from the last free swing test run by Yehonathan (17714) for all modes was < 2%. Thus, I will skip the diagonalization and moving to the next step of tuning the coils.

Procedure & Possible Changes

The data was collected in batches, for POS, PITCH (SUSfreeswing_ETMX_1377417624_POS_PIT_YAW_SIDE.txt) (1050 seconds, 15 kicks, 10000 counts) first and then for YAW (SUSfreeswing_ETMX_1377619412_YAW.txt) and SIDE (SUSfreeswing_ETMX_1377623258_SIDE.txt) (720 seconds, 5 kicks, 10000 counts) respectively. At some point, the default could be changed for freeSwing.py as the default setting (15 kicks, 1050 seconds) or 4 DOFs takes (4*15*1050/3600 = 17.5 hours) to new setting (5 kicks, 720 seconds) (4*5*720/3600 = 4 hours). getResFreqs.py is still troublesome so the analysis for this particular test was done in python. The notebook (freeSwingtest_Aug23.ipynb) is attached. It uses 2 really nice snippets of code that Paco has written to obtain the channel data and get the spectra (welch) .

Troublemakers
With some hardware changes to the ETMX (suspectedly the acromag), the script assumes some things which were important to run the test. Manual adjustments: Damping turned off, ramp times for DAMP FILTERS and Coil Outputs set to 0 in EPICS. 

The default value for the kick is 30000. However, kicking with this offset in the DOF basis gave clipping in the coil outputs. This was changed by giving it a 10000 offset using options.

Suspicion: In order to run the subsequent scripts (getResFreqs.py and sus_diagonalization.py), it's important to run freeSwing.py by giving the degrees of freedom for which you would want to obtain the resonant frequencies (eg  -k POS PIT YAW SIDE) as there is an internal dependency for it. Not sure how the UR Coil kick (default) is usually processed ahead (need to read into this in detail)

Even with the above changes, getResFreqs.py was having trouble reading data from the channel (ValueError: could not broadcast input array from shape (xxxx) into shape (xxxx)). Unsure why. 

With the same options (5 kicks, 720 seconds, 10000 counts) for the freeswing test conducted at 01:00am (SUSfreeswing_ETMX_1377565258_YAW_SIDE.txt) and 09:00am (SUSfreeswing_ETMX_1377619412_YAW.txt), the time series for YAW looks terrible for the former (?????). The comparisions are attached (freeswing_yaw_5kicks_10000counts_720s_good.png , freeswing_yaw_5kicks_10000counts_720s_bad.png)

Resonant Frequency in Position:  0.9524518193317955 Hz
Resonant Frequency in Pitch:  0.7238633826921645 Hz
Resonant Frequency in Yaw:  0.833423765599566 Hz
Resonant Frequency in Side:  1.0001085187194791 Hz

COIL BALANCING FOR ETMX
Summary : I ran coil balancing on ETMX using the CoilStrengthBalancing.ipynb script to get a feel for it, no changes were required from the last time it was run by Paco. I realized I was measuring the wrong signal for the POS coupling (C1:SUS-ETMX_SUSPOS_IN1) while trying to minimize the BUT-POS coupling. This was stupid because the shadow sensors and actuation coils in this case are the OSEMs. The LSC error signal would be more appropriate for measuring the POS coupling.

The convention for the actuation vector used for the coils is [UL, UR, LL, LR]. The frequency, excitation counts are given through the LOCKIN1 channel (SUS->ETMX->LOCKIN1->f(Hz), Amp). The excitation vector is set in (SUS->ETMX->Output Filters->LOCKIN1)
Here, the excitation frequency used = 13Hz.
For "decoupling" the degrees of freedom, the script used is given in /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/coilStrengthBalancing/ETMX/CoilStrengthBalancing.ipynb. In here, small steps are taken to "remove" the DOF contribution such that \\new_gain = old_gain +/- e*(decoupling DOF vector)\\. (e = step size)
The decoupling signals are observed in diaggui in the frequency range of (0 - 20Hz) and a bandwidth of 0.5Hz with exponential averaging (10 averages)

1. Minimizing BUT-POS coupling
Here, the LSC error signal (C1:LSC-POX11_I_IN1) is observed to measure the coupling in POS. For this, the arm is kept locked to obtain a decent error signal.
SANITY CHECK: This was tested by exciting POS [1,1,1,1] at 13Hz and measuring at the LSC error signal in diaggui which indeed showed a peak at 13Hz indeed. Damp filters and OPLEV servos were enabled to prevent the loss of lock.
The initial excitation was given to the Butterfly DOF [1, -1, -1, 1] at 10000 counts and 5 steps were taken in both directions of the POS vector to decouple the POS DOF. The initial peak showing up in the LSC error signal was already at a minimum. The excitation was ramped up to 20000 counts, where the peak was still very small. Thus, no change was made here (Attachment 1).

2. Minimizing POS-PIT coupling
Here, the OPLEV signal for PIT (C1:SUS-ETMX_OL_PIT_IN1) is observed to measure the coupling in PIT. The damping filters and OPLEV servos are disabled.
The initial excitation is given to POS [1, 1, 1, 1] at 5000 counts and 5 steps were taken in both directions of the PIT vector to decouple the PIT DOF. The initial peak showing up in the OPLEV signal was already at a minimum. Thus, no change was made here (Attachment 2).

3. Minimizing POS-PIT coupling
Here, the OPLEV signal for YAW (C1:SUS-ETMX_OL_YAW_IN1) is observed to measure the coupling in YAW. The damping filters and OPLEV servos ared disabled.
The initial excitation is given to POS [1, 1, 1, 1] at 5000 counts and 5 steps were taken in both directions of the YAW vector to decouple the YAW DOF. The initial peak showing up in the OPLEV signal was already at a minimum. Thus, no change was made here (Attachment 3).

4. Minimizing PIT-YAW coupling
This was one rather robust and was not susceptible to the decoupling process. Here, the OPLEV signal for both PIT (C1:SUS-ETMX_OL_PIT_IN1) and YAW (C1:SUS-ETMX_OL_YAW_IN1) are used to measure their relative coupling. Either of the DOF can be excited and while the other DOF can be used for the decoupling vector. Here, PIT was excited and the decoupling DOF vector was YAW. The damping filters and OPLEV servos ared disabled.
The initial excitation was given to the PIT DOF [1, 1, -1, -1] at 5000 counts and 5 steps were taken in both directions of the YAW vector to decouple the YAW DOF. The initial peak showing up in the YAW signal was already at a minimum. The excitation was ramped up to 10000 counts, however the YAW peak barely moved. Thus, no change was made here (Attachment 4).

To next.

PRM CHANNEL 1-4 (BS FEEDTHROUGH 1-3)

[Koji, Radhika, Murtaza]

Connector on the BS Chamber that feeds to PRM UL/LL/UR coils (PRM 1 in Attachment 1) has pin 5 shorted to pin 1 inside the chamber 
- To resolve this, a DB25 connector was recycled from the old coil drivers
- pin 5 was isolated by cutting (green cable on the DB25 connector)
- The connector was attached between the chamber and the cable that runs through to the rack (Attachment 1)
- The connector was labelled (Attachment 2)

The PD outputs were read on the PRM SATAMP (Pins 1-4, Pin 5 (Ground))

No need to apply an external bias to Pin 5!

Can be fixed during the next vent!

[JC, Paco, Radhika, Murtaza]

IFO ALIGNED

1. WFS Relief
We tried to change the gain to offload the offsets in the reliefMCWFS script but it The gains might need some tuning to get it to work

2. WFS Error Signals Diverging
The error signal C1:IOO-WFS2_I_PIT_MON was staying at a constant offset from 0 using the existing output matrix (C1IOO_WFS_OUTMATRIX). We tried changing the matrix coefficients that may have caused this behavior but it led to divergence in other signals (C1:IOO-WFS1_I_PIT_MON, C1:IOO-WFS2_I_YAW_MON). THIS NEEDS TO BE FIXED

3. BS was aligned using OPLEV readouts and the damping filters were checked. No funny business for BS anymore.

4. The original IFO Align scripts used the suffix "COMM" for each optic. This was changed to "OFFSET" for all arguments by editing the IFO_ALIGN screen (left click-> Execute -> Edit this screen -> !Align -> Label/Cmd/Args)

5. The OPLEV gains for ITMY were unstable and needed some tuning. New gains: C1:SUS-ITMY_OL_PIT_GAIN (14->3.5) and C1:SUS-ITMY_OL_YAW_GAIN (-8->-4). (The upgrade should not have affected this so this could be revisited later).

6. YARM (transmission ~ 1) and XARM (transmission ~ 0.6) were locked successfully!

ITS A GOOD IDEA TO HAVE PRM AND SRM MISALIGNED WHILE TRYING TO LOCK THE IFO.

[Paco, JC, Murtaza]

[WIP]

To fix the WFS loops, went through the following steps

With the WFS loop turned off

- We manually aligned the optics MC1, MC2 and MC3 (IOO -> C1IOO_MC_Align) to maximize transmission (MC Trans Sum -> ~13300)

- We manually aligned the QPDS for WFS1 and WFS2 to center the beam by looking at the DC signals (C1IOO_WFS_QPD). The laser was clipping on WFS2

With the WFS loop turned on

- We changed the gains of the WFS filters for all signals (1.0 -> 2.0), this led to faster conversion but clipping on C1:IOO-WFS2_YAW_OUTPUT. The gains were restored to 1.0 and thus left unchanged.

- We increased the reliefMCWFS gain by a factor of 10 by changing the arguments (Execute -> Edit this screen -> Actions -> label/cmd/args -> Arguments) (0.02 -> 0.2) 

- We ran WFSoutMatBalancing.py (17334) to calculate the new output matrix