ID |
Date |
Author |
Type |
Category |
Subject |
15988
|
Thu Apr 1 21:13:54 2021 |
Anchal | Update | SUS | Matrix 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 |
gautam | Update | SUS | Matrix 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 |
rana | Configuration | IOO | McWFS 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 |
rana | Configuration | IOO | McWFS 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 |
Alberto | Configuration | Computers | Measure 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 |
Naomi | Summary | General | Measure 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 |
Jenne | Update | oplevs | Measured 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 |
Jenne | Update | LSC | Measured 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 |
rana | Update | LSC | Measured 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 |
Koji | Update | LSC | Measured 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 |
rob | Update | Locking | Measured 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 |
rob | Update | Locking | Measured 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 |
rob | Update | Locking | Measured 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 |
rana | Update | PSL | Measured 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 |
Koji | Update | PSL | Measured 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 |
Jenne | Update | Modern Control | Measured 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 |
Jenne | Update | Electronics | Measured 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 |
RANA | Update | Electronics | Measured 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 |
Deeksha | Summary | Electronics | Measured 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 |
Ignacio | Update | IOO | Measured 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 |
Deeksha | Summary | Wiki | Measured 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 |
Koji | Configuration | Electronics | Measurement 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 |
Alberto | Update | ABSL | Measurement 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 |
Alberto | Update | ABSL | Measurement 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 |
Alberto | Update | ABSL | Measurement in progress |
A measurement will be running for the next hour. Please be careful. |
2513
|
Wed Jan 13 12:03:00 2010 |
Alberto | Update | ABSL | Measurement 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 |
Yehonathan | Update | BHD | Measurement 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 |
kiwamu | Update | IOO | Measurement 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 |
Yehonathan | Update | BHD | Measurement 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 |
Mirko | Update | IOO | Measurement 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 |
Alberto | Update | General | Measurement 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 |
Alberto | Update | ABSL | Measurement 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 |
Alberto | Update | ABSL | Measurement 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 |
Jenne | Update | ABSL | Measurement 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 |
Alberto | Update | ABSL | Measurement 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 |
Alberto | Update | ABSL | Measurement 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 |
Andrey | Update | Computer Scripts / Programs | Measurements 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 |
Deeksha | Update | Electronics | Measuring 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 |
Jenne | Update | LSC | Mediocre 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 |
Jenne | Update | IOO | Meditations 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 |
Jenne | Update | Adaptive Filtering | Meditations 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 |
Jenne | Update | Adaptive Filtering | Meditations 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 |
pooja | Update | Cameras | Medm 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 |
josephb | Configuration | Computers | Megatron |
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 |
josephb | Update | Computers | Megatron 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 |
josephb | Update | Computers | Megatron 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 |
josephb | Update | Computers | Megatron 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 |
josephb | Update | Computers | Megatron 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 |
Alberto | Configuration | Computers | Megatron 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 |
Alberto | Configuration | Computers | Megatron 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. |
|