MICH was locked with BHD DCPD A-B signal with LO phase controlled.
Locking procedure and configuration was as follows (see Attachment #1).
1. Lock MICH with AS55_Q, with C1:LSC-MICH_GAIN=-3, FM4, FM5, FM8, FM10 (boost filters are turned off to have more phase margin).
2. Lock LO PHASE with BH55_Q, with C1:HPC-LO_PHASE_GAIN=6, FM5, FM8, feeding back to AS1.
- C1:LSC-BH55_PHASE_R=136.136 deg was tuned to minimize I when AS-LO is fringing with MICH locked with an offset of 50 (we first thought 136.136 deg - 90 deg is better from 40m/17216, but today, 136.136 deg seems to work better; Reason needs to be investigated).
- We are supposed to use C1:HPC-BH55_Q_AS1_DEMOD_I_OUT to control the LO phase to give maximum MICH signal on BHD_DIFF (40m/17170), but somehow BH55_Q without audio dither was OK to get MICH signal. Line injection at 211.1 Hz on BS was seen in BHDC_DIFF (and AS55_Q), even if we use BH55_Q to lock LO PHASE (see Attachment #2; MICH_B is BHDC_DIFF and MICH_A is AS55_Q) or BH55_Q_AS1_DEMOD_I to lock LO PHASE (with both signs). Reason needs to be investigated.
- Audio dither was done using AS1 with excitation of 15000 counts at 281.79 Hz. C1:HPC-BH55_Q_AS1_DEMOD_PHASE=60 deg was tuned to minimize Q with injection of line at 13 Hz using LO1.
3. Handed over MICH lock from AS55_Q to 0.66 * C1:LSC-DCPD_A - 1 * C1:LSC-DCPD_B. This was done by using C1:LSC-MICH_A and MICH_B gains. C1:LSC-MICH_A_GAIN=1 was handed over to C1:LSC-MICH_B_GAIN=-1.
- 0.66 * A - B was tuned so that BHDC_DIFF will be zero (as it supposed to be with MICH offset of zero).
- AS55_Q and BHDC_DIFF had roughly the same optical gain at 211.1 Hz (actually, BHDC_DIFF had higher optical gain; see Attachment #2), so we used MICH_A_GAIN=1 and C1:LSC-MICH_B_GAIN=-1
- After handing over of BHDC_DIFF, OLTF was measured. UGF was ~70 Hz (Attachment #3).
- Investigate how to get optimal LO phase. With BH55_Q or BH55_Q + audio dithering? How to optimize demod phases?
- How do we balance DCPD A and B? What is the effect of BHD BS being 44:56 not 50:50?
- Measure amount of MICH signal in BHDC_DIFF with different LO phases.
- Improve SNR in BH55.
- It will be much simpler if we send BHDC_SUM and BHDC_DIFF to c1lsc from c1hpc, instead of sending un-unwhitened BHDC_A and B.
I swapped the 1 inch BS and lenses along the POP beam to clear the apertures and avoid clipping this beam. The results are illustrated by the attached pictures; this was done right after Yuta had optimized IFO alignment so it's hopefully a good reference from now on. Yuta also tuned the alignment of BHDC path in ITMY table, which mostly improved the alignment to DCPD A (90-ish counts improved to 100-ish counts with ITMY single bounce).
[Yehonathan, Yuta, Paco]
We would like to estimate:
I have confirmed the ability to install the sensoray drivers on Debian 11 in a virtual machine environment. I will do testing with the sensoray device on this tomorrow and if all works, begin working on code for capturing images. I will then test this out on Donatella once Tega finishes installing Debian across all computers in the coming week or so.
The ALS Cal for ITMY actuation was off by ~ 1000, so I decided I don't trust / understand what this beatnote is seeing. Then, I went in the lab to inspect things;
The factor above may be explained by the bogus signals coming into the beat fine phase channels on the ALS model. After locking the YARM with POY11, and locking the YAUX to the YARM cavity, I turned on the LSC oscillators -- all five of them see Attachment #1 for the screenshot -- and looked for the lines in the C1:ALS-BEATY_FINE_PHASE_OUT channel. Here, again the sensing output matrix was set up to actuate on ITMY, while the ETMY (control point of YARM loop) had all the output notches on. Once all lines were visible in the YAUX beatnote, I had to reduce the LSC filter gain from 0.012 to 0.011 to prevent loop oscillations... Then I recorded the gpstimes below with different conditions.
Basically, only the DARM line was recorded (DQ channs) so I modified the c1cal to store the SIG_OUT and DEMOD_I_IN1 channels for both BEATX and BEATY cal signals. This means I need to repeat this measurement. In the meantime I am also going to try and rerun calibrate the BEAT HZ transfer function.
We removed splitter to route BHD DC PD signals to c1hpc and c1lsc. This was necessary to circumvent IPC error, but this is no longer necessary. Now BHD DC PD signals are ADC-ed with c1hpc, and sent to c1lsc via IPC.
We also found that BHD DC PD signals have whitening filters as described in LIGO-T2000500 (Readout board is LIGO-D1400384).
We added unwhitening filter zpk([151.9;3388],[13.81],1,"n") to C1:HPC_BHDC_A and B, based on measured whitening stage gain (see Sec 3.1 of characterization reoprt in LIGO-T2000500).
This solved the signals leaking to minus (40m/17068).
- Modify c1hpc model to send BHD DCPD signals to c1lsc after unwhitening. (Note added on Nov 15: The same unwhitening filter is also added to C1:LSC-DCPD_A and B for now. See attached.)
- Redo visibility measurements,
We installed a steering mirror intersecting the BHD beam path and put the AS beam on the ITMY Oplev QPD (see Attachment #1 for a photo of this temporary hack) . This is done to do coil balancing of AS1/AS4, LO1/LO2. QPD sees ~ 10000 counts when the beam is centered.
We follow this procedure -- but with different sensors for all BHD suspension coil output balancing.
We dither BUTT first, lock the LO-AS fringe (DC lock), and look at the residual LO_PHASE spectrum to minimize POS coupling. We then unlock, misalign LO beam and look at the hijacked Oplev (ITMY) while dithering POS to minimize PIT and YAW couplings.
We dither BUTT first, lock thChangeset summarye LO-AS fringe (DC lock), and look at the residual LO_PHASE spectrum to minimize POS coupling. We then unlock, misalign AS beam and look at the hijacked Oplev (ITMY) PIT/YAW residual noise while dithering POS to minimize PIT/YAW coupling.
The new coil output gains are summarized in the table below:
Finally, I reverted the hacked QPD setup to restore the ITMY OPLEV.
I stopped the Docker PID script and started the old python script on megatron. Instructions on how to do this are here.
On optimus I ran:
On megatron I ran:
However, the daemon service keeps failing and restarting. So currently the FSSSlow is not running. I do not know how to debug this script.
On a side note, I tested the docker service by restarting it, and it was working. From the logs, it seems like it got stuck because it could not find C1:IOO-MC_LOCK channel which occurs when c1psl epics servers fail or get stuck. The blinker on this script runs when the script is running but it does not stop if the script gets stuck somewhere. If someone decides to use this script in the future, they would need to correct error catching so that no reply from caget looks like an error and the script restarts rather than keep trying to get the channel value. Or the blinker implementation should change in the script so that it displays a stuck state.
Whoever knows about this, please stop that Docker PID and we can just run the old python script on megatron.
The problem with trends was due to the epics data collection process (standalone_edc) that runs on c1sus. When all the FEs were rebooted earlier this week, this process was started automatically, but for some reason it hasn’t been doing its thing and sending epics data to the framebuilder. I restarted it just now, and it’s working again. Until this problem is sorted out, we need to remember to check on this process after rebooting c1sus.
I also tried to post a trend plot, but the minute trends don't yet reach the current date (!!!). They seem to have stopped recording a few days ago, so I guess the Framebuilder still needs some help or its tough to figure out things like when exactly the new SLOW servo stopped working.
I was trying to debug why the NPRO PZT is all over the place, and it turns out that the new FSS SLOW script is not actually running.
The BLINKY is blinking, but the script is not running. I wasn't able to figure out how to kill the broken Docker thing, but if the code reports that its running but actually does not, we should probably just put back the old perl or python script that ran before. I don't know how to debug this current issue, but the IMC locks will be limited in length due to this servo being broken. Whoever knows about this, please stop that Docker PID and we can just run the old python script on megatron.
After clicking on the extra MC1 unwhitening filter, I was going to retune the damping gains to give a Q ~ 5 for the suspension. I found it was very over damped. I also checked the other MC SUS. They were all overdamped.
A Q ~ 5 means that the amplitude of the oscillation should drop by 1/e after 5 oscillations. Most of the DOFs were damping in 1-2 cycles. This is good for lock acquisition impulses, but because it ties the suspension to the frame, it reduces the seismic isolation that we get from the pendulum. So we normally want the Q to be ~4-7. Someone more clever can figure out a better local damping servo that minimizes the overall MCF and IMC WFS signals, but that is a project that takes some thought.
I turned on the extra un-whitening filter (not the same as dewhitening) which Anchal has installed in the XXSEN filter banks of MC1. Seems good, so I'm leaving them on.
Anchal determined that the new satellite for MC1 was whitening, and also the old one was whitening, which made the whole thing non-white. So, I turned on the FM3 filter. I then checked that the ADCs were not saturating by looking at the spectrum of the IN1 channels (before the un-whitening). They are very far from saturating, but we should trend the ADC overflows on MC1 to make sure that this is not an issue (someone besides Tega should ask Tega how to add these to the summary pages so that not only Tega can edit summary pages).
In the attached plot, we can see that the reference trace for the unwhitened MC1 (FM1 ON, FM3 OFF) (black) sensor looks noisier than the others at 16 Hz, where we expect the suspensions to be mostly the same. This is because the analog whitening (amplification) was not being compensated properly. With FM1 and FM3 ON (RED) we can see that the spectra line up nicely below 20 Hz. Above 20 Hz the MC1 sensor is quieter than the others because the ADC noise is being reduced more.
Clearly, the other sensors could use some more whitening. If we find a reason to need lower damping noise in the future, let's remember this elog and remember that we ought to do proper signal conditioning on all our OSEMs. For now, probably doesn't matter.
WFS Whitening and Demod boards were scavenged. ' iLIGO WFS cards are in big plastic boxes placed on the north wall around Section Y5 or Y6 (not under the arm). The WFS head PCBs, empty WFS housing, WFS components, I/Q demod components are at SectionY10 under the arm tube. ' - Koji . I have taken pictures of the boards and will upload them to the DCC once I find a way to add a Serial Number . (I will upload this to the eLog as a HowTo) The next step is to search for at least 2 extender boards to troubleshoot these board and find if there are any issues. We may have replace some components and retune the boards. Attachment #1 is an example of the WFS Whitening Filter and Attachment #2 is and example of the the WFS Demod Board.
If you use the Camera DO NOT remove the strap. I have also purchased lens caps for the camera, so after usage PUT THE LENS CAP BACK ON.
I turned all the LSC oscillators on and used the digital demod for BEATYF (fine y als beat) to grab the data. For this I added notches onto SCY ETMY LSC filter banks FM6-10 to account for these lines at 30.92, 211.10, 313.31, 315.17 Hz (basically just reusing the osc models) and adjusted the sensing matrix to actuate on ITMY.
I aligned and locked YARM, and then I aligned and locked the YAUX. The lock seems pretty robust with an avg green transmission GTRY ~ 0.185 counts for TEM00.
Trying to see other lines appear on the BEATYF demod channels, but so far no luck. I scaled down the exc gain from 500 counts (snr ~ 20 at 575 Hz) and verified the notches are working. Since I am unsure of the issue here and WFS tests are happening at 4 today, I decided to take some beat data under different conditions -->
HEPA OFF and PSL Shutter Open
HEPA OFF and
PSL Shutter Closed
gpstime end = 1352246216
HEPA ON and
Late elog; original time Thursday, Nov 10 16:00 2022
MC1 is using a new satellite amplifier which was a whitening circuit on it with 3 Hz zero and 30 Hz pole. But to read out this signal, we use the old whitening board as it serves as the interface board with the ADC too. This is D000210 Whitening and Interface Board. This board has a switchable whitening filter which our RTS models supply GND as the switch input. It was not immediately clear to me if the GND input to this switch means whitening is ON or not.
I disconnected inputs and outputs to the whitening Board used for MC1 OSEM PDs, and I used a moku:go to measure the transfer function for the UR channel. This confirmed that whitening is turned ON on this interface board as well, which means the MC1 OSEM signals are whitened twice, while digitally we have been dewhitening only once. To fix this there are two possible solutions:
To check out the bandwidths and cross-coupling in the WFS loops, I made a script (attached) to step the offsets around, sleeping between steps. Its also in the scripts/MC/WFS/ dir.
You can see from the steps that there is some serious cross coupling from WFS1-PIT to MC_TRANS PIT. This cross-coupling is not a disaster because we run the MC2 centering loop with such a low gain. This gain hirearchy means that you can effectively consider the IMC with the WFS loops closed to be an "open loop" plant that the MC TRANS loop is trying to control.
I've started another run at 4:40 UTC since my previous one only paused for 30 seconds after turning each offset OFF/ON. This is clearly not long enough to grab the MC_TRANS loop; although you can tell sort of how slow it is from the slope of the error signal after the step is applied.
To make the plot, I used diaggui in the time series mode, with a 3 Hz BW. I applied a 4th order Butterworth filter at 0.3 Hz to low pass the data using the foton string in the time series tool.
Today I found the MC WFS settings all weird. Not only was the input slider set to zero, but the filter bank outputs were off, and also the ON/OFF buttons after the output matrix.
I think we may have been hacked, because there was not mention of this settings change in the ELOG, even though we have this scary red sign.
I am now trying to recover things as best as I can, but I'm not sure exactly which settings the hacker changed. Stay tuned...
Plan to calibrate single arm actuation strength
The analysis is as follows:
I have set a free swing test for MC2 and MC3 to trigger at 1 am tonight. The test should last for about 4.5 hrs upto 5:30 am. It will close the PSL shutter, perform the test, and open the shutter afterwards. To cancel or interrupt the test, go to rossa and do:
I took a coil to OSEM transfer function for MC1 osems (LL, UR) today and again the slope of the transfer function was -1.4 instead of -2 as expected. I compared this with MC3 coil to osem transfer function (LL) which correctly had the slope of -2. See attachments 1 and 2 for the results. This measurement was taken with PSL shutter closed and local damping loops turned off.
As I mentioned earlier, MC1 is using new satellite amplifier box (S2100029-v2) whose transfer function data exists and was actually measured by me in 40m/15776. Using this transfer function data, and the foton 3:30 (FM1) filter, I tried to recreate the product transfer function that should happen if both filters are working correctly. Attachment 3 shows these transfer function plots. I overlayed on top of this the measured transfer function of OSEM to position displacement as done in 40m/17238 by making the magnitude equal at 1 Hz. It is suspicious how nicely the measured transfer function overlay with the satellite amplifier measured transfer function, both in magnitude and phase. I'll investigate more tomorrow.
We migrated fb1 OS from the teststand fb1 drive to the internal 2TB RAID of fb1. We then rebooted twice to check that we no longer have the fb1 booting issue.
The next step is to set up software RAID and backup for chiara, which we plan to complete this week. Then we would work on nodus and workstation OS upgrade next week.
Following configurations were kept today morning:
f2a filters with Q=10 (FM3) were turned on all IMC optics.
It would be good if you can post the uncertainties with these measurements (and for generally any measurements). This is so that we can propagate that uncertainty later for other measurements. From your entry, it looks like there are something like 7 digits of precision, which would be astounding.
I suggest that we adopt the convention of reporting Uncertainty properly by number of significant figures and the parantheses notation.
I have been looking at various replacements for the sensoray, and have found that the majority of new usb video encoders don't have drivers anymore and now just work through being embedded with video-capturing software. This means that the hardware must be used with a compatible video player such as VLC or OBS. VLC can natively be run with terminal commands, and because OBS is open source, there are packages that can be downloaded to use terminal commands to control the software as well. I am not sure to what extent the usb video encoder can then be controlled with these commands, but this seems to be the easiest method so far. I will finish picking which new unit we should purchase tomorrow, and order it through JC.
I did the same measurement for MC3 with one difference that OSEMs report more motion than IMC cavity length change due to it being at 45 degrees. Following are the new cts2um gain values
I reran this measurement at low frequency 0.1016 Hz. Following were the cts2um gain changes:
Edited AG: Wed Nov 9 12:17:12 2022 : Uncertainties added by taking coherence of each channel and MC_F with excitation, using to get fractional error in ASD values I used for taking ratios(where is coherence and is number of averages (5 in this case)), and adding MC_F ASD frac error to all sensor's frac error, and finally multiplyingit witht he ratios obtained above to get error in cts2um gain values.
RXA: I don't believe it. This is more accurate than the LIGO calibration of strain and also more accurate than the NIST calibration of laser power.
This looks really good to me. Rather than fully invert the plant, what we would like to do is now design a filter which allow this loop to have a high UGF and a high gain below 1 kHz. Anchal and Paco probably have gain requirements for this loop in the ALS-CAL paper they are writing. The loop would have the cavity transfer function, as well as the demod electronics for the green PDH loop.
In addition to the gain requirements, we would also like to have a phase margin > 30 deg, and a gain margin of > 10 dB.
Here I describe efforts to cancel the AUX laser PZT mechanical resonances from ~200 kHz-400kHz. While these may not be the resonances we end up wanting to suppress, I chose this region as an exercise because it contains the most significant peaks.
The PZT transfer measurement was taken on 09/06 by myself and Anchal. The Moku:Go outputted a swept-sine (1kHz - 1MHz) I sent to the AUX laser PZT. The beat note between the AUX and frequency-doubled PSL was sent to the DFD, and the I and Q channels were routed back as input to the Moku:Go. We also took a calibration transfer function of the Moku:Go, sending output 1 to inputs 1 and 2.
Almost all of the signal was present in the I channel, so I proceeded to use the I data for fitting/next steps. After normalizing the measured frequency response by the calibration measurement (and adjusting for the calculated time delays in the loop - see ), I fit the resulting data using vectfit [Attachment 1]. I supplied the function with n_poles=16, which in reality fit for 16 complex pairs of poles. This complexity of fit was not necessary to capture the 3 prominent peaks, but would likely be needed to fit any of the more heavily-damped resonances.
I chose to invert all fitted poles between 200 kHz and 367 kHz and the corresponding fitted zeros. The result of this filter applied to the original frequency response data can be seen in Attachment 2, where the blue-shaded region contains the inverted poles/zeros. In total, 9 pairs of poles and 9 pairs of zeros were inverted.
This time the test was succesful but I have reverted MC3 f2a filters back to with Q=3, 7, and 10. The inital part of the test is still useful though. I'm attaching amplitude spectral density curves for WFS control points and C1:IOO-MC_F_DQ in the different configurations. The shaded region is the 15.865 percentile to 84.135 percentile bounds of the PSD data. This corresponds to +/- 1 sigma percentiles for a gaussian variable. Also note that in each decade of freqeuncy, the FFt bin width is different such that each decade has 90 points (eg 0.1 Hz bin width for 1Hz to 10 Hz data, 1 Hz binwidth for 10 Hz to 100 Hz and so on.)
The WFS control points do not show any significant difference in most of the frequency band. The differences below 10 mHz are not averaged enough as this was 30min data segments only.
C1:IOO-MC_F_DQ channel also show no significant difference in 0.1 Hz to 20 Hz. Between 20-100 Hz, we see that higher Q filters resulted in slightly less noise but the effect of the filters in this frequency band should be nothing, so this could be just coincidence or maybe the system behaves better with hgiher Q filters. In teh lower frequency band, we would should take more data to average more after shortlisting on some of these f2a filters. It seems like MC1 Q=10 (red curve) filter performs very good. For MC2, there is no clear sign. I'm not sure why MC2 Q=3 curve got a big offset in low frequency region. Such things normally happen due to significant linear trend presence in signal.
I'm not sure what other channels might be interesting to look at. Some input would be helpful.
I tuned MC3 local damping gains by looking at step responses in the DOF bassis. The same procedure was followed as described in 40m/17133. The gains were changed as following:
Attachement 1 shows the step responsed with the old gains and attachment 2 shows the step responses with the new gains. There is considerable cross coupling between SIDE OSEM and Coil to the face DOFs (POS, PIT, YAW). I think the high SIDE gain earlier was the culprit that started ringing with the f2a filters.
I agree that POS and SIDE step responses could look better but this was the best I was able to achieve. Further attempts by others is most welcome.
I also verified running f2a filter with Q=3 and it has been stably running with no ringing for past few minutes. More long term behavior is yet to be seen.C1:SUS-MC3_SUSSIDE_GAIN
this measurement is not valid because of the coil to sensor coupling that I mentioned before. This is why I suggested you make the measurement at low frequencies (like 0.1 Hz).
MC2 OSEM outputs were calibrated today using MC_F to get the output values in microns. This was done using this diaggui file. We drive a sine wave at 13 Hz and 5000 cts at C1:SUS-MC1_BIASPOS_EXC.
I have made little progress in getting the sensoray driver installed on Donatella. I have confirmed that it is indeed the reason why none of the hardware is working. I am now working through changes on a virtual machine that is running Scientific Linux to find something that may work. If no progress is made soon, I will ensure that software for a replacement video encoder is able to be installed before requesting we order one.
Following up, I tried to do this exercise with MC1 and MC3. While MC3 shows expected minute corrections to the previous value, MC1 showed much alrger corrections which led me to investigate further. Koji suggested to take a transfer function between MC_F and the OSEM outputs for both MC1 and MC3 the same way to see if something is different. And Koji was absolutely right. MC1 MC_F to OSEM outptu transfer function has a frequency dependent value, with a slope of ~0.6. Very weird. I'm holding on to doing OSEM calibration on both MC1 and MC3 until we know better on what is happening. See attached transfer functions.
Reminder, MC1 is using new satellite amplifier box, but OSEM outputs are read through single ended PDMon outputs rather than the differential ended PD Output port, because rest of the MC1 electronics is still last generation and the whitening board for them take in single ended input.
MC2 OSEM outputs were calibrated today using MC_F to get the output values in microns. This was done using this diaggui file. We drive a sine wave at 13 Hz and 5000 cts at C1:SUS-MC1_BIASPOS_EXC. This signal is read at C1:IOO-MC_F and the C1:SUS-MC1_ULSEN_OUT and similar OSEM output channels. MC_F calibration in Hz is assumed to be correct. In diaggui, a calibration conversion of 4.8075e-14 m/Hz is added to convert MC_F signal into meters. This is then used to calibrate the OSEM outputs and necessary gain changes were done in teh cts2um filter module in all of the face OSEM input filters. Following are the new gains:
Note that this measurement was done after the coil strengths for MC2 have been balanced in 40m/17223.
The new QPD installation is turning out to be much more hard than it originally seemed. After finsing the cable, QPD and interface board, when I tried to use the cable, it seems like it is not powered or connected to the interface board at all. I tried both QPD ports on the QPD interface board (D990692) both none worked. I measured the output pins of IDC style connector on the interface board and they seem to have the correct voltages at the correct pins. But when I connect this to our cable and go to the other side of the cable which is a DB25, use a breakout board and see for the voltages, I see nothing. The even pins which are supposed to be connected to each other and to GND are also not connected to each other. I pulled out teh DB25 end of the cable and brought it close to the IDC end to do a direct conitnuity test and this test failed too.
I even foudn another IDC end of a spare QPD cable hanging near 1Y2, but could not find the other end of this cable either.
So moving forward, we have following options:
I tired running for a few hours F2A filter with Q=1 and for maybe 30 min Q=0.3 on MC3 today and that keeps the suspension stable. So I'm going to put in Q=0.3 at FM1, Q=0.7 at FM2, and Q=1 filter on FM3. I am setting the test again for tonight with some modifications. Now the separate set of filters will be tried one by one on the three different optics so that we know the best Q filter for each optic. It is set to trigger at 1 am tonight in tmux sessions f2aMC1Test, f2aMC2Test, f2aMC3Test on rossa. To cancel the test or interrupt, do:
I checked again today by sending excitation at POS and reading back from C1:IOO-MC_TRANS_P and C1:IOO-MC_TRANS_Y. I found that there was some POS->PIT and POS->YAW coupling remaining that I was to remove by same method. New coil gains are:
I am borrowing the fiber illuminator / fiber tester / VisiFault for the OMC lab. It has been stored in the top drawer at the center work bench.
This test was not successfull as IMC lost lock during the f2A filter trial. However, we do have 1 hour off data when all f2A filters were turned off in between following GPS times:
start gpstime: 1351584077
stop gpstime: 1351587677
After this gpstime, the f2A filters were turned ON for all IMC optics. After about 2000 seconds of no issues, the MC3 suspension suddenly rung up 1 Hz oscillations around 1351590720 gpstime. See attachment one for noise spectra of local damping error signals for MC3 before and after this event. See attachment 2 for time series of this event.
So, after this point, MC3 remained rung up and IMC remained unlocked, so no WFS signals are meaningful after gpstime 1351590720.
I have seen this happening out of nowhere to MC3 today too when PSL shutter was closed and only thing interacting with MC3 was the local damping loop. This suggests that some glitch event happens in MC3 which is not taken well by the f2a filter on it. The ringing goes down as soon as we turn OFF the f2a filter. The other optics show no such signs.
We'll do more tests in future to figure out the issue. For now, MC3 f2a filters are kept off. Maybe we need custom filter for MC3 rather than the design value default filter we are using right now. I'm attaching foton bode plot for MC3 f2a filters for verification that correct filters are in place.
We came in this morning and noted the IMC was grossly misaligned, with MC3 still damped but with >= 100 rms motion in all coil monitors (a lot but not enough to trip the WD)... Turning off the WFS didn't do much so it was obviously an issue with the recent f2A output filters, so we turned all off (though only MC3 had this excess motion). After this we aligned IMC, engaged the lock and turned WFS back on.
There was no elog about f2A beyond this test scheduled to run Friday, I guess the filters were meant to stay on long term?
The new tool box has came in! I have spent serious time organizing these tools and making it look pretty, so please take care of it! A few things I would like to note.
Hope you all like it!
The LO phase lock that was achieved lasts for a short time because as soon as a considerable POS offset is required on AS1, the POS to PIT coupling causes the AS-LO overlap to go away. To fix this, we need to balance the coil outputs of AS1 atleast and add the f2a filters too. To follow similar method as used for IMC optics, we need a sensor for true PIT and YAW motion of AS1. Today, we looked into the possiblity of installing a QPD at BHD output path to use it for AS1, AS4, LO1, LO2, SR2, PR2 and PR3 coil strength tuning. We found a QPD which is mentioned in this elog. We found QPD interface boards setup for old MCT and MC Refl QPDs (dating before 2008). We also found the old IP-POS QPD cable between 1Y2 and BS Oplev table. We took out this cable from BS oplev end upto ITMY opleve table, put on a new DB25 connector on the ribbon cable, and connected it to the QPD on ITMY table. There is still following work to be done:
I'll setup some test of switching between different Q filters in future.
The f2A filters are set to test on IMC optics. The script used is testF2AFilters.py. The script is running on rossa in a tmux session named f2aTest. It will trigger at 1 am, Nov 4th 2022. First the script will turn off all F2A filters on IMC optics, wait for an hour, then it will try out the three F2A filter sets with different Q values, one at a time, for one hour each. So the test should last for roughly 4 hours. The gpstime stamps will be written in a logfile that can be used later to readback noise performance of IMC with different filter. The script has a try-except failsafe to revert things to original state if something fails. To stop the script from triggering or stop it during runtime, do following on rossa:
The simulink webview generation cronjob on megatron was not working, apparently due to a matlab license problem. I switched it to matlab 2019a (the current CDS standard), and added a script to generate medm screens from the webview. This can help with keeping hand-made screens up to date, or be a substitute for hand-made screens if the model is simple.
Balanced MC3 coil strengths using the same method.
Final coil strengths found:
I am currently working on getting the driver reinstalled on Donatella for the sensoray. An issue keeps arising that will not allow me to run "make" successfully in the unzipped driver folder. Will continue to remedy this.
This is why there is no light showing up on the device while plugged in. The computer does see the device, but does not show its model due to the inability for it to communicate without the driver.
Balanced MC2 coil strengths using the same method.
I balanced the face coil strengths of MC1 using following steps:
By the end, I was able to see no actuation on POS when butterfly is driven with 30000 counts amplitude at 13 Hz. I was able to see no PIT or YAW actuation when POS is driven with 10000 counts at 13 Hz.
I used this notebook while doing the above work. It has a couple of functions that could be useful in future while doing similar balancing.
We added a notch filter on ETMY (the actuation point of the YARM control loop) to inject our calibration line at 575.170 Hz. The excitation is injected using the DARM Oscillator, with an exc. gain of ~ 500 (this gets us a decent > 10 SNR line in the ALS Y beat). With the arm cavity locked to the PSL (~150 Hz control bandwidth), and the aux laser locked to the cavity (~10 kHz control bandwidth) the goal of this run is to calibrate our actuator strength and more importantly to budget its uncertainty. For this we have looked at the ALS beat stability using Allan statistics; we noticed the ALS beatnote frequency fluctuations start to become dominated by 1/f (or divergent noise due to systematic drifts in the YARM loop) after 10 seconds (see Attachment #1) (we have managed to see 30 seconds stability with the HEPAs off and without locking to IMC).
Our prediction is that our demodulated calibration lines will display the least residual rms noise when averaging down to around this time. This is the only reason one would use allan statistics; to quantify the separation between statistical and systematic effects in a frequency measurement. To be continued...