40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 139 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  15988   Thu Apr 1 21:13:54 2021 AnchalUpdateSUSMatrix results, new measurement set to trigger
New Input matrix used for MC2 (C1:SUS-MC2_INMATRIX_ii_jj
  UL UR LR LL SIDE
POS 0.2464 0.2591 0.2676 0.2548 -0.1312
PIT 1.7342 0.7594 -2.494 -1.5192 -0.0905
YAW 1.2672 -2.0309 -0.9625 2.3356 -0.2926
SIDE 0.1243 -0.1512 -0.1691 0.1064 0.9962

New output matrix for MC2 (C1:SUS-MC2_TO_COIL_ii_jj_GAIN)
  POS PIT YAW
UL 1 1.022 0.6554
UR 1 0.9776 -1.2532
LL 1 -0.9775 1.2532
LR 1 -1.0219 -0.6554

Measured Sensing Matrix (Cross Coupling) (Sensed DOF x Excited DOF)
  Excited POS Excited PIT Excited YAW
Sensed POS 1 1.9750e-5 -3.5615e-6
Sensed PIT 0 1 -6.93550e-2
Sensed YAW 0 -2.4429e-4 1

A longer measurement is set to trigger at 5:00 tomorrow on April 2nd, 2021. This measurement will run for 35 iterations with an excitation duration of 120s and bandwidth for CSD measurement set to 0.1 Hz. The script is set to trigger in a tmux session named 'cB' on pianosa.

  15993   Fri Apr 2 15:22:54 2021 gautamUpdateSUSMatrix results, new measurement set to trigger

How should I try to understand why PIT and YAW are so different? 

Quote:
New output matrix for MC2 (C1:SUS-MC2_TO_COIL_ii_jj_GAIN)
  POS PIT YAW
UL 1 1.022 0.6554
UR 1 0.9776 -1.2532
LL 1 -0.9775 1.2532
LR 1 -1.0219 -0.6554
  439   Tue Apr 22 22:51:30 2008 ranaConfigurationIOOMcWFS Status
I've been working a little on the MC WFS in the last few days. I have made many
changes to the sensing matrix script and also to the MCWFSanalyze.m script.

The output matrix, as it was, was not bad at low frequencies but was making noise in
the ~1 Hz band. Turning the gain way down made it do good things at DC and not make
things work higher.

The output matrix generating script now works after Rob fixed the XYCOM issue. Not sure
what was up there. As Caryn mentioned the SUS2.ini channels were all zero after Andrey's
PEM power cycle a few days ago. Rob booted c1susvme to get the SUS1 channels back and
today we did c1susvme2 to get the IOO-MC_L et. al. back.

Even after doing the matrix inversion there is some bad stuff in the output matrix. I
checked that the sensing matrix measurement has good coherence and I measured and set the
MC WFS RF phases (they were off by ~20-30 deg.). Still no luck.

My best guess now is that the RG filters I've used for POS damping and the movement of the
beam on the MC mirror faces has made a POS<->YAW instability at low frequencies. My next
move is to revert to velocity damping and see if things get better. Should also try redoing
the A2L on the MC1-3.
  1503   Mon Apr 20 20:00:44 2009 ranaConfigurationIOOMcWFS gains re-allocated
Since it looks like the night time people have been running with a WFS gain of 0.05 and I like the slider
to be at 1.0, I lowered all of the WFS1/2_P/Y gains by 10 and increased the overall slider from 0.05 to 1.0.
So the loop gains are now 2x higher; with it like this I guess the UGFs are in the ~0.2-0.5 Hz range.
  545   Thu Jun 19 15:52:06 2008 AlbertoConfigurationComputersMeasure of the current absorbed by the new Megatron Computer
Together with Rich Abbot, sam Abbot and I measured the current absorbed by the new Megatron computer that we installed yesterday in the 1Y3 rack. The computer alone absorbs 8.1A at the startup and then goes down to 5.9A at regime. The rest of the rack took 5.2A without the computer so the all rack needs 13.3 at the startup and the 11.1A.

We also measured the current for the 1Y6 rack where an other similar Sun machine has been installed as temporary frame builder and we get 6.5A.


Alberto, Rich and Sam Abbot
  13080   Mon Jun 26 09:39:15 2017 NaomiSummaryGeneralMeasure transfer functions of Mini-Circuits filters

I have spent my first few days as a SURF getting experience working with the Network/Spectrum Analyzer (AG 4395A). After an introduction to the 40m by Koji, I was tasked with using the AG4395A to measure the transfer function of several filters (for example, Mini-Circuits Low Pass Filter SLP-30). I am now familiar with configuring the AG 4395A, taking a single set of data using a command from one of the control computers, and plotting the dataset as a Bode plot (separate plots for magnitude and phase) using Python.

To Do:

  • Use AGmeasure to take multiple datasets with a single command.
  • Plot multiple datasets for each filter on a single Bode plot and perform some statistical analysis. 

To experiment with plotting multiple datasets on a single Bode plot, I used a single dataset from the Network Analyzer using the SLP-30 filter and added random noise to create ten datasets to plot. I am attaching the resulting Bode plot, which has the ten generated sets of data plotted along with their average.

We discussed with Rana and Koji how to interpret this type of dataset from the Network Analyzer. Instead of considering the magnitude and phase as separate quantities, we should consider them together as a single complex number in the form H(f) = M exp(iπP/180), where M is the magnitude and P is the phase in degrees. We can then find the average value of the measured quantity in its complex number form (x + iy), as opposed to just taking the average of the magnitude and phase separately.  

  1662   Tue Jun 9 11:29:07 2009 JenneUpdateoplevsMeasured ETMY oplev beam size...put everything back

I measured the ETMY oplev beam size at a couple different distances away from the HeNe by taking out the steering mirror and letting the light propagate a ways.  I put the steering mirror back, aligned the oplev, and was able to relock the Yarm, so I think it's all back as it has been the last couple of weeks.

 

Now I need t o do some geometry and ray-tracing matrices to decide what focal length lens to buy, then we'll have  a shiny new ETMY oplev. 

  2317   Mon Nov 23 21:30:29 2009 JenneUpdateLSCMeasured MC length

With Koji's help, I measured the length of the Mode Cleaner.

The new modulation frequencies (as quoted on the Marconi front panels) are: 

165.980580 MHz

 33.196116 MHz

132.784464 MHz

199.176696 MHz

The Frequency Counter readback is 165980584.101 Hz (a 4Hz difference).  All of the Marconi's front-panel frequencies read ###.##### MHz Ext, and the Frequency standard has it's "locked" light illuminated, and the 1pps input light blinking, so I think everything is still nicely locked to the frequency standard, and the frequency standard is locked to the GPS.

While changing the marconi's, I accidentally touched the MC's 29.5 MHz marconi.  It is set back to the nominal value (according to Kiwamu's rack photos) of 29.485MHz.  But the phase might be sketchy, although hopefully this doesn't matter since we don't do a double demodulation with it.

I also ran the scripts in the wiki page: How To/Diagonalize DRMI Length Control to set the DD Phases.

 

 

  2319   Tue Nov 24 08:00:16 2009 ranaUpdateLSCMeasured MC length

I propose that from now on, we indicate in the elog what frequencies we're referring to. In this case, I guess its the front panel readback and not the frequency counter -- what is the frequency counter readback? And is everything still locked to the 10 MHz from the GPS locked Rubidium clock?

Plus, what FSS Box? The TTFSS servo box? Or the VCO driver? As far as I know, the RC trans PD doesn't go through the FSS boxes, and so its a real change. I guess that a bad contact in the FSS could have made a huge locking offset.

 

  2320   Tue Nov 24 10:36:21 2009 KojiUpdateLSCMeasured MC length

What I meant was the VCO driver, not the FSS box.

As for the frequency, all written numbers were the Marconi displays.
The number on the frequency counter was also recorded, and so will be added to the previous entry shortly... 

Quote:

I propose that from now on, we indicate in the elog what frequencies we're referring to. In this case, I guess its the front panel readback and not the frequency counter -- what is the frequency counter readback? And is everything still locked to the 10 MHz from the GPS locked Rubidium clock?

Plus, what FSS Box? The TTFSS servo box? Or the VCO driver? As far as I know, the RC trans PD doesn't go through the FSS boxes, and so its a real change. I guess that a bad contact in the FSS could have made a huge locking offset.

 

  2325   Wed Nov 25 03:05:15 2009 robUpdateLockingMeasured MC length

Quote:

What I meant was the VCO driver, not the FSS box.

As for the frequency, all written numbers were the Marconi displays.
The number on the frequency counter was also recorded, and so will be added to the previous entry shortly... 

Quote:

I propose that from now on, we indicate in the elog what frequencies we're referring to. In this case, I guess its the front panel readback and not the frequency counter -- what is the frequency counter readback? And is everything still locked to the 10 MHz from the GPS locked Rubidium clock?

Plus, what FSS Box? The TTFSS servo box? Or the VCO driver? As far as I know, the RC trans PD doesn't go through the FSS boxes, and so its a real change. I guess that a bad contact in the FSS could have made a huge locking offset.

 

 

Locking has gone sour.  The CARM to MCL handoff, which is fairly early in the full procedure and usally robust, is failing reliably. 

As soon as the SUS-MC2_MCL gain is reduced, lock is broken.  There appears to be an instability around 10Hz.  Not sure if it's related.

  2333   Wed Nov 25 15:38:08 2009 robUpdateLockingMeasured MC length

Quote:

Quote:

What I meant was the VCO driver, not the FSS box.

As for the frequency, all written numbers were the Marconi displays.
The number on the frequency counter was also recorded, and so will be added to the previous entry shortly... 

Quote:

I propose that from now on, we indicate in the elog what frequencies we're referring to. In this case, I guess its the front panel readback and not the frequency counter -- what is the frequency counter readback? And is everything still locked to the 10 MHz from the GPS locked Rubidium clock?

Plus, what FSS Box? The TTFSS servo box? Or the VCO driver? As far as I know, the RC trans PD doesn't go through the FSS boxes, and so its a real change. I guess that a bad contact in the FSS could have made a huge locking offset.

 

 

Locking has gone sour.  The CARM to MCL handoff, which is fairly early in the full procedure and usally robust, is failing reliably. 

As soon as the SUS-MC2_MCL gain is reduced, lock is broken.  There appears to be an instability around 10Hz.  Not sure if it's related.

 Whatever the locking problem was, the power of magical thinking has forced it to retreat for now.  The IFO is currently locked, having completed the full up script.  One more thing for which to be thankful.

  2332   Wed Nov 25 14:29:08 2009 robUpdateLockingMeasured MC length--FSS trend

Quote:

Quote:

What I meant was the VCO driver, not the FSS box.

As for the frequency, all written numbers were the Marconi displays.
The number on the frequency counter was also recorded, and so will be added to the previous entry shortly... 

Quote:

I propose that from now on, we indicate in the elog what frequencies we're referring to. In this case, I guess its the front panel readback and not the frequency counter -- what is the frequency counter readback? And is everything still locked to the 10 MHz from the GPS locked Rubidium clock?

Plus, what FSS Box? The TTFSS servo box? Or the VCO driver? As far as I know, the RC trans PD doesn't go through the FSS boxes, and so its a real change. I guess that a bad contact in the FSS could have made a huge locking offset.

 

 

Locking has gone sour.  The CARM to MCL handoff, which is fairly early in the full procedure and usally robust, is failing reliably. 

As soon as the SUS-MC2_MCL gain is reduced, lock is broken.  There appears to be an instability around 10Hz.  Not sure if it's related.

 Five day minute trend.  FAST_F doesn't appear to have gone crazy.

  2335   Wed Nov 25 16:13:27 2009 ranaUpdatePSLMeasured MC length--FSS trend

but the increase in both the RCtrans and the RCrefl is consistent with my theory that the power going to the RC has increased ; its not just an increase in the visibility.

We should scan the AOM/VCO to make sure the frequency is matched to the resonance to within 0.5 dB.

  2336   Wed Nov 25 16:44:52 2009 KojiUpdatePSLMeasured MC length--FSS trend

I checked C1:PSL-FSS_VCODETPWR. The attached is the 4 months trend of the FSS RCTRANS / RFPDDC(=FSS REFL) / VCODETPWR / VCOMODLEVEL.

Although VCO modulation level setting was mostly constnt, VCODETPWR, which presumably represents the RF level, changes time by time.
It coincides with the recent reduction of the RCTRANS/RFPDDC. Actually, my touch restored the VCO to the previous more stable state.
One can see that this is not only a single occation, but it happened before too. (In the middle of Aug.)

This could be explained by the bad contact of some cable or connector.

Nevertheless we need more careful investigation:

1. Understand what VCODETPWR is exactly.
2. Investigate relationship between VCOMODLEVEL / VCODETPWR / AOM deflection efficiency / RCTRANSPD
3. Confirm the frequency matching between the VCO and AOM.

Quote:

but the increase in both the RCtrans and the RCrefl is consistent with my theory that the power going to the RC has increased ; its not just an increase in the visibility.

We should scan the AOM/VCO to make sure the frequency is matched to the resonance to within 0.5 dB.

 

  10967   Tue Feb 3 04:07:49 2015 JenneUpdateModern ControlMeasured PRM -> POP QPD TFs

Today (after centering the POP QPD), I measured the PRM to POP QPD transfer functions.  I am suspicious that this was part of my problem last week.  Since most of the angular noise is coming from the folding mirrors, but I can't actuate on them, I need to know (rather, the Wiener calculator needs to know) how actuating on the PRM will affect the spot at the POP QPD.

For the plots below, I have cut out any data points that have coherence less than 0.95. I may want to go back and fill in a little bit some of the areas (particularly around 3Hz) that I had trouble getting coherence in.

Using these to prefilter my witness data, I am failing to calculate a Wiener filter.  I have tried the Levinson algorithm, as well as brute-forcing it, but I'm too close to singular for either to work.  I am able to calculate a set of Wiener filters without the prefiltering, or with a dummy very simple prefilter, so it's not inherently in the calculators.  Separately, I can plot my vectfit-ed actuator TFs, and I can convert them to a discrete fiilter with the bilinear transform, and then use sosfilt to filter some white noise data, which comes out with the shape I expect.  So.  It's not inherently the filters either.  More work to do, when it's not 4am.

Here are the measured actuator transfer functions.  They were measured as usual with DTT, but since the measurement kept getting interrupted (MC unlock, or I wanted to add more integrations or more cycles), these are several different DTT files stitched together.  In both cases I am acuating PRM's ASC[pit, yaw] EXC point, and looking at the POP QPD.

 

  9661   Mon Feb 24 13:21:00 2014 JenneUpdateElectronicsMeasured REFL165 demod board

I measured the REFL 165 demod board's I/Q separation. 

Our 11MHz signal is currently 11.066092 MHz, so I put a signal to the RF input of the REFL165 demod board at 165.992380 MHz (15*11 MHz + 1kHz), with a signal of -13 dBm.

I then used the SR785 to measure the transfer function between the I and Q output channels. 

I got 82.7 degrees, at -0.64 dB. (I don't remember now if I had I/Q, or Q/I, not that it really matters). So, it seems that the REFL165 demod board has good separation, and at least isn't totally broken.

  9666   Mon Feb 24 17:59:31 2014 RANAUpdateElectronicsMeasured REFL165 demod board

 

 Demod boards should be at 90 deg, not 82.7 or 12 or yellow or ****. We should re-inject the RF and then set the D Phase in the filter module to make the signals orthogonal. 165 is a challenging one to get right, but its worth it since the signals are close to degenerate already.

  16964   Thu Jun 30 17:19:55 2022 DeekshaSummaryElectronicsMeasured Transfer Functions of the Control Loop, Servo (OLTF); got Vectfit working

[Cici, Deeksha]

We were able to greatly improve the quality of our readings by changing the parameters in the config file (particularly increasing the integration and settle cycles, as well as gradually increasing our excitation signals' amplitude). Attached are the readings taken from the same (the files directly printed by ssh'ing the SR785 (apologies)) - Attachment 1 depicts the graph w/ 30 data points and attachment 2 depicts the graph with 300 data points. 

Cici successfully vectfit to the data, as included in Attachment 3. (This is the vectfit of the entire control loop's OLTF). There are two main concerns that need to be looked into, firstly, the manner in which to get the poles and zeros to input into the vectfit program. Similarly, the program works best when the option to enforce stable poles is disabled, once again it may be worth looking into how the program works on a deeper level in order to understand how to proceed. 

Just as the servo's individual transfer function was taken, we also came up with a  plan to measure the PZT's individual transfer function (using the MokuLab). The connections for the same have been made and the Moku is at the Xend (disconnected). We may also have to build a highpass filter (similar to the one whose signal enters the PZT) to facilitate taking readings at high frequencies using the Moku. 

  11550   Mon Aug 31 14:15:23 2015 IgnacioUpdateIOOMeasured the MC_F whitening poles/zeroes

I measured the 15 Hz zero and the 150 Hz pole for the whitening filter channels of the Generic Pentek board in the IOO rack. The table below gives these zero/pole pairs for each of the 8 channels of the board.

channel zero [Hz] pole [Hz] Chan
1 15.02 151.05 C1:ASC-POP_QPD_YAW
2 15.09 150.29 C1:ASC-POP_QPD_PIT
3 14.98 150.69 C1:ASC-POP_QPD_SUM
4 14.91 147.65 C1:ALS-TRX
5 15.03 151.19 C1:ALS-TRY
6 15.01 150.51 ---
7 14.95 150.50 C1:IOO-MC_L
8 15.03 150.93 C1:IOO-MC_F

Here is a plot of one of the measured transfer functions,

and the measured data is attached here: Data.zip


EQ: I've added the current channels going through this board. 

More importantly, I found that the jumpers on channel one (QPD X) were set to no whitening, in contrast to all other channels. Thus, the POP QPD YAW signals we've been using for who knows how long have been distorted by dewhitening. This has now been fixed. 

Hence, the current state of this board is that the first whitening stage is disabled for all channels and the second stage is engaged, with the above parameters. 

  17035   Mon Jul 25 18:22:30 2022 DeekshaSummaryWikiMeasured the PZT TF Successfully

Measured the PZT beatnote using the setup mentioned in elog post 17031. Attached is the data taken from 10kHz to 1MHz, decadewise data was also taken that I'm not including in this post. A_R refers to the transfer function taken of channel A wrt the voltage reference (the swept sine we are inputting which has an IF of 30kHz). A and B correspond to the I and Q components of the signal taken from the DFD, respectively. I am currently working on plotting the data, and will shortly update this post with plots. Next steps - 

- quantify the uncertainty in the signal (I think)

- vectfit the data to find poles and zeroes

(and possibly find a better way to print/obtain data)

Edit: first pass of data plotted

  8591   Thu May 16 11:50:25 2013 KojiConfigurationElectronicsMeasurement and empirical models of the AI board TFs

Yesterday, I pulled out the AI board for the PRM/BS SUSs. (After the investigation it was restored)

Contrary to our expectation, the board D000186 was not Rev. A but Rev. B.

According to Jay's note in D000186 (for Rev.D), the differences of the Revs are as follows

Rev.A: Initial Release (Analog Biquad version, 4dB 4th order elliptic with notches)
Rev.B: Filter implemented by Freq Devices chip
Rev.C: Differential input version with better RF filtering
Rev.D: 3rd order 0.5dB ripple Cheby with notches at 16K&32K, DB25 input version


I went to the WB EE shop and found bunch of AI filter modules. At least I found one Rev.A and six Rev.D.
I found at least one Rev. C.

I took Rev.A and Rev. D to see the difference of the transfer functions.
Rev.A has more ripple but steeper roll-off. Rev. D is flater at the pass band with slower roll-off.
Rev.D has more phase lag, but it will be fine once the entire frequency response is shifted to x4 high frequency.
The notch frequency of the Rev. D looked right.

I made the empirical pole/zero modeling of the transfer functions.
The LISO models are attached as the ZIP file.
I faced an unexplainable phase behavior at around one the notches for Rev.A.
This may suggest there could have been internal saturation is the stage during the sweep.

More importantly, Rev. D has differential inputs although the connector formfactor is different from the current 40pin IDC.
In fact we should not use Rev.A or Rev.B as they have single end inputs.
Currently the inputs of the AI's for the SUSs are single ended while the DACs are differential.
This means that
1) We waste a half of the DAC range.
2) The negative outputs of the DACs are short-circuited. OMG
3) The ground level fluctuation between the DAC and the SUS rack fluctuates the actual actuation voltage.

Now I am looking at the noise performance of the filters as well as the DAC output noise and range.
I hope we can use Rev.D by replacing the connector heads as this will remove many of the problems we currently have.

  2521   Mon Jan 18 18:34:01 2010 AlbertoUpdateABSLMeasurement in progress

I started a long measurement of the PRC's transmissivity. I'm leaving the lab and I'm going to be back at about 8 tonight. Please do not disturb the interferometer. it is important that the MC and the PRC stay locked all the time.

  2522   Mon Jan 18 20:58:40 2010 AlbertoUpdateABSLMeasurement in progress

Quote:

I started a long measurement of the PRC's transmissivity. I'm leaving the lab and I'm going to be back at about 8 tonight. Please do not disturb the interferometer. it is important that the MC and the PRC stay locked all the time.

 That measurement is finished. I'm now going to start another one that will take another hour or so. I'm leaving it running for the night. If you want to work on the IFO, it should be definitely done by 11pm.

  2531   Tue Jan 19 12:54:39 2010 AlbertoUpdateABSLMeasurement in progress

A measurement will be running for the next hour. Please be careful.

  2513   Wed Jan 13 12:03:00 2010 AlbertoUpdateABSLMeasurement now running. Please be careful

At the moment I'm running a measurement on the PRC and I'm planning to leave it going for the time we'll be at the 40m meeting.

Please be careful in the lab. Thank you.

  16961   Tue Jun 28 23:10:34 2022 YehonathanUpdateBHDMeasurement of AS55 demod board conversion factor

{Yuta, Yehonathan}

We measured the AS55 demod board conversion from the amplitude of a 55MHz signal to a demodulated signal. We hooked the unused REFL55 LO into the PD input port on the AS55 demod board.

The REFL55 LO was measured to be 1.84 Vpp. The IQ outputs were: I = 0.86 Vpp, Q = 2.03 Vpp giving an amplitude of 2.205 Vpp. The overall conversion factor is sqrt(0.86**2+2.03**2)/(1.82/2)=2.422.

We also set to measure the loss in the RF cable from AS55 PD to the demod board on 1Y2. REFL55 was connected with a long BNC cable to the input of the cable under test. REFL55 at the input was measured to be 1.466 Vpp and 1.28 Vpp at the output signifying a transmission of 87.6%.

  5093   Tue Aug 2 15:41:06 2011 kiwamuUpdateIOOMeasurement of MC spot positions : done

[Suresh / Kiwamu]

 The measurement of the spot positions on the MC mirrors are DONE.

Surprisingly the spot positions are not so different from the ones measured on May.

    Feb 26 2011      May 08 2011 (New !) Aug 2 2011
MC1 pit [mm]   1.6   1.9  1.93
MC2 pit [mm]   6.4   9.0 9.03
MC3 pit [mm]   1.4   2.0 2.01
MC1 yaw [mm]   -1.5   -1.7 -1.72
MC2 yaw [mm]   1.0   0.2 0.178
MC3 yaw [mm]   -1.3   -1.9 -1.87

 

(some notes)
We used Valera's script senseMCdecenter to estimate the spot positions ( see his entry).

It returns so many EPICS error messages and sometime some measured values were missing. So we had to throw away some of the measurements.

Anyways we gave the resultant ASCII file to Valera's matlab file sensmcass.m to get the actual amount of off-centering in milli-meter.

The attached file is the resultant plot from his matlab code.

  16960   Tue Jun 28 22:27:11 2022 YehonathanUpdateBHDMeasurement of input and output electronics noise

{Yuta, Yehonathan}

For MICH noise budgeting we measure the input electronics noise which includes the AS55 RFPD, preamp, demod board, the whitening, and the AA filters, and the ADC noises. To do so we simply close the laser shutter and take the spectrum of C1:LSC-AS55_I_ERR_DQ and C1:LSC-AS55_Q_ERR_DQ shown in attachment 1.

Next, we measured the output electronics noise which includes the DAC, dewhitening and AI filters, and coil driver noises. We disabled the BS watchdog and went to 1X4 rack. We measured the spectrum of one of the lemo outputs on the BS coil driver module using an SR785. Attachment 2 shows the spectrum together with the SR785 dark noise.

  5981   Tue Nov 22 20:45:21 2011 MirkoUpdateIOOMeasurement of the actuator matrix

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!?!?

 

  2500   Mon Jan 11 09:18:44 2010 AlbertoUpdateGeneralMeasurement running

I'm working on the AbsL experiment. A measurement which involved the PRC locked is running at the moment.

Please make sure of not interfering with the interferometer until it is done. Thank you.

  2502   Mon Jan 11 11:06:53 2010 AlbertoUpdateABSLMeasurement running

Quote:

I'm working on the AbsL experiment. A measurement which involved the PRC locked is running at the moment.

Please make sure of not interfering with the interferometer until it is done. Thank you.

 I'm done for the moement.

I realized that I need to take into account somehow the DC power from the photodiode. By now the measurement of the transmitted beat's power is affected by the total power circulating inside of the PRC and thus it depends on the cavity alignment.

I closed the laser shutter and turned down the flipping mirrors.

I'm planning to restart measuring by 2.30pm today. Till then the interferometer is available.

  2505   Mon Jan 11 19:36:13 2010 AlbertoUpdateABSLMeasurement running

Leaving for dinner. Back in ~1hr.

I left a measurement running. Please don't interfere with it till I'm back. Thanks.

  2506   Mon Jan 11 21:49:17 2010 JenneUpdateABSLMeasurement running

Quote:

Leaving for dinner. Back in ~1hr.

I left a measurement running. Please don't interfere with it till I'm back. Thanks.

 Per Alberto's instructions, I have closed the shutter on his laser so that the Adaptive Team can play with the Mode Cleaner.

  2553   Fri Jan 29 12:06:58 2010 AlbertoUpdateABSLMeasurement running today at lunch time

I just started a measuremtn that will be running for the next hour or so. Please be careful with the interferometer.

  2554   Fri Jan 29 13:14:49 2010 AlbertoUpdateABSLMeasurement running today at lunch time

Quote:

I just started a measuremtn that will be running for the next hour or so. Please be careful with the interferometer.

Done. IFO available

  208   Thu Dec 20 21:57:34 2007 AndreyUpdateComputer Scripts / ProgramsMeasurements in XARM today

Today at 2PM I started a program, it should change the suspension gains in the interval from 1.0 to 3.8 with the step 0.2. Estimated running time is till 3.30AM coming night.

Results will be reported on Friday.

BELOW: ADDITION MADE ON FRIDAY EVENING.

Due to some unforeseen circumstances, I was unable to add results on Friday. I have so far accelerometer spectra only, which I add to this ELOG entry.

I have files with the measurement results, and I will process them after Christmas and add to this ELOG entry. I might not be in the lab on Dec. 24 and 25.
  16974   Wed Jul 6 18:51:20 2022 DeekshaUpdateElectronicsMeasuring the Transfer Function of the PZT

Yesterday, we set up the loop to measure the PZT of the transfer function - the MokuLab sends an excitation (note - a swept sine of 1.0 V) to the PZT. The cavity is locked to the PSL and the AUX is locked to the cavity. In order to measure the effect of our excitation, we take the beat note of the PSL and the AUX. This gives us a transfer function as seen in Attachment 1. The sampling rate of the MokuLab is set to 'ultrafast' (125kHz), so we can expect accurate performance upto 62.5kHz, however, in order to improve our readings beyond this frequency, modifications must be made to the script (MokuPhaseMeterTF) to avoid aliasing of the signal. A script should also be written to obtain and plot the coherence between the excitation and our output. 

Also attached are - Attachment 2 -  the circuit diagram of the setup, and Attachment 3 - the TF data calculated.

Edit - the SR560 as shown in the circuit diagram has since been replaced by a broadband splitter (Minicircuits ZFRSC-42-S+).

  11207   Wed Apr 8 03:44:48 2015 JenneUpdateLSCMediocre locking night

It was only a mediocre locking night.  I was foiled for a long time by 2 things, both of which are now taken care of in the scripts, so I don't waste so much time again.

  • Somehow FM4 (LP700) in the CARM_A filter bank was turned off.  It took me a long time to figure this one out. 
    • At first, I had a 2056Hz oscillation, and then if I notched that, I would have problems at the edges of my notch.
    • I turned on the LP1000 in CARM_B (which we don't usually use) to fight the 2k resonances, but then I had violin mode problems. 
    • I couldn't turn off the violin mode filters on MC2 for the transition, so the edges of these notches were causing instability.
    • Anyhow, in the end, I realized that FM4 of CARM_B wasn't on, but it usually is.
    • It is now turned on in the carm_cm_up.sh script.
  • After that fiasco, I had trouble turning on the ASC loops.
    • Turns out we had left the offsets in place from last night in the ASC loops, so that when I zeroed the outputs of the transmission QPDs, the offsets in the ASC loops didn't make any sense, and they pushed the IFO severely out of alignment.
    • Now the ASC down script (which is run by the carm down script) zeros the filter bank offset values

Scripts are checked into the svn.


I used Q's handy-dandy 2D histogram plotter (..../scripts/general/dataHist, which I have taken the liberty of adding to the svn) to set the PRCL offset when I was locked on REFL165.  Here is a version of the plot, when I had an offset of +10 in the PRCL filter bank. There was so much noise on the PRCL input that I quit bothering to try and put in an excitation or ramp the offset value.  Note that I have since moved this offset to PRCL_A's offset instead, so taking this plot again should have PRCL_IN1 centered around zero.

I had trouble doing something similar for PRCL when I was locked on REFL55.  At first, the offset was so poor that POP110 was only about half the value it was when locked on REFL165, and it had a huge amount of RIN.  I tried just doing a z avg of the PRCL_B_IN1 (REFL55I) while locked on REFL165, and that said that REFL55I had an offset of +33.8 counts, so I tried an offset of -33.8 counts to get to zero.  But, that was still terrible for POP110 power.  As I increased the offset, eventually up to +30 counts, POP110 kept getting better and better.  I lost lock at that point (while trying to get 10 sec of histogram data), so I'm not sure that +30 is the final value.  I want to also get equivalent histograms with POP22 and POPDC (and maybe arm transmissions?) as the X-axis on these plots.  There's no excitation, so all of these can be collected at once.


By babysitting the ITM alignment (looking at the rough DC values of the optical lever error siganls), and doing a little adjustment of the ASC differential offset, I was able to keep lock a few times for more than 2 or 3 minutes while all 1f.  Not a whole lot longer than that though, even if I wasn't "poking" the interferometer other than maintaining alignment.

  8175   Wed Feb 27 00:08:43 2013 JenneUpdateIOOMeditations on converting TT channels to be more SUS-like

Jamie and I have had a few back-and-forths on this, but I wanted to write down my thoughts on the parts of the SUS infrastructure that we need for the active tip tilts.

I think we want the ASC pitch and yaw filter banks.  I also think we want to change the channel names so that they are C1:SUS rather than C1:IOO, to make scripting easier.  A corollary to this is that we should make the DC bias sliders have the same naming structure as the regular suspensions (C1:SUS-TT#_{PIT/YAW}_COMM).  This makes scripts like the save/restore scripts easier.  If we keep the IOO naming, it would still be convenient to add the _COMM.

I am having trouble imagining what we might want the lockins for, so I propose we leave them out.

Do we want the output matrix (PIT/YAW -> coils) to be a filter bank matrix?  If we want f2a filters, we need to change this to a filter bank matrix.

I also think we want a master on/off switch for the AC actuation (ASC stuff).  We don't have sensors, so we won't have watchdog-ing, but it might be useful to have a 'panic' switch.  Perhaps though if we are careful to set limits on the ASC filter banks, we won't ever have a panic about actuating too hard.

I'm think I'm joining Jamie's side in the medm screen debate....I think we want a separate TT_SINGLE screen, laid out similar to the SUS_SINGLE, but without all of the irrelevant parts.

EDIT:  Yuta just pointed out to me that right now, the TT DC bias sliders are not recorded anywhere (_DQ, conlog,...).  We *must* fix this.

  5576   Thu Sep 29 12:56:27 2011 JenneUpdateAdaptive FilteringMeditations on the OAF

[Mirko, Den, Jenne]

We're modifying the c1oaf model, and we got to talking about the "Fx" part of "FxLMS".  In the past, we put in a guess for the filter.  What if we use the static wiener filter as the F, and send the wiener filtered witness channels to the adaptation algorithm? 

Are the wiener filter and the plant compensation filter ("Fx") the same?  Will this work?  Or is there some reason that they must be different?

Also:  Notes to self:  Put in filtered witness channels as well as regular into Adapt block.  Make sure that the order/number of inputs is correct.

  5602   Mon Oct 3 16:18:05 2011 JenneUpdateAdaptive FilteringMeditations on the OAF

Quote:

[Mirko, Den, Jenne]

We're modifying the c1oaf model, and we got to talking about the "Fx" part of "FxLMS".  In the past, we put in a guess for the filter.  What if we use the static wiener filter as the F, and send the wiener filtered witness channels to the adaptation algorithm? 

Are the wiener filter and the plant compensation filter ("Fx") the same?  Will this work?  Or is there some reason that they must be different?

Also:  Notes to self:  Put in filtered witness channels as well as regular into Adapt block.  Make sure that the order/number of inputs is correct.

 More meditations...

Mirko and I were talking about the tunability required for each DoF.  For right now, we're going to give each DoF its own mu and tau (adaptation gain and adaptation decay), but we're leaving all of the other things (number of taps, number of witnesses, delay, downsample rate) the same for each DoF's adaptation.  This may need to change later, but we'll get there when we get there. 

The one I'm most concerned about is the number of witnesses...  Mirko is suggesting that we give each adaptation algorithm all witnesses, and unused ones should converge to ~0.  I agree in principle, but I'm not sure that it's actually going to work that way.  I think we may need to be able to tell the algorithm which witnesses to look at for which DoF. 

Also, the Delay.... we may need to adjust it for each DoF.  In Matt's OAF "manual" in elog 395, he mentions the need to calculate the delay based on a plant TF.  Presumably since (except for the MC) all the witnesses come in together, and all the DoFs come in together, the delay should be about the same for all?  We'll have to see...

  14037   Wed Jul 4 20:48:32 2018 poojaUpdateCamerasMedm screen for GigE

(Gautam, Pooja)

Aim: To develop medm screen for GigE.

Gautam helped me set up the medm screen through which we can interact with the GigE camera. The steps adopted are as follows:

(i) Copied CUST_CAMERA.adl file from the location /opt/rtcds/userapps/release/cds/common/medm/ to /opt/rtcds/caltech/c1/medm/MISC/.

(ii) Made the following changes by opening CUST_CAMERA.adl in text editor.  

  • Changed the name of file to "/cvs/cds/rtcds/caltech/c1/medm/MISC/CUST_CAMERA.adl"
  • Replaced all occurences of "/ligo/apps/linux-x86_64/camera/bin/" to "/opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/" & "/ligo/cds/$(site)/$(ifo)/camera/" to "/opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/"

(iii) Added this .adl file as drop-out menu 'GigE' to VIDEO/LIGHTS section of sitemap (circled in Attachment 1) i.e opened Resource Palette of VIDEO/LIGHTS, clicked on Label/Name/Args & defined macros as CAMERA=C1:CAM-ETMX,CONFIG=C1-CAM-ETMX in Arguments box of Related Display Data dialog box (circled in Attachment 2) that appears. In Related Display Data dialog box, Display label is given as GigE and Display File as ./MISC/CUST_CAMERA.adl

(iv) All the channel names can be found in Jigyasa's elog https://nodus.ligo.caltech.edu:8081/40m/13023

(v) Since the slider (circled in Attachment 3) for pixel sum was not moving, changed the high limit value to 10000000 in PV Limits dialog box. This value is set such that the slider reaches the other end on setting the exposure time to maximum.

(vii) Set the Snapshot channel C1:CAM-ETMX_SNAP to off (very important!). Otherwise we cannot interact with the camera.

(vii) GigE camera gstreamer client is run in tmux session.

Now we can change the exposure time and record a video by specifying the filename and its location using medm screen. However, while recording the video, gstream video laucher of GigE stops or is stuck.

  2301   Thu Nov 19 11:33:15 2009 josephbConfigurationComputersMegatron

I tried rebooting megatron, to see if that might help, but everything still acts the same. 

I tried using daqconfig and changed channels from deactiveated to activated.  I learned by activating them all, that the daq can't handle that, and eventually aborts from an assert checking a buffer size being too small.  I also tried activating 2 and looking at those channels, and it looks like the _DAQ versions of those channels work, or at least I get 0's out of C1:TST-ETMY_ASCPIT_OUT_DAQ (which is set in C1TST.ini file).

I've added the SENSOR channels back to the /csv/cds/caltech/chans/daq/C1TST.ini file, and those are again working in data viewer.

At this point, I'm leaving megatron roughly in the same state as last night, and am going to wait on a response from Alex.

  2558   Tue Feb 2 10:38:30 2010 josephbUpdateComputersMegatron BO test

Last night, I connected megatron's BO board to the analog dewhitening board.  However, I was unable to lock the y arm (although once I disconnected the cable and reconnected it back the xy220 the yarm did lock).

So either A) I've got the wrong cable, or B) I've got the wrong logic being sent to the analog dewhitening filters.

During testing, I ran into an odd continuous on/off cycle on one of the side filer modules (on megatron).  Turns out I had forgotten to use a ground input to the control filer bank (which allows you to both set switches as well as read them out), and it was reading a random variable.  Grounding it in the model fixed the problem (after re-making).

 

 

  2580   Mon Feb 8 17:00:36 2010 josephbUpdateComputersMegatron ETMY model updated (tst.mdl)

I've added the control logic for the outputs going to the Contec Digital Output board.  This includes outputs from the QPD filters (2 filters per quadrant, 8 in total), as well as outputs going to the coil input sensor whitening.

At this point, the ETMY controls should have everything the end station FE normally does.  I'm hoping to do some testing tomorrow afternoon with this with a fully locked IFO.

  2544   Mon Jan 25 11:42:24 2010 josephbUpdateComputersMegatron and BO board

I was talking with Vladimir on Friday discussing the Binary Output board, we looked at the manual for it (Contec DO-32L-PE) and we realized its an opto-coupler isolated open-collector output.  He mentioned they had the right kind of 50 channel breakout board for testing in Riccardo's lab.

This morning I borrowed the 50 channel breakout board from Riccardo's lab, and along with some resistor loads, test the BO board.  It seems to be working, and I can control the output channel on/off state.

  2515   Fri Jan 15 11:21:05 2010 josephbUpdateComputersMegatron and tst model for ETMY

The tst model wasn't compiling this morning due to some incorrect lines in the RfmIOfloat.pm file located in /home/controls/cds/advLIgo/src/epics/util/lib file on megatron. 

The error was "Undefined subroutine &CDS::RfmIOfloat::partType called at lib/Parser2.pm line 354, <IN> line 3363."

I changed RfmIO to RfmIOfloat on lines 1 and 6.
Basically the first 6 lines are now

package CDS::RfmIOfloat;
use Exporter;
@ISA = ('Exporter');

sub partType {
        return RfmIOfloat;
}

The tst now compiles.  At the moment, I believe we should be able to switch megatron in for ETMY and attempt to lock the arm.  The whitening/dewhitening filters are still not automatically synced in software and hardware, but I don't think that should prevent locking.

  724   Wed Jul 23 16:31:02 2008 AlbertoConfigurationComputersMegatron connected
Joe, Rana, Alberto,

we found out the password for Megatron so we could log in and set a new one so that now it's the same as that for controls.
The IP address is 131.215.113.59.

We had to switch to another LAN ports to actually connect it.
  725   Wed Jul 23 17:19:48 2008 AlbertoConfigurationComputersMegatron connected
We changed the IP address. Ther new one is 131.215.113.95.

Joe, Alberto


Quote:
Joe, Rana, Alberto,

we found out the password for Megatron so we could log in and set a new one so that now it's the same as that for controls.
The IP address is 131.215.113.59.

We had to switch to another LAN ports to actually connect it.
ELOG V3.1.3-