40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 140 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  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. 

Attachment 1: TFSR785_29-06-2022_114042.pdf
TFSR785_29-06-2022_114042.pdf
Attachment 2: TFSR785_29-06-2022_114650.pdf
TFSR785_29-06-2022_114650.pdf
Attachment 3: TF_OLG_vectfit.png
TF_OLG_vectfit.png
  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. 

Attachment 1: Data.zip
  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

Attachment 1: A_R_MAG.txt
"4395A REV1.12"
"DATE: Sep 17 2017"



"CHANNEL: 1"
"MEASURE TYPE: A/R"
"FORMAT TYPE: LOG MAG"
"NUMBER of POINTS: 801"
"SWEEP TIME:  385.3 ms"
... 811 more lines ...
Attachment 2: A_R_PHASE.txt




"CHANNEL: 2"
"MEASURE TYPE: A/R"
"FORMAT TYPE: PHASE (DEG)"
"NUMBER of POINTS: 801"
"SWEEP TIME:  385.3 ms"
... 808 more lines ...
Attachment 3: B_R_MAG.txt
"4395A REV1.12"
"DATE: Sep 17 2017"



"CHANNEL: 1"
"MEASURE TYPE: B/R"
"FORMAT TYPE: LOG MAG"
"NUMBER of POINTS: 801"
"SWEEP TIME:  385.3 ms"
... 809 more lines ...
Attachment 4: B_R_PHASE.txt




"CHANNEL: 2"
"MEASURE TYPE: B/R"
"FORMAT TYPE: PHASE (DEG)"
"NUMBER of POINTS: 801"
"SWEEP TIME:  385.3 ms"
... 807 more lines ...
Attachment 5: freq_resp_I.png
freq_resp_I.png
Attachment 6: freq_resp_Q.png
freq_resp_Q.png
  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.

Attachment 1: D000186AD_TF.pdf
D000186AD_TF.pdf
Attachment 2: D000186AD_TF.zip
  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.

Attachment 1: MCdecenter.png
MCdecenter.png
  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.

Attachment 1: input_noise_spectrum.pdf
input_noise_spectrum.pdf
Attachment 2: output_noise_spectrum.pdf
output_noise_spectrum.pdf
  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.
Attachment 1: Accelerom_ETMX.png
Accelerom_ETMX.png
Attachment 2: Accelerom_ITMX.png
Accelerom_ITMX.png
  17076   Thu Aug 11 17:15:33 2022 CiciUpdateGeneralMeasuring AUX Laser UGF with Red Pitaya

TL;DR: Have successfully measured the UGF of the AUX laser on my Red Pitaya! Attached is one of my data runs (pdf + txt file). 

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

  • Figured out how to get a rudimentary coherence (use scipy.signal.coherence to get Cxy = abs(Pxy)**2/(Pxx*Pyy), then find what point is the closest to the frequency I'm inserting on that iteration of the swept sine and get the coherence closest to that). Not precisely the coherence at the frequency I'm inserting though, so not perfect... more of a lower bound of coherence.
  • Figured out how to get the UGF from the data automatically (no error propagation yet... necessary next step)
  • Put my red pitaya in the X-arm AUX laser control electronics (thank you to Anchal for help figuring out where to put it and locking the x-arm.) Counts dropped from 4500 to 1900 with the x-arm locked, so 58% mode matching. I lose lock at an amplitude >0.05 or so.
  • Wrote a little script to take data and return a time-stamped text file with all the parameters saved and a time-stamped pdf of the TF magnitude, UGF, phase, and coherence, so should be easy to take more data next time!

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

  • need to take more accurate coherence data
  • need to propagate uncertainty on UGF (probably high...)
  • take more data with higher coherence (the file attached doesn't have great coherence and even that was one of my better runs, will probably increase averaging since increasing amplitude was a problem)
Attachment 1: rpi_OLG_2022_08_11_16_51_53.pdf
rpi_OLG_2022_08_11_16_51_53.pdf
Attachment 2: rpi_OLG_2022_08_11_16_51_53.txt
# frequency start: 500.0
# frequency stop: 50000.0
# samples: 50
# amplitude: 0.01
# cycles: 500
# max fs: 125000000.0
# N: 16384UGF: 9264.899326705621
# Frequency[Hz] Magnitude[V/V] Phase[rad] Coherence
4.999999999999999432e+02 5.216612299292965105e+01 -7.738468629291910261e-01 7.660920305860696722e-02
5.492705709937790743e+02 3.622076363933444298e+01 -5.897393740774580229e-01 3.183076012979469405e-01
... 49 more lines ...
  17101   Wed Aug 24 10:49:43 2022 CiciUpdateGeneralMeasuring DFD output/X-arm laser PZT TF with Moku

We measured the TF of the X-arm laser PZT using the Moku so we can begin fitting to that data and hopefully creating a digital filter to cancel out PZT resonances. 

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

We calculated the DFD calibration (V/Hz) using:

Vrf = 0.158 mV (-6 dBm), Km = 1 (K_phi = Km*Vrf), cable length = 45m,  Tau = cable length/(0.67*3*10^8 m/s) ~ 220 ns. 

We've taken some preliminary data and can see the resonances around 200-300 kHz.

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

Next steps are taking more data around the resonances specifically, calibrating the data using the DFD calibration we calculated, and adjusting parameters in our model so we can model the TF.

 

Attachment 1: AUX_PZT_Actuator_nofit.pdf
AUX_PZT_Actuator_nofit.pdf
  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+).

Attachment 1: pzt_transfer_fn.png
pzt_transfer_fn.png
Attachment 2: ckt_diagram.jpeg
ckt_diagram.jpeg
Attachment 3: MokuPhaseMeterTFData_20220706_174753_TF_Data.txt
2.000000000000000364e+04 1.764209350625748560e+07 2.715833132756984014e+00
1.928351995884991265e+04 1.695301366919569671e+07 1.509398637395631626e+00
1.859270710016814337e+04 1.647055321367538907e+07 -2.571975165101855865e+00
1.792664192275710593e+04 1.558169995329630189e+07 6.272729335836754183e-01
1.728443786563210961e+04 1.500850042360494658e+07 -1.500422400597591466e+00
1.666524012797089381e+04 1.456986577652360499e+07 2.046163000975175894e+00
1.606822453133765885e+04 1.376167843637173250e+07 1.736835046956476614e+00
1.549259642266657283e+04 1.326192932667389885e+07 -1.272425049850132606e+00
1.493758961654484847e+04 1.283127345074228011e+07 -2.026149685362535369e+00
1.440246537538758821e+04 1.208854709974890016e+07 -3.248352694840740407e-01
... 11 more lines ...
  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.

Attachment 1: PRCL_R165_offsetplus10.png
PRCL_R165_offsetplus10.png
  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.

Attachment 1: sitemap.png
sitemap.png
Attachment 2: GigE_macros.png
GigE_macros.png
Attachment 3: CUST_CAMERA.png
CUST_CAMERA.png
  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.
  1258   Thu Jan 29 16:50:53 2009 josephb, albertoConfigurationComputersMegatron fixed
The warning light on megatron and the fans at full speed were fixed by not just power cycling, but completely unplugging megatron from power, waiting for a minute, and then reconnecting the power cables.

Apparently, the Sunfire X4600s at Hanford have also had intermittent problems, which required unplugging the machines completely. In their case, they were unable to access the machine normally, nor could they access the the Intergrated Lights Out Manager (ILOM).

Here, we could interact normally with megatron, but were unable to connect to the ILOM. We were able to get BIOS, but unable to change any of the setting for the ILOM connection. Since the ILOM is a seperate processor and effectively always on, even when the power light is off, a normal shutdown won't reset it. Hence the need to completely disconnect the power supply.
  13778   Sat Apr 21 20:19:05 2018 gautamUpdateGeneralMegatron hard-rebooted

I found megatron in a similar state to that which nodus was in yesterday. Clued by the fact that MCautolocker wasn't executing the mc scripts (as was evident from looking at the wall StripTool trace), I tried ssh-ing into megatron, but was unable to (despite it being responsive to ping requests). So I went into the VEA and plugged in a monitor to megatron - saw nothing on it. With no soft reboot options available, I power cycled the machine via the front panel button. It came back up smoothly. I manually restarted the autolocker, FSSslow and EX thermal control processes (the former two with initctl, while the latter runs in a tmux session). Everything seems alright for now. Not sure how long megatron has been dead for.

  14473   Sun Mar 3 14:16:31 2019 gautamUpdateIOOMegatron hard-rebooted

IMC was not locked for the past several hours. Turned out MC autolocker was stuck, and I could not ssh into megatron because it was in some unresponsive state. I had to hard-reboot megatron, and once it came back up, I restarted the MCautolocker, FSS slow servo and nds2 processes. IMC re-locked immediately.

I was pulling long stretches of OSEM data from the NDS2 server (megatron) last night, I wonder if this flakiness is connected. Megatron is still running Ubuntu12.

  14762   Mon Jul 15 18:55:05 2019 gautamUpdateIOOMegatron hard-rebooted

[koji, gautam]

In addition to c1psl needing a reboot, megatron was un-ssh-able (although it was responding to ping). Clue was that the NPRO PZT control voltage was drifting a lot on the StripTool trace. Koji hard-rebooted the machine. Now IMC is locked, and FSS slow servo is also running.

  3590   Mon Sep 20 16:59:26 2010 josephbUpdateCDSMegatron in 1X2 rack, to be come c1ioo

[Rana, Koji, Joe]

We pulled the phase shifters in the 1X2 rack out to make room for megatron.  Megatron will be converted into c1ioo, and the 8 core, 1U computer will be used as c1lsc.  A temporary ethernet cable was run from 1X2 to 1X3 to connect megatron to the same sub-network.

The c1lsc machine was worked on today, setting it up to run the real time code, along with the correct controls accounts, passwords, .cshrc files, etc.  It needs to be moved from 1X1 to 1X4 tomorrow.

  4126   Sat Jan 8 21:12:12 2011 ranaUpdateCDSMegatron is back

 I started reverting Megatron into a standard Ubuntu workstation after Joe/Osamu's attempt to steal it for their real time mumbo jumbo.

First, I installed a hard drive that was sitting around on top of it. That whole area is still a mess; I'm not surprised that we have so many CDS problems in such a chaotic state. There's another drive sitting around there called 'RT Linux' which I didn't use yet.

Second, I removed the ethernet cables and installed a monitor/keyboard/mouse on it.

Then I popped in the Ubuntu 10.04 LTS DVD, wiped the existing CentOS install and started the standard graphical installation of Ubuntu.

megatron.jpg

Megatron's specs attached: 

Attachment 2: sysinfo.text
  2266   Fri Nov 13 10:28:03 2009 josephb, alexUpdateComputersMegatron is back to its old self

I called Alex this morning and explained the problems with megatron.

Turns out when he had been setting up megatron, he thought a startup script file, rc.local was missing in the /etc directory.  So he created it.  However, the rc.local file in the /etc directory is normally just a link to the /etc/rc.d/rc.local file.  So on startup (basically when we rebooted the machine yesterday), it was running an incorrect startup script file.  The real rc.local includes line:

/usr/bin/setup_shmem.rtl mdp mdc&

Hence the errors we were getting with shm_open().  We changed the file into a soft link, and resourced the rc.local script and mdp started right up.  So we're back to where we were 2 nights ago (although we do have an RFM card in hand).

Update:  The tst module wouldn't start, but after talking to Alex again, it seems that I need to add the module tst to the /usr/bin/setup_shmem.rtl mdp mdc& line in order for it to have a shared memory location setup for it.  I have edited the file (/etc/rc.d/rc.local), adding tst at the end of the line.  On reboot and running starttst, the code actually loads, although for the moment, I'm still getting blank white blocks on the medm screens.

  1255   Wed Jan 28 12:51:32 2009 YoichiUpdateComputersMegatron is dying
For the past three days, Megatron has been making a huge noise. Sounds like a fan is failing.
There is an LED with "!" sign on the front panel. It is now orange. Looks like some kind of warning.
We can login to the machine. "top" shows the CPU load is almost zero.
Shall we try rebooting it ?
  13381   Mon Oct 16 12:13:38 2017 gautamUpdateCDSMegatron maintenance

Wall StripTool traces showed that IMC has not been locked for at least 8 hours when I came in this morning. Going to the IMC autolocker log, it looks like the last timestamp was at ~6pm yesterday. Megatron was responding to ping, but I couldn't ssh into it. So I went over to the machine and did a hard-reboot via front panel power switch. The computer took ~10mins to come back online and respond to ping. Once it did, I was able to ssh into it. However, trying the usual commands to restart the IMC autolocker and FSS Slow loops didn't work. Specifically, monitoring the logfile with tail -f Autolocker.log, I would see that the autolocker seemed to get stuck after starting the "blinky" script. Trying to restart the process using sudo initctl restart MCautolocker, init would print to shell that the restart had worked, and reported the PID, but the logfile wouldn't update "live" as it should when tail is used with the -f option. All very strange frown.

Anyways, as a last resort, I kill -9'ed the PID for the init instance, and init automatically restarted the Autolocker - this did the trick, IMC is locked now and logfile seems to be getting updated normallyyes.

I also cleared a bunch of matlab crash dump files in the home directory.

  11626   Mon Sep 21 11:40:30 2015 ericqUpdateGeneralMegatron maitenence

The MC autolocker and FSSslow scripts weren't running on Megtron. These were started by running the following commands on megatron:

sudo initctl start MCautolocker
sudo initctl start FSSslow

The new autoburt cronjob was failing because the .cron file was not executable (fixed by chmod +x burtnew.cron), and the new perl script didn't use the full path for ifconfig. Similarly, the simulink webview updating script was failing because the full path for matlab wasn't being given. Both of these fixes have been tested and commited to SVN. 

In general, cron scripts can be a real pain, since the cron process doesn't run our .bashrc, and so doesn't know about updates to $PATH, or other environment vairables that get updated through /ligo/cdscfg/workstationrc.sh, which is called by .bashrc. So something that manually works fine in the terminal may not play out as expected when run by cron.

  11834   Tue Dec 1 17:26:14 2015 KojiUpdateGeneralMegatron maitenence

SLOWDC servo was dead. I followed EricQ's instruction.

  11835   Tue Dec 1 20:20:16 2015 KojiUpdateGeneralMegatron maitenence

MC Autolocker got stack somewhere. I had to go to megatron and kill MC Autolocker.

init relaunched the autolocker automatically, and now it started properly.

  779   Fri Aug 1 10:45:46 2008 josephbConfigurationComputersMegatron now running tcsh
At Rana's request, I've remotely switched Megatron over to using tcsh. I had to ssh -X in order ot use the "/sbin/system-config-users" program which is a graphical UI for modifying users. I had to go to preferences and uncheck hide system users, which then allowed me to see the controls user (at the bottom of the list), and edit it.

I also created a .tcshrc file in the /home/controls directory and copied the information from the .bashrc file, and also moved the matlab path definition into the PATH environment variable.

Does anyone know if sourcing /cvs/cds/caltech/cshrc.40m would be usable on a 64 bit machine, or does a new one need to be made for Megatron and/or Rosalba?
  2225   Tue Nov 10 10:51:00 2009 josephb, alexUpdateComputersMegatron on, powercycled c1omc, and burt restored from 3am snapshot

Last night around 5pm or so, Alex had remotely logged in and made some fixes to megatron.

First, he changed the local name from scipe11 to megatron.  There were no changes to the network, this was a purely local change.  The name server running on Linux1 is what provides the name to IP conversions.  Scipe11 and Megatron both resolve to distinct IPs. Given c1auxex wasn't reported to have any problems (and I didn't see any problems with it yesterday), this was not a source of conflict.  Its possible that Megatron could get confused while in that state, but it would not have affected anything outside its box.

Just to be extra secure, I've switched megatron's personal router over from a DMZ setup to only forwarding port 22.  I have also disabled the dhcp server on the gateway router (131.215.113.2).

Second, he turned the mdp and mdc codes on.  This should not have conflicted with c1omc.

This morning I came in and turned megatron back on around 9:30 and began trying to replicate the problems from last night between c1omc and megatron.  I called Alex and we rebooted c1omc while megatron was on, but not running any code, and without any changes to the setup (routers, etc).  We were able to burt restore.  Then we turned the mdp, mdc and framebuilder codes on, and again rebooted c1omc, which appeared to burt restore as well (I restored from 3 am this morning, which looks reasonable to me). 

Finally, I made the changes mentioned above to the router setups in the hope that this will prevent future problems but without being able to replicate the issue I'm not sure.

ELOG V3.1.3-