I came in today and it seems like the main laser tripped again yesterday around 3:00 pm.
There was a series of earthquakes in Turkey today, but all our suspension seem to be okay.
For the loop calculation, don't you have to consider the IMC cavity pole? What about the analog filter on the output of the HV driver for the laser PZT?
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.
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.
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.
Additions Sun Feb 5 18:06:54 2023:
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
We devised a plan to systematically hunt for the line noise source assuming it has something to do with BH44 and/or our recent changes in the LSC rack. Our noise estimate is the IMC_error point (TP1A) at the MC servo board. Our traces from Attachment #1 represent, in the following order:
PSL shutter open, IMC locked, C1:IOO-MC_SW1 = 1
PSL shutter closed, IMC unlocked, C1:IOO-MC_SW1 = 1
PSL shutter closed, IMC unlocked, C1:IOO-MC_SW1 = 0
PSL shutter open, IMC locked, C1:IOO-MC_SW1 = 1, rewired the delay box on LSC rack.
Same as above, plus we connected a loose "ground" wire to the delay box supply.
Same as above, plus we removed the PD interface unit connection.
Same as above plus we disconnected the 44 MHz local oscillators and terminated their outputs at the RF distribution box.
Same as above plus we disconnected the RFPD (BH44) from the IQ demod board at the LSC rack.
Where all the measurements used +4 dB input gain, 40:4000 filter enabled, and Boost = 0 settings on the MC servo board. In between measurements 3 and 4 we had to replace the SR560 (buffer) because the starting one ran out of battery... We found a good one in the YEND, used to buffer the OLTF excitation for the YAUX loop TF measurements.
We estimated the frequency noise of IMC output beam at 60 Hz using different methods to see if they are consistent.
They are not inconsistent, but seems hard to explain by an easy single dominating noise source (multiple noise sources at similar noise level?).
IMC suspension damping:
- We checked that 60 Hz comb filters are all on for all OSEM sensors of MC1, MC2, MC3 (Attachment #1), and they all have comb(60,30,-40,3), which is 60 Hz comb filter of Q=30, -40 dB, 3 harmonics.
Revisiting IMC error point calibrations:
The estimated (in loop) line noise (60 Hz) levels are 70 uV/rtHz, which using the calibration 13 kHz/Vrms (from 40m/14691) amounts to 0.9 Hz/rtHz of (supressed) frequency noise at IMC Error point.
This number (0.9 Hz/rtHz) in terms of displacement corresponds to 1.28e-15 m/rtHz. The measured DARM noise (2e-10 m/rtHz @ 60 Hz from 40m/17414) is not accounted for by this amount.
- We revisited this calibration in 40m/17431. First, 0.9 Hz/rtHz corresponds to 1.3e-13 m/rtHz, as L/nu = 40 m / 282 THz = 1.4e-13 m/Hz.
- Also, we need to add a loop correction. MC servo board settings when we took this data was as follows:
- +4 dB in IN1
- 40 Hz pole, 4000 Hz zero filter was on
- 0 boost
assuming 1/f around UGF of 200 kHz (40m/17009), and 1/f^2 between 40-4000 Hz, openloop gain at 60 Hz will be (4e3/60)**2*(200e3/4e3)=2e5. So, the estimated frequency noise at the output of IMC in terms of arm length is 1.3e-13 m/rtHz * (1+G) = 2.6e-8 m/rtHz (or 1.8e-8 m RMS considering 0.5 Hz bandwith).
- Noise measured with the same condition but PSL shutter closed was 7 uV/rtHz at 60 Hz (40m/17431). This correspond to 1.3e-14 m/rtHz (or 9.2e-15 m RMS), which is an estimated dark noise.
Measuring frequency noise using arms:
- We then proceeded to measure frequency noise using arms locked with POX11 and POY11. Attachment #2 and #3 is calibrated XARM and YARM noise using the error signals and feedback signals. For both, it is 1e-10 m/rtHz at 60 Hz (or 4.3e-11 m RMS considering 0.187493 Hz bandwidth). And this is more than x10 higher than what we have measured in August 2022 (dotted lines).
- MC_F calibrated using 1.4e-13 m/Hz reads 7.1e-9 m/rtHz at 60 Hz (or 3.1e-9 m RMS considering 0.187493 Hz bandwidth).
- Noise measured at DARM in FPMI locked with RF (but CARM with POX11+POY11, as 60 Hz was too much to switch to REFL55_I) was 3e-10 m/rtHz at 60 Hz (or 1.8e-10 m RMS considering 0.374994 Hz bandwidth) (Attachment #5), which is roughly the same as past measurements (40m/17414).
- To check if MC_F is calibrated correctly, we injected a line at 57 Hz with 3000 counts in amplitude into MC2. Using MC2 actuation efficiency -14.17e-9 /f^2 m/counts in arm length (40m/16978), this should give
14.17e-9/(60**2)*3000 = 1.2e-8 m -> 0.93e-8 m RMS
in XARM length noise. RMS value of YARM calibrated spectra reads 1.1e-8 m (Attachment #4), which is consistent within ~20%, so MC_F calibration is OK. Note that MC_F at 60 Hz are at the same level in August 2022 (green curves).
Summary of frequency noise measurements at 60 Hz:
- 1.8e-8 m RMS as measured at IMC error point TP1A
This gives you total of IMC length noise, error point noise, PSL free run noise, feedback noise.
Estimated dark noise at error point TP1A is 9.2e-15 m RMS, and is small.
Calibration might be wrong, as this rely on IMC loop gain estimate and error signal calibration of 13kHz/V a while ago in 2018 (from 40m/14691, which is from 40m/13696), which might not be true for TP1A at 60 Hz (note that there is a 40 Hz/4000 Hz filter).
- 3.1e-9 m RMS as measured at MC_F
This gives you total of IMC length noise, error point noise, PSL free run noise, but the noise injected at feedback point before MC_F is suppressed by ~2e5.
As estimated dark noise is much less, it is IMC length noise, PSL free run noise or noise injected after MC_F.
Note that typical NPRO free run noise at 60 Hz is 1e4/60 Hz/rtHz * 1.4e-13 m/Hz = 2.3e-11 m/rtHz, and is small, but we might be having large NPRO noise.
- 4.3e-11 m RMS as measured using XARM and YARM
This gives you total of IMC length noise, error point noise, but PSL free run noise and feedback noise are suppresed by ~2e5.
But this also includes noise injected in XARM and YARM loops.
If this is mainly from PSL free run noise or feedback noise, we expect 3.1e-9 m RMS/2e5 = 1.6e-14 m RMS, so it doesn't explain 4.3e-11 m RMS.
If this is mainly from IMC length noise, this should be equal to frequency noise measured at MC_F, but MC_F is higher by nearly two orders of magnitude.
Noise in POX11 or POY11 are smaller by a factor of more than 100 when dark (see 40m/17431), so contribution from dark noise of POX11 and POY11 at 60 Hz to XARM/YARM noise is negligible.
These mean that the noise might be from combination of IMC and PSL. (For example, if noise injected at error point is 9.2e-15 m RMS, IMC length noise is 4.3e-11 m RMS, PSL free run noise is 3.1e-9 m RMS, and noise injected at feedback point is 1.8e-8 m RMS, it explains all the measurements so far.)
- 1.8e-10 m RMS as measured using FPMI DARM
Frequency noise in DARM should be suppressed by common mode rejection, but it is actually x3 higher than what we see in XARM and YARM.
There might be extra noise from FPMI loops (note that CARM is controlled by POX11+POY11 in this measurement).
- Check IMC error point calibration (is 13 kHz/V correct?) by driving MC2 at around 60 Hz (but not at 60 Hz) by known amount
- Measure frequency noise at IN1 of MC servo board to avoid 40 Hz/4000 Hz filter
- Check what exactly are we measuring at MC_F. Are there possibility of additional noise for MC_F, which is not fed back to laser frequency?
- Drive MC2 at around 60 Hz (but not at 60 Hz) to see if MC_F and X/YARM spectra matches
- Estimate IMC length noise from MC OSEMs
- Touch electronics around 1X2 to see if 60 Hz at IMC error point changes (monitor the live spectrum!)
[Steve, Koji, JC]
Steve Vass came by today and was loaded with information. Here are a couple things we went over:
- Removal of the large optical table.
- Disconnecting the roughing pumps to prevent oil contamination.
- Plexiglass End Enclosures
- TP1 maintenance Information
Removal of the large optical table.
Steve mention to us that there will be 2 machines that have to raise and rotate the optical. The optical table is 2 ft wide when rotated and this seems to easily give us clearance to get this guy out if we set it on piano dollies. The only issue we encountered is that we may have to disconnect the small power supply rack by 1X2 to make room for one of the machines that will rotate the table. If we manage to lift the table, slide it over to a more open area, lift again, and remove the dollies, then this may give us enough space for this machine and we won’t have to disconnect the power supply rack by 1x2. Overall, turning the table over on its side and maneuvering it into the aisle to go down the aisle along Xarm is the trickiest part. From there, we just have to find out where we are going to take this monster of an optical table.
Disconnecting the roughing pumps to prevent oil contamination
Disconnecting the roughing pumps to prevent oil contamination.
Steve let us know that he would disconnect to oil vacuum pumps after getting to your nominal vacuum pressure. This prevents these pump from possibly feeding oil into the system. Each of these pumps have an intentional leak vale that keeps the pressure above 300 mtorr. If the pressure get any lower, the pumps will begin to back pressure oil into the system.
I asked Steve about some information on the end enclosures and PSL Enclosure. For the end enclosures, these were custom made. The film on the enclosure was added by people who do car window tinting. This film is not as strong as the plexiglass for the PSL Table. I have to look through Steve’s physical documents to find a receipt, or information of where he purchase the custom enclosure. As for the PSL enclosure, the film is actually imbedded/ combined with the plexiglass. This can withstand much more power than the end enclosures.
Steve has sent TP1 and the controller for maintenance before. It seems like we need to do this roughly ever 4-6 years and the last time TP1 was shipped out for maintenance was in 2018. During this, Steve said he thinks he was shipped a temporary pump to use in the mean time while TP1 was being repaired. When there is an error with the pump, it will pop up on the controller as show in [elog 14189](https://nodus.ligo.caltech.edu:8081/40m/14189)Anyways, it seems like TP1 will have some issues coming up.
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.
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.
[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:
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.
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.
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.
Today while aligning optics at the xend, my knee engaged the AUX laser interlock. I spent some time trying to disable the interlock, and I'm putting the solution here for mainly my reference: pull on the red interlock button. This shorts the two pins on the back of the Mephisto controller.
During my time shadowing Anchal, we discussed the need for digital control systems on the suspension systems for the 40 meter optics. The controls and diagnostics system (CDS) allows us to develop our own feedback controls and filters for the suspension systems by taking in analog signals from the shadow sensors. The feedback control system developed in the CDS then utilizes the OSEM actuators to dampen harmonic motion and noise on the suspension lines. While improving these feedback loops is an ongoing challenge, it is a problem that is likely non-linear, meaning the system must be understood on a much higher level to make further improvements. This brings us to the new addition of a wavefront sensor in the 40m lab, which will allow for constant monitoring of the active wavefront in the interferometer. The wavefront will soon be used for gathering training data for a neural net that will help further analyze the non-linear effects within the suspension and damping system. What Anchal was working on today was an update within a CDS model for clioo to allow for the integration of the wavefront sensor such that he may use a switch to change between connections in the mode cleaner and the arm cavity. The CDS models may be edited and updated using Matlab/Simulink to arrange blocks and code in a robust and visual manner. The final system designed in Simulink can then be saved and compiled using the real-time code generator (RCG), which cross-compiles the Simulink file into C code that can be read by the CDS system to assign inputs, outputs, and various logic or algorithms for filtering.
Chub mentioned to Paco and I that the Nitrogen seemed to be losing pressure quicker than usual. After looking over the previous 4 months on Dataviewer, the pressure has a pretty consistent slope. I have ran into the issue of the neck of the N2 tank slighty leaking, so this may have been the issue. For now, there does not seem to be any significant or obvious problem.
I reconnected the green REFL monitor channel and acquired its spectra when the laser was (mostly) locked. During the collection window, TEM00 would catch lock for a few seconds, drop, and catch again. As of today this is the longest the lock will hold. I'm uploading a screenshot for now but will replace with a proper .pdf spectra image.
There is a peak ~558 Hz and at its second harmonic. Additionally there is a less sharp peak at 760 Hz.
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:
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.
Attachments 1 and 2 are two separate lock durations, with x-axes spanning 1 second each. The trace of interest (error signal out of mixer) is Channel 1. Channel 2 contains the control signal outputted by the PDH servo box.
The error signal is contained in a slow-moving envelope at ~4.5 Hz, zoomed in with time cursors in Attachments 3 and 4.
Zooming in further, the error signal has a fast component at ~150 Hz (Attachments 5, 6).
Before taking these traces, I captured the green REFL signal and open-loop PDH error signal shapes (Attachment 7). This error signal linear range spans ~500 mVpp. From looking at this signal it seems like the closed loop contains excess noise.
From considering the above traces and loop calculations I can start to infer the closed loop shape and/or UGF, and what direction we need to move in to recover good locking.
Today I setup Moku:Pro MP1 with phasemeter app to replace DFD + Phase tracker.
Moku Input output settings:
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
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.
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 took transfer function measurement of DFD AM coupling using noise excitation.
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:
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.
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.
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.
I tried restarting all models this afternoon to see if the DC error 0x2000 on c1cal model cleared (currently no frame data is being written from c1cal). By running ./restartAllModels.sh on the scripts/cds/ folder, and then BURT restoring, but unfortunately this didn't work. I also tried restarting DAQD without success. Finally, I guess since the error has been related to channel inconsistencies in the model's .INI file (what where when?) I tried rtcds build c1cal and rtcds install c1cal and then another full restart. No success.
PMC hit a drop around mid-day on Saturday and has been going down since. As of now,
C1:PSL-PMC_PMCTRANSPD - 0.664
I will go in and adjust now.
One of these V beam dumps was installed for BH44 RF PD.
The rest is now stored in the box in the shelf along Yarm, together with RF PD mounts.
So far different measurements are consistent with the hypothesis that the 60 Hz noise is from PSL frequency noise (40m/17423).
We have done several measurements in REFL55 and POX/POY to show this hypothesis, and all are consistent with the frequency noise hypothesis.
However, 60 Hz noise in the IMC error point seems too small to explain the 60 Hz noise in DARM.
[Koji, Paco, Yuta]
REFL55 attenuation experiment:
- To check if the 60 Hz is in the light or not, we have compared the spectrum of REFL55_I_IN1 with different ND fiters in front of REFL55 RF PD.
- Attachment #1 shows the result. Spectrum was taken when both arms are locked indivitually using POX and POY, feeding back to ETMs, MICH freely swinging. Red curve is nominal, blue is with OD0.5, and green is with OD1.
- Attenuation in 60 Hz noise and side lobes are consistent with OD filter attenuation, which suggets that the noise is from the light.
- Note that having side lobes is natural, as MICH is fringing (sorry for confusing plot). However, if the side lobes come from the RF saturation, we expect side lobes to decrease more than OD filter attenuation, but this was not the case.
Phase measurements between POX and POY:
- When both arms are locked indivitually using POX and POY, feeding back to ETMs, transfer function from POX to POY had gain of ~1 and the phase of -10 deg (Attachment #2).
- With PSL shutter is closed, transfer function from POX to POY had gain of ~0.1 and the phase of -100 deg, with lower coherence (Attachment #3).
- These also support that 60 Hz noise in POX and POY when the arms are locked are from common origin, such as frequency noise.
[Michael, Paco, Yuta]
IMC error point measurement:
- Attachment #4 shows the IMC Servo Board configuration we used for the all three measurements below.
For this measurement we took TP1A (from MC Servo board) and buffered it with a battery powered SR560 (DC coupled, low noise, gain x1) before connecting it to the single ended A1 channel on a SR785. The noise level was set to -42 dBVpk, and three different noise spectra were acquired:
This number (0.9 Hz/rtHz) in terms of displacement corresponds to 1.28e-15 m/rtHz. The measured DARM noise (2e-10 m/rtHz @ 60 Hz from 40m/17414) is not accounted for by this amount.
- Check the IMC error signal calibration
- Measure the calibrated out-of-loop frequency noise using various signals (POX, POY, REFL55, AS55 with single arm, ALSBEAT, PMC_CTRL)
Timeline (as far as written in the elog):
- Dec 20: FPMI BHD locked using BH55 (40m/17367).
- Dec 21: FPMI RF locked, but not BHD, DARM noise 1e-11 m/rtHz @ 60 Hz (40m/17369).
- Jan 10-11: AS WFS boards testing at 1X2 (40m/17391, 40m/17393).
- Jan 11: FPMI BHD locked using BH55, DARM noise 2e-11 m/rtHz @ 60 Hz (40m/17392).
- Jan 13 2pm: FPMI BHD locked using BH55, DARM noise 2e-11 m/rtHz @ 60 Hz (40m/17399).
- After measuring the sensing matrix etc., LO_PHASE locking became unstable and FPMI BHD could not be recovered (I thought something similar to Dec 21 is happening).
- Jan 13 6pm: FPMI BHD locked using BH55 recovered. DARM noise 2e-11 m/rtHz @ 60 Hz. Discovered that the 60 Hz noise is higher when LO_PHASE locking is unstable (40m/17400).
- Jan 17: BH44 hardware/software installed. Found IQ demod board needs tuning (40m/17401).
- Jan 18: Tuned IQ demod board for BH44 installed (40m/17402).
- Jan 19: BH44 RF PD placed and connected to IQ demod board. FPMI RF locked, LO_PHASE locked with BH44, but found 60 Hz noise everywhere (40m/17405).
- Jan 24: FPMI RF locked (with CARM locked with POX11+POY11 instead of REFL55_I). DARM noise 2e-10 m/rtHz @ 60 Hz (40m/17414).
- Jan 24: AS WFS boards mounted in 1X2 (40m/17416).
- Jan 25: Isolating BH44 setup didn't help (40m/17423).
- Jan 26: Fixed tripping of -5V supply in 1X1 (40m/17425).
- Jan 27: IMC error point measurements at 1X2 (this elog).
this is very exciting! Its the beginning of the task of reducing vast amounts of PEM data into human-useful (bite sized) info. Imagine if we had 60 Hz BLRMS on various channels - we would know exactly when ground loops were happening or disappearing.
EP30-2 Epoxy bonding of V beam dumps for LSC PDs.
- Supplied 1"x0.5" glass pieces from the stock in the OMC lab.
- The black glass pieces were cleaned by IPA / Aceton / Aceton+Cotton Qtip scrub / First Contact
- 3 beam dumps are built. They require ~24 hrs to get cured.
=> Handed to Yuta on Jan 27, 2023
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.
PMC aligned (Attachment #1).
Over the past month, PMC transmission is actually slowly growing from 0.68 to 0.70 (Attachment #2), since it suddenly dropped from 0.72 on Dec 27 (40m/17390).
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.
Connect any video signal supported by the adapter. Use Windows / Mac or any other OS. If it keeps complaining, contact Magwell support.
[Paco, Anchal, Yuta]
Isolating BH44 setup from the rest didn't help reducing the 60 Hz noise.
Frequency noise from IMC also seems unchanged before and after BH44 installation.
- To see if BH44 setup installed is causing the 60 Hz issue, we compared the spectra of FPMI sensors with BH44 setup and with BH44 setup disconnected.
- In the latter configuration, BH44 setup was isolated from the rest by disconnecting the SMA cables and the RFPD power cable, as shown in Attachment #1.
- There was no significant difference in the spectra with BH44 and with BH44 isolated.
We have even put the old AS156 IQ demodulator board we have pulled out to insert BH44 IQ demodulator board back, but didn't change.
- We have also disconnected the 22 MHz generation setup around 40m Frequency Generation Unit at 1X2 for switchable IMC/AS WFS, but it also didn't help.
- Attachment #2 is the orignal spectra with both arms locked with POX and POY, feeding back to respective ETMs (MICH is not locked), and Attachment #3 is those with BH44 setup isolated, AS156 IQ demod back, and 1X2 22MHz generation isolated. Both look basically the same.
- BH44 setup was reverted after the comparison.
IMC frequency noise:
- As adding a resonant gain at 60 Hz helped reducing the 60 Hz noise (40m/17419), the noise might be from frequency noise. It also explains why it is not present in MICH when ETMs are mis-aligned, and only present when one of the arms is involved (40m/17413).
- To see if the frequeny noise at 60 Hz increased after BH44 installation, I compared the spectrum of C1:IOO-MC_F_DQ on January 11 (same Wednesday) with that measured today at almost the same time.
- Attachment #4 is the result. 60 Hz noise and its harmonics seems almost the same in MC_F. It is rather noisy today in other frequencies, but not at 60 Hz.
- Read the book.
Thus far, the software needed for the Magewell video encoder has been successfully installed on Donatella. OBS studio has also been installed and works correctly. OBS will be the video recording software that can be interfaced via command line once the SDI video encoder starts working. (https://github.com/muesli/obs-cli)
So far, the camera can not be connected to the Magewell encoder. The encoder continues to have a pulsing error light that indicates "no signal" or "signal not locked". I have begun testing on a secondary camera, directly connected to the Magewell encoder with similar errors. This may be able to be resolved once more information about the camera and its specifications/resolution is uncovered. At this time I have not found any details on the LCL-902K by Watec that was given to me by Koji. I will begin looking into the model used in the 40 meter next.
Kapton tape is a good insulator, so its a good block for 60 Hz. But it is mostly useless for RF since the capacitance between the mount and the table is
C = epsilon * A / d
For Kapton the dielectric constant is 3.5, the PD mount area is 10 cm x 10 cm, and the film thickness is ~50 um. So C ~ 5 nF.
Z ~ 1 / (2 * pi * 44 MHz) / C
~ 0.5 Ohms
I returned the half-wave plates on the XEND table back to their original angles, and restored the loop configuration with the PDH servo box. I returned the PD gain to 40 dB (original setting), and set the servo gain knob to 6. This was the region of highest loop stability, with the lock holding for a few seconds (as before). The control signal on the scope did not look intuitive - the peaks of the control signal corresponded with zero crossings of the error signal.
Paco encouraged me to retake transfer function measurements of the PDH servo box. The main takeaway is the PDH servo (boost on) has the expected frequency response at a gain setting of 3 or under, up to 100 mVpp of input. Attachment 1 shows the frequency response at a servo gain of 2, for varying input amplitudes.
The rest of the bode plots correspond to servo gain of 4, 6, 8, and 10 (boost on). The saturation LED would turn on above a gain value of ~3.25, so these results can't be analyzed or interpreted. But it does seem like a steep, low-frequency jump is a signature of the saturated servo. This jump doesn't appear with 10 mVpp input, at least at or above 1 Hz.
Following was done to investigate 60 Hz noise issue, but no significant change in the FPMI noise observed.
- Even before BH44 installation, we have been experiencing flaky REFL55 RF output. When some work was done at AP table or something, sometimes the amplitude of REFL55_I and REFL55_Q goes very low, and/or offset changes. This was usually fixed by touching the RF output of REFL55.
- So, we took out REFL55 and opened the back lid to inspect. RF output seemed rigid and the SMA connector was properly grounded to the box; didn't find any issue (Attachment #1).
- REFL55 was put back to its original position, and the cables were also put back.
BH44 Kapton tape:
- I realized that other RFPDs have Kapton tape in between the RFPD golden box and the black mount, but not for BH44 we recently installed.
- I have checked that the golden box of BH44 and the optical table is not grounded when RF output and the DB15 cable was disconnected, but is gounded when they are connected, just like BH55.
- Anyway I removed BH44 and put a Kapton tape (Attachment #2), just in case, and BH44 was put back to its original position, and the cables were also put back.
FPMI noise spectra after the work:
- Attachment #3,4,5 are noise spectra of FPMI BHD sensors when FPMI is RF locked with AS55_Q, REFL55_I, and REFL55_Q, and LO_PHASE is locked with BH55 with the following configurations.
- Attachment #3: whitening/unwhitening filters for AS55, REFL55, POX11, POY11, BH55, BH44 turned on (nominal configuration after lock acquisition)
- Attachment #4: whitening/unwhitening filters for AS55, REFL55, POX11, POY11, BH55, BH44 turned off. No significant change except for expected whitening filter transfer function.
- Attachment #5: whitening/unwhitening filters for AS55, REFL55, POX11, POY11, BH55, BH44 turned on, 30 dB resonant gain at 60 Hz, Q=10 in CARM loop. Significant 60 Hz reduction everywhere. This was not observed when resonant gain at 60 Hz was put in DARM loop (only 60 Hz at AS55_Q was reduced). 60 Hz noise mainly coming from something in CARM loop?
Don't forget to:
- Put a beam dump for BH44
We came this morning and noticed the FSS_FAST channel was moving very rapidly. Short inspection showed that MC3 watchdog got tripped. After reenabling the watchdog the issue was fixed and the MC is stable again.
There is a spike in the seismometers 8 hours ago and it was probably due to the 4.2 magnitude earthquake that happened in Malibu beach around that time.
1) Turning the whitening filter before the ADC on/off didn't changed the relative height of 60 Hz peak compared with the noise floor. When the whitening filter was turned on, increase of the dark noise measured at C1:LSC-****_(I|Q)_IN1 was roughly consistent by eye with the whitening filter transfer function (gain of 1 at DC, ~15 Hz zero x2, ~150 Hz pole x2), which suggests the 60 Hz pickup is before the whitening filter.
2) Attached is the electronics diagram around BH44 and BH55.
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.
1) do a comparison with the whtiening before the ADC on/off. This will tell us if it is pickup before the whtiening filter or not.
2) If there are ground loops made by 44 MHz setup, we want to draw a simple diagram which includes which sides are grounded and which have transformers. How about make a drawing to bring to the group meeting tomorrow? IN the lab we have these coaxial BALUNs for making a 1:1 transformer coupling.
3) Another source of 60 Hz is the unintentional demodulation of spikes made by the Sorensen switching supplies: they produce spikes all the way up to 100 MHz, so if they land near 44 MHz, you may get some 60 Hz on the demodulation. You should be able to see this with a dipole antenna or a hoop antenna.
Just to show how bad 60 Hz noise is, I compared FPMI displacement noise with pre-BH44 era (measured on Jan 13, 40m/17400).
Blue curve in Attachment #1 is the sensitivity with FPMI locked with RF in pre-BH44 era, and pink curves are that measured today (C1:CAL channels are currently unavailable due to 0x2000 appeared after running restatAllModels.sh).
60 Hz + harmonics pedestals are apparent today, but was not there on Jan 13. Today, DARM could be handed over to AS55_Q from POX11-POY11, but CARM could not be handed over to REFL55_I from POX11+POY11 (this was possible last night).
Attachment #2 shows FPMI error signals when electronic FPMI is locked. Too much 60 Hz, especially in REFL55_I_ERR and AS55_I_ERR (note that REFL55_Q is used for MICH lock, but AS55_Q is not in-loop yet when this screenshot was taken.)
- Fix c1cal 0x2000 issue
- Fix REFL55 loose RF output
- Disconnect cables in BH44 to open possible ground loops made during BH44 installation (especially 44 MHz generation part??).
[Paco, Yehonathan, Yuta]
Since we have installed BH44, we are seeing side lobes of 60 Hz + harmonics in AS55, REFL55, BH55, BH44, preventing us from locking FPMI BHD (40m/17405).
BH55 RF amp removed:
- We have noticed that the side lobes are there in BH55 (but not in BH44) when LO-ITMX single bounce is fringing (ETMs and ITMY mis-aligned).
- Changing whitening gains and turning on/off whitening/unwhitening filters didn't help.
- When LO-ITMX single bounce is locked with BH55, the side lobe in BH55 reduces.
- Dithering LO1 at 11 Hz created 180 +/- 11 Hz signal, which confirms that this side lobes are from the up conversion of optic motion.
- We thought it could be from RF saturation, so we have put a 55-67 MHz bandbass filter (SBP-60+) in between BH55 RFPD and RF amp (ZFL-1000LN+; 40m/17195). Didn't help.
- We then removed the RF amp. This largely reduced the side lobes (but still some at 180 Hz). We could lock LO-ITMX single bounce without the RF amp, so we decided to remove it for now.
Side lobes only when one of the arms is locked:
- When ETMs are mis-aligned, MICH fringing and BHD fringing, there are 60 Hz + harmonics, but the side lobes are not there.
- But with Xarm is locked (ETMY, ITMY mis-aligned) or Yarm is locked (ETMX, ITMX mis-aligned), the side lobes appear in AS55, REFL55, BH55, BH44.
- Changing whitening gains and turning on/off whitening/unwhitening filters didn't help.
- As the error signals are normalized by TRX and TRY, we turned on/off the power normalization, but didn't help.
- Switching 60 Hz comb in BS, ITMX, ITMY, ETMX, ETMY suspension damping didn't help.
- When ETMs are mis-alined, POX11 had relatively large 60 Hz + harmonics, but almost none in POY11 (unlike other RFPDs; see Attchment #1).
- However, when ETMY is aligned and Yarm is loked with POY11, the side lobe grows in POY11.
- Changing the feedback point from ETMY to ITMY or MC2 didn't help.
- We have unplugged the IQ demod board for BH44 from the eurorack (without removing the cables) and removed the fuse for the power supply of the RF amp for 44 MHz generation (40m/17401), but these also didn't help.
- We have also tried locking Yarm with REFL55(= ~2 x POY11), BH55(= ~10 x POY11), ALSY(= ~2000 x POY11), but the side lobes were always there.
- Disconnect cables in BH44 to open possible ground loops made during BH44 installation (especially 44 MHz generation part??).
- Check if the noise was there before BH44 installation using past data.
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.
Both the TF measurement and the noise measurements are useful, but the nosie measurement is much more meaningful. Since we expect the main coupling to be incoherent, what we really want is a noise budget style measurement:
Here's the beam path of BH44.
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.
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.
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.
[JC, Paco, Anchal, Yuta]
- We installed the new BH44 beam path and RFPD.
- JC installed the new beam path for the LO/AS camera.
- We succeeded in locking LO Phase with BH44_Q_ERR, but didn't attempt FPMI BH44 because we noted large 60 Hz harmonics in most of our RF error signals.
BH44 RPFD/Camera installation:
- We picked off LO/AS beam path previously going to the camera, and installed a Y1 (45 deg, s-pol) mirror, a f=150mm lens and the RFPD (Attachment #1). We initially tested it using the incandescent light from a flashlight and then aligned the beam, we also made sure it's not saturating.
- Using the spurious transmission from the mirror mentioned above, we steered a new beam path for the camera and realigned it using another short focal length lens (f ~ 100 mm).
LO Phase control:
- We increased the whitening gain from 0 dB to 42 dB for both C1:LSC-BH44_I and C1:LSC-BH44_Q, and zeroed the offsets. Even before this step we could see a fringe from BH44, which is quite promising!
- After alignment was recovered on the LO/AS path, we succeeded in locking the single bounce (ITMX) LO phase using BH44_Q. Here the configuration was FM4, FM5 and a gain of ~ 5 * 0.5 = 2.5 (to match the typical BH55_Q error point).
- While BH44_Q was used to control the LO phase, we saw the BH55_Q was not zero but actually almost at max fringe value (see Attachment #2). This implies the BH44_Q is indeed orthogonal to BH55_Q with respect to the LO Phase!
- We locked electronic FPMI but noted a large 60 Hz + harmonics component in the RF error signals including AS55, BH55, REFL55, and BH44 (see Attachment #3). We could hand off to FPMI and even locked the LO phase with BH44_Q, but we were not sure the BHD_DIFF error signal was fit for handoff to FPMI BHD. Therefore we stopped here.
60 Hz + harmonics:
- We did a quick investigation around the areas we have been working in the lab to see if we had introduced this noise in any obvious way. First we checked the new amplifier for the 44 MHz LO, we briefly removed its power but the 60 Hz noise remained. Then we checked the AP table, but nothing had really changed there. We also disconnected and removed the rolling cart with the marconi and other instruments from the LSC rack. Finally, we turned all the lights down. None of these quick fixes changed the amount of noise.
- We also tried looking at these error signals under different IFO alignment and feedback configurations. We always see the noise in the AS55 and REFL55 quadratures, but not in BH44, BH55 or BHD_DIFF unless MICH is locked.
- Investigate more into 60 Hz noise, why? where?
- Measure sensing matrix with LO Phase locked with BH44 and BH55 to make comparison.
the problems with these circle plots:
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.
I tested a spare IQ demod board labeled 33.3 MHz (closer to 44 MHz than the 165 MHz we had started using) and using the Moku adjusted the trim caps after the transformer T1 to adjust orthogonality (using an oscilloscope). The orthogonality seems quite good on this board and it seems to be working fine, so I decided to swap out the BH44 (previously AS165) IQ demod board for this one. To do this I first unpowered the amplifier, then disconnected the load (IQ demod board) then release from the Eurocrate, then add the new board.
Finally, using Marconi at 11.066195 * 4 to get close to the 44 MHz LO frequency, I measured a 63.9 Hz tone at the C1:LSC-BH44_I_IN1 and C1:LSC-BH44_Q_IN1 channels (whitening gain 0 dB). The measured angle between these two channels was 86.97 deg, so the orthogonality is much better now. The gain imbalance is also relatively better, Q/I ~ 0.57
[Anchal, Paco, JC, Yuta]
We have started hardware installations for BH44 RF PD. 44 MHz LO generation and signal chain from IQ demodulator was checked successfully, but found that IQ demodulator is not orthogonal.
RF PD Interface:
- We have unplugged Ch2 of the RFPD Interface (labeled "Special") to re-use it for BH44. Ch2 was used for "UNIDENTIFIED" RFPD. DB15 cable was routed to ITMY table and connected to BH44 RF PD (40m/17398) now sitting on the cover of ITMY table. See Attachment #1.
- Finding a DB15 RF PD interface cable was easy because of the organization work!
44 MHz LO generation:
- LO for BH44 was generate following the scheme proposed in 40m/17319.
- 11 MHz LO from RF distributor labeled "+16 dBm" (measured to be 16.5 dBm) and 55 MHz LO labeled "SPARE 55" (measured to be 2.26 dBm) was mixed with a mixer ZFM-1H-S+ (using 11 MHz as LO, and 55 MHz highpass filtered with SHP-50+ as RF). The mixer output was lowpass filtered with SLP-50+, and amplified with ZFL-500LN+, which gave 8.07 dBm at 44 MHz. The second heighest peak was -11.53 dBm at 22 MHz, which seems low enough. See Attachment #2 for the photo of the setup.
- We have used unused IQ demodulator labeled "AS165" to use it for BH44. See Attachment #3.
- We have quickly checked if the IQ demodulator is working or not with LO from BH55, PD input of 55 MHz generated using Moku to see I and Q outputs. The outputs are sine waves at frequency consistent with the difference between LO frequency and "PD input" frequency, and the phase was off as expected. Q output was ~4 dBm higher than I output.
Measured diff of BH44:
- After CDS modifications where done, BH44 IQ demodulator was tested by using 44 MHz LO generated in a method mentioned above, and injecting 11.066195 * 4 MHz signal from Moku as PD input. This gave ~75 Hz signal in C1:LSC-BH44_I and C1:LSC-BH44_Q.
- With 0dB whitening gain and whitening/unwhitening filters off, gain imbalance was measured to be Q/I=137.04/62.49=2.19, and measured phase difference to be PHASE_D=27.21 deg (see Attachment #4; gpstime=1358051213).
- With 0dB whitening gain and whitening/unwhitening filters on, gain imbalance was measured to be Q/I=138.44/63.21=2.19, and measured phase difference to be PHASE_D=26.95 deg (see Attachment #5; gpstime=1358051325138). This is consistent with whitening/unwhitening off, and noise is smaller, which mean whitening/unwhitening filters are probably working fine.
- IQ demodulator board might be not working properly, as I and Q signals are not quite orthogonal.
- Use different IQ demodulator board that has better IQ orthogonality.
- Connect BH44 RF PD and use 44 MHz test input to check the signal chain.
- Install BH44 RF PD optical path.
- Try locking LO_PHASE with BH44.