40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 240 of 337  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  10649   Wed Oct 29 03:33:38 2014 ericqUpdateLSCTrying to PRMI on 165

 

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

  13227   Thu Aug 17 22:54:49 2017 ericqUpdateComputersTrying to access JetStor RAID files

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 crying

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:

Checking for SCSI ID:0
Checking for SCSI ID:1
Checking for SCSI ID:2
Checking for SCSI ID:3
Checking for SCSI ID:4
Checking for SCSI ID:5
Checking for SCSI ID:6
Checking for SCSI ID:7
Checking for SCSI ID:8
Checking for SCSI ID:9
Checking for SCSI ID:10
Checking for SCSI ID:11
Checking for SCSI ID:12
Checking for SCSI ID:13
Checking for SCSI ID:14
Checking for SCSI ID:15
Nothing found, contact the author
 
I don't know what to try at this point.
  3644   Mon Oct 4 15:28:10 2010 josephbUpdateCDSTrying to get c1ioo booting as Gentoo.

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

  2927   Thu May 13 15:19:44 2010 josephbUpdateCDSTrying to get lsc.mdl and lsp.mdl working

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.

 

  2299   Thu Nov 19 09:55:41 2009 josephbUpdateComputersTrying to get testpoints on megatron

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.

 

  3507   Wed Sep 1 12:24:47 2010 josephbUpdateCDSTrying to get up to date CDS code runnning

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.

  16005   Wed Apr 7 17:38:51 2021 AnchalUpdateSUSTrying to uncouple only PIT and YAW first

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:

Output matrix for uncoupling PIT and YAW from eachother
PIT YAW COILS
1.01858 1.16820 UL
0.98107 -0.79706 UR
-0.98107 0.79706 LL
-1.01858 -1.16820 LR

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 sad.
  • 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.
  1426   Wed Mar 25 04:18:28 2009 YoichiUpdateLockingTuesday Locking
After the new PO_DC PD was installed, I tweaked several gains to make the locking scripts work right.
First of all, I increased the gain of PD12 (PD12_I is SPOB) by a factor of 1.4 to compensate for the power decrease
by the insertion of the BS. SPOB is used by the PRM alignment script. I was too lazy to modify the scripts.

Then I optimized the SRC DD signal which is taken from the POB.

I also had to do some gain adjustments for the CARM loop.

The attachment (AO path open loop TF) shows a depressing fact that the 3.8kHz peak is still there with the new PO_DC PD. So it was not a problem of the SPOB PD.
Next, I will check the cross over frequencies of the PZT and PC paths in the FSS and the VCO/MCL cross over.
  568   Wed Jun 25 13:56:56 2008 JohnSummaryLockingTuesday night locking
Rob, John

Worked to try and reduce the CARM offset using the dc arm transmissions before changing to SPOB DC. This proved somewhat unsuccessful, the offset couldn't be reduced to more than five (arms storing 5x more power than single arm cavity lock).
  16091   Wed Apr 28 17:09:11 2021 AnchalUpdateSUSTuned Suspension Parameters uploaded for long term behavior monitoring

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.

  4713   Fri May 13 17:20:48 2011 Leo SingerConfigurationSUSTuned bounce and roll mode of ETMY suspension

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.

  9150   Sun Sep 22 21:03:15 2013 ranaConfigurationSUSTuned bounce and roll mode of ETMY suspension

 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.

  4652   Fri May 6 14:59:36 2011 Leo SingerConfigurationSUSTuning ITMY bandstop

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.

  8288   Wed Mar 13 16:25:16 2013 ManasaUpdateIOOTuning MC length/FSR

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

  8349   Tue Mar 26 01:40:49 2013 KojiUpdateIOOTuning MC length/FSR

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

  8353   Tue Mar 26 15:00:55 2013 ManasaUpdateIOOTuning MC length/FSR

Quote:

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

The goal was to tune the carrier modulation frequency, f1 ~ 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 (fMC-f1),  (fMC+f1), (fMC-f2) and (fMC+f2); where fMC (the MC modulation frequency) = 29.5MHz, f1(carrier modulation frequency) ~ 11.06MHz and f2 ~ 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.

MC_spectrum.png

  8354   Tue Mar 26 15:43:45 2013 ranaUpdateIOOTuning MC length/FSR

  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.

  8357   Tue Mar 26 17:27:17 2013 KojiUpdateIOOTuning MC length/FSR

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.

  7748   Mon Nov 26 23:45:52 2012 AyakaUpdateIOOTuning MC_L

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

POYerr_MCL.jpg

(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-MCFxover.jpg

(MCL-MCF_xover.xml in zip file)

After the LPF is added, the cross over has been changed as below;
MCL-MCFxover2.jpg

(MCL-MCF_xover2.xml in zip file)

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

  4646   Thu May 5 17:19:21 2011 Leo SingerConfigurationSUSTuning notch filters for bounce mode suspensions

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

 

 

  7709   Tue Nov 13 22:12:15 2012 JenneUpdateIOOTurn off MCL path before doing MC spot measurement

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

  7711   Wed Nov 14 09:01:42 2012 Dumb statement catcherUpdateIOOTurn off MCL path before doing MC spot measurement

Quote:

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.

  7712   Wed Nov 14 13:58:18 2012 JenneUpdateIOOTurn off MCL path before doing MC spot measurement

Quote:

Quote:

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.

  8617   Wed May 22 15:48:56 2013 JamieUpdateSUSTurn off zero padding in DAC outputs

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.

  8625   Thu May 23 10:20:33 2013 JamieUpdateSUSTurn off zero padding in DAC outputs

Quote:

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

  8426   Tue Apr 9 00:32:39 2013 ranaConfigurationIOOTurn on MCL

 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.

  8434   Wed Apr 10 03:59:41 2013 DenConfigurationIOOTurn on MCL

Quote:

 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.

  4209   Wed Jan 26 14:49:48 2011 AidanUpdateEnvironmentTurned on Control room AC

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

  6905   Mon Jul 2 23:08:38 2012 YaakovUpdateSTACISTurning on STACIS

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:

stacy1.JPG

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.

geo_open.GIF

 

 geo_closed.GIF

SCRN0005.GIF

  4817   Tue Jun 14 16:38:31 2011 JamieUpdatePSLTweaked input pointing to PMC

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.

  12213   Thu Jun 23 17:24:32 2016 ericqUpdateGeneralTweaks

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. 

  14170   Mon Aug 20 14:04:53 2018 johannesBureaucracyEquipment loanTwo C30642G PDs removed

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.

  1866   Fri Aug 7 20:43:35 2009 Clara, Jenne, Rana, JanUpdatePEMTwo Guralps plugged in, prepped for huddle test

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.

  1868   Sat Aug 8 17:19:07 2009 ranaUpdatePEMTwo Guralps plugged in, prepped for huddle test

 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.

  482   Fri May 16 14:38:50 2008 josephbSummaryCamerasTwo cameras setup
I've changed the pickoff setup from yesterday for the GigE cameras to include a 33% beam splitter (first one I could find). The reflection is going to the GC650 (CCD camera) while the transimission is going to the GC750 CMOS camera. This means the CMOS camera has roughly twice the light incident as the GC650 and should be kept in mind in all comparisons. The distances from the beam splitter are approximately the same both cameras, but some more accurate positioning might be useful.

Its very easy to get the GC650 camera into a bad state where you need to go out and cycle the power (simply unplug and re-plug in the power supply either at the camera or outlet). If the ListCamera program doesn't see it, this is probably necessary.

Andrey added at 6.30PM: Actually the 650 camera keeps crashing constantly. Every time I attempt to capture an image, the camera fails.
  7166   Mon Aug 13 21:47:30 2012 YaakovUpdateSTACISTwo changes to STACIS noise budget

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:

noise_budget_8-13.bmpnoise_budget_8-13.fig

  424   Thu Apr 17 20:17:37 2008 AndreyUpdatePEMTwo issues with our weather station

I encountered two difficulties working with the "Weather Station".

(1) It turns out that there is no indication for "outside humidity" on the "weather monitor" (a small black box located on the north wall of the interferometer). I realized that "outside humidity" is absent in our system when I tried to see the Dataviewer trend and real-time value from the channel "C1: PEM-weather-outsideHumid". It shows impossible number 128%.

It follows from the "Davis" technical documentation that the outside sensor can be of two types: either "External Temperature Sensor" or "External Temperature/Humidity Sensor". I suspect (I do not know for sure) that we have the first type of sensor "external temperature only" and therefore we in principle cannot have information about outside humidity. I propose to Steve to climb to the roof on Friday to resolve this uncertainty looking at the sensor.

(2) I wanted to change the units of pressure from "Pascal" (force/area) to other units, "mbar" for example. For this purpose I need to edit the file "Weather.st" in the directory /cvs/cds/caltech/target/c1pem1 (this file is run on the VME processor "c1pem1"). Unfortunately, when I try to open the file with emacs, I get the message that the file exists but protected from modifications. I do not know how to unblock the file "Weather.st". I need some help with that.

I thought that switching-off the processor "c1pem1" could resolve the issue, so I switched-off the whole crate where the processor "c1pem1" is installed for about 5 minutes, turning the metallic key. As it did not make any difference for the accessibility of the file "Weather.st", I switched-on the crate after 5 minutes. There are other processors besides "c1pem1", so they were turned-off for several minutes earlier today.

Also, I created a new MEDM screen which has information about weather only, a smaller version of the "C0Checklist.adl" MEDM screen. Both screens are now located under the most top-left button "Checklist" of the main MEDM screen.
  915   Wed Sep 3 18:43:19 2008 YoichiConfigurationElectronicsTwo more active probes
I found two active probes, an HP41800A and a Tektronix P6201.
Thanks John for telling me you saw them before.
Now we have three active probes, wow !
We have to find or make a power supply for P6201.
The manual of the probe is attached.
  1523   Sun Apr 26 02:13:18 2009 YoichiUpdateLockingTwo more successes of RF CARM handoff
Tonight, the RF CARM hand off (mostly) succeeded twice.
But still, the IFO lost lock when I reduced the REFL_DC gain in the AO path to zero.

At the beginning of tonight's work, MICH DD hand off failed several times. This was because the the PD9 gains were set to zero.
I found that the offset script, which I called before starting the locking, fails to restore the gain values sometimes.
This happens when ezcaread fails to read the current gain. We have to be careful when running the LSCoffsets script.
  501   Wed May 28 12:51:32 2008 josephbConfigurationComputersTwo more switches mounted
Two more Prosafe 24 port switches have been mounted in the racks, one in 1Y9 and one in 1Y6. (The first one was placed in 1X4).

The one in 1Y9 has been set to an IP address of 131.215.113.251, while the one in 1Y6 is set to 131.215.113.252, and these have been labeled as such.
  10861   Wed Jan 7 02:56:15 2015 diegoUpdateLSCUGF Servo for DARM

 [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;
  10875   Thu Jan 8 02:52:09 2015 ericqUpdateLSCUGF Servo for LSC

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. 

  10901   Wed Jan 14 19:27:09 2015 ericqUpdateLSCUGF servo now linear again

The UGF servos have been moved to the control point, are are once again totally linear!

  10902   Thu Jan 15 03:18:11 2015 diegoUpdateLSCUGF servo now linear again

The UGF servos were recommissioned today:

  • suitable values of frequency, excitation, phases and gain were found;
  • the phases were chosen in order to maximize the I signal and suppress the Q one;
  • the servos seemed sufficiently stable when in a quiet state, but they didn't performed well in other cases;
  • I also found out that DARM & CARM and MICH & PRCL are maybe too much coupled, but that could be actually due to the main loops rather than the UGF ones;
  • however, after some weird rampings with no apparent reasons, and after some quite bad and glitchy step responses, I found out that the effect of the chosen phases vanished: the I and Q signals were of the same order of magnitude again, probably causing the bad performance;
  • Jenne and I tried to increase che SINGAINs and COSGAINs (but keeping them equal to each other): this has the good effect of separating more the I and Q signals, but it's just a zoom effect: there still are mixing effects and, more important, some zero-crossings into negative values that cause the signal going into the servo to go crazy.

Our idea is that we need with some thinking about these servos and most of all try to figure out all this phase thing before we can start to trust the servos to be used for locking.

  10911   Fri Jan 16 04:14:05 2015 diegoUpdateLSCUGF servo now linear again

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.

 

  10916   Fri Jan 16 20:37:52 2015 diegoUpdateLSCUGF servo now linear again

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

TEST1 = a + i b\hspace{.5cm},\hspace{.5cm}}TEST2 = c + id

we have that TEST3:

 

TEST3 = \frac{TEST2}{TEST1} = \left(\frac{ac+bd}{a^2+b^2}\right) + \left(\frac{ad-bc}{a^2+b^2} \right)i

 

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.

  5645   Mon Oct 10 16:32:18 2011 steveUpdateSUSUL sensor of ETMY is recovered

 I lost UL osem voltage this morning when I was checking the actual connection at rack ETMY

This after noon I disconnected  the 64 pins IDE connector from satelite amp at the rack, and the two 25 pins Dsubs at this juction board.

UL OSEM recovered after reconnecting these three connectors.

Atm3, bad connection.........noisy UL

 

  2692   Mon Mar 22 02:03:57 2010 ranaSummaryElectronicsUPDH Box #17: Ready

It took too long to get this box ready for action. I implemented all of the changes that I made on the previous one (#1437). In addition, since this one is to be used for phase locking, I also made it have a ~flat transfer function. With the Boost ON, the TF magnitude will go up like 1/f below ~1 kHz.

The main trouble that I had was with the -12V regulator. The output noise level was ~500 nV/rHz, but there was a large oscillation at its output at ~65 kHz. This was showing up in the output noise spectrum of U1 (the first op-amp after the mixer). Since the PSRR of the OP27 is only ~40 dB at such a high frequency, it is not strange to see the power supply noise showing up (the input referred noise of the OP27 is 3.5 nV/rHz, so any PS noise above ~350 nV/rHz becomes relavent).

I was able to tame this by putting a 10 uF tantalum cap on the output of the regulator. However, when I replaced the regulator with a LM7912 from the blue box, it showed an output noise that went up like 1/f below 50 kHz !! I replaced it a couple more times with no benefit. It seems that something on the board must now be damaged. I checked another of the UPDH boxes, and it has the same high frequency oscillation but not so much excess voltage noise. I found that removing the protection diode on the output of the regulator decreased the noise by a factor of ~2. I also tried replacing all of the 1 uF caps that are around the regulator. No luck.

Both of the +12 V regulators seem fine: normal noise levels of ~200 nV/rHz and no oscillations.

Its clear that the regulator is not functioning well and my only guess is that its a layout issue on the board or else there's a busted component somewhere that I can't find. In any case, it seems to be functioning now and can be used for the phase locking and PZT response measurements.

  2693   Mon Mar 22 10:07:30 2010 KojiSummaryElectronicsUPDH Box #17: Ready

For your reference: Voltage noise of LM7815/LM7915 (with no load)

  1763   Mon Jul 20 10:35:06 2009 steveUpdateVACUPS batteries replaced

 APC Smart-UPS (uninterruptible power supply) batteries RBC12 replaced at 1Y8 vacuum rack.

Their life span were 22 months.

ELOG V3.1.3-