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.

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):

*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.

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

[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.

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.

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.

[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.

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:

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:

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

[Yuta, Anchal]

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.

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.

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.

Model changes and addition of Moku Phasemeter

Today I setup Moku:Pro MP1 with phasemeter app to replace DFD + Phase tracker.

Phasemeter settings:

• Both channels:
  • Frequency: Auto (Auto track frequency)
  • Bandwidth: 1 MHz
• Advanced:
  • Freewheeling: ON
  • Single input: ON (Used for now, later the two channels will use different inputs)
• Output for both outputs:
  • Signal: Freq offset
  • Scaling: 1.000 mV/Hz
  • Invert: off
  • Offset: 0.0000 V

Moku Input output settings:

• In 1 and In 2:
  • AC: 50 Ohm
  • -20 dB attenuation: 4 Vpp range
• Out1 and Out2:
  • +14 dB gain: 10 Vpp range

The phasemeter is set to autotrack the frequency with PLL bandwidth fo 1 MHz. The output of the phasemeter (frequency offset) is sent out through the output channels at 1mV/Hz rate. These are digitized at c1lsc ADC and are available as an alternative to phase tracker output channel. One can switch between the two ways of measurement by using C1:ALS-SEL_PHASE_SOURCE channel. See attachment 1 and 2 for the two mode options. For this, I modified c1lsc model today

Moku Phasemeter calibration

I used marconi to send 45 MHz RF output as -2 dBm level with internal FM modulation of peak 200 Hz at 211 Hz. This was used to calibrate the Moku Phasemeter outputs to set channels

C1:ALS-BEATX_MOKU_PHASE_OUTPUT_HZ and C1:ALS-BEATY_MOKU_PHASE_OUTPUT_HZ in units of Hz. This method is not very reliable as I do not know if marconi actually sent 200 Hz peak. The calculations from ADC conversion and moku slope of 1mV/Hz give similar numbers though. However, if we want to be accurate in our calibration project, more detailed calibration of these channels is required with a better technique. For now, I assumed that this value is good atleast to a 1% level.

AM coupling test and noise measurement

I followed the exact same setup as in 40m/17409 to create a RF signal using MP1 waveform generator which is AM modulated by awggui noise excitation to create similar AM noise as measured for BEATY RF output. The measurement can then take AM coupling transfer function measurements. Attachment 3 are the results of this measurement. In comparison to DFD + Phase tracker system, the transfer function is 2 orders of magnitude less. Even if my calibration of AM modulation is wrong, same calibration is sued for both transfer functions, so the difference measured is real. We are mostly measuring noise in this measurement as the coherence is also very low for all of the frequency range. See the 4th plot to see the inferred measurement noise of Moku phasemeter setup. Attachment 4 shows this data in comparison to data taken in 40m/17409 with DFD + Phase Tracker setup. Moku Phasemter setup provides roughly factor of 4 less noise in our calibration line frequency band.

I wondered if Moku could have lied about its noise measurement since the RF source was the same Moku device. To avoid this bias, today I repeated this measurement with sendinf RF from Marconi. Marconi settings were:

• Carrier Frequency: 45 MHz
• RF Level: -2 dBm
• Mod AM ext DC: 90 %

The Marconi was fed noise from DAC output to match the measured BEATY RF amplitude like the previous posts: Attachment 1 shows AWGGUI settings required and attachment 2 shows the measured RF amplitude noise with the simulated source.

This source was then fed one by one to DFD + Phase tracker system (attachment 3) and then Moku Phasemeter setup (attachment 4). The phasemeter settigns were same as the previous post. Attachment 5 shows the two transfer functions of AM to frequency coupling on the same plot for comparison. Attachment 6 shows the comparison of frequency noise floor between the two methods on the same plot. In this measurement, I rechecked by DAC actuation calibration by measuring it directly. For Marconi AM modulation slope, I took into account the fact that the slope is in %/Vrms. I got it crosschecked with Paco this time. I think the calibration is correct. Moku phasemeter is indeed better by atleast 20 times in the frequency region of interest. The nosie floor is a factor of 3 less. I think this measurement clears Moku phasemter as the choice of frequency discriminator for calibration project. Any comments/opinions are welcome.

[Anchal, JC, Radhika, Paco]

JC reported that power outage happened twice in 40m today at around 4:17 pm.

We followed instructions from this page mostly to recover today. Following are some highlights:

Main laser controller fan broke

Paco reported that the adhoc fan in the back of main laser controller slid down and broke. Their might be contamination on the table from broken fan parts. Paco replaced this fan with another fan which is larger. I think it is time to fix this fan on the controller for good.

Main volume valve V1 shutdown

The main volume valve shut down because c1vac turned off. We restored the vacuum state by simply opening this valve again. Everything else was same as until the final step in vacuum resetting steps.

Mode cleaner locking issues

The burt restore for mode cleaner board settings do not bring back the state of channels C1:IOO-MC_FASTSW and C1:IOO-MC_POL. This has been an issue which has puzzled us in the past too as we try to get the mode cleaner to lock after power outage recovery. I have now added these channels and their required state in autolocker settings so that autolocker scan in the correct state always. It seems like I added with Yuta's name in the commit author.

Model and medm changes

After incrementally doing the model changes, I found out that the model was failing to build because of creation of a subsystem. If I just kept all divertor blocks out in the main model instead of in a single subsystem, the compilation works. Maybe the reason is because RCG can only take subsystems at base level which have top_names attribute. But I did nto test this, I just went with what works.

In summary, I added a new subsystem in c1ioo model called AWS (stands for Antisymmetric Wavefront Sensors). This subsystem and IOO subsystem receive teh WFS RF demodulated signals based on a single binary switch named C1:IOO-SEL_WFS_IMC_OR_AS. Value 0 connects the subsystem IOO to the inputs and value 1 connects AWS to the inputs. There is a switch on the left edge in the WFS screens now to select between the two.

Inside the AWS, the WFS I/Q phase rotation is done and then it goes into one of the two subsystems called AWS-XARM or AWS-YARM for using the AS for either XARM or YARM. THis is based on a single binary switch called C1:AWS-SEL_ARM_X_OR_Y. Value 0 selects output to XARM and value 1 selects output to YARM. There is a switch near top left of  C1AWS_XARM_WFS_MASTER.adl and C1AWS_YARM_WFS_MASTER.adl screens. I copied these screens from C1IOO_WFS_MASTER.adl, so they have same structure. See attachment 1. Any edits should be made to /opt/rtcds/caltech/c1/medm/c1ioo/master/C1AWS_XARM_WFS_MASTER.adl and simply run python opt/rtcds/caltech/c1/medm/c1ioo/master/createYARMWFSscreensFromX.py to create teh YARM screen from it.

Along with this, models c1scy and c1scx were edited also to take in IPC directly from c1ioo instead of going through RFM. We should phase out use of RFM eventually and directly connect all IPC connections with the ends.

First tests

[Anchal, Yuta]

After the model is up and running, we flipped the WFS path to use AS beam. I switched the 8 RF outputs of the WFS from IMC WFS boads to AS WFS boards and switched the IDC connectors to WFS. Attachment 2 shows teh photo in this flipped state. Then we misaligned both ITMX and ETMX. First simple test was to check if we see the YARM PDH error signal when YARM was flashing. And indeed we saw that on all 16 channels. So next we locked YARM and injected 311 Hz line with 300 counts amplitude at ETMY. We looked for this peak in the Q channels of WFS outputs and adjusted all phases to 0.1 degrees to minimize Q signal to the noise floor. For WFS2 case, teh SNR is bit higher due to more power than WFS1 and their phase angle might be adjusted to even better degree but we did not got for it.

Then I used C1AWS_XARM_WFS_MASTER.adl>!Actions>Correct WFS RF offsets button to remove offsets in all the RF demodulated signals. I have set this button to use /opt/rtcds/caltech/c1/Git/40m/scripts/RFPD/resetOffsets.py script.

At this point, we are ready to see if we have WFS sensitivity but I need to work on other projects today and Yuta and Paco took over interferometer for 60 Hz noise hunting.

Filter and scripts setup

I copied IOO_WFS1_I filter bank to AWS_WFS1/2_I/Q filter banks to copy the dewhitening and 60comb filters. Then I turned them on.

Similarly, I copied IOO_WFS1_PIT filter bank to AWS_YARM/XARM_WFS1/2_PIT/YAW filter banks. I created a generalised script to handle all WFS on/off.hold/onfromhold operations here. I also generalized toggleWFSoffsets script to be used for measuring DC sensing matrix.

DC sensing matrix measurement

This measurement folllowed the method used by Koji in 40m/17354. The measurement is pushed here. Ntoe that when using this method, while the test finishd in ~1000 seconds, it takes dtt >20 min to retrieve the timeseries data from DQ channels. Thisis weird because cdsutils.getdata does not have this lag. If anyone knows why this is the case, it would be helpful in making this method faster.

• Locked YARM and misaligned ITMX and ETMX
• Centered the AS beam on WFS using DC value.
• Ran ASS on YARM to get to best aligned cavity state.
• Unlocked YARM and ran C1AWS_YARM_WFS_MASTER>!Actions>Correct WFS RF offsets to zero teh offsets.
• Locked YARM again and waited for >120 seconds.
• Ran python /opt/rtcds/caltech/c1/Git/40m/scripts/AWStoggleWFSoffsets.py AWS BOTH -a YARM -t 120
  • Measurement start time: 04/02/2023 22:37:00 UTC
• The offset values required for step response test above were determined by trying out values and making sure that transmission does not go down by more than 15%.
• I had to leave by 3:30 pm, so I couldn't complete the analysis of measured data.I'll post data here soon.

Additions Sun Feb 5 18:06:54 2023:

Data analysis

I got the step response data using cdsutils.getdata and measured the sensing matrix and took and inverse with error propagation. Attachment 1 page 1 shows the raw data measured. Then the data was segmented based on step response time data and a linear fit is used to get linear trend of each channel in null configuration. This is used to remove bias later while measuring the step heights in each sensor. Page 2 shows this data. Page 3 shows final detrended and normalized step response data that was used to measure the sensing matrix. It came out to be:

                                                             YARM WFS DC Sensing Matrix

        ITMY PIT         ETMY PIT         ITMY YAW         ETMY YAW
   1.94 +/- 0.02    0.83 +/- 0.07   -0.15 +/- 0.04      1.3 +/- 0.1  to WFS1 PIT
   5.62 +/- 0.05      8.8 +/- 0.2     -0.2 +/- 0.1      2.5 +/- 0.2  to WFS2 PIT
  -0.43 +/- 0.03   -1.13 +/- 0.07    1.51 +/- 0.04     -0.9 +/- 0.2  to WFS1 YAW
  -1.42 +/- 0.05     -7.1 +/- 0.2      3.3 +/- 0.1    -19.5 +/- 0.4  to WFS2 YAW

Taking it's inverse with uncertainties supported matrix inverse function gave following output matrix to be used:

        WFS1 PIT         WFS2 PIT         WFS1 YAW         WFS2 YAW
   0.628+/-0.022   -0.031+/-0.007   -0.027+/-0.020    0.039+/-0.004  to ITMY PIT
  -0.431+/-0.020    0.146+/-0.007   -0.002+/-0.018 -0.0099+/-0.0030  to ETMY PIT
  -0.086+/-0.031    0.078+/-0.010    0.728+/-0.029   -0.029+/-0.008  to ITMY YAW
   0.097+/-0.009 -0.0377+/-0.0030    0.126+/-0.008 -0.0555+/-0.0020  to ETMY YAW

Our main laser has tripped suspiciously twice since the power shutdown. The last time it happened on Thursday Feb 2 night (the day of power outage happened). Next morning Paco turned the laser back on, I'm not sure if he did anything else other than turning the diode current driver ON. Paco, please add anything else you did.

Chris reported that the laser tripped again last night on Feb 4th around 6 pm. I came today to see the same situation, laser diode turned OFF. After a discussion with a friend in the weekend, it turned out that sometimes when brief power outages happen, the TEC circuit for mainitaing laser tremperature turns OFF while the current driver keeps running. I'm not sure if that is the case for us but that can cause such tripping due to over heating. So today instead of simply turning on the current driver again, I power cycled the laser controller. Laser is back on and mode cleaner is locked with fewer counts though since PMC transmission dropped. I don't have time to realign PMC today and I think it might be the case that the transmission would increase once laser has reached a steady state. On Monday, we need to consult with people with more experience and understand why our laser is tripping. I hope it is not sick.

[Anchal, JC]

During shimmer test yesterday, the man laser tripped again. This morning, JC and I went to inspect the situation closer. We figured that if we can take a look inside the controller, we can get the replacement fan part number. Attached are some photos of inside. To open the controller, all you need to do is take out the two standoffs that are at the edges in the back side, then the top or botttom cover can slide out. Inside, all heatsinks of heat generating ICs are clamped to a larged metal heat sink which is covered on all side but one at the rear end. Through two holes in the top of this cavity, two fan push air through the heat sink to the back. This prompted us to understand that if the externam cooling fan direction is wrong, it would be pshing in air rather than pulling it out. So we decided to try the configuration where the fan is pulling out air. We think the direction of the fan was wrong till now which might be causing the laser controller to shut down. Now we need to wait and watch. For now, the laser is up and running.

Bt the way, we could not get any part number from the fans inside. We are still looking around in the lab if we have the replacement fans in hand as steve said they procured some.

I uploaded this measured output matrix to the YARM WFS model:

        WFS1 PIT         WFS2 PIT         WFS1 YAW         WFS2 YAW
   0.628+/-0.022   -0.031+/-0.007   -0.027+/-0.020    0.039+/-0.004  to ITMY PIT
  -0.431+/-0.020    0.146+/-0.007   -0.002+/-0.018 -0.0099+/-0.0030  to ETMY PIT
  -0.086+/-0.031    0.078+/-0.010    0.728+/-0.029   -0.029+/-0.008  to ITMY YAW
   0.097+/-0.009 -0.0377+/-0.0030    0.126+/-0.008 -0.0555+/-0.0020  to ETMY YAW

Then I played witht the signs of the gains and their values in the C1:AWS-YARM_WFS1/2_PIT/YAW filter banks until I saw a correct response for steps on ETMY and correction within 10-20 s.

I measured the OLTF of the loops with noise injection in each loop simultaneously. This test takes ~10 min. Except for the WFS2 YAW loop, all other loops behaved as expected with UGFs in WFS1 PIT 0.02 Hz, WFS1 YAW 0.04 Hz, and WFS2 PIT 0.035 Hz.

I left this state On for 1 hour and the YARM retained transmission. Attachment 2 shows the history.

Then I conducted another toggle test to see how the step response is. Attachment 3 shows the same results as last post for the new output matrix. Note high sensitivity of WFS2 YAW signal to PIT actuations. The worst row was for WFS2 YAW degree as expected (see page 3 attachment 3).

The new calculated output matrix (after product with the existing matrix) is:

                                                         YARM WFS Estimated Output Matrix

        WFS1 PIT         WFS2 PIT         WFS1 YAW         WFS2 YAW
     0.70+/-0.05    0.011+/-0.014   -0.203+/-0.032   -0.093+/-0.010  to ITMY PIT
    -0.42+/-0.04   -0.111+/-0.010    0.025+/-0.025    0.019+/-0.007  to ETMY PIT
    -0.00+/-0.05   -0.091+/-0.016      0.76+/-0.04    0.041+/-0.013  to ITMY YAW
   0.201+/-0.022    0.062+/-0.007    0.244+/-0.015    0.067+/-0.005  to ETMY YAW

With this matrix in, I had to change all gain signs to negative and teh loop was stable to my kick test on ITMY and ETMY on both PIT and YAW DOFs. OLTFs can be tuned further. Maybe later, I'll do another toggle testin hope of getting an identity matrix.

I did a quick step response test today with YARM WFS loops running. Steps were put in as offsets in channels C1:SUS-I/ETMY_ASCPIT/YAW_OFFSET to not let transmission go below 0.6-0.7 out of 1. I waited 30 seconds between each step by simply running sleep 30 on my terminal. Once finished, dtt still was taking a long time to get recently measured data even for 16 Hz channels. I used cdsutils getdata to get the measurement and calculate time constants for each loop. Time constant is defined by the time it took for C1;SUS-I/ETMY_ASCPIT/YAW_OUT16 channel to come to 1/e of the offsetted value. Inverse of this time constant is also printed as text on the plot. Note that I redid step on ETMY PIT as the first pass seemed not strong enough to me. See attachment 2 for settings.

The Pit loops seem to be bit faster with about 5s time constant while YAW loops have about 10s.

[Anchal, Yuta]

We think we have narrowed down the source of 60 Hz noise to one fo the following possibilities:

• Ground loop present along the MC1 suspension damping loop
• 60 Hz DAC noise on inputs of MC1 coil driver
• 60 Hz noise injected at dewhitening board before the dewhitening filter

The second and third cases are unlikely because we see 60 Hz noise present only in MC1 coils, not MC3 coils while they both share the same connection from DAC to SOS dewhitening filter boards as they share the SOS dewhitening board D000316-A. So it is unlikely that only the MC1 channels have this noise while the MC3 channels do not.

This inference was made from following observations:

Note: Turning ON analog dewhitenign on MC1 coil is done by turning off FM9 switch which is the simulated digital dewhitening filter. Also note that theanalog dewhitening filter has an attenuation of 30 dB at 60 Hz.

MC1 has an unconvetional setup where the satellite amplifier is from the new generation while the coil driver and dewhitening boards are from the old generation. The new generation satellite amplifiers sen PD signal through differential ended signals but the old generation PD whitening interface expects single ended inputs, so we ahve been using PD monitor outputs from the satellite amplifier which connects the ground of the two boards to each other. Maybe this is the reason for the ground loop.

I have updates the ASC model inside c1ioo.mdl file to take inputs from IMC WFS when selected with AS option (on the left side of AS WFS block. I've also implemented the missing lockin option in this model. Currently the old AWS model is still in c1ioo which will be removed once we have successfully used the new ASC model for locking AS WFS loops for YARM. Now ETMX and ETMY QPD signals are also available in the input matrix for use and available outputs are ETMs, ITMs, BS, PRM, and SRM.

While changing these models, I also removed use of RFM model in ASC as this is not required anymore. The IPC from any model to any model can be done directly now. Overtime, c1rfm would be retired by removing one channel connection at a time.

Overtime the coil output filters on IMC optics have drifted into a bad configuration. Today at the meeting, Rana told us the correct configuration for these filters. I'll summarize this here and we have changes the filters on all IMC optics, MC1, MC2, and MC3 to match this configurations:

MC1 and MC3

Analog side:

Both MC1 and MC3 have a 28 Hz 5th order elliptical low pass filter as teh dewhitening filter in LIGO-D000316

Digital side:

At the coil output filters named as C1:SUS-MC1_ULCOIL, the filter module FM9 is connectd in RTCDS to the analog dewhitening filter such that only one of the two can remain ON. So For MC1 and MC3, we put a ellip("LowPass", 5, 1, 50, 28) filter on FM9 for all 5 coil output filters.

Note: We do not add a inverse dewhitening filter at FM10 like most other optics as inverting this filter will create resonant peaks at the dips of the elliptical filter which we want to avoid and we anyways do not use MC1 and MC3 optics for any kind of actuation above 20 Hz.

MC2

Analog side:

For MC2, the dewhitening filter is a 10 Hz pole, 30Hz zero like most other suspended optic.

Digital side:

At the coil output filters named as C1:SUS-MC2_ULCOIL, the filter module FM9 is connectd in RTCDS to the analog dewhitening filter such that only one of the two can remain ON. So For MC2 we put a SimDW filter which is matched to the anlog filter. We also put a InvDW filter on FM10, which is the analytical inverse of the SimDW filter. This filter does the anti-dewhitening required on the digital side and should be always ON.

To MC2 equivalent to other IMC optics in terms of overall transfer function for the local damping loops and ASC loops, we need additional 28 Hz elliptical low pass filter in these loops. But such a filter should not be in the path of LSC feedback when MC2 is used for locking CARM with a bandwidth of ~100 Hz. Thus, we put a ellip("LowPass", 5, 1, 50, 28) filter on FM6 of the following filters, which should be always ON as well:

• C1:SUS-MC2_ASCPIT
• C1:SUS-MC2_ASCYAW
• C1:SUS-MC2_SUSPOS
• C1:SUS-MC2_SUSPIT
• C1:SUS-MC2_SUSYAW
• C1:SUS-MC2_SUSSIDE

Effect on 60 Hz Noise

With the above changes, we see that the 60 Hz noise is same as the previous levels when we use the analog dewhitening filter (28 Hz elliptical filter) for MC1. We can move forward with our science experiments with that configuration but there is still something fishy about MC1 in comparison to MC3 which does not have this behavior. So this still needs to be looked at in future.

Wiki page for filter details and configurations

Information of this kind should be stored in a wiki page in my opinion. We should have a page where we list all common filter configurations for our suspensions and other loops, that can be generally classified and is useful for understanding legacy configuration for future folks who work here. I'm starting such a wiki page here, where I'll dump more information as I collect it and get time. Everyone is encouraged to update this in there free/procrastination times.

On rossa in tmux session name FPMI_DARM_Cal, a script is running to take FPMI DARM calibration data at 1:00 am on March 9th. Please do not disturb the experiment untill 6 am. To stop the script do following on rossa:

The script will lock both arms, run ASS, then lock FPMI, then tune beatnote frequency with Y AUX laser to around 40 MHz, set phase tracked UGF to 2 kHz, clear phase history, take OLTF of DARM from 2 kHz to 10 Hz, take OLTF of CARM and AUX loop at calibration line frequencies, turn on the calibration lines, and wait for FPMI to unlock or 5 hours to pass, whatever happens first. At the end it will turn off the calibration lines.

Running this test again tonight. Will probably run it every night now.

I tried a different method today to see if it works. Following are the steps:

• Run WFS relief.
• Turn off the WFS loops.
• Calculate the effective current YAW matrix by transferring C1:IOO-MC#_YAW_GAIN to respective rows of the matrix read from C1:IOO-OUTMATRIX_Y. No need to change the matrix itself.
  • This step should not be required. We should move these gains to the matrices as soon as we can.
• Put in the first column (corresponds to WFS1_YAW controller output) of this effective current YAW matrix to C1:IOO-LKIN_OUT_MTRX_4_1, C1:IOO-LKIN_OUT_MTRX_5_1, C1:IOO-LKIN_OUT_MTRX_6_1.
  • This is the output matrix of LOCKIN in WFS screens.
  • We are trying to actuate on what we think only affects WFS1_YAW and see if it is crosscoupled to WFS2_YAW or MC2_TRANS.
  • Then we can cancel coupling to the other two sensors by changing our couple vector.
• Turn on locking at 0.5 Hz with gain 1.
• Turn on BLP0.3 filter module. This is a 8th order 0.3 Hz butterworth filter.
• Adjust phases to get all signal in the I quadratures.
• Using ratio of C1:IOO-WFS_LKIN_I5_OUT16 to C1:IOO-WFS_LKIN_I4_OUTPUT, subtract or add this much factor of the WFS2_YAW column (the second column) of the effective YAW matrix to the column that is put in the LOCKIN output matrix.
  • I was able to subtract to less than 10% cross coupling with the intial matrix I started with.
• Repeat until no cross-coupling is seen between WFS1_YAW and WFS2_YAW.
• Repeat the above steps for WFS2_YAW column by putting that into the LOCKIN output matrix. Use the column calculated in last step for adding or subtracting WFS1 actuation.
  • I was able to make WFS2 column very clean with less than 1% measurable crosscoupling to other sensors.
• I repeated the step for WFS1 column again to remove the cross coupling to WFS2 further to less than 1%.
• For doing the above steps for MC2_TRANS column, the initial effective matrix column was very bad. The outputs were higher in WFS1 and WFS2 then MC2_TRANS output itself.
• So I made the first guess by taking a cross-product between the obtained WFS1_YAW and WFS2_YAW columns estimated earleir.
• Then I repeated the above steps to minimize coupling to WFS1 or WFS2 sensors to less than 10% of MC2_TRANS.
• THe three column vectors obtained represent the new outpute YAW matrix. I removed the normalization that would be applied by C1:IOO-MC#_YAW filter gains from the rows of this amtrix to get the output matrix that can be put into C1:IOO-OUTMATRIX_Y

Once this matrix was in, I quickly tested it by closing the loop and making gain sign flips if required. Then I took quick swept sine transfer functions to estimate UGFs and scaled the columns of the output matrix to get UGF of 2.5 Hs for WFS1_YAW and WFS2_YAW loops and 0.1 Hz for MC2_TRANS YAW loop when all filter gains are 1 and overall gain C1:IOO-WFS_GAIN is 4. See attached plots.

Old matrix:

-4.094  ,  -3.0383 ,  34.0917
-0.1259 ,   0.27008, -16.081  
-7.1811 ,   0.74271,  28.9458

This was used with gains: 0.5 for WFS1_YAW loop, 0.6 for WFS2_YAW loop and 0.3 for MC2_TRANS_YAW loop.

New matrix:

-1.48948, -1.3029 , -4.93096
-0.05839,  0.15206, -3.66245
-2.82285,  0.92391, -4.68009

All loop gains 1.

Alex and Tomohiro are characterizing this matrix with step response and UGF measurements.

I realized that for more phase margin, rana added 6:3lead filter on WFS PIT loops. Since we have increased the UGF on YAW loops too, I turned these on the YAW loops as well. The loops remain stable unlike with the previous matrix. Attachment 1 is the repeat of teh emasurement done by rana earlier but with the new matrix and updated gains in PIT loops. The dark green traces are the references from last measurment with higher gain and HEPA off. The remainging colored traces were measured today.

The WFS loops were not maximizing the IMC transmission. The transmission counts remained stuck at around 12500 counts. The reflection DCMON from IMC had reached above 0.35 while nominally it had been around 0.2. So today, I manuaaly aligned the IMC to best transmission and lowest reflection, then unlocked IMC and reset the offsets on WFS1 and WFS2 RF readouts. After the offsets were changed, the error singals were fluctuating around 0 in best algined state. Then turning on the WFS loops made the transmissions slighlty higher to 13250 counts.

I've updated c1ioo model with adding WFS sensor to optic angle matrix and output filter module option. The output filter modules are named like EST_MC1_PIT to signify that that these are "estimated" angles of the optic. We can change this naming convention if we don't like it. I've also started DQ on the outputs of these filter moduels at 512 Hz sampling rate.

No medm screens have been made for these changes yet. One can still access them through:

For SENS_TO_OPT_P Matrix

For SENS_TO_OPT_Y Matrix

For filter modules:

I confirmed that MC Length feedback path to MC2 position is present and has been turned off in recent history. Feedback filter module can be seen in sitemap>IOO>Lock MC>MC2_LSC where the bottom fitler module is for feeding back MC Length to MC2. See attached screenshot.

This feedback signal goes and gets added to MC2 suspension longitudnal signal through ALTPOS path which is nominally not shown in any of the suspension screens (including the old ones). Note that this path is different than the LSC path that comes into each suspension screen.

Today, I tried a quick turning ON of this apth without playing around with any of the filters to see if the feedback helps. On first glance, it does not seem to help. Probably the gain values and filter modules need ot be adjusted. See attachment 2.

I'm turning this off again and in future someone should take a look at this loop.

I ran two recently trained neural network controllers today between 10 am and Noon. Each test comprised of four segments:

• All loops open
• Linear loop closed
• Neural Network working alone
• Neural Network + Linear Loop

The latest controller unfortunately failed in both cases, working alone and working together with linear loop.

The second latest controller functioned well, keeping the arm locked throughout.

I've turned on NN controller for MC WFS PIT loops. One can disable this controller and go back to linear controller by sitemap>IOO>C1IOO_WFS_MASTER>Actions!>Stop Shimmer . One can start the controller again sitemap>IOO>C1IOO_WFS_MASTER>Actions!>Run Shimmer .

I calibrated the moku phasemeter setup for reading beatnote fluctuations today. The calibration is referred to the DFD output (not including the phase tracker) channels by using the measurement made by gautam in 40m/14981.

Measurement setup

• Set marconi to 40 MHz carrier, FM1 sine deviation of amplitude 2000 kHz (we expect maximum beatnote fluctuation of ~1.8 kHz for 50 pm length modulation in the arm length) at 145 Hz.
• The output of amrconi is splitted, one half going to DFD for BEATY, one half going to Moku Phasemeter input 1.
• Moku phase meter is set with following settings:
  • Input1:
    • Frequency : Auto
    • Bandwidth: 1 MHz
    • Coupling: AC
    • Impedance: 50 Ohms
    • Range: 400 mVpp
  • Output1:
    • Signal Freq offset
    • Scaling: 1 mV/Hz
    • Invert: Off
    • Offset: 0
    • Range: 10 Vpp
• Measurement taken from 1365442502 to 1365444003

Analysis

• Read channels C1:ALS-BEATY_FINE_I_OUT C1:ALS-BEATY_FINE_Q_OUT C1:ALS-BEATY_MOKU_PHASE_IN1 for 500s.
• Used np.arctan2(Q, I) to read DFD phase output. Multiplied it by 1e6/70.973 to convert it into Hz using DFd calibration by Gautam in 40m/14981. This measurement brings in 340 ppm of uncertainty in the measurement.
• Demodulated the phase at 145 Hz to get the signal sent by Marconi. Blue trace in the attachment is this signal.
• Demodulated Moku phase output at 145 Hz and calculated the calibration constant required to match the ampltiude with 400second averaged DFD output.
  Calibration constant came out to be: 0.2953 +/- 0.0001
• Multiplied the calibration constant to moku phase output. This is the orange curve in the attachment.
• With this method, we get 0.035% uncertainty on phase calibration from Moku.
• We can now use moku phasemeter for calibration measurements as the pahse tracker gain is not high enough for calibration lines above 200 Hz.

I did offline analysis with the available data. We were only saving signals at 2048 Hz rate, so analysis can not be done on 1.4 kHz line. See attached plot for the difference in the two analysis.

We are aiming to prepare a realtime system deployable calibration method, that's why we were using phase tracker. Note that the calibration results with phase tracker have been compensated for any lack of gain due to phase tracke limited bandwidth, open loop gain of aux loop or remaining suppression from YARM loop despite the notches.

About the moku, we think that something is wrong in connection of moku output to ADC. We see the same cal line heights in the moku app in ipad but after going through ADC, we see about 10 times less line heights and 10 time sles noise floor too. But when we stick a marconi split between DFD and moku, we see the same results, so we are not sure what is wrong with it but it is not trustworthy. Maybe the order of magnitude noise reduciton is because of this factor of 10 that happens when it reads beatnote. To be solved in future, we will carry on with DFD for now.

Last night I took ITMY calibration data using MICH with AS55_Q. Adding that to the same plot. The error bars are probably underestimate with the MICH calibration method due to systematics not taken into account. For this measurement, MICH was locked with low UGF of 20 Hz to avoid all lines in MICH loop. Notches at the line frequencies were also put in. MICH OLTF was measured and any possible suppression of lines has been compensated for (very small). Note that error bars are present for DFD method too, but they are too small in this scale.

MICH calibration did not independently verify the higher actuation strength found by DFD methods at higher frequencies. For an ideal pendulum, the calibration constants should ahve been freqeuncy independent. It does see higher calibration constant values at 500 Hz and 1.4 kHz lines, but with a lot of noise. See attachment 2 for the calibration in real time, but this plot is bit messy. For the three lower frequency lines, DFD+Phase tracker and DFD with offline analysis match in their estimates , there is a significant mismatch at 500 kHz line and we do not have data for doing this for 1.4 kHz line.

I modified the analysis to correct for any affects due to Anti-Aliasing or Anti-Imaging filters, and I also found a insignificant error on how I was undoing the suppression due to MICH loop in the MICH data. I also propagated the calibration in MICH method better. Attached are the updated results. The upward swing is still present.

Also, last night, Koji and I looked into any frequency dependent deviation in sensing arm length between POY11 and BEATY_PHASE (using DFD+Phase tracker) This was done by locked the YARM to the main laser and locking YAUX to the YARM, sending excitationa at C1:SUS-ETMY_POSCAL_EXC and taking transfer function between C1:LSC-YARM_IN1 and C1:ALS-BEAT_Y_FINE_PHASE_OUT. This transfer function was flat upto about 600 Hz and the deviation from there to 2000 Hz was expected based on limited bandwidth of the phase tracker. I don't have the plot to attach, someone should redo this quick measurement to save the data.
Interestingly, the same measurement when done with  C1:LSC-DARM_IN1 in FPMI configuration did not show a flat response. This is can mean that the DARM strain relationship with the beatnote frequency deviation is not a simple constant factor and/or depends on DARM or CARM OLTFs. I leave my remarks on this project here for the baton to be picked up by others in future. I unfortunately only have this much time to contribute to FPMI calibration.

I wanted to mention here that I have a printed circuit board design (LIGO-D1800304) for using AD590 as temperature sensors. I believe printed boards and all required components are stored on the wire shelf in the WB EE shop on a box labeled with this DCC number. This circuit is also meant to be read by Acromag, maybe it can come of some use to you. You can check out the use in CTN lab in WB near the south-east end of the table.

 REFL33 and REFL165 cables were connected from the AP table to the rack.  Cables on the rack for REFL33I, 33Q, 165I, 165Q ports were connected, too. Connections were confirmed by the data viewer. Two SMA cables which will be used for the two PDs on the AP tabl were built. We will be able to place the two PDs tomorrow. The beamsplitters to split the laser to REFL33 and REFL165 ports were mounted and ready to be placed.

Kiwamu, Keiko, Anamaria

Looking at the I and Q signals coming from REFL11 and REFL55 we saw large offsets, which would mean we have amplitude modulation, especially at 11MHz. We checked the PD themselves with RF spectrum analyzer, and at their frequencies we see stationary peaks (even if we look only at direct reflection from PRM). We changed the attenuation of the PSL EOM, and saw the peak go down. So first check is beam out of PSL EOM, to make sure the input beam is aligned to the crystal axis and is not giving AM modulation in adition to PM.