40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 18 of 346  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  17246   Tue Nov 8 19:39:34 2022 AnchalUpdateSUSMC3 OSEMs calibrated using MC_F

I did the same measurement for MC3 with one difference that OSEMs report \sqrt{2} more motion than IMC cavity length change due to it being at 45 degrees. Following are the new cts2um gain values

  • UL 0.36 -> 0.39827(0.00045)
  • UR 0.36 -> 0.33716(0.00038)
  • LL 0.36  -> 0.34469(0.00039)
  • LR 0.36 -> 0.33500(0.00038)

 

  17249   Wed Nov 9 11:07:16 2022 AnchalUpdateSUSIMC test

Following configurations were kept today morning:

Start Time Stop Time HEPA PSL Shutter WFS Loops

1352046006

08:19:48 PST
16:19:48 UTC

1352050278

09:31:00 PST
17:31:00 UTC

OFF OPEN OFF

1352050393

09:32:55 PST
17:32:55 UTC

1352054538

10:40:00 PST
18:40:00 UTC

OFF OPEN ON

1352054537

10:41:59 PST
18:41:59 UTC

1352058724

11:51:46 PST
19:51:46

OFF CLOSED OFF

f2a filters with Q=10 (FM3) were turned on all IMC optics.

  17251   Wed Nov 9 20:01:38 2022 AnchalUpdateSUSMC1 OSEMs output is weird

I took a coil to OSEM transfer function for MC1 osems  (LL, UR) today and again the slope of the transfer function was -1.4 instead of -2 as expected. I compared this with MC3 coil to osem transfer function (LL) which correctly had the slope of -2. See attachments 1 and 2 for the results. This measurement was taken with PSL shutter closed and local damping loops turned off.

As I mentioned earlier, MC1 is using new satellite amplifier box (S2100029-v2) whose transfer function data exists and was actually measured by me in 40m/15776. Using this transfer function data, and the foton 3:30 (FM1) filter, I tried to recreate the product transfer function that should happen if both filters are working correctly. Attachment 3 shows these transfer function plots. I overlayed on top of this the measured transfer function of OSEM to position displacement as done in 40m/17238 by making the magnitude equal at 1 Hz. It is suspicious how nicely the measured transfer function overlay with the satellite amplifier measured transfer function, both in magnitude and phase. I'll investigate more tomorrow.

 

Attachment 1: MC1_COIL_to_OSEM_TF.pdf
MC1_COIL_to_OSEM_TF.pdf MC1_COIL_to_OSEM_TF.pdf
Attachment 2: MC3_COIL_to_OSEM_TF.pdf
MC3_COIL_to_OSEM_TF.pdf MC3_COIL_to_OSEM_TF.pdf
Attachment 3: MC1_UR_OSEM_TF.pdf
MC1_UR_OSEM_TF.pdf
  17252   Wed Nov 9 20:29:20 2022 AnchalUpdateSUSMC2 and MC3 set to undergo free swing test tonight

I have set a free swing test for MC2 and MC3 to trigger at 1 am tonight. The test should last for about 4.5 hrs upto 5:30 am. It will close the PSL shutter, perform the test, and open the shutter afterwards. To cancel or interrupt the test, go to rossa and do:

tmux a -t FST
ctrl+c
exit

 

  17256   Fri Nov 11 11:29:11 2022 AnchalUpdateSUSMC1 OSEMs output is weird

Late elog; original time Thursday, Nov 10 16:00 2022

MC1 is using a new satellite amplifier which was a whitening circuit on it with 3 Hz zero and 30 Hz pole. But to read out this signal, we use the old whitening board as it serves as the interface board with the ADC too. This is D000210 Whitening and Interface Board. This board has a switchable whitening filter which our RTS models supply GND as the switch input. It was not immediately clear to me if the GND input to this switch means whitening is ON or not.

I disconnected inputs and outputs to the whitening Board used for MC1 OSEM PDs, and I used a moku:go to measure the transfer function for the UR channel. This confirmed that whitening is turned ON on this interface board as well, which means the MC1 OSEM signals are whitened twice, while digitally we have been dewhitening only once. To fix this there are two possible solutions:

  • We turn on another identical dewhitening filter in MC1 OSEM input filter modules (a 3:30 at FM3)
  • We can change the MC1 Simulink model to stop keeping whitening on by default.
Attachment 1: MC1_UR_WhtnBrd_TF.png
MC1_UR_WhtnBrd_TF.png
  17263   Sat Nov 12 21:59:24 2022 AnchalFrogsComputer Scripts / ProgramsFSS SLOW servo not running

I stopped the Docker PID script and started the old python script on megatron. Instructions on how to do this are here.

On optimus I ran:

sudo docker stop scripts_PID_FSS_Slow_1

On megatron I ran:

sudo systemctl enable FSSSlow
sudo systemctl restart FSSSlow

However, the daemon service keeps failing and restarting. So currently the FSSSlow is not running. I do not know how to debug this script.


On a side note, I tested the docker service by restarting it, and it was working. From the logs, it seems like it got stuck because it could not find C1:IOO-MC_LOCK channel which occurs when c1psl epics servers fail or get stuck. The blinker on this script runs when the script is running but it does not stop if the script gets stuck somewhere. If someone decides to use this script in the future, they would need to correct error catching so that no reply from caget looks like an error and the script restarts rather than keep trying to get the channel value. Or the blinker implementation should change in the script so that it displays a stuck state.

Quote:
 

 Whoever knows about this, please stop that Docker PID and we can just run the old python script on megatron.

 

  17281   Thu Nov 17 16:48:07 2022 AnchalFrogsComputer Scripts / ProgramsFSS SLOW servo running Now

I've moved the FSS Slow PID script running to megatron through systemd daemons. The script is working as expected right now. I've updated megatron motd and the always running scripts page here.

  17286   Fri Nov 18 17:00:15 2022 AnchalUpdateSUSMC1 and MC3 OSEMs calibrated using MC_F

After the MC1 osem dewhitening was fixed, I did the calibration of MC1 OSEM signals using MC_F using this notebook. A 0.1 Hz oscillation with amplitude of 1000 cts was sent to MC1 lockin2 and was kept on between 1352851381 and 1352851881. Then I read back the data from DQ channels and performed a welch with standard deviation calculation from the different segments used. From this measurement, I arrive to the following cts2um gain values that were changed in MC1 filter file. The damping remained stable after the changes:

MC1:
UL: 0.09 -> 0.105(12)
UR: 0.09 -> 0.078(9)
LR: 0.09 -> 0.065(7)
LL: 0.09 -> 0.087(10)

I followed the same method for MC3 as well to get mroe meaningful error bars. This measurement was done between 1352856980 and 1352857480 using this notebook. Here are the changes made:

MC3
UL: 0.39827 -> 0.509(57)
UR: 0.33716 -> 0.424(48)
LR: 0.335 -> 0.365(40)
LL: 0.34469 -> 0.376(43)

The larger error bars could be due to more noisy MC3 osem outputs as the satellite amplifier gain is lower here.

  17289   Sun Nov 20 13:42:21 2022 AnchalUpdateSUSIMC test

I repeated this test for the following configuration:

  • PSL shutter closed at good IMC transmission
  • Offset value of 14000 written to C1:IOO-MC_TRANS_SUM_FILT_OFFSET
  • WFS loops ON but ASCPIT outputs of the optics were turned off.

The test ran for 4000 seconds between following timestamps:

start time: 1352878206
stop time: 1352882207

This script was used to run this test and can be used again in future to repeat the same test.

  17295   Mon Nov 21 18:33:05 2022 AnchalUpdateSUSMC2 OSEMs calibrated using MC_F

Repeated this for MC2 using the error measurement technique mentioned in 40m/17286 using this notebook. Following are the cts2um gain changes:

UL: 0.30408 -> 0.415(47)
UR: 0.28178 -> 0.361(39)
LR: 0.80396 -> 0.782(248)
LL: 0.38489 -> 0.415(49)

I averaged 19 samples to get these values hoping to have reached systematic error limit. The errors did not change from a trial with 9 samples except for the LR OSEM.
  17298   Tue Nov 22 10:29:31 2022 AnchalSummarySUSITMY Coil Strengths Balanced

I followed this procedure to balance the coil strengths on ITMY. The position sensor was created by closing PSL shutter so that IR laser is free running, and locking the green laser to YARM, this makes C1:ALS-BEATY_FINE_PHASE_OUT a position sensor for ITMY. The oplev channels C1:SUS-ITMY_OL_PIT_IN1 and C1:SUS-ITMY_OL_YAW_IN1 were used for PIT and YAW sensors. Everything else followed the procedure. The coil gains were changed as follow:

C1:SUS-ITMY_ULCOIL_GAIN :   1.036 -> 1.061
C1:SUS-ITMY_URCOIL_GAIN : -1.028 -> -0.989
C1:SUS-ITMY_LRCOIL_GAIN :   0.930 -> 0.943
C1:SUS-ITMY_LLCOIL_GAIN : -1.005  -> -1.007

I used this notebook and this diaggui to do this balancing.

  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.

  17310   Thu Nov 24 11:23:35 2022 AnchalUpdateSUSLow noise state

I've turned off HEPA fan and all lights at
PST: 2022-11-24 11:23:59.509949 PST
UTC: 2022-11-24 19:23:59.509949 UTC
GPS: 1353353057.509949

c1ioo model has been updated to acquire C1:IOO-MC2_TRANS_PIT_OUT  and C1:IOO-MC2_TRANS_YAW_OUT at 512 Hz rate.

I'll update when I turn the HEPA on again. I plan to turn it on for a few hours everyday to keep the PSL enclosure clean.


Turned on HEPA again at:

PST: 2022-11-25 12:14:34.848054 PST
UTC: 2022-11-25 20:14:34.848054 UTC
GPS: 1353442492.848054

However this was probably not a low noise state due to vacuum disruption mentioned here.

  17311   Thu Nov 24 15:37:45 2022 AnchalUpdateASCIMC WFS output matrix diagonalization effort

I tried following the steps and the method I was using converged to same output matrix upto 2 decimal points but there is still left over cross coupling as you can see in Attachment 1. With the new output matrix, WFS loop can be turned on with full overall gain of 1.


Changes:

  • I switched off +20dB FM2 on C1IOO-WFS1_PIT and increased gain C1:IOO-WFS1_PIT_GAIN from 0.1 to 1 to be uniform with other filters.
  • Output matrix change:
    • Old matrix:
      -2.   4.8 -7.3
       3.6  3.5 -2. 
       2.   1.  -6.8
    • New Matrix:
      3.44  4.22 -7.29
      0.75  0.92 -1.59
      3.41  4.16 -7.21
  • I think the main change that allowed the WFS loop to become stable was the 0,0 element sign change.

Method:

  • I made overall gain C1:IOO-WFS_GAIN 0
  • Switched of (0:0.8) FM3 on PIT filter modules (IOO-WFS1_PIT, IOO-WFS2_PIT, IOO-MC2_TRANS_PIT)
  • Changed ramp time to 2 seconds on all these modules
  • Used offset of 10000 for WFS2 and MC2_TRANS, and 30000 for WFS1 (for some reason, response to WFS1 step was much lower than others)
  • Measured the following sensor channels
    • C1:IOO-WFS1_I_PIT_OUT
    • C1:IOO-WFS2_I_PIT_OUT
    • C1:IOO-MC_TRANS_PIT_OUT
  • First I took 30s average of these channels, then applied the offsets in the three modules one by one and recorded steps in each sensor.
  • Measured step from reference value taken before, and normalized each step to the DOF that was actually stepped to get a matrix.
  • Inverted this matrix and multiplied with existing output matrix. Made sure column norm1 is same as before and column signs are same as before.
  • Repeated a few times.

Note: The standard deviation on the averages was very high even after averaging for 30s. This data should be averaged after low passing high frequencies but I couldn't find the filter module medm screens for these signals, so I just proceeded with simple averaging of full rate signal using cdsultis avg command.


Fri Nov 25 12:46:31 2022

The WFS loop are unstable again. This could be due to the matrix balancing done while vacuum was disrupted. The above matrix does not work anymore.

Attachment 1: WFS_Step_DCResponses_Offsets_Marked.png
WFS_Step_DCResponses_Offsets_Marked.png
  17312   Fri Nov 25 12:15:46 2022 AnchalUpdateVACVacuum Gate valves restored

I came today to find that PSL shutter was closed. I orginially thought some shimmer obersvations are underway in the quiet state. But that was not the case. When I tried to open the shutter, it closed back again indicating a hard compliance condition making it close. This normally happens when vacuum level is not sufficient, so I opened the vacuum screena dn indeed all gate valves were closed. This most probably happend during this interlock trip. So the main volume was just slowly leaking and reached to milli torr level today.

Lesson for future: Always check vacuum status when interlock trips.


[Paco, Anchal]

Paco came by to help. We went to asia (the Asus laptop at vacuum workstation) but could not open the medm or find the nfs mounted files. The chiara change did something and nfs mounted directories are not available on asia of c1vac. We rebooted asia and the nfs mount was working again. We can't simply restart c1vac because it runs acromag channels for vacuum system and needs to be done more carefully, a task for Monday.

After restarting asia, we opened the the vacuum control medm screen and followed the vaccum pump down instructions (mainly opening of the gate vales as the pumps were already on). Point to keep in mind, rule of thumb, do not open valve between a turbo pump and a volume if the pressure differential is more than 3 orders of magnitude. Saving turbo pumps is the priority.. Now the main volume is pumping down.

Attachment 1: Screenshot_2022-11-25_12-29-23.png
Screenshot_2022-11-25_12-29-23.png
  17313   Fri Nov 25 15:35:23 2022 AnchalUpdateSUSLow noise state

Turned off HEPA at:

PST: 2022-11-25 15:34:55.683645 PST
UTC: 2022-11-25 23:34:55.683645 UTC
GPS: 1353454513.683645

Turned on HEPA back at:

PST: 2022-11-28 11:14:31.310453 PST
UTC: 2022-11-28 19:14:31.310453 UTC
GPS: 1353698089.310453
 

  17315   Mon Nov 28 11:15:23 2022 AnchalUpdateCDSFront ends DAC Kill (DK) got activated; restored FEs

[Anchal, Paco, Yehonathan, JC]

Last night at 9:15 pm PST (Nov 27th, 2022) some kind of disruption happened to FEs. See attachment 1 to see the changes in FE state words of the IOP models. on c1lsc, c1sus and c1scex, change of 140 happend, that's 2nd, 3rd and 7th bit of the FE word was flipped, which I think is the TIM, ADC and DAC KILL (DK). When we came in morning, IMC suspensions were undamped and not responsive to coil kicks, vertex suspensions the same case, ETMX also same. The c1sus2 modelw as all in red.

To fix this, we restarted all rtcds models on all FEs by sshing into the computers and doing:

rtcds restart --all

Then we burt restored all models to 27th Nov, 3:19 am point doing following on rossa:

~>cd /opt/rtcds/caltech/c1/Git/40m/scripts/cds
cds (main)>./burtRestoreAndResetSUS.sh /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2022/Nov/27/03:19

Note: this issue was previously seen when fb1 was restarted without shutting down the FEs, and once when the martian switch was disrupted while FE models were running.

I'm not sure why this happened this time, what caused it at 9:15 pm yesterday, and why only c1lsc, c1sus and c1iscex models went to DAC KILL state. This disruption should be investigated by cds upgrade team.

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

  17320   Mon Nov 28 20:14:27 2022 AnchalUpdateASCAS WFS proposed path to IMC WFS heads

In Attachment 1, I give a plan for the proposed path of AS beam into the IMC WFS heads to use them temporarily as AS WFS. Paths shown in orange are the existing MC REFL path, red for the existing AS path, cyan for the proposed AS path, and yellow for the existing IFO refl path.  We plan to overlap AS beam to the same path by installing the following new optics on the table:

  • M1 will be a new mirror mounted on a flipper mount reflecting 100% of AS beam to SW corner of the table.
  • M2 will be a new fixed mirror for steering the new AS beam path to match with MC WFS path.
  • M3 will be the existing beamsplitter used to pick off light for MC refl camera. We'll just mount this on a flipper so that it can be removed from the path. Precaution will be required to protect the CCD from high intensity MC reflection by putting on more ND filters.
  • The AS beam would need to be made approximately 1 mm in beam width. The required lenses for this would be placed between M1 and M2.

I request people to go through this plan and find out if there are any possible issues and give suggestions.


PS: Thanks JC for the photos. I got it from foteee google photos. It would be nice if these are also put into the 40m wiki page for photos of optical tables.


RXA: Looks good. I'm not sure if ND filters can handle the 1 W MC reflection, so perhaps add another flipper there. It would be good if you can measure the power on the WFS with a power meter so we know what to put there. Ideally we would match the existing power levels there or get into the 0.1-10 mW range.

Attachment 1: F5B115E5-885F-463C-9645-BB2EB73B6144_1_201_a.jpeg
F5B115E5-885F-463C-9645-BB2EB73B6144_1_201_a.jpeg
  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
  17329   Thu Dec 1 20:43:25 2022 AnchalSummaryCalibrationSingle arm cal with 5 lines

[Anchal, Paco]

We are doing this attempt again in following configuration:

  • PSL shutter is closed. (So IR laser is free running)
  • Beanote frequency between Y arm and Main laser is about 45 MHz.
  • Green laser on Y end is locked. Transmission is above 1.1 (C1:ALS-TRY_OUT)
  • All calibration oscillators are turned on and set to actuate ITMY. See screenshot attached.
  • The calibration model was changed to demodulate the C1:ALS-BEATY_FINE_PHASE_OUT channel insteald. We'll have DQ channels before mixing with oscillator, after mixing, and also after applying a 4th order 30 Hz butterworth filter.

Start time:

PST: 2022-12-01 20:44:23.982114 PST
UTC: 2022-12-02 04:44:23.982114 UTC
GPS: 1353991481.982114
 

Stop time:

PST: 2022-12-02 14:32:29.547603 PST
UTC: 2022-12-02 22:32:29.547603 UTC
GPS: 1354055567.547603

Attachment 1: SingleArmCalibration.png
SingleArmCalibration.png
  17331   Sat Dec 3 10:13:56 2022 AnchalUpdateSUSLow noise state

I've turned off HEPA fan and all lights at:

PST: 2022-12-03 10:13:03.184705 PST
UTC: 2022-12-03 18:13:03.184705 UTC
GPS: 1354126401.184705

  17332   Sat Dec 3 17:42:25 2022 AnchalUpdateASCIMC WFS Fixed for now

Today I did a lot of steps to eventually reach to WFS locking stably for long times and improving and keeping the IMC transmission counts to 14400. I think the main culprit in thw WFS loop going unstable was the offset value set on MC_TRANS_PIT filter module  (C1:IOO-MC_TRANS_PIT_OFFSET). This value was roughly correct in magnitude but opposite in sign, which created a big offset in MC_TRANS PIT error signal which would integrate by the loops and misalign the mode cleaner.


WFS offsets tuning

  • I ran C1:IOO-WFS_MASTER > Actiona > Correct WFS DC offsets script while the two WFS heads were blocked.
  • Then I aligned IMC to maximize transmission. I also made PMC transmission better by walking the input beam.
  • Then, while IMC is locked and WFS loops are off, I aligned the beam spot on WFS heads to center it in DC (i.e. zeroing C1:IOO-WFS1_PIT_DC, C1:IOO-WFS1_YAW_DC, C1:IOO-WFS2_PIT_DC, C1:IOO-WFS2_YAW_DC)
  • Then I ran C1:IOO-WFS_MASTER > Actiona > Correct WFS DC offsets script while keeping IMC locked (note the script says to keep it unlocked, but I think that moves away the beam). If we all agree this is ok, I'll edit this script.
  • Then I checked the error signals of all WFS loops and still found that C1:IOO-MC_TRANS_PIT_OUTPUT and C1:IOO-MC_TRANS_YAW_OUTPUT have offsets. I relieved these offsets by averaging the input to these filter moduels for 100s and updating the offset. This is where I noticed that the PIT offset was wrong in sign.

WFS loops UGF tuning

  • Starting with only YAW loops, I measured the open loop transfer functions (OLTFs) for each loop by simultaneously injecting gaussian noise from 0.01 Hz to 0.5 Hz using diaggui at the loop filter module excitation points and taking ration of IN1/IN2 of the filter modules.
  • Then I scaled the YAW output matrix columns to get UGF of 0.1 Hz when YAW loop was along turned on.
  • Then I tried to do this for PIT as well but it failed as even with overall gain of 0.1, the PIT loops actuate a lot of YAW motion causing the IMC to loose lock eventually.
  • So I tried locking PIT loops along with YAW loops but with 0.1 overall gain. This worked for long enough that I could get a rough estimate of the OLTFs. I scaled the columns of PIT output matrix and slowly increased the overall gain while repeating this step to get about 0.1 Hz UGF for all PIT loops too.
  • Note though that the PIT loop shape did not come out as expected with a shallower slope and much worse coherence for same amount of excitation in comparison to YAW loops. See attached plots.
  • Never the less, I was able to reach to an output matric which works at overall gain of 1. I tested this configuration for atleast 15 minutes but the loop was working even with 6 excitations happening simultaneously for OLTF measurement.
  • We will need to revisit PIT loop shapes, matrix diagonalization, and sources of noise.

OLTF measurements were done using this diaggui file. The measurement file got deleted by me by mistake, so I recreated the template. Thankfully, I had saved the pdf of the measurements, but I do not have same measurement results in the git repo.

 

Attachment 1: IMC_WFS_OLTF.pdf
IMC_WFS_OLTF.pdf IMC_WFS_OLTF.pdf
  17334   Sun Dec 4 16:44:04 2022 AnchalUpdateASCIMC WFS Fixed for now

Today, I worked on WFS loop output matrix for PIT DOFs.

  • I began with the matrix that was in place before Nov 15.
  • I followed the same method as last time to fist get all UGFs around 0.06 Hz with overall gain of 0.6 on the WFS loops.
  • This showed me that MC2_TRANS_PIT loop shape matches well with the nice working YAW loops, but the WFS1 and WFS2 loops still looked flat like before.
  • This indicated that output matrix needs to be fixed for cross coupling between WFS1 and WFS2 loops.
  • I ran this script WFSoutMatBalancing.py which injects low frequency (<0.5 Hz) oscillations when the loops are open, and measures sensing matrix using error signals. I used 1000s duration for this test.
  • The direct inverse of this sensing matrix fixed the loop shape for WFS1 indicating WFS1 PIT loop is disentangled from WFS2 now.
  • Note this is a very vague definition of diagonalization, but I am aiming to reach to a workign WFS loop asap with whatever means first. Then we can work on accurate diagonalization later.
  • I simply ran the script WFSoutMatBalancing.py again for another 1000s and this time the sensing matrix mostly looked like an identity.
  • I implemented the new output matrix found by direct inversion and took new OLTF.Again though, the WFS2_PIT loop comes out to be flat. See Attachment 1.
  • Then noting from this elog post, I reduced the gain values on MC2 TRANS loops to 0.1 I think it is better to use this place to reduce loop UGF then the output matrix as this will remind us that MC2 TRANS loops are slower than others by 10 times.
  • I retook OLTF but very unexpected results came. The overall gain of WFS1_YAW and WFS2_YAW seemed to have increased by 6. All other OLTFs remained same as expected. See attachment 2.
  • To fulfill the condition that all UGF should be less than 0.1 Hz, I reduced gains on WFS1_YAW and WFS2_YAW loops but that made the YAW loops unstable. So I reverted back to all gains 1.
  • We probably need to diagonalize Yaw matrix better than it is for letting MC2_TRANS_YAW loop to be at lower UGF.
  • I'm leaving the mode cleaner in this state and would come back in an hour to see if it remains locked at good alignment. See attachment 3 for current state.

Sun Dec 4 17:36:32 2022 AG: IMC lock is holding as strong as before. None of the control signals or error signals seem to be increasing monotonously over the last one hour. I'll continue monitoring the lock.


Mon Dec 5 11:11:08 2022 AG: IMC was locked all night for past 18 hours. See attachment 4 for the minute trend.

Attachment 1: IMC_WFS_OLTF_All_Gains_1.pdf
IMC_WFS_OLTF_All_Gains_1.pdf IMC_WFS_OLTF_All_Gains_1.pdf
Attachment 2: IMC_WFS_OLTF_Nom_Gain.pdf
IMC_WFS_OLTF_Nom_Gain.pdf IMC_WFS_OLTF_Nom_Gain.pdf
Attachment 3: WFS_Loop_Configuration.png
WFS_Loop_Configuration.png
Attachment 4: WFS_Loop_Performance.png
WFS_Loop_Performance.png
  17335   Mon Dec 5 12:05:29 2022 AnchalUpdateCDSc1sus2 all FE models crashed spontaneously

Just a few minutes ago, all models on FE c1sus2 crashed. I'm attaching some important files that can be helpful in investigating this. CDS upgrade team, please take a look.

I fixed this by running following on c1sus2:

controls@c1sus2:~$ rtcds restart --all
Attachment 1: c1sus2Failed.txt
controls@c1sus2:~$ rtcds status
found host specific environment file '/etc/advligorts/systemd_env_c1sus2'
Kernel Module Status
mbuf                   24576  40 c1bac,c1x07,c1su2,c1hpc,c1su3
gpstime                40960  5 c1bac,c1x07,c1su2,c1hpc,c1su3
dis_kosif             131072  5 dis_ix_ntb,dis_intel_dma,dis_ix_dma,dis_sisci,dis_irm
dis_ix_ntb            307200  1 dis_irm
dis_ix_dma             36864  1 dis_ix_ntb
dis_irm               462848  4 dolphin_proxy_km,dis_sisci
dis_sisci            1093632  0
... 28 more lines ...
Attachment 2: c1sus2Failed.png
c1sus2Failed.png
  17336   Mon Dec 5 16:24:45 2022 AnchalUpdateASCIMC WFS servo diagnosis

Also reply to: 40m/17255


I ran the toggleWFSoffsets.py script to generate a step response of the WFS loops in operation. Attachment 1 shows the diaggui measured time response following the parameters mentioned in 40m/17255. There are few things to quickly note from this measurement without doing detailed analysis:

  • WFS2_PIT is heavily cross-coupled with WFS1_PIT and MC2_TRANS_PIT. This was also the inference from the previous post based on loop shape for WFS2_PIT loop. This needs to be fixed.
  • Weirdly enough, it seems that WFS2_PIT is also cross coupled with MC2_TRANS_YAW.
  • MC2_TRANS_PIT is not coupled to WFS1_PIT or WFS2_PIT. This was the major issue in last measurement in 40m/17255.
  • WFS1_PIT is coupled to MC2_TRANS_PIT by about half, but is not cross-coupled to WFS2_PIT.
  • For YAW, the DOFs are mostly disentangled except for a cross coupling of WFS1_YAW to MC2_TRANS_YAW by about 60%.

To get out the UGF of the loops from the step responses, I need to read this into python and apply the same filters and analyze time constants. I still have to do this part, but I thought I'll put out the result before spending more time on this.


GPSTIME: 1354314478

 

Attachment 1: IMC_WFS_Step_Response.pdf
IMC_WFS_Step_Response.pdf
  17337   Mon Dec 5 20:02:06 2022 AnchalUpdateASCIMC WFS heads electronic feasibility test for using for Arm ASC

I took transfer function measurement of WFS2 SEG4 photodiode between 1 MHz to 100 MHz in a linear sweep.


Measurement details:

  • The reincarnated Jenne laser head was used for this test. The laser diode is 950 nm though, which should just mean a different responsivity of the photodiode while we are mainly interested in relative response of the WFS heads at 11 MHz and 55 MHz with respect to 29.5 MHz.
  • See attachment 2 for how the laser was placed on AP table.
  • The beam was injected in between beam splitter for MC reflection camera and beam splitter for beam dump.
  • The input was aligned such that all the light of the laser was falling on Segment 4 of WFS2.
  • Using moku, I took RF transfer function from 1 MHz to 100 MHz, 512 points, linearly spaced, with excitation amplitude of 1 V and 100,000 cycles of averaging.
  • Measurement data and settings are stored here.

Results:

Relative to 29.5 MHz, teh photodiode response is:

  • At 11 MHz: -20.4 dB
  • At 55 MHz: -36.9 dB
  • At 71.28 MHz: -5.9 dB

I'm throwing in an extra number at the end as I found a peak at this frequency as well. This means to use these WFS heads for arm ASC, we need to have 10 times more light for 11 MHz and roughly 100 times more light for 55 MHz. According to Gautam's thesis Table A.1 and this elog post, the modulation depth for 11 MHz is 0.193 and for 55 MHz is 0.243 in comparison to 0.1 for 29.5 MHz., so the sideband TEM00 light available for beating against carrier TEM01/TEM10 is roughly twice as much for single arm ASC. That would mean we would have 5 times less error signal for 11 MHz and 40 times less error signal for 55 MHz. These are rough calculations ofcourse.

 

Attachment 1: 20221205_193105_WFS2_SEG4_RF_TF_Screenshot.png
20221205_193105_WFS2_SEG4_RF_TF_Screenshot.png
Attachment 2: PXL_20221206_033419110.jpg
PXL_20221206_033419110.jpg
  17342   Tue Dec 6 16:52:26 2022 AnchalUpdateASCIMC WFS heads electronic feasibility test for using for Arm ASC

I tested teh WFS demod board for possibility of demodulating 11 MHz or 55 MHz signal with it. It definitely has some bandpass filter inside as the response is very bad for 11 MHz and 55 MHz. See attached the ASD curves for the excitations seens on I and Q inputs of WFS1 Segment 2 when it was demodulated with a clock of different frequencies but same amplitude of 783.5 mVpp (this was measured output of 29.5 MHz signal from RF distribution board). See attachments 2-4 for mokulab settings. Note for 29.5 MHz case, I added an additional 10 dB attenuator to output 1.

The measurement required me to change signal power level to see a signal of atleast 10 SNR. If we take signal level of 29.5 MHz as reference, following are the responses at other frequencies:

  • At 11 MHz:
    • I: -92 dB
    • Q: -97 dB
  • At 55 MHz:
    • I: -75 dB
    • Q: -72 dB

Note that I and Q outputs are unbalanced as well for the two different demodulation frequencies.

This means that if we want to use the WFS demodulation boards as is, we'll need to amplify the photodiode signal by the above amounts to get same level of outputs. I stil need to see the DCC document of these board and if the LO is also bandpassed. In which case, we can probably amplify the LO to improve the demodulation at 11 and 55 MHz. THe beatnote time series for the measured data did not show an obvious sinusoidal oscillation, so I chose to not show a plot with just noise here.

 

Attachment 1: WFS1_SEG2_DEMOD_Test.pdf
WFS1_SEG2_DEMOD_Test.pdf
Attachment 2: 11MHz.png
11MHz.png
Attachment 3: 29.5MHz.png
29.5MHz.png
Attachment 4: 55MHz.png
55MHz.png
  17348   Thu Dec 8 20:40:14 2022 AnchalUpdateASCWFS demodulation board modification attempt

Based on the previous two elog posts, Koji and I decided that we should use 11 MHz signal for arm cavity ASC and modify a spare WFS demod board to work at 11 MHz. This board LIGO-D980233, uses a PLL to lock the to LO input and generate I and Q ECL clock signals from it. For this purpose, it uses POS-XX minicircuits VCO. For IMC WFS boards the model number is POS-75 and with the board design, it can work for 18.75 MHz to 37.5 MHz modulation frequencies.

To make it work for 11 MHz, we have to swap this with POS-25 but that is not available for purchase anywhere. So Koji and I decided to use Moku:GO as a VCO and make connections to the pin holes on the board. Today, I modified a spare WFS board to make this possible. I added a right angle SMA connector to take in VCO output signal and a BNC connector to send out tuning signal. See attached photos for the details of this hack.

Then I went to 1X2 and tried on this modified board on a Euro crate empty slot. I used Moku:GO in a multi-instrument mode in which first instrument was a Waveform generator set to modulate from external input 1 at 6 MHz/V. The output RF level was checked on an oscilloscope and increased until I got about 9.5 dBm power at the output. The second instrument was just an spectrum analyzer to see if the test output from ICLK looks ok. I fed LO from a spare output port on RF distribution box for 11 MHz signal. I made sure to attenuate this signal to get 2 dBm LO signal which is the case for the WFS demod board LO input as well. 

This test however failed. I could not see any signal from ICLK or QCLK output. I then tried to use the same slot as the demod board for WFS1 is used and I still did not see any output on ICLK or QCLK. I split the VCO tuning signal coming from the board to see it on an oscilloscope and it was mostly noise of ~1 mV level. I then tried to check ICLK and QCLK on oscilloscope and saw that they had a huge offset of -1.7 V. I suspect some ground mismatch issue between Moku:GO and the demod board.

I decided to call it a day here.

I reset everything back to how it was on the rack and turned on IMC WFS again. It is working as usual keeping lock steady for atleast last 20 min that I have seen it.


 

Attachment 1: PXL_20221209_035720569.jpg
PXL_20221209_035720569.jpg
Attachment 2: PXL_20221209_035729233.jpg
PXL_20221209_035729233.jpg
  17352   Fri Dec 9 14:18:43 2022 AnchalSummarySUSIMC optics angular actuation calibration at DC

Also reply to: 40m/16125


I migrated the code used in 40m/16125 to our scripts git repo and used it to apply offsets to IMC optics and noticing the parabolic change in the transmission values. Fitting the data with parabola and using the calculations mentioned in the previous post, we get following angular actuation calibration at DC from the PIT/YAW alignment output channels (cts) to actual motion in (urad):

Optic and DOF Calibration constant at DC [urad/cts]
MC1 PIT 13.92(3)
MC2 PIT 20.6(2)
MC3 PIT 11.95(3)
MC1 YAW 12.85(3)
MC2 YAW 18.9(2)
MC3 YAW 13.62(4)

*Note that in the previous post, the radius of curvature of MC2 used was wrong and has been corrected in this calculation to 17.87 m taken from Gautam's thesis Table A.1

Due to lack of time, we ran test faster on MC2, hence more uncertainty in it's results. Also, during MC1 YAW test, lock for breifly lost which required me to manually throw away some data points, but it did not affect the quality of fit much. Please see attached the data plots and fit.

For calibration at AC, another test needs to be performed which I did not do right now. 40m/16125 also describes how to do that, so someone can repeat that in future.

Quote:
 

It would be good if someone can post here the actuation calibration in radians, so that we can have a physical calibration of the sensing matrix in counts/radian.

 

Attachment 1: IMC_Ang_Act_Calibration.pdf
IMC_Ang_Act_Calibration.pdf IMC_Ang_Act_Calibration.pdf IMC_Ang_Act_Calibration.pdf IMC_Ang_Act_Calibration.pdf IMC_Ang_Act_Calibration.pdf IMC_Ang_Act_Calibration.pdf
  17357   Tue Dec 13 23:49:17 2022 AnchalUpdateSUSLow noise state

I've turned off HEPA fan and all lights at:

PST: 2022-12-13 23:49:12.955214 PST
UTC: 2022-12-14 07:49:12.955214 UTC
GPS: 1355039370.9552


Turned HEPA back on:

PST: 2022-12-14 10:47:49.944161 PST
UTC: 2022-12-14 18:47:49.944161 UTC
GPS: 1355078887.944161

  17363   Fri Dec 16 21:55:54 2022 AnchalUpdateASCWFS demodulation board modification attempt 2 - sort of working

[Koji, Anchal]

short version: We checked signals at different points in the circuit to make sense of why it was not working. We found out that teh comparator chip AD96687BR was not working as expected and was not converting the analog signal from our VCO or LO inputs to ECL. We tested 2 other spare board with same behavior. We decided to try replacing the comparator chip with a new one, and indeed that was the issue. The new chip was working as expected and we are able to get PLL lock on the board with Moku:Lab as the VCO. However, there are some issues that need to be ironed out. The PLL does not catch lock right away and we could not figure our a systematic way of reaching to a locked state. That smells fishy to me as in my experience, when PLLs work, they work very robustly. More analysis with data and figures will follow. For now, we have some hope that this can work.

There is always the option of not closing PLL loop and injected twice the demodulation frequency at the VCO port that we have access two. For this, I'll need to create a SHG unit for 11 MHz with 21.4 MHz BLP. I'll look into this solution as well.

  17364   Fri Dec 16 22:06:55 2022 AnchalUpdateSUSLow noise state

I've turned off HEPA fan and all lights at:

PST: 2022-12-16 22:06:53.830911 PST
UTC: 2022-12-17 06:06:53.830911 UTC
GPS: 1355292431.830911


Tuned on HEPA again:

PST: 2022-12-17 14:39:57.974212 PST
UTC: 2022-12-17 22:39:57.974212 UTC
GPS: 1355352015.974212


I've turned off HEPA fan and all lights at:

PST: 2022-12-17 17:26:28.740675 PST
UTC: 2022-12-18 01:26:28.740675 UTC
GPS: 1355362006.740675
 

I also started WFS relief script at this time. This script would end in 600s from the above time.

  17365   Sat Dec 17 16:56:19 2022 AnchalUpdateASCWFS demodulation board modification - further study

I played with the PLL bit more today to understand the issue. From what I understand, the following is the summary:

Moku as VCO in WFS demod board PLL:

  • Moku input in VCO mode is actually limited to ~ +/-21 V contrary to what it says on the app (10 Vpp)
  • Whenever the VCO tuning signal goes beyond this range, Moku just ignores the input and sends a pure sine wave at the carrier frequency.
  • I think because of this rail point behavior, the PLL goes off to a bad mode where the VCO tuning signal from demod board rails to +15 or -15V, and thus Moku does nothing to correct for it.
  • I found a deterministic way of catching lock with Moku VCO:
    • With whatever carrier frequency, set the VCO slope to at least 1 MHz/V (10 MHz/V is better).
    • The VCO tuning signal most probably would rail to +15V or -15V.
    • Reduce +/- 15V supply, this moves the railing voltage with it.
    • When the voltage rails reach +/2 V, the PLL catches the lock.
    • Now slowly ramp back the power supply back to +/- 15V.
  • This way I was able to repeatedly catch the lock (see attachment 1), but of course, this can't be done when our board is mounted in the Eurocrat.
  • So I thought if I attenuate the VCO tuning signal by 20 dB and pass it through an SR560, I can control the VCO tuning signal amplitude. This approach however did not work. It was always required to reduce the +/- 15V supply to the board to catch the lock.
  • This makes me think that the phase detector chip AD9901 needs to be turned off initially or supplied with low voltage rails. I'm not sure why.
  • With this, I think we should scrap this idea of using Moku as VCO, it will be just too unreliable.
  • So we need to move to the possibility of feeding 22 MHz signals to the WFS demod board where VCO output goes.

Basically, we make our own PLL outside the board to generate 2 times LO frequency or we create 2 times LO frequency by second harmonic generation.

Moku:Pro as a frequency multiplier

This white paper from liquid instruments describes how Moku:Pro can be used as a frequency multiplier in the phasemeter app now. This functionality however has not been extended to Moku:Lab, so in 40m, we can not do this right now. If we get access to Moku:Pro, following will be required:

  • Send 11 MHz LO signal to Moku:Pro input 1 with phasemeter app on.
  • Select frequency multiplier option of 2 at the output 1. Set voltage to 2 Vpp and feed this signal to VCO RF out port on the modified demod board.
  • Leave VCO tuning port unconnected.
  • This way we would replace the internal PLL with Moku digital PLL. Moku's PLL can be run upto 10 kHz bandwidth and would be very robust for such use.

Second harmonic generation using mixer and bandpass filter

  • Split the 14 dBm 11 Mhz output from frequency generation box (I simulated this with benchtop function generator) using a splitter.
  • Send both outputs to ZP-3+ mixer (level 7).
  • Filter the output with SBP-21.4 band pass filter. Koji has measured this filter in 2013. See elog 40m/9010.
  • Amplify the output twice, first with ZFL-500HLN+ (20dB amplification), then with ZFL-1HADX (11 dB).
  • This setup provides enought output amplitude for the comparator chip AD96687 to generate clean ECL signal at 22 MHz without slipping. With only 20dB amplification, I could see the phase slip by 180 degrees enough times that the oscilloscope shows both outputs overlapped.
  • Attachment 2 shows the ICLK and QCLK signals generated by the board with this setup.

Next steps:

  • I'll modify one more board for sending in LO like this.
  • I'll test the demodulation performance of the board with LO input from the second harmonic generation.
  • Setup the optical path for AS WFS.
Attachment 1: MokuVCOAttempt.jpg
MokuVCOAttempt.jpg
Attachment 2: SHGmethod.jpg
SHGmethod.jpg
  17367   Tue Dec 20 18:27:14 2022 AnchalSummaryLSCFPMI locked, DARM calibration data taken, FPMI BHD locked!

[Anchal, Paco, Yuta]

FPMI locked with BHD readout!!!


Paco and I figured the repeatable recipe for locking FPMI today. The settings are saved as snapshot file. In short, we first lock fake FPMI using POX+POY and POX-POY and then locking MICH to REFL55_Q. We make sure there are no offsets in AS55Q or REFL55Q. Then we handoff CARM and DARM loops to 0.496*REFL55_I and 2.617*AS55_Q by changing gains on A and B paths simultaneously with tramp time of 5s. WE have pushed new measurements of CARM, DARM and MICH loop OLTFs to measurement repo.

We turned on 5 oscillators all sending calibration lines to ITMY at different frequencies to calibrate DARM readout. WE took this data for about 90 minutes and then decided to try locking FPMI with BHDC DIFF.

A simple handoff to 0.68*BHDC_DIFF at error point for DARM loop worked. The OLTF for DARM loop remained the same.

I need to run now, so more detailed elog will come later.

On another news, this was last day of Tega, a warm farewell to him.

Attachment 1: PXL_20221221_013126861.MP.jpg
PXL_20221221_013126861.MP.jpg
  17378   Tue Jan 3 11:32:32 2023 AnchalUpdateCDSYearly DAQD fix 2023, did not work :(

Every year some changes need to be done manually in a driver c code file for daqd to work. The gpstime offset needs to be changed on fb for some package.

We followed the procedure on this thread, but this year it did not work. Here is a summary of our findings:

We first confirmed this is indeed the issue by doing:

controls@fb1:~$ cat /proc/gps
946926959.95

This is clearly wrong gpstime. We went to the file /opt/rtcds/rtscore/release/src/include/drv/spectracomGPS.c in fb1 and added following lines after line 110:

/* 2022 has no leap seconds or leap days, so adjust for that */
       pHardware->gpsOffset += 31536000;

After this, we went to  /opt/rtcds/rtscore/release/src/drv/symmetricom and ran:

controls@fb1:/opt/rtcds/rtscore/release/src/drv/symmetricom$ sudo make
make -C /lib/modules/4.19.0-6-rtcds-amd64/build SUBDIRS=/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom modules
make[1]: Entering directory '/usr/src/linux-headers-4.19.0-6-rtcds-amd64'
  CC [M]  /opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.o
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:59:27: error: initialization of ‘long int (*)(struct file *, unsigned int,  long unsigned int)’ from incompatible pointer type ‘int (*)(struct inode *, unsigned int,  long unsigned int)’ [-Werror=incompatible-pointer-types]
         .unlocked_ioctl = symmetricom_ioctl,
                           ^~~~~~~~~~~~~~~~~
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:59:27: note: (near initialization for ‘symmetricom_fops.unlocked_ioctl’)
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c: In function ‘get_cur_time’:
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:89:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
  int sync = getGpsTime(&timeSec, &timeUsec);
  ^~~
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c: In function ‘symmetricom_ioctl’:
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:116:23: error: implicit declaration of function ‘copy_to_user’; did you mean ‘raw_copy_to_user’? [-Werror=implicit-function-declaration]
                   if (copy_to_user ((void *) arg, &res,  sizeof (res))) return -EFAULT;
                       ^~~~~~~~~~~~
                       raw_copy_to_user
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c: In function ‘symmetricom_init’:
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:175:26: error: implicit declaration of function ‘create_proc_entry’; did you mean ‘remove_proc_entry’? [-Werror=implicit-function-declaration]
         proc_gps_entry = create_proc_entry("gps", PROC_MODE, NULL );
                          ^~~~~~~~~~~~~~~~~
                          remove_proc_entry
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:175:24: warning: assignment to ‘struct proc_dir_entry *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
         proc_gps_entry = create_proc_entry("gps", PROC_MODE, NULL );
                        ^
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:181:23: error: dereferencing pointer to incomplete type ‘struct proc_dir_entry’
         proc_gps_entry->read_proc = procfile_gps_read;
                       ^~
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:188:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
  struct pci_dev *symdev = pci_get_device (SYMCOM_VID, SYMCOM_BC635_TID, 0);
  ^~~~~~
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:222:3: warning: label ‘out_remove_proc_entry’ defined but not used [-Wunused-label]
   out_remove_proc_entry:
   ^~~~~~~~~~~~~~~~~~~~~
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:158:22: warning: unused variable ‘pci_io_addr’ [-Wunused-variable]
  static unsigned int pci_io_addr;
                      ^~~~~~~~~~~
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:156:6: warning: unused variable ‘i’ [-Wunused-variable]
  int i;
      ^
At top level:
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:158:22: warning: ‘pci_io_addr’ defined but not used [-Wunused-variable]
  static unsigned int pci_io_addr;
                      ^~~~~~~~~~~
cc1: some warnings being treated as errors
make[4]: *** [/usr/src/linux-headers-4.19.0-6-common-rtcds/scripts/Makefile.build:315: /opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.o] Error 1
make[3]: *** [/usr/src/linux-headers-4.19.0-6-common-rtcds/Makefile:1534: _module_/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom] Error 2
make[2]: *** [Makefile:146: sub-make] Error 2
make[1]: *** [Makefile:8: all] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.19.0-6-rtcds-amd64'
make: *** [Makefile:28: all] Error 2

We don't know how to deal with these error messages. This did not happen last year, so this might have to do with the change in fb1 or our cds setup. Chris and/or Jamie, please help.

  17388   Mon Jan 9 19:41:01 2023 AnchalUpdateSUSNull stream (butterfly/pringle) row added and DQed

I updated the suspension model (/cvs/cds/rtcds/userapps/trunk/sus/c1/models/lib/sus_single_control_new.dml) to add a 5th row in the input matrix so that we can put in the calculated NULL stream vector (also have been called as Butterfly mode or Pringle mode in the past). The output of this row would go through a filter module and then is sent to the testpoint named 'C1:SUS-OPT_SENSOR_NULL' where OPT is the optic acronym. This channel is acquired in frames at 256 Hz and would be available as C1:SUS-OPT_SENSOR_NULL_DQ. After the update in the model, I built, installed and restarted models c1sus, c1mcs, c1scx, c1scy, c1su2, and c1su3. Then I restarted daqd, and everything came up nicely. After but restore, I added the null stream vector for the optics it was already known from a free swing test. ITMX, ITMY, ETMX, PRM, and SRM null stream vectors needs to be calculated from the other 4 rows. It is set to zero right now. Medm screen for the input matrix was also updated to allow seeing this row.

 

Attachment 1: SUS_Model_Changes.png
SUS_Model_Changes.png
Attachment 2: MC1_INMATRIX.png
MC1_INMATRIX.png
  17391   Tue Jan 10 20:24:29 2023 AnchalUpdateASCWFS demodulation board 111B - Working as expected

I've completed the modifications on two WFS demod boards. This required replacing all 8 mixer ICs on each board. I also tuned each channel to get less than 2 mV offset on all of them.

I was able to complete testing the board SNo. 111B today. The results are attached. The test was done by feeding the board 22 MHz LO generated by frequency doubling. A signal at 11 MHz was generated using Moku:Lab at 1mVpp and then further attenuated by 10 dB to make a fair comparison with the previous testing of the IMC WFS board at 29.5 MHz. This board has the same response as the IMC WFS board at 29.5 MHz. I tested all four channels in the second plot.

I'll complete the testing of the second board SNo 112 B and then move on to setting up the optical path for AS WFS.

Attachment 1: WFS_Board_111B_Test.pdf
WFS_Board_111B_Test.pdf
  17393   Wed Jan 11 17:05:55 2023 AnchalUpdateASCWFS demodulation board 112B - Working as expected

The other modified board 112B has been fixed and tested now. See the results attached. The issue was in some malfunctioning OP284 which have been replaced by AD8672.

Attachment 1: WFS_Board_112B_Test.pdf
WFS_Board_112B_Test.pdf
  17398   Fri Jan 13 13:34:12 2023 AnchalSummaryBHDBH44 tuned and transimpedance measured

I've tuned one gold box RFPD to be resonant at 44.26 MHz and I left the notch to be near 66 MHz, however, it is only effective by 10 dB. Attached is the measured transimpedance using the test port. This measurement should be updated with PD testbed measurement.

This photodiode is ready to be installed for the dual RF lO phase locking scheme.


Thu Jan 19 15:06:43 2023 Updating the measurement with Moku:Pro calibration TF

Attachment 1: BH44_Transimpedance_From_Test_Port.pdf
BH44_Transimpedance_From_Test_Port.pdf
  17403   Thu Jan 19 12:12:09 2023 AnchalSummaryBHDIQ demod orthogonal

By sending two frequencies offset from eachother to LO input and RF input, we measured the remaining phase difference between I and Q outputs of this demod board and correct that by setting C1:LSC-BH44_PHASE_D to 86.2 degrees and balancing the amplitudes by putting C1:LSC-BH44_Q_GAIN to 1.747. See attached for XYPlot after correction.

Attachment 1: BH44_IQDemodMeasuredDiff_1358192471.pdf
BH44_IQDemodMeasuredDiff_1358192471.pdf
  17406   Thu Jan 19 20:35:54 2023 AnchalUpdateASCInstalled 2 flipper mirrors for handingl MC reflection beam to camera

Today I installed two flipper mirrors M3 and M4 (see attached photo) to create alternate route for MC reflection camera beam. Both these mirrors are Y1-1037-45S. In nominal operation where IMC is using the WFS, we will keep M3 upright and M4 flipped down. When using WFS for AS, M3 will be flipper down and M4 will be upright to save the camera from the high intensity MC reflection beam.

Note that everytime M3 is flipper and put back upright, the alignment into WFS would need to be tuned as the flipper apparatus does not come back to same alignment everytime. I centered the beams on the WFS heads today and zeroed RF offsets usingC1IOO_WFS_MASTER>!Actions>Correct WFS RF Offsets script. After this, the IMC WFS loops are working as expected atleast for last 15 minutes that I have monitored them. Hopefully, this will remain consistent.


Upcoming work:

  • Change the steering mirror that steers the beam to black hole to be a flipper mirror too as AS beam strength (measured when MICH was locked to bright port) is 0.3 mW and IMC WFS heads combined power is 0.5 mW in nominal operation, so we can not afford to dump any AS beam light.
  • Put flipper mirror M1 and fixed mirror M2 mentioned in 40m/17320 for steering AS beam to IMC WFS heads.
Attachment 1: PXL_20230120_041313615.jpg
PXL_20230120_041313615.jpg
  17407   Fri Jan 20 20:13:20 2023 AnchalUpdateASCInstalled 2 flipper mirrors for handingl MC reflection beam to camera

After discussions with Yuta, I figured that a better optical layout is possible which does not interfere with the existing IMC WFS path at all. So I reset the IMC WFS path today (and zeroed RF offsets again) and changed the MC reflection camera and MC reflection beam dump (black hole) position to create space for a flipper mirror that will pop up in the IMC WFS path and steer in the AS beam. New proposed path is shown in the photo in cyan. Red is MC reflection beam, yellow is IFO reflection beam and orange is teh AS beam that we will pick up using flipper mirror M1. Note that I found an intense 6.4 mW ghost beam coming out of the interferometer in between IFO refl and MC refl beams. This beam is shown in pink which I have dumped now. This beam was earlier not dumped. We will need to investigate more on the source of this beam and correct it in the next vent.

Attachment 1: PXL_20230121_035908170.NIGHT.jpg
PXL_20230121_035908170.NIGHT.jpg
  17408   Sat Jan 21 15:32:40 2023 AnchalUpdateASCAS WFS path nominally set

I've completed the beam redirection path for AS beam to WFS heads in a nominal way. By that I mean that all mirrors (M1, M2, M3, and M4) are now in their final positions and we will need to install one or two lenses to collimate the beam to match the mode that the WFS path is expecting as it has it's on the focusing lens before the photodiodes. For this last part, I think the fasted way would be to profile the beam and calculate the correct lens and position rather than trial and error as the beam intensity is very low for estimating the beam size by eye.

IMC WFS state: Flip M1 and M2 down.

AS WFS state: Flip M1 and M2 up.

Attachment 1: PXL_20230121_231740878.NIGHT.jpg
PXL_20230121_231740878.NIGHT.jpg
  17409   Sat Jan 21 18:01:06 2023 AnchalUpdateALSDFD and Phase tracker AM coupling

I took transfer function measurement of DFD AM coupling using noise excitation.


Noise excitation setup

Noise is injected using C1:BAC-SPARE_CH14_EXC using awggui which is filtered by a foton filter to simulate the real beatnote RF amplitude noise measured by taking quadrature sum of C1:ALS-BEATY_FINE_I_OUT and C1:ALS-BEATY_FINE_Q_OUT. See attachment 1.

The DAC output is connected to MP1 at CH1. MP1 is set to run in waveform generation mode with following settings:

 

  • Carrier frequency: 45 MHz
  • Carrier Level: 500 mVpp
  • No offset or phase offset
  • Amplitude modulation ON
    • Modulation slope: 100%/V
    • Source Input: Ch1

The AWGUI is set to excite C1:BAC-SPARE_CH14_EXC using settings mentioned in attachment 2.

With this setup, the RF amplitude noise is simulated with MP1 and DAC excitation.


Transfer function measurement

With AWGGUI running as mentioned above, I simply used diaggui in spectrum mode for channels C1:BAC-SPARE_CH14_EXC and C1:ALS-BEATY_FINE_PHASE_OUT_HZ. The second channel is already calibrated into Hz, and the first channel is in counts. To convert it into voltage of amplitude fluctuation, I first converted DAC excitation to voltage by assuming 16 bit DAC with +/- 10 V range, this gives conversion constant of 10/2**15 V/cts. Then since MP1 is doing 100%/V AM modulation, for 500 mVpp RF level, this means 0.25 V/V AM modulation. Multiplying these two together gives, 7.6294e-5 V/cts. I put this number in teh diaggui calibration for C1:ALS-BEATY_FINE_PHASE_OUT_HZ.

This created the transfer function measurement attached in attachment 3.

The measurement resulted in roughly 2kHz/V AM to frequency coupling in DFD + phase tracker setup. The previous measurement with coherent sinusoidal excitation was exactly a factor of 1000 less than this, so I believe I might have made some error in calibrating or there could be an error in the previous elog. Please check my calculations. But a solid thing to note is the coherence measured below 1Hz. I'll do more sophisticated analysis on weekdays.

I also think that coherence was low because of low excitation. We should redo this test with more noise power to get good coherence in all frequency band to have good idea of what would happen to ebatnote RF amplitude noise at all frequencies.


Mon Jan 23 11:47:23 2023 Adding Attachment 4:

I realised that with the noise excitation setup set to mimic real beatnote amplitude noise with very low frequency noise as it is seeded with Moku:Pro, the measured frequency noise by the DFD+Phase Tracker setup at C1:ALS-BEATY_FINE_PHASE_OUT_HZ is an indicator of how much RF amplitude noise of beatnote contribute to the frequency noise measured by DFD+Phase tracker. Attachment 4 is the spectrum measured during this measurement.

Attachment 1: BeatYRFAmplitudeNoiseASDwithSimulation.pdf
BeatYRFAmplitudeNoiseASDwithSimulation.pdf
Attachment 2: AWGguiSettingsForSimulatedRFAMNoise.png
AWGguiSettingsForSimulatedRFAMNoise.png
Attachment 3: DFD_AM_to_Hz_Coupling_upto_0p1Hz.pdf
DFD_AM_to_Hz_Coupling_upto_0p1Hz.pdf DFD_AM_to_Hz_Coupling_upto_0p1Hz.pdf
Attachment 4: DFD_Phase_Tracker_Noise_Due_To_Amplitude_Noise.pdf
DFD_Phase_Tracker_Noise_Due_To_Amplitude_Noise.pdf
  17412   Mon Jan 23 20:50:58 2023 AnchalUpdateASCAS WFS path beam profiled

I measured the expected beam profile by WFS photodiodes by measuring the beam when mode cleaner was unlocked from the point where beam is picked for WFS. See attachment 1 for beam details. z=0 is the point in the path where AS beam will merge.

For measuring the beam profile of AS beam, I had to focus it using a lens. I picked up a 360.6 mm ROC lens and placed it at z=-67 inch point. Then I profiled the beam at some comfortable section of the path and fitted it. with reverse z-axis. Using this method, I can place the lens back and obtain the original beam back. Attachment 2 shows this fitting process and identification of the original beam profiles. I plotted the AS beam profiles again in attachment 3 and saved them for seeding mode matching effort later. Note that we don't want to be super accurate here, so I did not do any error analysis, just wanted to finish this fast. Also pardon me for the bad quality plots, I did not want to learn Matlab plotting to make it beautiful.

Note: There is significant astigmatism in both IMC reflection beam and AS beam. This could be due to beam going through far off-center on lens. Something to keep in mind, again this measurement is not ideal in terms of precision but this large an astigmatism could not be due to measurement error.


Next:

  • Identify correct len(s) and their positions
  • Align the AS beam to WFS heads
  • Test the full signal chain.
Attachment 1: WFSPathBeamProfile.pdf
WFSPathBeamProfile.pdf WFSPathBeamProfile.pdf WFSPathBeamProfile.pdf
Attachment 2: ASFocPathBeamProfile.pdf
ASFocPathBeamProfile.pdf ASFocPathBeamProfile.pdf ASFocPathBeamProfile.pdf
Attachment 3: ASPathBeamProfile.pdf
ASPathBeamProfile.pdf ASPathBeamProfile.pdf ASPathBeamProfile.pdf
  17416   Tue Jan 24 21:04:59 2023 AnchalUpdateASCAS WFS path beam profiled

I completed the mode matching calculation today and found good solution with 360.6 mm ROC PLCX lens at -1.2 m from z=0 point. I placed the lens there today and aligned all mirrors to get centered beam on both WFS PDs when the flipper mirrors are flipper up. This alignment would probably require tweaking everying we flip the mirrors as the flipper mirrors do not come back to same position usually.

I mounted the modified WFS boards 111B and 112B next to the whitening filter boards of existing WFS. Now to switch over, onewould need to transfer the 8 RF lemo cables and the 2 IDE ribbon cables.

I'm working on rtcds model to read AS WFS data and handle it separately. I'll keep a WPICS binaruy switch to switch between IMC WFS or AS WFS. I need to figure out some build issues on this work still.

 

Attachment 1: ASBeamFocusingLens.png
ASBeamFocusingLens.png
  17425   Thu Jan 26 15:56:30 2023 AnchalUpdateASC1X1 -5V sorenson tripped

[Yuta, Anchal]

Quote:

I mounted the modified WFS boards 111B and 112B next to the whitening filter boards of existing WFS.

The mounting of two additional WFS demodulation boards drew too much current on -5V rail which tripped the sorenson on 1X1. This was undetected until today. Because of this, the existing WFS boards were not working either. After investicgation to beam paths and PD to board signal chain, we found out this issue. We raised the current limit on -5V supply and it came back to 5V. This brought back functioning of the exisitng WFS boards as well. We increased the current limit slightly on +5V supply too as these boards take a lot of current on +/5 V rails. But we should do this more properly by knowing what current limit the supply is set to. We'll do this part in near future after reading the manuals/wiki.
IMC WFS loops are now working.

  17427   Thu Jan 26 18:20:43 2023 AnchalUpdatePEMHEPA Monitor setup using WFS BLRMS

I implemented the BLRMS on WFS1/2_I_PIT/YAW outputs and using there value, a HEPA state can be defined. I've currently set it up to use average of 10-30 Hz noise on WFS signals low passed at 0.3 Hz. For ON threshold of 100 and OFF threshold of 50, it is working for my limited testing time. To read HEPA state, one can do caget C1:IOO_HEPA_STATE. I've turned OFF HEPA for tonight's shimmer test. This is bare bones quick attempt, people can make the screen more beautiful and add more complexity if required in future.

Attachment 1: HEPA_MONITOR.png
HEPA_MONITOR.png
  17435   Tue Jan 31 11:02:16 2023 AnchalSummaryBHDc1cal DAQ error 0x2000 fixed

The 0x2000 error happens when the rtcds model can not acquire the requested number of channels at their data rates. Basically, there is a maximum total data acquisition that one model can do (which is unknown to me). To fix this, I removed 2048 Hz acquiring of C1:CAL-SENSMAT_<DOF>_<RFPD>_<I/Q>_DEMOD_SIG_IN1. This would not allow us to do software demodulation of calibration lines ourselves. but C1:CAL-SENSMAT_<DOF>_<RFPD>_<I/Q>_DEMOD_<I/Q>_IN1 are still acquired at 2048 Hz to do our own low pass filtering in software and C1:CAL-SENSMAT_<DOF>_<RFPD>_<I/Q>_DEMOD_<I/Q>_OUT are acquired at 256 Hz.

This removal worked, and restarting DAQD worked and now c1cal does not have any DC errors. Current total data acquisition C1:DAQ-FEC_50_TOTAL is 2521 which is less than our other heavy models like c1lsc, c1sus etc. So c1cal can probably acquire more in future, but care is required while adding new channels. This issue happened because we added BH44 to the calibration model.

ELOG V3.1.3-