40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 33 of 344  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  17287   Fri Nov 18 22:46:02 2022 yutaSummaryBHDMICH optical gain measurements with different LO phases, with signs

MICH optical gain with a sign was measured with different LO phases over ~180 degrees, with updated calibration and higher MICH UGF.
Zero crossing of BH55_Q_ERR seems to be 68 degrees away from optimal LO phase.

Calibrated sensing matrix:
 - Locked MICH with AS55_Q at dark fringe, with UGF of ~200 Hz. Notch at 311.1 Hz was turned on.
 - Locked LO PHASE with BH55_Q, with UGF of ~10 Hz (C1:HPC-LO_PHASE_GAIN=-2, using LO1).
 - Measured the sensing matrix as written in 40m/17279, but with different dither frequencies to avoid violin mode frequencies and to match with already-installed notch filters.
 - Sensing matrix was calibrated into meters using actuator gains measured in 40m/17285
 - Sign was added by comparing the phase with C1:SUS-xx_LSC_OUT. If they are 90-270 deg apart, minus sign was added to the sensing matrix.
 - Resuts are as follows. At least important green ones are consistent with previous measurements (40m/17279).

Calibrated sensing matrix with the following demodulation phases (counts/m)
{'AS55': -164.1726747789845, 'BH55': 169.57651332419115}
      Sensors            MICH @311.1 Hz           LO1 @147.1 Hz           AS1 @141.79 Hz           
C1:LSC-AS55_I_ERR_DQ    2.72e+06 (84.89 deg)    6.41e+05 (14.60 deg)    -1.98e+05 (206.79 deg)    
C1:LSC-AS55_Q_ERR_DQ    -1.20e+09 (-228.85 deg)    -1.43e+06 (-106.51 deg)    1.41e+06 (29.21 deg)    
C1:LSC-BH55_I_ERR_DQ    -2.45e+09 (-230.64 deg)    -6.57e+07 (167.84 deg)    7.28e+07 (-16.56 deg)    
C1:LSC-BH55_Q_ERR_DQ    7.81e+09 (-48.64 deg)    -7.34e+08 (159.70 deg)    8.06e+08 (-10.08 deg)    
C1:HPC-BHDC_DIFF_OUT    -9.91e+08 (-224.55 deg)    -1.13e+08 (164.14 deg)    1.26e+08 (-3.95 deg)    
C1:HPC-BHDC_SUM_OUT    -6.84e+06 (-104.69 deg)    1.50e+07 (-8.71 deg)    -1.79e+07 (173.80 deg)    
LO phase from C1:LSC-BH55_Q_ERR_avg 4.98e-03 +/- 1.65e+01 deg

Estimating LO phase:
 - Using 7.34e+08 counts/m, which is an optical gain of BH55_Q for LO1, LO phase can be estimated as follows.

A = BH55optgain*lamb/(4*pi) = 62 counts
LOphase = arcsin(BH55_Q/A)

 - When C1:HPC-LO_PHASE_GAIN is plus, LOphase was calculated with the following to take into account of the sign flip in the controls.

LOphase = 180 - arcsin(BH55_Q/A)

Balancing A-B:
 - BHDC_A and BHDC_B were balanced to give null MICH signal in BHDC_SUM at 311.1 Hz. This gave BHDC_DIFF = 0.919*A - B.
 - It seems like this balancing gain changes over time by ~30%.

Result:
 - Attachment #1 is uncalibrated MICH optical gain in different LO phases, and Attachment #2 is the calbirated one. Basically the same with 40m/17282, but with updated calibration and sign considerations.
 - In addition to the previous measurements, we can see that BHD_SUM is not dependent on LO phase (small dependence probably from not perfect A and B balancing).
 - 0 deg of LO phase means that it is a zero crossing of BH55_Q with a slope that LO PHASE loop can be closed with a minus C1:HPC-LO_PHASE_GAIN, feeding back to LO1.
 - Dotted and dashed gray lines are from scipy.optimize.curve_fit using the following fitting function (not an eyeball fit this time!).

def fitfunc(x, a,b,c):
    return a*np.sin(np.deg2rad(x-b))+c

 - Fitting results show that we are -22 deg away from our intuition that BH55_Q crosses zero when BHDC_DIFF give no MICH signal (68 degrees away from optimal LO phase).
 - Fitting results also show that BH55_Q sensitivity to MICH crosses zero when BHD_DIFF sensitivity to MICH maximizes. This suggests that BH55+MICH dither can be used to lock LO phase to optimal LO phase.

Notebook: /opt/rtcds/caltech/c1/Git/40m/scripts/CAL/SensingMatrix/MeasureSensMatBHD.ipynb

Next:
 - Compare with expected values from simulations
 - Why do we have -22 deg?
   - Check if there is any RAM in 55 MHz in the input beam by measuring AM with ITM single bounce (quick measurement shows it is small)
   - Unbalanced BHD BS?
   - Contribution from 55 MHz sidebands from LO beating with 55 MHz sidebands from AS?
       - Lock LO phase using audio dither only (demodulate BHDC_DIFF?).

Attachment 1: UncalibratedMICHOpticalGainVSLOphase20221118.png
UncalibratedMICHOpticalGainVSLOphase20221118.png
Attachment 2: CalibratedMICHOpticalGainVSLOphase20221118.png
CalibratedMICHOpticalGainVSLOphase20221118.png
  17294   Mon Nov 21 17:44:00 2022 yutaSummaryBHDMICH BHD displacement sensitivity with AS55_Q and BHD_DIFF

[Paco, Yuta]

MICH displacement sensitivity was compared under AS55_Q locking and BHD_DIFF locking.
Sensitivity with BHD was better by more than an order of magnitude due to smaller sensing noise.
During the measurement, LO phase fluctuation was ~13 deg RMS.

Locking configurations:
 - MICH was first locked with AS55_Q, no offset, and then handed over to BHD_DIFF after LO phase locked. FM2, FM3, FM4, FM5, FM6, FM8, FM10 on, C1:LSC-MICH_GAIN=-3 gave UGF of around 80 Hz.
 - LO PHASE was locked with BH55_Q, no offset. FM5, FM8 on, C1:HPC-LO_PHASE_GAIN=-2 feeding back to LO1 gave UGF of around 40 Hz.
 - Attachment #1 shows the OLTFs.

Sensitivity estimate:
 - Sensitivity was estimated using measured actuator gains and optical gains. Following numbers are used.

C1:LSC-AS55_Q_ERR to MICH 1.08e-9 counts/m (measured at 311.1 Hz today)
C1:HPC-BHDC_DIFF to MICH 1.91e-9 counts/m (measured at 311.1 Hz today)
BS   : 26.54e-9 /f^2 m/counts (40m/17285)
LO1  : 26.34e-9 /f^2 m/counts (40m/17285)

 These numbers were also reflected to C1:CAL-MICH_CINV and C1:CAL-MICH_A.
 C1:CAL-MICH_A_GAIN = 0.5 was used to take into account of LSC output matrix of MICH to BS being C1:LSC-OUTPUT_MTRX_8_2=0.5.

 - Attachment #2 shows the displacement spectrum of MICH (top) and LO PHASE (bottom). Brown MICH curve is when locked with AS55_Q and black MICH curve is when locked with BHD_DIFF. RMS of original and in-loop LO PHASE was estimated to be

 Original LO phase noise: 393 nm RMS (266 deg RMS)
 In-loop LO phase noise: 19.4 nm RMS (13 deg RMS)

Next:
 - Improve LO phase loops to reduce LO phase noise
 - Estimate LO phase noise contribution to MICH sensitivity

Attachment 1: Screenshot_2022-11-21_17-33-20_OLTF.png
Screenshot_2022-11-21_17-33-20_OLTF.png
Attachment 2: Screenshot_2022-11-21_17-45-25_MICHBHDDisplacement.png
Screenshot_2022-11-21_17-45-25_MICHBHDDisplacement.png
  17296   Mon Nov 21 18:43:46 2022 yutaUpdateBHDc1hpc and c1lsc modified to send BHD_DIFF and BHD_SUM

[Anchal, Yuta]

To send BHD signals from c1hpc after unwhitening and taking sum/diff, c1hpc and c1lsc models are modified.
PDDC_DOF_MTRX medm screen was modified to reflect this change.
We don't need to unwhiten and take sum/diff again in c1lsc model anymorewink
 

Attachment 1: Screenshot_2022-11-21_18-42-49_BHD.png
Screenshot_2022-11-21_18-42-49_BHD.png
  17301   Wed Nov 23 11:06:08 2022 AnchalUpdateBHDc1hpc and c1sus modified to add BS dither and demodulation option

c1hpc has option of dithering BS now (sending excitation to BS LSC port to c1sus over IPC). This is available for demodulating BHDC and BH55 signals. Also BS is a possible feedback point, however, we would stick to using LSC screen for any MICH locking.

c1sus underwent 2 changes. All suspension models were upgraded to the new suspension model (see 40m/16938 and 40m/17165). Now the channel data rates are set in simulink model and activateDQ script is not doing anything for any of the suspension models.

  17302   Wed Nov 23 12:58:33 2022 YehonathanUpdateBHDSome more calculations

Changed the BHD BS transmissivity to 0.56.

Demodulation Phases

As was noted before. The LO phase sensitivity plot vs LO phase from the previous elog shows the optimal sensitivity at each LO phase. That means that the optimal demodulation phase might change as a function of LO phase. Attachment 1 shows the previous plot and a plot showing the optimal modulation phase for some of the methods. When double demodulation is involved I optimize one modulation and show the optimal demodulation angle of the second. As can be seen, optimal audio demodulation angles don't change as a function of LO phase.

Additionally, as expected maybe, for the single RF sideband methods that nominally should not have worked at nominal LO phase (angle in which BHD Diff is most sensitive to MICH), the optimal demodulation angle changes quite a bit around the nominal LO phase.

Fixed demodulation angle

Attachment 2 shows the LO phase sensitivity in the single 55MHZ sideband method when we fix the demodulation angle. -23.88 is the demod angle optimal for nominal LO phase. 66.12 is 90 degrees away from that. -75.21 is the is the demod angle optimal for LO phase at the amplitude quadrature and 14.78 is 90 degrees away from that. It can be seen that fixing the demod angle can be mostly harmless.

Effect of MICH offset

The simulations were run with 0 MICH offset. Attachment 3 shows the LO phase sensitivity of the different methods when MICH offset is introduced together with the optimal demod angle. As expected the single RF SB methods are sensitive to this offset while the double demod methods are not since they are not relying on DC fields.

Quote:

[Yehonathan, Yuta, Paco]

We would like to estimate:

  • LO phase sensitivty (for RF55 + audio dither scheme), as a function of RF demod angle (both I and Q); not to be confused with audio dither angle.
  • LO phase sensitivity (for all schemes like in Attachment #2 of this previous post) but with some nonzero MICH offset.
  • LO phase sensitivity (for RF55 + audio dither scheme) but with the uBHDBS (44:56) values from this post.

 

Attachment 1: LO_phase_sens_vs_LO_phase_RF.pdf
LO_phase_sens_vs_LO_phase_RF.pdf
Attachment 2: LO_phase_sens_vs_LO_phase_RF_fixed_demod.pdf
LO_phase_sens_vs_LO_phase_RF_fixed_demod.pdf
Attachment 3: LO_phase_sens_vs_MICH_Offset.pdf
LO_phase_sens_vs_MICH_Offset.pdf
  17303   Wed Nov 23 14:59:11 2022 PacoSummaryBHDBHD_DIFF sensitivity to BS dither with MICH Offset

[Yuta, Paco, Anchal]

We measured

(a) BHDC_DIFF sensitivity to BS dither for a set of MICH offsets.


Configurations

  • MICH locked with AS55_Q
    • The MICH offset was varied below
  • LO_PHASE locked with BH55_Q
    • Balanced DCPD_A and DCPD_B by applying a digital gain of 1.00 to DCPD_A
    • Changed the BH55 demod angle to 140.07 deg to minimize BH55_I
  • BS dither at 311.1 Hz
    • Use newly added HPC_BS Lockins to readback the demodulated signals

Results & Discussion

The analysis was done with the '/cvs/cds/rtcds/caltech/c1/Git/40m/scripts/CAL/BHD/BHD_DIFFSensitivity.ipynb' notebook.

Attachment #1 shows the main result showing the sensitivity of various demodulated error signals at 311.1 Hz for a set of 21 MICH offsets. We noted that if we didn't randomize the MICH offset scan, we observed a nonzero "zero crossing" for the offset.
Note that, although LO_PHASE loop was always on to control the LO phase to have zero crossing of BH55_Q, actual LO phase is not constant over the measurement, as MICH offset changes BH55_Q zero crossing.
When MICH offset is zero, LO_PHASE loop will control the LO phase to 0 deg (90 deg away from optimal phase), and BHDC_DIFF will not be sensitive to MICH, but when MICH offset is added, BHDC_DIFF start to have MICH sensitivity (measurement is as expected).
For BHDC_SUM, MICH sensitivity is linear to MICH offset, as it should be the same as ASDC, and does not depend on LO phase (measurement is as expected).
For BH55_Q, MICH sensitivity is maximized at zero MICH offset, but reduces with MICH offset, probably because LO phase is also being changed.


Attachment 1: BHDIFF_rand_SensvsMICHOffset.pdf
BHDIFF_rand_SensvsMICHOffset.pdf
  17308   Wed Nov 23 17:28:39 2022 YehonathanUpdateBHDSome more calculations

Fields at the BHD BS. More on this later.

Attachment 1: Fields_at_BHDBS.pdf
Fields_at_BHDBS.pdf
  17309   Wed Nov 23 20:58:23 2022 yutaSummaryBHDBHD_DIFF sensitivity to BS dither with MICH Offset with different BH55 demodulation phases

[Anchal, Paco, Yuta]

Attachment #1 is the same plot as 40m/17303 but with MICH sensitivity for ASDC and AS55 also included (in this measurement, BH55 demodulation phase was set to 140.07 deg to minimize I fringe).
Y-axis is now calibrated in to counts/m using BS actuation efficiency 26.54e-9 /f^2 m/counts (40m/17285) at 311.1 Hz.
2nd X-axis is calibrated into MICH offset using the measured AS55_Q value and it's MICH sensitivity, 8.81e8 counts/m (this is somehow ~10% less than our usual value 40m/17294).
ASDC have similar dependence with BHDC_SUM on MICH offset, as expected.
AS55_Q have little dependence with MICH offset on MICH offset, as expected.

This plot tells you that even a small MICH offset at nm level can create MICH sensitivity for BHDC_DIFF, even if we control LO phase to have BH55_Q to be zero, as MICH offset shifts zero crossing of BH55_Q for LO phase.

Notebook: /opt/rtcds/caltech/c1/Git/40m/scripts/CAL/BHD/BH_DIFFSens_pydemod.ipynb

Attachment #2 is the same plot, but BH55 demodulation phase was tuned to 227.569 deg to have no MICH signal in BH55_Q (a.k.a measurement (c)).
In this case, LO phase will be always controlled at 0 deg (90 deg away from optimal), even if we change the MICH offset, as BH55_Q will not be sensitive to MICH.
In this plot, BHD_DIFF have little sensitivity to MICH, irrelevant of MICH offset, as expected.
MICH sensitivity for BH55_I is also constant, which indicate that LO phase is constant over this measurement, as expected.

Notebook: /opt/rtcds/caltech/c1/Git/40m/scripts/CAL/BHD/BH_DIFFSens_pydemod.ipynb

Attachment #3 is the same plot, but BH55 demodulation phase was tuned to 70 deg.
This demodulation phase was tuned within 5 deg to maximize MICH signal in BHD_DIFF with large MICH offset (20).
In this case, LO phase will be always controlled at 90 deg (optimal), even if we change the MICH offset, as BH55_Q will not be sensitve to LO carrier x AS sideband component of the LO phase signal.
In this plot, BHD_DIFF have high sensitivity to MICH, irrelevant of MICH offset (at around zero MICH offset it is hard to see because LO_PHASE lock cannot hold lock, as there will be little LO phase signal in BH55_Q, and measurement error is high for BHD_DIFF and BH55 signals).
MICH sensitivity for BH55_I and BH55_Q is roughly constant, which indicate that LO phase is constant over this measurement, as expected.

These plots indicate that BH55 demodulated at MICH dither frequency can be used to control LO phase robustly at 90 deg, under unknown or zero MICH offset.


Notebook: /opt/rtcds/caltech/c1/Git/40m/scripts/CAL/BHD/BH_DIFFSens_pydemod.ipynb

LO phase delay:
 From these measurements of demodulation phases, I guess we can say that phase delay for 55 MHz in LO path with respect to MICH path (length difference in PR2->LO->BHDBS and PR2->ITMs->AS->BHDBS) is

2*(227.569-70(5)-90)-90 = 45(10) deg

 This means that the length difference is (omegam=5*2*pi*11.066195 MHz)

c * np.deg2rad(45(10)+360) / omegam = 6.1(2) m   (360 deg is added to make it close to the design)

  Is this consistent with our design? (According to Yehonathan, it is 12.02 m - 5.23 m = 6.79 m)

  Attachment #4 illustrates signals in BH55.

Next:
 - Lock LO PHASE with BH55 demodulated at MICH dither frequency (RF+audio double demodulation), and repeat the same measurement
 - Finer measurement at small MICH offsets (~1nm) to see how much MICH offset we have
 - Repeat the same measurement with BH55_Q demodulation phase tuned everytime we change the MICH offset to maximize LO phase sensitivity in BH55_Q (a.k.a measurement (b)).
 - What is the best way to tune BH55 demodulation phase?

Attachment 1: BHDIFF_rand_SensvsMICHOffset_pydemod.pdf
BHDIFF_rand_SensvsMICHOffset_pydemod.pdf
Attachment 2: BHDIFF_rand_SensvsMICHOffset_pydemod_NoMICHinBH55Q.pdf
BHDIFF_rand_SensvsMICHOffset_pydemod_NoMICHinBH55Q.pdf
Attachment 3: BHDIFF_rand_SensvsMICHOffset_pydemod_BH55at70deg.pdf
BHDIFF_rand_SensvsMICHOffset_pydemod_BH55at70deg.pdf
Attachment 4: MICHBHD_BH55.pdf
MICHBHD_BH55.pdf
  17317   Mon Nov 28 16:53:22 2022 AnchalSummaryBHDF2A filters on LO1 LO2 AS1 and AS4

[Paco, Anchal]

I changed the script in /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/outMatFilters/createF2Afilters.py to read the measured POS resonant frequencies stored in /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMatCalc/resFreqs.yml instead of using the estimate sqrt(g/len). I then added Q = 3 F2A filters into FM1 output filter of LO1, LO2, AS1 and AS4 suspensions in anticipation of BHD locking scheme work.

  17319   Mon Nov 28 18:21:50 2022 PacoSummaryBHDBH44 prep

I checked the LSC rack to evaluate what we might need to generate 44 MHz rf in the hypothetical case we go from BH55 to BH44 (a.k.a. double RF demod scheme). There is an 11 MHz LO port labeled +16 dBm (measured 9 Vpp ~ 23 dBm actually) on the left hand side. Furthermore, there is an unused 55 MHz port labeled "Spare 55 LO". I checked this output to be 1.67 Vpp ~ +8.4 dBm. Anyways the 55 MHz doesn't look very nice; after checking it on the spectrum analyzer it seems like lower frequency peaks are polluting it so it may be worth checking the BH55 LO (labeled REFL 55) signal to see if it's better. Anyways we seem to have the two minimum LOs needed to synthesize 44 MHz in case we move forward with BH44.


[Paco, Yuta]

We confirmed the noisy 55 MHz is shared between AS55, BH55 and any other 55 MHz LOs. Looking more closely at the spectrum we saw the most prominent peaks at 11.06 MHz and 29.5 MHz (IMC and PMC nominal PM freqs). This 55 MHz LO is coming all the way from the RF distribution box near the IOO rack. According to this diagram, this 55 MHz LO should have gone through a bandpass filter; interestingly, checking the RF generation box spare 55 MHz the output is *cleaner* and displays ~ 17 dBm level... ??? Will continue investigating when we actually need this RF.

  17322   Tue Nov 29 15:32:32 2022 AnchalUpdateBHDc1hpc model updates to support double audio dither

Many changes have been done to c1hpc to support dual demodulation at audio frequencies. We moved away with ASS style of lockin setup as the number of connections and screens required would become very large. Instead now, the demodulation is done for a selected oscillator, on a selected signal. Similarly, the demodulated signal can be further demodulated for another selected oscillator. Please familarize yourself with new screen and test the new model. The previous version of the model is kept as backup alogn with all it's medm screens, so nothing is lost. Shown as an example in the screenshot, AS1 and BS oscillators can be turned on, and BHDC_DIFF signal can be demodulated first with BS and next with AS oscillator to get the signal.

Attachment 1: Screenshot_2022-11-29_15-36-05.png
Screenshot_2022-11-29_15-36-05.png
  17339   Tue Dec 6 13:09:44 2022 yutaUpdateBHDc1cal model updates to support sensing matrix for BHD

[Anchal, Yuta]

We have modified c1cal model to support sensing matrix measurements for BHD PDs on Friday last week.
c1cal model now can inject dither to LO1, LO2, AS1, and AS4, and demodulate BH55_I, BH55_Q, BHDC_SUM and BHDC_DIFF signals.
Related models, c1lsc, c1hpc, and c1sus2 are also modifed accordingly.
MEDM screens are also edited accordingly.
Attachments highlight the modifications.

Attachment 1: Screenshot_2022-12-06_13-02-05_c1calMEDM.png
Screenshot_2022-12-06_13-02-05_c1calMEDM.png
Attachment 2: Screenshot_2022-12-06_13-06-35_c1lsc.png
Screenshot_2022-12-06_13-06-35_c1lsc.png
Attachment 3: Screenshot_2022-12-06_13-07-14_c1cal.png
Screenshot_2022-12-06_13-07-14_c1cal.png
Attachment 4: Screenshot_2022-12-06_13-07-50_c1caldemod.png
Screenshot_2022-12-06_13-07-50_c1caldemod.png
  17343   Tue Dec 6 17:12:23 2022 yehonathanSummaryBHDLO phase control using audio (MICH and AS1) + RF

{Yuta, Yehonathan}

Today we lock LO phase using audio+RF method in two variants: AS1+RF and MICH(BS)+RF. We measure the TFs and find that AS1 variant has a UGF ~ 17Hz and MICH variant has a UGF ~ 32Hz.

Details

1. We lock MICH in the usual way using AS55. ITMs are aligned to make AS port dark. We use a single bounce and optimize mode-matching with LO beam by minimizing the BHDDC-A signal.

2. Using the new BHD Homodyne phase control MEDM screen we first try AS1. We put an elliptic filter with 80Hz corner frequency on the DEMOD1 filter bank. We find that the notch of that filter is at 281.768Hz and this is where we put the AS1 dither line.

AS1 is dithered with 20000 counts. We optimize the DEMOD1 demodulation angle by dithering LO1 at 27Hz and minimizing the Q quadrature in diaggui. We find that 45 degrees is the optimal demod angle. We lock the LO phase with a gain of ~ 45 and take the OLTF (attachment 1).

3. Next, we use MICH degree of freedom to lock LO phase. We dither BS with the same frequency as before with 4000 counts. Higher counts seem to put some offset on ASDC. As before we optimize the DEMOD1 demod angle and find it to be 115deg. We lock LO phase with a gain of 20 and take the OLTF (attachment 2).

 

Attachment 1: Screenshot_2022-12-06_16-44-37_LOPHASE_OLTF_BH55_Q_AS1dither.png
Screenshot_2022-12-06_16-44-37_LOPHASE_OLTF_BH55_Q_AS1dither.png
Attachment 2: Screenshot_2022-12-06_17-10-47_LOPHASE_OLTF_BH55_Q_BSdither.png
Screenshot_2022-12-06_17-10-47_LOPHASE_OLTF_BH55_Q_BSdither.png
  17345   Wed Dec 7 16:21:05 2022 yutaSummaryBHDImproved MICH BHD alignment

[Yehonathan, Yuta]

We found that moving AS1 in yaw improves power on ASDC and AS55.
We compensated this move with AS4 and SR2 to keep the BHD fringe (ITM single bounce and LO beam fringes ~600 counts in amplitude at BH55).
We have also aligned BHD CCD camera to avoid clipping on a lens just before the camera (all the other optics on ITMY table remain untouched).
After the alignment, MICH BHD sensing matrix were measured with new C1CAL model (40m/17339) under the following conditions.
 - Locked MICH with AS55_Q at dark fringe. Notch at 311.1 Hz was turned on.
 - Locked LO PHASE with BH55_Q with C1:HPC-LO_PHASE_GAIN=-2, using LO1.

Sensing matrix with the following demodulation phases (counts/m)
{'AS55': -161.16488964312092, 'BH55': 162.57275834049358}
Sensors      BS @311.1 Hz           LO1 @147.1 Hz           AS1 @141.79 Hz           
AS55_I       (-0.19+/-1.45)e+07    (-0.26+/-2.43)e+06    (+0.35+/-2.39)e+06    
AS55_Q       (-1.74+/-0.02)e+09    (+1.61+/-8.31)e+06    (+1.08+/-8.59)e+06    
BH55_I       (+3.01+/-0.17)e+09    (+3.20+/-9.59)e+07    (-3.67+/-9.46)e+07    
BH55_Q       (-6.77+/-0.45)e+09    (+1.09+/-0.17)e+09    (-1.22+/-0.18)e+09    
BHDC_DIFF    (-8.41+/-4.81)e+08    (-1.26+/-0.94)e+08    (+1.38+/-1.03)e+08    
BHDC_SUM     (-2.75+/-9.14)e+07    (+1.18+/-1.13)e+07    (-0.97+/-1.02)e+07  
 


AS55_Q optical gain to MICH and BH55_Q optical gain to LO phase was improved by ~45%, compared with previous measurements (see 40m/17287).
The value for AS55_Q is consistent with the free swing measurement as attached.
SENSMAT part of c1cal seems to be working fine.

Attachment 1: LSC-AS55_Q_ERR_DQ_1354479181.png
LSC-AS55_Q_ERR_DQ_1354479181.png
  17347   Thu Dec 8 17:52:39 2022 yutaSummaryBHDMICH BHD optical gain measurements at different LO phases, RF+audio dither

[Yehonathan, Yuta]

Sensing matrix measurements at different LO phases were performed under LO phase locked to both BH55_Q and BH55_Q+MICH dither.
We confirmed that BH55_Q+MICHdither can lock LO phase to around maximum MICH sensitivity for BHD_DIFF.

Locking configuratons
 - MICH was lockied using AS55_Q feeding back to BS, at dark fringe. Notch at 311.1 Hz was turned on. C1:LSC-MICH_GAIN=-6 (lowered to reduce BS DAC saturation).
 - LO PHASE was locked using BH55_Q, feeding back to LO1. FM2, FM5, FM8 on. C1:HPC-LO_PHASE_GAIN=+/-2.
 - LO PHASE was also locked using BH55_Q+MICHdither. BS was dithered with C1:HPC-BS_POS_OSC_CLKGAIN=4000 at 281.768 Hz (2nd notch of ELP80 used for demodulation). Feeding back to LO1. FM5, FM8 on (no LF boost). C1:HPC-LO_PHASE_GAIN=+/-20.
  -- Note that we could not increase the dither amplitude more as BS DAC starts to saturate (we are using BS for MICH loop, sensing matrix measurement, and audio dither; see 40m/17343).

Sensing martix measurements
 - Lines are injected to BS @ 311.1 Hz with amplitude of 1000, LO1 @ 147.1 Hz and AS1 @ 141.79 Hz with amplitude of 5000.

Estimating LO phase
 - Estimation of LO phase was done in the same way described in 40m/17287. We used measured sensitivity of BH55_Q for LO1 at BH55_Q zero crossing (-1.42e9 counts/m) to estimate LO phase offset from BH55_Q zero crossing.
 - In BH55_Q+MICHdither case, LO phase was flipped using the following equation when C1:HPC-LO_PHASE_GAIN is minus (to have consistend LO phase dependence with BH55_Q locking. NEEDS CHECK).

LOphase = 180 - arcsin(BH55_Q/A)

Result
 - Attachment #1 shows the sensitivity of AS55, BH55, BHDC_DIFF/SUM to BS (upper panel), LO1 (middle) and AS1 (lower), under LO phase locked to BH55_Q. The upper plot is the same plot as 40m/17287. As we can see, "0 deg" in the x-axis is not the optimal phase for BHDC_DIFF to have maximum MICH sensitivity. "0 deg" is the optimal point in terms of BH55_Q sensitivity to LO1/AS1, as we tuned the demodulation phase to maximize it.
 - Attachment #2 shows the same plot, under LO phase locked to BH55_Q+MICH dither. Sensitivity of BH55_Q to MICH crosses zero at round these measurements, as we are zero-ing it with this locking scheme. Around these LO phases, sensitivity of BHDC_DIFF to MICH is maximized as expected. Also, sensitivity of BHDC_DIFF to LO1/AS1 is minimized, as expected (assuming residual MICH offset and contrast defect are small).
 - Attachment #3 is the combined data from #1 and #2. Data points from BH55_Q locking are marked with "o" and those from BH55_Q+MICH dither locking are marked with "x" (they have larger uncertainties in LO phase). Both measurements are somewhat inconsistent in some channels (BS to BHDC_DIFF and LO1/AS1 to BH55_Q). Needs further investigation.
 - Dashed lines are from scipy.optimize.curve_fit using the following fitting function.

def fitfunc(x, a,b,c):
    return a*np.sin(np.deg2rad(x-b))+c

Notebook: /opt/rtcds/caltech/c1/Git/40m/scripts/CAL/SensingMatrix/SensMatBHDvsLOPhase.ipynb

Next:
 - Lock MICH with BHDC_DIFF under LO phase locked to BH55_Q+MICHdither
 - Estimate LO phase noise contribution to MICH displacement sensitivity
 - Improve LO phase loop
 - Try audio+audio dither
 - Move on to FPMI
 - Move on to 44MHz
 - Estimate the amount of residual MICH offset and contrast defect from these plots

Attachment 1: BHDMICHSensingMatixvsLOPhase1354581028.pdf
BHDMICHSensingMatixvsLOPhase1354581028.pdf
Attachment 2: BHDMICHSensingMatixvsLOPhase1354580582.pdf
BHDMICHSensingMatixvsLOPhase1354580582.pdf
Attachment 3: BHDMICHSensingMatixvsLOPhaseCombined.pdf
BHDMICHSensingMatixvsLOPhaseCombined.pdf
  13   Thu Oct 25 00:01:21 2007 ranaSoftware InstallationCDSGEO DV => LIGO DV
Martin Hewitson of GEO600 fame has modified the cool GEO DV
to work with the LIGO NDS system with some NDS advice from Rolf (who's over in Germany this week).

I've moved it onto the 40m CDS system and installed it on the AdhikariLab computer named 'django'. It worked immediately.

I modified the main .m file to include the 40m's NDS server. When you run it you have to include the path to the NDS
client written by Ben Johnson.

The attached is a screenshot of it working on a Mac; it looks as cool on Linux.

Its installed in /cvs/cds/caltech/apps/ligoDV/. In matlab you navigate to that directory and then
type addpath('/cvs/cds/caltech/apps/linux/UNIX_NDS_Client_beta2/') to add the NDS client.
On the Solaris machines, type type addpath('/cvs/cds/caltech/apps/solaris9/UNIX_NDS_Client_beta2/') instead.

Then type ligoDV to start it up. Then click away and have fun.

In the example I've selected
C1:PEM-BS_ACC_EAST_Z
and plotted its specgram.

Big grin
Attachment 1: Picture_1.png
Picture_1.png
  28   Mon Oct 29 23:25:42 2007 tobinSoftware InstallationCDSframes mounted
I mounted the frames directory on mafalda and linux3. It's intentionally not listed in the /etc/fstab so that an fb crash won't prevent the controls machines from booting. The command to mount the frames directory is:

mount fb40m:/frames/frames /frames
  144   Fri Nov 30 11:22:22 2007 ajwSummaryCDSGEO DV => LIGO DV

Quote:
Martin Hewitson of GEO600 fame has modified the cool GEO DV
to work with the LIGO NDS system with some NDS advice from Rolf (who's over in Germany this week).

I've moved it onto the 40m CDS system and installed it on the AdhikariLab computer named 'django'. It worked immediately.

I modified the main .m file to include the 40m's NDS server. When you run it you have to include the path to the NDS
client written by Ben Johnson.

The attached is a screenshot of it working on a Mac; it looks as cool on Linux.

Its installed in /cvs/cds/caltech/apps/ligoDV/. In matlab you navigate to that directory and then
type addpath('/cvs/cds/caltech/apps/linux/UNIX_NDS_Client_beta2/') to add the NDS client.
On the Solaris machines, type type addpath('/cvs/cds/caltech/apps/solaris9/UNIX_NDS_Client_beta2/') instead.

Then type ligoDV to start it up. Then click away and have fun.

In the example I've selected
C1:PEM-BS_ACC_EAST_Z
and plotted its specgram.

Big grin


Download and installation instructions, as well as a few examples for use
can be found here (typical lsc username and password):

https://www.gravity.phy.syr.edu/dokuwiki/doku.php?id=ligodv:home
https://www.gravity.phy.syr.edu/dokuwiki/doku.php?id=ligodv:downloading_the_ligodv_software
  170   Wed Dec 5 19:25:07 2007 ranaDAQCDSDMF
I made a database file on C1AUX called dmf.db. It has 9 DMF EPICS channels which are also trended
so that one can now write data to those channels from a DMF Monitor and the data will be records.

New channels:
[C1:DMF-SEIS_1]
[C1:DMF-SEIS_2]
[C1:DMF-SEIS_3]
[C1:DMF-LINE_1]
[C1:DMF-LINE_2]
[C1:DMF-LINE_3]
[C1:DMF-MC_1]
[C1:DMF-MC_2]
[C1:DMF-MC_3]

I added these to C1AUX because it doesn't do much and can be booted without having much effect.
(it controls Mech Shutters, Video, and Illuminators. It used to also do the EO Shutter but I
removed that from its startup.cmd and it will no longer load those records).
  270   Fri Jan 25 21:36:40 2008 ranaUpdateCDSmDV / channel issues
Fri Jan 25 21:30:00 2008

As it turns out, the residual problem with the mDV stuff was not to do with our button pushing episode but instead fallout from the 'turning off of the computers' during the water leak caused by the rain and construction.

The /frames partition from fb0 (the FrameBuilder) is not mounted to the control machines via vfstab; it does not remount on bootup. I originally did this because Ben Johnson and Dave Barker had warned me that during a power outage, fb0 may not come up right away. This could make the control room machines hang up for awhile. I elected to have the mount be by hand.

So the thing to do is to put the mount command into the cold start procedures (Andrey). Its in an old elog entry of mine from Feb '07.
  278   Sun Jan 27 21:44:48 2008 ranaUpdateCDSSeismic BLRMS on Matlab
I wrote a matlab script to produce band limited RMS trends from our accelerometers. It mimics the code written
by Ed Daw which makes the seismic FOMs at the sites.

Here's how it works:
  • Use mDV to get data by reading directly from frames.
  • Use the Matlab pwelch function to produce a power spectrum of the channels.
  • Use the Matlab find function and rms.m to get the RMS in user-defined frequency bands.
  • Makes a tdswrite command string which writes all the values to EPICS channels.
  • The EPICS channels are just a list of simple names in a database file.
  • The channel names are (will be) added to the C0EDCU.ini file so that its all trended.

The code is in the mDV/extra/C1 directory; its ~20 lines of code (excluding comments and spaces).

Next up is to add more DMF trend channels to the database and upgrade the code to use a .conf file
instead of hardcoded channel names. We should also evaluate if the bands I used are appropriate for the 40m;
I just used Ed's choices (0.1-0.3, 0.3-1, 1-3, 3-10, and 10-30 Hz).

In the medium term, we should make this compiled (like what RW did with the linetracker), and explore if we
want it to write values faster than 1/minute.
Attachment 1: seisBLRMS.m
% Seismic BLRMS Monitor
%
%
%
% RA 08-01-26

% 0 for no messages, 1 for debugging
debug_flag = 1;

% ------------ Build channel list
... 82 more lines ...
  356   Tue Mar 4 19:14:09 2008 ranaConfigurationCDSTDS & SVN
Matt, Rob, Rana

Today we added the TDS software to the 40m SVN repo.

First we rationalized things by deleting all the old TDS directories and taking
the tds_mevans dir and making it be the main one (apps/linux/tds).

We also deleted all of the TDS directories in the project area. It is now very
likely that several scripts will not work.
We're going to have the teething
problems of repointing everything to the nominal paths (in the apps areas).

Finally we did:
svn import tds https://40m.ligo.caltech.edu/svn/40m/tds --username rana

to stick it in. To check it out do:
svn checkout https://40m.ligo.caltech.edu/svn/40m/tds --username rana

We'll get a couple of the O'Reilly SVN books as well to supplement our verion control knowledge.
Unitl then you can use the SVN cheat sheets available at:
http://www.digilife.be/quickreferences/quickrefs.htm
  383   Sun Mar 16 17:03:32 2008 robConfigurationCDSASS code change

I've updated the ass.mdl file in the directory:

/cvs/cds/caltech/users/alex/cds/advLigo/src/epics/simLink/

to get us started in the adaptive PEM noise subtraction.

After several iterations of remote help from Alex, the code compiles and runs, receives signals from the LSC, PEM, and MC2, and communicates with the suspension controllers. I've also adapted the .par file from the code generator, but haven't got the testpoints working with the new ASS code. There are no MEDM screens yet, and Matt's adaptive filter code has not been installed (there's a matrix as a placeholder).

Putting in the adaptive code should be simple, building the MEDM screens tedious, and getting the testpoints working uncertain. I noticed that the new testpoint.par file starts at a different channel number than the previous (working) version, which is strange. I probably have a script somewhere to change all these numbers by a constant offset, but I don't know if that's the actual problem--maybe stuff just needs to be rebooted.

The code receives as input the first 24 channels from the PEM ADCU, the eight suspension control signals from the LSC, and the output of the MCL filter from MC2. It outputs to the MCL filter input of each suspension (except MC2).
  394   Sat Mar 22 22:39:02 2008 mevansSummaryCDSDirect Form 2 filters are bad
Here I show a comparison between the filter algorithm currently used in LIGO (Direct Form II), and an alternative algorithm designed to reduce numerical noise. The input signal is

x = sin(2 * pi * t) + 1e-9 * sin(2 * pi * (fs / 4) * t);

where fs = 16384 is the sample rate. The filter is a 4th order notch at 1Hz (f_poles = f_zeros = 1Hz, Q_poles = 1, Q_zeros = 1e6). It is clear that the DF2 algorithm produces a noise floor that is, for this simple filter, 1e-11 / rtHz smaller than the input drive amplitude (see plots). That should probably be scary given how many second-order-sections we run our signals through. The low-noise form does a somewhat better job. The low-noise algorithm has the same memory and computational requirements as DF2, and our CDS guys have the code in hand. I suggest we start testing soon.

(The code is included below. You will need my Matlab library to run the top level test script.)
Attachment 1: low-noise_filtering.png
low-noise_filtering.png
Attachment 2: low-noise_zoom.png
low-noise_zoom.png
Attachment 3: FiltRT.zip
  459   Tue Apr 29 21:09:12 2008 ranaDAQCDSFE Filters
These are new FE filters for downsampling and upsampling. We will be going from native hardware sampling rates of 64k down to 32k, 16k, and 2k.

The attached plot shows these filters. They are 3dB ripple, 40 dB stopband, 4th order elliptic filters in which I have moved the zeros around
into good places (e.g. to the Nyquist frequency).

I'm also attaching the .txt file containg the filter coefficients and the design strings. The filters are called x2, x4, and x32, for the
D2, D4, and D32 downsampling, respectively.
Attachment 1: fefilters.jpg
fefilters.jpg
Attachment 2: fefilters.txt
# FILTERS FOR ONLINE SYSTEM
#
# Computer generated file: DO NOT EDIT
#
# MODULES ULYAW
#
################################################################################
### ULYAW                                                                    ###
################################################################################
# SAMPLING ULYAW 65536
... 28 more lines ...
  1782   Thu Jul 23 07:34:45 2009 AidanUpdateCDSAdded C2 MEDM screens to 40m SVN.

 

See Adhikari eLOG entry: http://nodus.ligo.caltech.edu:8080/AdhikariLab/194

  1801   Tue Jul 28 18:32:21 2009 KojiUpdateCDSRCG work

Peter and Koji,

We are constructing a setup for the new 40m CDS using Realtime Code Generator (RCG).
We are trying to put simulated suspensions and test suspension controllers on a different processors of megatron
in order to create a virtual control feedback loop. Those CDS processes are communicating
each other via a shared memory, not via a reflective memory for now.

After some struggles with tremendous helps of Alex, we succeeded to have the communication between the two processes.
Also we succeeded to make the ADC/DAC cards recognized by megatoron, using the PCI express extension card replaced by Jay.
(This card runs multi PCI-X cards on the I/O chasis.)

Next steps:
- Establish a firewall between the 40m network and megatron (Remember this)
- Make DTT and other tools available at megatron
- Try virtual feedback control loops and characterize the performance
- Enable reflective memory functionalities on megatron
- Construct a hybrid system by the old/new CDSs
- Controllability tests using an interferometer


Note on MATLAB/SIMULINK
o Each cdsIPC should have a correct shared memory address spaced by 8 bytes. (i.e. 0x1000, 0x1008, 0x1010, ...)

Note on MEDM
o At the initial state, garbage (e.g. NaN) can be running all around the feedback loops. They are invisible as MEDM shows them as  "0.0000".
To escape from this state, we needed to disconnect all the feedback, say, by turning off the filters.

Note on I/O chasis
o We needed to pull all of the power plugs from megatron and the I/O chasis once so that we can activate
the PCI-e - PCI-X extension card. When it is succeeded, all (~30) LEDs turn to green.

  2045   Fri Oct 2 18:04:45 2009 robUpdateCDSDTT no good for OMC channels

I took the output of the OMC DAC and plugged it directly into an OMC ADC channel to see if I could isolate the OMC DAC weirdness I'd been seeing.  It looks like it may have something to do with DTT specifically.

Attachment 1 is a DTT transfer function of a BNC cable and some connectors (plus of course the AI and AA filters in the OMC system).  It looks like this on both linux and solaris.

Attachment 2 is a transfer function using sweepTDS (in mDV), which uses TDS tools as the driver for interfacing with testpoints and DAQ channels. 

Attachment 3 is a triggered time series, taken with DTT, of the same channels as used in the transfer functions, during a transfer function.  I think this shows that the problem lies not with awg or tpman, but with how DTT is computing transfer functions. 

 

I've tried soft reboots of the c1omc, which didn't work.   Since the TDS version appears to work, I suspect the problem may actually be with DTT.

Attachment 1: omc_dac_dtt.png
omc_dac_dtt.png
Attachment 2: omc_dac_sweepTDS.png
omc_dac_sweepTDS.png
Attachment 3: omc_dac_dtt_ts.png
omc_dac_dtt_ts.png
  2173   Tue Nov 3 12:47:01 2009 KojiConfigurationCDS1Y9 Rack configuration update

For the CDS upgrade preparation I put and moved those stuff at the rack 1Y9:

Placed 1Y9-12 ADC to DB44/37 Adapter LIGO D080397

Placed 1Y9-14 DAC to IDC Adapter LIGO D080303

Moved the ethernet switch from 1Y9-16 to 1Y9-24

Wiki has also been updated.

  2181   Thu Nov 5 16:24:59 2009 KojiUpdateCDSETMY CDS test stuff

Joe, Peter, Jay, Koji, Rana

We put the new CDS stuff at Y end 1Y9 rack.

Items

  • megatron
  • wireless router
  • IO chasis (black)
  • Extention cable (between megatron & IO chasis)
  • 1 ADC card
  • 1 DAC card
  • 1 BIO card
  • The adapter box for ADC
  • The adapter box for DAC
  • The adapter box for BIO
  • 2x IDC-DB37 cable for the ADC box - AA chasis
  • 1x IDC cable for the DAC box - Pentek
  • 1x DB cable for the BIO box
  • 1x +/-15V cable for the BIO box
  2233   Wed Nov 11 01:33:52 2009 peteUpdateCDSRCG ETMY code update

 I've added the side coil to the model controller and plant, and the oplev quad to the model controller and plant.  After the megatron wipe, the code now lives in /home/controls/cds/advLigo/src/epics/simLink.  The files are mdc.mdl (controller) and mdp.mdl (plant).  These RCG modules go at 16K with no decimation (no_oversampling=1 in the cdsParameters block) so hopefully will work with the old (16K) timing.

I've loaded many of the filters, there are some eft to do.  These filters are simply copied from the current frontend.  

Next I will port to the SUS module (which talks to the IO chassis).  This means channel names will match with the current system, which will be important when we plug in the RFM.

  2243   Wed Nov 11 20:46:07 2009 peteUpdateCDSRCG ETMY phase I update

The .mdl code for the mdc and mdp development modules is finished.  These modules need more filters, and testing.  Probably the most interesting piece left to do is putting in the gains and filters for the oplev model in mdp.  It might be OK to simply ignore oplevs and first test damping of the real optic without them.   However, it shouldn't be hard to get decent numbers for oplevs, add them to the mdp (plant) module, and make sure the mdc/mdp pair is stable.  In mdp, the oplev path starts with the SUSPIT and SUSYAW signals. Kakeru recently completed calibration of the oplevs from oplev cts to radians:   1403  .  From this work we should find the conversion factors from PIT and YAW to oplev counts, without making any new measurements.  (The measurements wouldn't be hard either, if we can't simply pull numbers from a document.)  These factors can be added to mdp as appropriate gains.

I've also copied mdc to a new module, which I've named "sas" to address fears of channel name collisions in the short term, and replaced the cpu-to-cpu connections with ADC and DAC connections.  sas can be the guy for the phase I ETMY test.  When we're happy with mdc/mdp, we hopefully can take the mdc filter file from chans, replace all the "MDC" strings with "SAS", and use it.

  2259   Thu Nov 12 17:24:29 2009 Koji, Joe, PeterConfigurationCDSETMY CDS test started

We started the test of the new CDS system at ETMY.

The plan is as follows:
We do the ETMY test from 9:30 to 15:00 at ETMY from Nov 12~17. This disables the ETMY during this period.
From 15:00 of the each day, we restore the ETMY configuration and confirm the ETMY work properly.


Today we connected megatron to the existing AA/AI modules via designated I/F boxes. The status of the test was already reported by the other entry.

During the test, c1iscey was kept running. We disabled the ETMY actuation by WatchDog. We did not touch the RFM network.

After the test we disconnected our cables and restored the connection to ICS110B and the AI/AA boards.

The WatchDog switches were released.

The lock of the ETMY was confirmed. The full interferometer was aligned one by one. Left in the full configuration with LA=off.

  2471   Sun Jan 3 08:23:39 2010 ranaConfigurationCDSautoburt.pl 'fixed' for post 2009 years

Tobin & Keith pointed out in the LLO ilog that there was a code bug in the autoburt.pl script for autoburts.

I edited the autoburt.pl script so that it will work from now until 2099 (by which time we may no longer be using this version of perl):

nodus:autoburt>diff autoburt.pl~ autoburt.pl
234c234
<     $thisyear = "200".$timestamp[5];
---
>     $thisyear = "20".$timestamp[5];

The autoburt has not been working ever since 11PM on New Year's eve.

I ran it by hand and it seems to run fine. I noticed along the way that it was running on op340m (our old Sun Blade 150 machine). The autoburt.pl was pointing at /cvs/cds/bin/perl

which is Perl v5.0. I changed it to use '/usr/bin/env' and now points at '/usr/bin/perl' which is perl 5.8. It runs fine with the new perl:

op340m:scripts>time perl /cvs/cds/scripts/autoburt.pl >> /cvs/cds/caltech/logs/autoburtlog.log
5.37u 6.29s 2:13.41 8.7%

Also ran correctly, via cron, at 9AM.

  2640   Thu Feb 25 15:49:05 2010 AlbertoAoGCDSNew IO Chassis for the new CDS
Yesterday Kiwamu and I went to Downs to take all the available parts of the IO chassis that Gary and I had put together over there.
 
We've got only 3 of the 5 that we need for the Upgrade. The other 2 are currently being used for some other purpose in Downs labs.
 
I'm not sure about what each chassis has supposed to contain. They all also look different from each other.
Anyway, it looks like there should be a sort of motherboard and an IO Chassis Interface Board (DCC# D0902029) in each of them. The IO Chassis Interface Board is just a board with a bunch of PCI slots.
 
This is what the 3 chassis that we've got yesterday have:
Chassis 1
- 1 very big "motherboard"
- power supply
Chassis 2
- small motherboard
- IO Interface Board (DCC# D0902029)
- power supply
Chassis n.3
- "Dolpjin" motherboard
- IO Interface Board
- power supply
 
Apparently 2 of these 3 chassis are still missing their IO interface boards,
 
Also all chassis are still missing all the connections to powering, fans, LEDs, power and reset buttons. It's not clear how these connections should be. Gary didn't know it either.
  2824   Wed Apr 21 11:32:31 2010 josephbUpdateCDS40m CDS hardware update and software requests

This is mostly a reminder to myself about what I discussed with Jay and Alex this morning.

The big black IO chassis are "almost" done.  Except for the missing parts.  We have 2 Dolphin, 1 Large and 1 Small I/O Chassis due to us.  One Dolphin is effectively done and is sitting in the test stand.  However, 2 are missing timing boards, and 3 are missing the boards necessary for the connection to the computer.  The parts were ordered a long time ago, but its possible they were "sucked to one of the sites" by Rolf (remember this is according to Jay).  They need to either track them down in Downs (possibly they're floating around and were just confused by the recent move), get them sent back from the sites, or order new ones (I was told by one person that the place they order from them notoriously takes a long time, sometimes up to 6 weeks.  I don't know if this is exaggeration or not...).  Other than the missing parts, they still need to wire up the fans and install new momentary power switches (apparently the Dolphin boards want momentary on/off buttons).  Otherwise, they're done.

We are due another CPU, just need to figure out which one it was in the test stand.

6 more BIO boards are done.  When I went over the plans with Jay, we realized we needed 7 more, not 6, so they're putting another one together.  Some ADC/DAC interface boards are done.  I promised to do another count here, to determine how many we have, how many we need, and then report that back to Jay before I steal the ones which are complete.  Unfortunately, he did not have a new drawing for the ASC/vertex wiring, so we don't have a solid count of stuff needed for them.  I'll be taking a look at the old drawings and also looking at what we physically have.

I did get Jay to place the new LSC wiring diagram into the DCC (which apparently the old one never was put in or we simply couldn't find it).  Its located at: https://dcc.ligo.org/cgi-bin/private/DocDB/ShowDocument?docid=10985

I talked briefly with Alex, reminded him of feature requests and added a new one:

1) Single part representing a matrix of filter banks

2) Automatic generation of Simulated shared memory locations and an overall on/off switch for ADC/DACs

3) Individual excitation and test point pieces (as opposed to having to use a full filter bank).  He says these already exist, so when I do the CVS checkout, I'll see if they work.

 

I also asked where the adl default files lived, and he pointed me at ~/cds/advLigo/src/epics/util/

In that directory are FILTER.adl, GDS_TP.adl, MONITOR.adl.  Those are the templates.  We also discovered the timing signal at some point was changed from something like SYS-DCU_ID to FEC-DCU_ID, so I basically just need to modify the .adl files to fix the time stamp channel as well.  I basically need to do a CVS checkout, put the fixes in, then commit back to the CVS.  Hopefully I can do that sometime today.

I also brought over 9 Contec DO-32L-PE boards, which are PCIe isolated digital output boards which do into the IO chassis.  These have been placed above the 2 new computers, behind the 1Y6 rack.

 

  2826   Wed Apr 21 16:48:38 2010 josephbUpdateCDSHardware update

Alberto and myself went to downs and acquired the 3rd 4x processor (Dual core, so 8x cores total) computer.  We also retrieved 6 BIO interface boards (blue front thin boxes), 4 DAC interface boards, and 1 ADC interface boards.  The tops have not been put on yet, but we have the tops and a set of screws for them.  For the moment, these things have been placed behind the 1Y6 rack and under the table behind the 1Y5 rack

.irwin.jpg

The 6 BIO boards have LIGO travelers associated with them: SN LIGO-S1000217 through SN LIGO-S1000222.

  2849   Tue Apr 27 11:16:13 2010 josephbConfigurationCDSWiki page with CDS .mdl names, shared memory allocation

I've added a new page in the wiki which describes the current naming scheme for the .mdl model files used for the real time code generator.  Note, that these model names do not necessarily have to be the names of the channels contained within.  Its still possible to make all suspension related channels start with C1:SUS- for example.  I'm also allocating 1024 8 byte channels for shared memory address space for each controller and each simulated plant.

The wiki page is here

Name suggestions, other front end models that are needed long term (HEPI is listed for example, even though we don't have it here, since in the long run we'd like to port the simulated plant work to the sites) are all welcome.

  2860   Thu Apr 29 14:37:16 2010 josephbUpdateCDSNew Channel Name to Memory Location file

Awhile back we had requested a feature for the RCG code where a single file would define a memory location's name as well as its explicit hex address.  Alex told me it had been implemented in the latest code in SVN.  After being unable to find said file, I went back and talked to him and Rolf.  Rolf said it existed, but had not been checked into the SVN yet. 

I now have a copy of that file, called G1.ipc.  It is supposed to live in /cvs/cds/caltech/chans/ipc/ , so I created the ipc directory there.  The G1.ipc file is actually for a geo install, so we'll eventually make a C1.ipc file.

The first couple lines look like:

# /cvs/cds/geo/chans/ipc/G1.ipc
[default]
ipcType=SHMEM
ipcRate=2048
ipcNum=0
desc=default entry

[G1:OMC-QPD1P]
ipcType=SHMEM
ipcRate=32768
ipcNum=0
desc=Replaces 0x2000
#[G1:OMC-NOTUSED]
#ipcType=SHMEM
#ipcRate=32768
#ipcNum=1

[G1:OMC-QPD2P]
ipcType=SHMEM
ipcRate=32768
ipcNum=1
desc=Replaces 0x2008

 

There are also section using ipcType IPC:

[G1:SUS-ADC_CH_24]
ipcType=PCI
ipcRate=16384
ipcNum=1
desc=Replaces 0x20F0
[G1:SUS-ADC_CH_25]
ipcType=PCI
ipcRate=16384
ipcNum=2
desc=Replaces 0x20F0

 

Effectively the ipcNum tells it which memory location to use, starting with 0x2000 (at least thats how I'm interpreting it.  Every entry of a given ipcType has a different ipcNum which seems to be correlated to its description (at least early on - later in the file many desc= lines repeat, which I think means people were copy/pasting and got tired of editing the file.  Once I get a C1.ipc file going, it should make our .mdl files much more understandable, at least for communicating between models.  It also looks like it somehow interacts with the ADCs/DACs with ipcType PCI, although I'm hoping to get a full intro how to use the file tomorrow from Rolf and Alex.

  2861   Thu Apr 29 15:48:47 2010 josephbUpdateCDSNew CDS overview diagram in wiki

I've added a diagram in the wiki under IFO Upgrade 2009-2010->New CDS->Diagram section Joe_CDS_Plan.pdf (the .svg file I used to create it is also there).  This was mostly an exercise in me learning inkscape as well as putting out a diagram with which lists control and model names and where they're running.

A direct link is: CDS_Plan.pdf

  2871   Mon May 3 15:39:39 2010 josephbUpdateCDSDaily Downs update

Talked with Jay briefly today.  Apparently there are 3 IO chassis currently on the test stand at Downs and undergoing testing (or at least they were when Alex and Rolf were around).  They are being tested to determine which slots refer to which ADC, among other things. Apparently the numbering scheme isn't as simple as 0 on the left, and going 1,2,3,4, etc.  As Rolf and Alex are away this week, it is unlikely we'll get them before their return date.

Two other chassis (which apparently is one more than the last time I talked with Jay), are still missing cards for communicating between the computer and the IO chassis, although Gary thinks I may have taken them with me in a box.  I've done a look of all the CDS stuff I know of here at the 40m and have not seen the cards.  I'll be checking in with him tomorrow to figure out when (and if) I have the the cards needed.

  2872   Mon May 3 16:53:27 2010 josephbUpdateCDSUpdated lsc.mdl and the ifo plant model with memory locations

I've updated the LSC and IFO models that Rana created with new shared memory locations.  I've used the C1:IFO- for the ifo.mdl file outputs, which in turn are read by the lsc.mdl file.  The LSC outputs being lsc control signals are using C1:LSC-.  Optics positions would presumably be coming from the associated suspension model, and am currently using SUP, SPX, and SPY for the suspension plant models (suspension vertex, suspension x end, suspension y end).

I've updated the web view of these models on nodus.  They can be viewed at: https://nodus.ligo.caltech.edu:30889/FE/

I've also created a C1.ipc file in /cvs/cds/caltech/chans/ipc  which assigns ipcNum to each of these new channels in shared memory.

  2877   Tue May 4 13:14:43 2010 josephbUpdateCDSlsc.mdl and ifo.mdl to build (with caveats)

I got around to actually try building the LSC and IFO models on megatron.  Turns out "ifo" can't be used as a model name and breaks when trying to build it.  Has something to do with the find and replace routines I have a feeling (ifo is used for the C1, H1, etc type replacements throughout the code).  If you change the model name to something like ifa, it builds fine though.  This does mean we need a new name for the ifo model.

Also learned the model likes to have the cdsIPCx memory locations terminated on the inputs if its being used in a input role (I.e. its bringing the channel into the model).  However when the same part is being used in an output role (i.e. its transmitting from the model to some other model), if you terminate the output side, it gives errors when you try to make.

Its using the C1.ipc file (in /cvs/cds/caltech/chans/ipc/) just fine.  If you have missing memory locations in the C1.ipc file (i.e. you forgot to define something) it gives a readable error message at compile time, which is good.  The file seems to be being parsed properly, so the era of writing "0x20fc" for block names is officially over.

  2885   Thu May 6 11:34:35 2010 robUpdateCDSlsc.mdl and ifo.mdl to build (with caveats)

Quote:

I got around to actually try building the LSC and IFO models on megatron.  Turns out "ifo" can't be used as a model name and breaks when trying to build it.  Has something to do with the find and replace routines I have a feeling (ifo is used for the C1, H1, etc type replacements throughout the code).  If you change the model name to something like ifa, it builds fine though.  This does mean we need a new name for the ifo model.

Also learned the model likes to have the cdsIPCx memory locations terminated on the inputs if its being used in a input role (I.e. its bringing the channel into the model).  However when the same part is being used in an output role (i.e. its transmitting from the model to some other model), if you terminate the output side, it gives errors when you try to make.

Its using the C1.ipc file (in /cvs/cds/caltech/chans/ipc/) just fine.  If you have missing memory locations in the C1.ipc file (i.e. you forgot to define something) it gives a readable error message at compile time, which is good.  The file seems to be being parsed properly, so the era of writing "0x20fc" for block names is officially over.

 I suggest "ITF" for the model name.

  2895   Fri May 7 14:51:04 2010 josephbUpdateCDSWorking on meta .mdl file scripts

I'm currently working on a set of scripts which will be able to parse a "template" mdl file, replacing certain key words, with other key words, and save it to a new .mdl file.

For example  you pass it the "template" file of scx.mdl file (suspension controller ETMX), and the keyword ETMX, followed by an output list of scy.mdl ETMY,  bs.mdl BS, itmx.mdl  ITMX, itmy.mdl ITMY, prm.mdl PRM, srm.mdl SRM.  It produces these new files, with the keyword replaced, and a few other minor tweaks to get the new file to work (gds_node, specific_cpu, etc).  You can then do a couple of copy paste actions to produce a combined sus.mdl file with all the BS, ITM, PRM, SRM controls (there might be a way to handle this better so it automatically merges into a single file, but I'd have to do something fancy with the positioning of the modules - something to look into).

I also have plans for a script which gets passed a mdl file, and updates the C1.ipc file, by adding any new channels and incrementing the ipcNum appropriately.  So when you make a change you want to propagate to all the suspensions, you run the two scripts, and have an already up to date copy of memory locations - no additional typing required.

Similar scripts could be written for the DAQ screens as well, so as to have all the suspension screens look the same after changing one set.

  2903   Mon May 10 17:47:16 2010 josephbSummaryCDSFinished

So I finished writing a script which takes an .ipc file (the one which defines channel names and numbers for use with the RCG code generator),  parses it, checks for duplicate channel names and ipcNums, and then parses and .mdl file looking for channel names, and outputs a new .ipc file with all the new channels added (without modifying existing channels). 

The script is written in python, and for the moment can be found in /home/controls/advLigoRTS/src/epics/simLink/parse_mdl.py

I still need to add all the nice command line interface stuff, but the basic core works.   And already found an error in my previous .ipc file, where I used the channel number 21 twice, apparently.

Right now its hard coded to read in C1.ipc and spy.mdl, and outputs to H1.ipc, but I should have that fixed tonight.

  2908   Mon May 10 20:33:29 2010 KojiSummaryCDSFinished

This IPC stuff looks really a nice improvement of CDS.

Please just maintain the wiki updated so that we can keep the latest procedures and scripts to build the models.

Quote:

So I finished writing a script which takes an .ipc file (the one which defines channel names and numbers for use with the RCG code generator),  parses it, checks for duplicate channel names and ipcNums, and then parses and .mdl file looking for channel names, and outputs a new .ipc file with all the new channels added (without modifying existing channels). 

The script is written in python, and for the moment can be found in /home/controls/advLigoRTS/src/epics/simLink/parse_mdl.py

I still need to add all the nice command line interface stuff, but the basic core works.   And already found an error in my previous .ipc file, where I used the channel number 21 twice, apparently.

Right now its hard coded to read in C1.ipc and spy.mdl, and outputs to H1.ipc, but I should have that fixed tonight.

 

  2911   Tue May 11 16:38:16 2010 josephb,rana,rolfUpdateCDSCDS questions and thoughts

1) What is c1asc doing?  What is ascaux used for?  What are the cables labeled "C1:ASC_QPD" in the 1X2 rack really going to?

2) Put the 4600 machine (megatron) in the 1Y3 (away from the analog electronics)  This can be used as an OAF/IO machine.  We need a dolphin fiber link from this machine to the IO chassis which will presumably be in 1Y1, 1Y2 (we do not currently have this fiber at the 40m, although I think Rolf said something about having one).

3) Merge the PSL and IOOVME crates in 1Y1/1Y2 to make room for the IO chassis.

4) Put the LSC and SUS machines into 1Y4 and/or 1Y5 along with the SUS IO chassis.  The dolphin switch would also go here.

5) Figure out space in 1X3 for the LSC chassis.  Most likely option is pulling asc or ascaux stuff, assuming its not really being used.

6) Are we going to move the OMC computer out from under the beam tube and into an actual rack?  If so, where?

 

Rolf will likely be back Friday, when we aim to start working on the "New" Y end and possibly the 1X3 rack for the LSC chassis.

 

  2922   Wed May 12 12:32:04 2010 josephbConfigurationCDSModified /etc/rc.d/rc.local on megatron

I modified the /etc/rc.d/rc.local file on megatron removing a bunch of the old test module names and added the new lsc and lsp modules, as well as a couple planned suspension models and plants, to shared memory so that they'll work.  Basically I'm trying to move forward into the era of working on the actual model we're going to use in the long term as opposed to continually tweaking "test" models.

The last line in the file is now: /usr/bin/setup_shmem.rtl lsc lsp spy scy spx scx sus sup&

I removed mdp mdc mon mem grc grp aaa tst tmt.

  2923   Wed May 12 12:58:26 2010 josephbConfigurationCDSSetup fb to handle lsc, lsp models on megatron

I modified /cvs/cds/caltech/target/fb and changed the line "set controller_dcu=10" to "set controller_dcu=13" (where 13 is the lsc dcu_id number).

I also changed the set gds_server line from having 10 and 11 to 13 and 14 (lsc and lsp).

The file /cvs/cds/caltech/fb/master was modified to use C1LSC.ini and C1LSP.ini, as well as tpchn_C2.par (LSC) and tpchn_C3.par (LSP)

testpoint.par in /cvs/cds/caltech/target/gds/param was modified to use C-node1 and C-node2 (1 less then the gds_node_id for lsc and lsp respectively).

Note all the values of gds_node_id, dcu_id, and so forth are recorded at http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/Existing_RCG_DCUID_and_gds_ids

ELOG V3.1.3-