UGF Servos' commissioning still going on, updates of today:

• on Rana's suggestion, we don't use anymore the Q-signal rejection at the level of Phase 1 and Phase 2; instead, a proper complex division is made between those two signals (with a check in case of zero); then the resulting signal is demodulated with a new Phase 3, which is the one used to select the I signal while zeroing the Q one; changes to the model and the screens have been made;
• a new evaluation of all the parameters for the four servos has been made; aside for the new phase, and the zeroing of the other phases (because they are not used anymore for the selection), the parameters are not dissimilar from the prevoius ones
• the PRCL and MICH servos seem sufficiently stable;
• CARM and DARM are stable only for a short amount of time; what usually happens is that one of the two starts drifting in one random direction, and usually the other one follows shortly after; it is not clear if there is a relation or if they stop being stable after a similar amount of time; I still noticed a few lowest limits appearing in the input signal, which should be avoided; I'll check the model again tomorrow;
• the weird thing about CARM and DARM is that at the same time when one of them starts drifting, its I and Q signals begin to be comparable; when the servo is shut off, they resume their normal state;
• an increase in the excitation gain improves the separation of I and Q and also reduces their variations, but a high peak in the loop due to this might not be a good idea.

I found an error in the model of the UGF servos, I have now corrected it; for future reference, now the division between TEST2 and TEST1 is properly done with complex math: given

we have that TEST3:

TEST3 is the actual signal that is now phase rotated to select only the I signal while rejecting the Q one.

All the updates to the model, the screens and the script have been SVNed.

TL;DR: When the laser has good lock, the OLTF moves up and the UGF moves over!

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

Figured out with Paco yesterday that when the laser is locked but kind of weakly (mirrors on the optical table sliiightly out of alignment, for example), we would get a UGF around 5 kHz, but when we had a very strong lock (adjusting the mirrors until the spot was brightest) we would get a UGF around 13-17 kHz. Attached are some plots of us going back and forth (you can kind of tell from the coherence/error that the one with the lower UGF is more weakly locked, too). Error on the plots is propagated using the coherence data (see Bendat and Piersol, Random Data, Table 9.6 for the formula). 

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

Want to take data next week to quantitatively compare optical gain to UGF!

I added UGF servos for the DRMI DoFs, after creating a library block for the servos. I also deleted the FMs before the phase rotation, since we can just do it afterwards in other existing FMs. I've only added the MICH and PRCL buttons to the LSC screen because in the end, I feel like a dropdown is better, but I just wanted to get it running quickly tonight. The LSC model and the UGF block have been committed to the svn. 

We were able to use the PRCL UGF servo successfully, as Jenne was exploring MICH offset space. 

 [Jenne, Diego]

Today we began implementing the UGF Servos. Things we did:

• we updated the LSC model with both DARM and CARM servos, and moved them from after the control system to before it, at the level of the error signal;
• we updated the medm screens; new buttons are located in the main LSC screen;
• we started commissioning the DARM servo, at first using DARM for the lock of the single Y arm, then we moved on to the PRFPMI lock and the usual transition from ALS to Transmission;
• although we had several lock losses during the night, we managed to tweak the parameters of the DARM UGF servo (phases, excitation, gains), which now seems to work sufficiently fine;
• the filters added to the I and Q filter banks are a single lowpass in each, while the only filter in the main servio is a standard integrator;
• we don't have a step response at the moment, but we can say that the settling time of the servo is in the range of 10 seconds;
• we updated the ALSdown.py and ALSwatch.py scripts with a call to a new UGFdown.py script; this script, located in the scripts/PRFPMI folder, takes care of disabling the servos and putting the excitation to zero in case of a lock loss; re-enablement of such things must be done manually;

In eLog 7148 (http://nodus.ligo.caltech.edu:8080/40m/7148), Koji pointed out that the op-amp and SR560 noise values (which I took from specs and then multiplied by the geophone calibration factor to get m/s/rtHz) were waaay too low. My error was an extra multiplication factor in the plotting script.

The other change was recalculating the ADC noise by splitting a signal into two ADC channels and subtracting the time series (then taking the PSD and converting to m/s/rtHz). It compares well to the value I got by terminating the ADC channels, which was the ADC noise line in my last eLog.

Both these changes are included in the below plot:

Both Guralps and the Ranger have been placed in our nice new insulated foam box, complete with packing peanuts, in the corner between the x and y arms. The Guralp breakout box has been reinstalled and everything is plugged in in prepartion for the huddle test. However, we're having some issues with ADC channels, which will be worked out tomorrow (hopefully) so that data can be collected over the weekend.

Currently, one Guralp is plugged into the three SEIS-MC1 channels. We made new channels for the second Guralp (GUR-EW, GUR-NS, and GUR-VERT), but had issues with those. So, EW and NS have been plugged into PEM_AUDIO-MIC1 and MIC2 for the time being.

 I found that several of the cables are unlabeled so I'm not sure what's plugged in. In the end, I found that the TEMP_2, _3, & _44 channels were working and so I plugged in anything that looked seismic into there.

TEMP_2 is now apparently the X channel of the 2nd Guralp. If someone can figure out which cable belongs to the Y channel, please plug it into TEMP_3 and then we can fix the channel names.

I also removed (gently) all of the accelerometers from MC2's chamber. This didn't break the lock, but I intentionally broke it to make sure it reacquired fine. It did and the MC TRANS QPD showed no significant shift afterwards.

EDIT: After discussing with Koji and checking the existing M2ISS PDs I put the two C30642G back and took two C30665GH (active diameter: 3mm) diodes. Only one of this type remains in storage.

I removed two C30642G photodiodes from the stash for the new M2ISS hardware and updated the wiki page accordingly.

I spent some time this afternoon reviving some of my CESAR/ESCOBAR shenanigans on the Y arm. I found it neccesary to adjust a few things.

• PMC realigned 
• ETMY oplev centered
• Y End green realigned
• PSL/Y Green beat realigned

Afterwards, ALSY noise levels were good. 

The PMC trans power was a little low (0.77V or so).  I tweaked up the input pointing and now we're getting about 0.875V transmitted.

This past Friday I swapped out a burnt resistor on the spare STACIS unit I'm working with and powered it up. Here's the setup:

And here's what happened:

X an Y directions: When I switched from open to closed loop (making the internal geophones provide feedback), the STACIS started making a loud noise- it seemed like it was oscillating uncontrollably.

Z direction: The same thing happened in z until I added some weight to the top of the STACIS- then it quieted down, and seemed to work okay. The geophone signal dropped considerably compared to the open loop signal, which is expected if the feedback is working.

Then I tried driving the PZTs with a signal from the SR785 network analyzer. With an amplitude of tens of mV and frequencies from around .1 to 200 Hz, I could see the accelerometers I mounted on top of the STACIS definitely register motion, which means I was successfully driving the PZTs.

Below are transfer functions of the STACIS as I drove the PZTs from .1 to 100 Hz at 10 mV. The top graph is open loop, the second is closed loop. These were measured with the internal geophones.

In the bottom graph, "A" is closed loop and "B" is open loop, where the transfer functions were taken with the accelerometers instead of the geophones.

80 degrees is too uncomfortable in the control room so I turned on the AC. The set point is 74F.

I realized that for more phase margin, rana added 6:3lead filter on WFS PIT loops. Since we have increased the UGF on YAW loops too, I turned these on the YAW loops as well. The loops remain stable unlike with the previous matrix. Attachment 1 is the repeat of teh emasurement done by rana earlier but with the new matrix and updated gains in PIT loops. The dark green traces are the references from last measurment with higher gain and HEPA off. The remainging colored traces were measured today.

 Listening to the free swinging Y-arm, its clear that the fringe velocity is higher with the MCL path off, than on. I checked that the default gain of -300 was too high and changed it to -100 in the mcup script. With the higher gain value, there was clear gain peaking at just under 60 Hz (where the 60 Hz comb filter starts). We basically want the UGF to be between 20 and 60 Hz so that we can have the Bounce mode RG at 16.25 Hz and also the notch filter at 60 Hz.

Den is measuring and setting the UGF to be ~45 Hz.

With the MCL path on there is a high frequency horn-like noise in the Yarm when it locks. Its reduced a little by reducing the loop gain, but clearly this is just noise introduced by the MCL loop as Den noted before (and also tonight). He is cleaning up the whole MCL MEDM situation so that its useable by us. At the moment I've re-enabled it in the mcup.

My belief is that the frequency noise from the unstabilized MC is making the PRC locking harder. This will be investigated by tuning the shape of the MCL/MCF crossover so that we can turn it on without ruining the arm cavity spectra. Since the PRC length is ~2x smaller than the MC, we would expect it to be less sensitive to the MC frequency noise. But, since there is some common mode rejection in there, this may not be true. We'll only know by measuring PRC control signal with MCL on/off.

 I think if we make MCL UGF higher then 20 Hz, arm cavity spectra will feel it. It might be possible to use a combination of feedback and feedforward control from ground seismometers. I made MCL UGF at 3 Hz to reduce 1 Hz motion of the pendulum; feedforward OAF subtracted the stack at 3.3 Hz. Once OAF converged, I blocked adaptation and the filter became static FIR. MC length RMS was reduced by a factor of 10 and arm cavity spectra was not affected at frequencies >20 and became better at low frequencies. We'll see if this enough.

On the attached plot red color shows MC_F with MC_L OFF, blue - MC_L is ON, green - MC_L and OAF are ON.

Then I locked PRCL (using AS_Q and REFL55_I) to carrier and aligned the cavity. Power RIN was 50-70% and 00 beam on the POP camera was moving significantly. BS oplev was shaking the optics at 5 Hz. I fixed it, but there should be something else as RIN was still high.

After the results of the analysis in the #8598 thread, I have added the "no_zero_pad=1" flag to the cdsParameters block of all SUS models:

• c1mcs
• c1sus
• c1scx
• c1scy

The upsampling to the 64 kHz DAC output will now be done with sample-holds, instead of zero-pads.  This should reduce the 32 kHz lines we were noticing in the analog DAC output.

I note, though, that Brian Lantz points out that this might actually introduce a delay of about a half sample.  We will continue to investigate.

In any event, I have rebuilt and installed all models listed above.  I will restart as soon as opportunity allows.

I have restarted all the suspension models with the new no_zero_pad flag for the DAC upsampling.  Everything came up fine and all optics are damped as expected (except for concerns about c1scy which I'll note in a followup).

[Jenne, Den]

We have discovered that the MCL loop squishes the length fluctuations that result from the MC spot measurement angular dither.  This is good, in that the MCL is doing what it ought to do.  However, we need to turn it off before doing a spot measurement.

 This is totally non-sensical statement, of course.

We might also say that the DARM loop totally squishes the GW signal and so its better not to have any feedback in the interferometer.

 Hmmm, indeed.  To keep MC_L on, we should be looking at the control signal rather than the error signal.  I think Den has MC_L running nicely such that it always comes on when the MC locks, so I can switch it.

I am tuning the notch filters for the bounce modes in the suspensions, starting with the ITMs and ETMs.  I'll do the MCs, the PRMs, and the SRMs next.

I noticed that the filter for ITMX (in the file C1SUS.txt, the module ITMX_SUSPOS, the selection BounceRoll) that the filter was composed of two bandstops (and a constant gain).  It looked like this:

ellip("BandStop",4,1,40,11.4,12.2)ellip("BandStop",4,1,40,16.7,17.5)gain(1.25872)

Valera said that one of these was for the roll mode and the other for the bounce mode.  However, looking at the spectra that Kiwamu and I made this week, I don't perceive a resonance between 11.4 and 12.2 Hz.  So, we're taking a guess that this was for a mode that has moved due to new pendulum designs.  For many of the suspensions, in the free swinging test we noticed a line around 23 Hz; we thought we might as well re-use one of these elliptical filters to avoid exciting this line.  Of course, if this line does *not* result from excitation of an uncontrolled degree of freedom, this will not help and could be detrimental.  When we talk to Valera again, we can review this decision and at that point we might decide just to take out that bandstop.

ITMX is done.  I'll continue tomorrow.  I've attached closed-loop spectra for before the tuning (itmx-before.pdf) and after (itmx-after.pdf).

(Update: the following day, I took closed loop spectra with (itmx-withbounceroll.pdf) and without (itmx-nobounceroll.pdf) the bandstops.  It looks like the bandstops made the bounce mode slightly worse, but the roll mode slightly better.)

[Rana, Jamie, Ayaka]

We could not lock the arms with MC_L loop on. Therefore we measured the change in YARM error signal when the MC_L is turned on.

(data; POYerr_MCF.xml in zip file)

Green line; POY error signal when MCL loop was on and the YARM loop gain (0.5) was so high that the saturated control signal made funny peak around 250 Hz.
Blue line; POY error signal when MCL loop was off and the YARM loop gain was low (0.2).
Pink line; POY error signal when MCL loop was on (the gain was -300) and the YARM loop gain was low (0.2).
Red line; POY error signal when MCL loop was on, another low pass filter (2nd order, cut off frequency of 55Hz) was added to MCL loop and the YARM loop gain was low (0.2).

We also changed the filter trigger in order to lock YARM. The FM7 and 8 trigger was turned off. It means that spectrum above was took with FM2,3,4,5,6,9,10 on. Whitening filters were also on.

MCL control signal makes the arm spectrum bad because the MCL control signal moves MC2 mirror additionally and adds extra frequency noise.
Ideally, error signal should be the same at higher frequencies and go down at the lower frequencies when the MCL loop is on because MCL signal should suppress the seismic noise.

Before we added the LPF, MCF/MCL loop cross over (which was taken with the template /users/Templates/MC/MCL-MCF_xover-2012-8-23.xml) is below;

(MCL-MCF_xover.xml in zip file)

After the LPF is added, the cross over has been changed as below;

(MCL-MCF_xover2.xml in zip file)

For now, I will just turn off the MCL loop for the acoustic noise experiments.

[Koji, Manasa]

We looked at the MC modulation frequency on the spectrum analyzer and observed beat notes between MC modulation freq (29.5MHz) and modulation frequencies (11.06 MHz and 55.3MHz).

Beat notes were suppressed by changing the carrier frequency from 11.065910 MHz to 11.066147MHz. 

Detailed discussion and data will be posted in the next elog.

I'm still waiting for the follow-up analysis of the modulation freq tuning.

The goal was to tune the carrier modulation frequency, f₁ ~ 11.06 MHz to match the FSR  (c/2L) of the MC. (Reference to the technique: R.G.DeVoe et al., PRA 30, 5, Nov 1984)

We looked at the MC_REFL output on the spectrum analyzer. Since the MC FSR was not well matched with the carrier modulation frequency, we observed significant beat notes at the following frequencies (f_MC-f₁),  (f_MC+f₁), (f_MC-f₂) and (f_MC+f₂); where f_MC (the MC modulation frequency) = 29.5MHz, f₁(carrier modulation frequency) ~ 11.06MHz and f₂ ~ 55.3MHz. The carrier modulation frequency was changed at the frequency generator until these beat notes were suppressed i.e. until the cavity FSR matched the carrier modulation frequency.

The plot below shows the MC spectrum after the beat notes were suppressed.

  Please attach the data file of the measurement - its hard to get the real information out of picture. In general, WE should always include the code / explanation of how to reconstruct the plot and get the scientific information out.

Please add the discussions on the cavity absolute length (and its change, adjustment precision),
identification of the peaks, before/after comparison of the plot, the effect of the MC REFL PD response,
and comparison of the cavity linewidth vs deviation of the 55MHz SBs from the resonance.

I tuned the ITMY bandstops -- 'before' and 'after' spectra attached.  Note that the after the tuning, the bounce mode at ~16 Hz is about twice as quiet!

However, notice that in the 'before' plot the roll mode at about 23.5 Hz did not show up at all, whereas it is quite prominent in the 'after' plot.  I was concerned that this line could have been a result of placing the bandstop there, so I made another plot with the BounceRoll filter turned off.  Sure enough, the 23.5 Hz line is still there.  So I'm not crazy: the roll mode did start acting up at some time between my 'before' and 'after' plot, but not as a result of the tuning.

I tuned the bounce and roll mode bandstops for ETMY, although it was difficult for me to tell if there was improvement with the bandstops on relative to the bandstops off because it seemed like the bounce and roll modes were being excited intermittently.  I'll take spectra with the filters both on and off during an evening next week.

 Today I noticed that there was a lot of noise at the Bounce and Roll eigenfrequencies for ETMY. I found that the bandstop filter were set at completely the wrong frequencies, so I've remade them.

The filters were last tuned by Leo in May of 2011. Even so, he left the frequencies at the frequencies of the old MOS suspensions which had f_bounce ~ 12 Hz.

 The FOTON plot shows the OLD ones versus the NEW ones. The DTT spectra shows the oplev error signals in the usual state. I have also copied these over to the SUSPOS,PIT,YAW, and SIDE filter banks and turned them all ON.

I also turned OFF and deleted the 3 Hz RG filter that was there. There's no such peak in the error signal and even if one wanted to compensate for the stack mode, it should be a low Q filter, not this monster.

I have uploaded all the new settings mentioned in 16066 and 16072. The settings were uploaded through a single script present at anchal/20210428_IMC_Tuned_Suspension/uploadNewConfigIMC.py. The settings can be reverted back to old settings through anchal/20210428_IMC_Tuned_Suspension/restoreOldConfigIMC.py. Both these scripts can be run only through python3 in donatella or allegra.

GPSTIME of new settings: 1303690144

New settings include:

• New input matrices for MC1 and MC2.
• New Output coil gains for AC balancing on all three optics.
• Switching ON the FM8 filter modulae (Q=3 F2A filter) in POS column on output matrix of all optics.

We'll wait and watch the performance through summary pages and check back the performance on Monday.

To test if our method is working at all, we went for the simpler case of just uncoupling PIT and YAW. This is also because the sensor used for these two degrees of freedom is similar (the MC Trans WFS).

We saw a successful decrease in cross-coupling between PIT and YAW over the first 50 iterations that we tried. Here are some results:

Final output matrix:

Plots:

• Attachment 1 shows distance of sensing matrix from identity as iterations go.
• Attachment 2 shows the off-diagonal elements of sensing matrix as the iterations increase.
  • It is worth noting that PIT -> YAW coupling was the main element that was reduced successfully while the YAW -> PIT was reducing but much more slowly.
  • Most of the remaining cross coupling in the end was from YAW -> PIT.
• Attachment 3 shows first 10 oscillations in the time series data during excitation of some of the iterations.
• Attachment 4 shows the cross spectral density of the sensed data during excitation with each other. This has been normalized by reference PSD data (taken with no excitation) of the sensed DOFs involved in the CSD calculation.
• Attachment 5 shows the TF estimate made by normalizing CSD data column wise by the diagonal elements. The excitation frequency point in these plots become the Sensing matrix in the calculation.
  • One can notice how the PIT -> YAW element is going down in these plots.
  • Even though we are using only the real value of the sensing matrix, the imaginary values are also going down.

Next, tried uncoupling POS and PIT:

• Next, we tried to uncouple POS and PIT. We expect them to be more coupled than with YAW.
• At the time of writing this post, 15 iterations of this attempt have been completed and it is not looking good .
• The distance of the sensing matrix from identity is growing at an accelerated rate.
• The POS output matrix column seems to be trying to go towards the negative of PIT output matrix column! Why? We don't know.
• We have seen in the past that once POS transforms into PIT or YAW, it just makes the output matrix worse as no feedback actually goes into the POS column. Eventually, the IMC will cease to remain locked.
• So, I'm cancelling this attempt for now. Will consider more alternatives later.

Alex, Joe:

We copied the latest x02 to c1x02 and modified to our the config block in it.

We removed gds_node_id.  We just have one number now, the dcuid, which is unique for each controller, simulated plant and IOP.  Set site to C1 and host to c1sus.

Alex made the latest awgtpman backwards compatible, and checked that into svn.

We installed the latest framecpp onto c1sus from www.ldas-sc.ligo.caltech.edu/packages/ using wget.

wget www.ldas-sc.ligo.caltech.edu/packages/framecpp-1.18 and then used make.

This let us compile diagd on c1sus, using the command make stand in the /advLigoRTS/build area.

We copied gds from the seiteststand over at handford and are trying to build that on megatron.  However, there's a bunch of packages we need for it to install properly.  Alex said he'd work on that later, possibly trying to make some portable binaries.

Checked out the latest dataviewer into /opt/rtcds/caltech/c1/core/daq, however its not quite working yet either.  This is another thing Alex said he'll work on later.

We are also going to test Alex and Rolf's kernel patch over on c1iscex on Centos base kernel (apparently they've been using Gentoo up at hanford for the test stands...) and see how that works.

This is a continuation from last night, where Peter, Koji, and I were trying to get test point channels working on megatron and with the TST module.

Things we noticed last night:

We could run starttst, and ./daqd -c daqdrc, which allowed us to get some channels in dataviewer.  The default 1k channel selection works, but none of the testpoints do. 

However, awgtpman -s tst does appear in the processes running list.

The error we get from dataviewer is:

Server error 861: unable to create thread
Server error 23328: unknown error
datasrv: DataWriteRealtime failed: daq_send: Illegal seek

Going to DTT, it starts with no errors in this configuration.  Initially it listed both MDC and TST channels.  However, as a test, I moved the tpchn_C4.par , tpchn_M4.par and tpchn_M5.par files to the directory backup, in /cvs/cds/caltech/target/gds/param.  This caused only the TST channels to show up (which is what we want when not running the mdc module.

We had changed the daqdrc file in /cvs/cds/caltech/target/fb, several times to get to this state.  According to the directions in the RCG manual written by Rolf, we're supposed to "set cit_40m=1" in the daqdrc file, but it was commented out.  However, when we uncommented it, it started causing errors on dtt startup, so we put it back.  We also tried adding lines:

set dcu_rate 13 = 16384;
set dcu_rate 14 = 16384;

But this didn't seem to help.  The reason we did this is we noticed dcuid = 13 and dcuid = 14 in the /cvs/cds/caltech/target/gds/param/tpchn_C1.par file.  We also edited the testpoint.par file so that it correctly corresponded to the tst module, and not the mdc and mdp modules.  We basically set:

[C-node1]
hostname=192.168.1.2
system=tst

in that file, and commented everything else out.

At this point, given all the things we've changed, I'm going to try a rebuild of the tst and daq and see if that solves things.

I had a chat with Alex this morning and discovered that the dcu_ids 13,14,15,16 are reserved currently, and should not be used.  I was told 9-12 and 17-26 were fine to use.  I pointed out that we will eventually have more modules than that.  His response was he is currently working on the framebuilder code and "modernizing" it, and that those restrictions will hopefully be lifted in the future although he isn't certain at this time what the real maximum gds_id number is (he was only willing to vouch for up to 26 - although the OMC seems to be currently working and set to 30).

Alex also suggested running an iop module to provide timing (since we are using adcSlave=1 option in the models).  Apparently these are x00.mdl, x01.mdl, x11.mdl files in the /home/control/cds/advLigoRTS/src/epics/simLink/ directory.  I saved x00.mdl as io1.mdl (I didn't want to use io0 as its a pain to differentiate between a zero and 'O'.  This new IOP is using gds_node=1, dcu_id=9.  I modified the approriate files to include it.

I modified /etc/rc.d/rc.local and added io1 to shmem line.  I modified /cvs/cds/caltech/target/fb/daqdrc to use dcu_id 9 as the controller (this is the new iop model dcu_id number).  In that same directory I modifed the file master by adding /cvs/cds/caltech/chans/daq/C1IO1.ini as well as uncommenting tpchn_C1 line.  I modified testpoint.par in /cvs/cds/caltech/target/gds/param to include C-node0, and modified the prognum for lsc and lsp to 0x31001003 and 0x31001005.

So I started the 3 processes with startio1, startlsc, startlsp, then went to the fb directory and started the framebuilder.  However, the model lsc.mdl is still having issues, although lsp and io1 seem to be working.  At this point I just need to track down what fundamentally is different between lsc and lsp and correct it in the lsc model.  I'm hoping its not related to the fact that we actually had a previous lsc front end and there's some legacy stuff getting in the way.  One thing I can test is changing the name and see if that runs.

I modified the dhcpd.conf file in /etc/dhcp on the fb machine.  I added a entry for c1ioo, listing its MAC address and ip number near the bottom of the file.  I then restarted the dhcp server using "sudo /etc/init.d/dhcpd restart" while on the fb machine.

I also modified the rtsystab, which is used to determine which front end codes start on boot up of a machine.  I added a line: c1ioo   c1x03  c1ioo

I am now in the process of getting c1ioo to come up as a Gentoo machine so I can build a model with an RFM connection in it and test the communication between c1sus and c1ioo.  This involves removing the hard drives and checking to make sure the boot priority is correct (i.e. it checks for a network boot).

I tried to lock the Y/X arms to take some noise budget. However, we noticed that TRX/Y were oscillating coherently together (by tens of percent), meaning some input optics, essentially PR2/3 are swinging. There was no way I could do noise budgeting in this situation.

I set out to debug these optics. First, I notice side motion of PR2 is very weakly damped .

The gain of the side damping loop (C1:SUS-PR2_SUSSIDE_GAIN) was increased from 10 to 150 which seem to have fixed the issue. Attachment 1 shows the current step response of  the PR2 DOFs. The residual Qs look good but there is still some cross-couplings, especially when kicking POS. Need to do some balancing there.

PR3 fixing was less successful in the beginning. I increased the following gains:

C1:SUS-PR3_SUSPOS_GAIN: 0.5 -> 30

C1:SUS-PR3_SUSPIT_GAIN: 3 -> 30

C1:SUS-PR3_SUSYAW_GAIN: 1 -> 30

C1:SUS-PR3_SUSSIDE_GAIN: 10 -> 50

But the residual Q was still > 10. Then I checked the input matrix and noticed that UL->PIT is -0.18 while UR->PIT is 0.39. I changed UL->PIT (C1:SUS-PR3_INMATRIX_2_1) to +0.18. Now the Q became 7. I continue optimizing the gains.

Was able to increase C1:SUS-PR3_SUSSIDE_GAIN: 50 -> 100.

Attachment 2 shows the step response of PR3. The change of the entry of the input matrix was very ad-hoc, it would probably be good to run a systematic tuning. I have to leave now, but the IFO is in a very misaligned state. PR3/2 should be moved to bring it back.

The JetStor RAID unit that we had been using for frame writing before the fb meltdown has some archived frames from DRFPMI locks that I want to get at. I spent some time today trying to mount it on optimus with no success

The unit was connected to fb via a SCSI cable to a SCSI-to-PCI card inside of fb. I moved the card to optimus, and attached the cable. However, no mountable device corresponding to the RAID seems to show up anywhere.

The RAID unit can tell that it's hooked up to a computer, because when optimus restarts, the RAID event log says "Host Channel 0 - SCSI Bus Reset."

The computer is able to get some sort of signals from the RAID unit, because when I change the SCSI ID, the syslog will say 'detected non-optimal RAID status'.

The PCI card is ID'd fine in lspci as "06:01.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev c1)"

'lsssci' does not list anything related to the unit

Using 'mpt-status -p', which is somehow associated with this kind of thing returns the disheartening output:

I spent some time trying to debug our inability to get MICH onto REFL165Q while the arms are held off with ALS, to no real success. 

I set up our usual repeatable situation of PRMI on 33 I&Q, arms held off with ALS. I figured that it may help to first sideband lock on REFL55, since 165 is looking for the f2 sidebands and maybe there is some odd offset between the locking points for f1 and f2 or other weirdness. 

REFL 55 settings:

Demod angle 98->126 (was previously set for PRY locking)

PRCL = 0.5 * REFL55 I (UGF of ~200 Hz) (FM gain unchanged from REFL33 situation of -0.02)

MICH = 0.125 * REFL55 Q (UGF of ~60Hz) (same FM gain as 33)

Some REFL55 offset adjusting had to be done in order to not disturb the 33-initiated lock when handing off. 

I also adjusted POP110 phase to zero the Q when locked, and switched the triggering over to 110I

The PRMI can acquire lock like this with arms held off with ALS, no problem. 

Here, I tried to hop over to 165. PRCL was no problem, needing a +1 on 165I. However, I had no success in handing off MICH.   I twiddled many knobs, but none that provably helped. 

I saw indications that the sensing angle in 165 is small (~20deg), which is not consistent with current knowledge of the cavity lengths. We last interferometrically measured the PRC length by letting the PRMI swing and looking at sideband splitting in POP110. At LLO, they did a length measurement by looking at demod angle differences in PRMI carrier vs. sideband locking. (alog8562) This might be worth checking out...

Short report: Further frustrated by 165 tonight. The weird thing is, the procedure I'm trying with the arms held off on ALS (i.e. excitation line in MICH and PRCL, adjust relative gains to make the signs and magnitudes mach, ezcastep over) works flawlessly with the ETMs misaligned. One can even acquire SB PRMI lock on 165 I&Q, with 80-90 degrees of demod angle between MICH and PRCL. The only real difference in REFL55 settings for misaligned vs. ALS-offset arms is an extra factor of two in the FM gains to maintain the same UGF, so I hoped that the matrix elements for 165 with misaligned arms would hold for ALS-offset arms. 

Alas, no such fortune. I still have no clear explanation for why we can't get MICH on 165Q with the arms held off on ALS. 

I also gave a quick try to measuring the PRCL->REFL55 demod phase difference between carrier and sideband lock (with arms misaligned), and got something on the order of 55 degrees, which really just makes me think I wasn't well set up / aligned, rather than actually conveying information about the PRC length...

So unfortunately, I made the start-elog-nodus script smart enough to kill the debugging run I had (although thats probably good since there might have been issues with continuing to run - just poor timing on part of the crash).

In related news, I have gotten the latest version of the elog code to actually compile on Nodus.  I had to hack the cryptic.c file (elog/src/cryptic.c) to get it to work though.

The following was copied from the #ifdef _MSC_VER section of the code into the #else directly following that section. 

#define MAX(x,y) ((x)>(y)?(x):(y))
#define MIN(x,y) ((x)<(y)?(x):(y))
#define __alignof__(x) sizeof(x)
#define alloca(x) malloc(x)
#define mempcpy(d, s, n) ((char *)memcpy(d,s,n)+n)
#define ERANGE 34

I also removed #include <stdint.h> as the functionality it provides is covered by inttypes.h on Solaris machines, which is automatically included.

This new code was released August 5th 2010, while the old elog code we were running was 2.7.5 and was released sometime in 2008.  There are several crash fixes mentioned in the version notes so I'm hoping this may improve stability. I'm in the process of making a copy of the elog logbooks into the elog-2.8.0 install (so as to have a backup with the original 2.7.5).  I'm also copying over all the configuration files.   In a few minutes I'm going to try switching over to the new elog.  If it doesn't work, or is worse, its easy enough to just start up the current version.

All files are located in /cvs/cds/caltech/elog/elog-2.8.0 (the old directory is elog-2.7.5).  I've made  a new startup script called start-elog-nodus-2.8.0.  To start the new one, just run that script.  To start the old one, just go to the elog-2.7.5 directory and run the old start-elog-nodus script.

We resume the LO phase locking work. MICH was locked with an offset of 80 cts. LO and AS beams were aligned to maximize the BHD readout visibility on ndscope.

We lock the LO phase on a fringe (DC locking) actuating on LO1.

Attachment 1 shows BHD readout (DCPD_A_ERR = DCPD_A - DCPD_B) spectrum with and without fringe locking while LO2 line at 318 Hz is on. It can be seen that without the fringe locking the dithering line is buried in the A-B noise floor. This is probably due to multiple fringing upconversion. We figured that trying to directly dither-lock the LO phase might be too tricky since we cannot resolve the dither line when the LO phase is unlocked.

We try to handoff the lock from the fringe lock to the AC lock in the following way: Since the AC error signal reads the derivative of the BHD readout it is the least sensitive to the LO phase when the LO phase is locked on a dark fringe, therefore we offset the LO to realize an AC error signal. LO phase offset is set to ~ 40 cts (peak-to-peak counts when LO phase is uncontrolled is ~ 400 cts).

We look at the "demodulated" signal of LO1 from which the fringe locking error signal is derived (0 Hz frequency modulation 0  amplitude) and the demodulated signal of LO2 where a ~ 700 Hz line is applied. We dither the LO phase at ~ 50Hz to create a clear signal in order to compare the two error signals. Although the 50 Hz signal was clearly seen on the fringe lock error signal it was completely unresolved in the LO2 demodulated signal no matter how hard we drove the 700Hz line and no matter what demodulation phase we chose. Interestingly, changing the demodulation phase shifted the noisy LO2 demodulated signal by some constant. Will post a picture later.

Could there be some problem with the modulation-demodulation model? We should check again but I'm almost certain we saw the 700Hz line with an SNR of ~ 100 in diaggui, even with the small LO offset changes in the 700Hz signal phase should have been clearly seen in the demodulated signal. Maybe we should also check that we see the 50Hz side-bands around the 700Hz line on diaggui to be sure.