After a quick discussion with Yuta, we figured that the introduction of a finite Q that Peter Fritschel does in this DCC doc T010140 for the poles pair, he should have done the same for the zeros pair as well otherwise there will be a notch at around 1 Hz. So I simply modified the filter design to have same Q for both zero pair and pole pair and got following transfer functions:
For upper coils:
for lower coils:
Attachment 1 shows the new filter design. I tested this filter set on MC1 and the optic kept on going as if nothing changed. That is atleast a good sign. Now next step would be test test if this actually helped in reducing the POS->PIT coupling on MC1, maybe using WFS signals.
The filters were added using this createF2Afilters.py script.
I've cleared all old attempts on F2A filters on MC1, MC2, and MC3, and added the default F2A filter described in the last post. I added 3 such sets of filters, with Q=3, 7, and 10. I have turned on Q=3 filter for all IMC optics right now. I'll setup some test of switching between different Q filters in future.
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.
Final coil strengths found:
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.
Balanced MC2 coil strengths using the same method.
Balanced MC3 coil strengths using the same method.
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 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:
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.
Following configurations were kept today morning:
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 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:
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:
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.
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.
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 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 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.
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
f2a filters with Q=10 (FM3) were turned on all IMC optics.
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.
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:
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:
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.
I've moved the FSS Slow PID script running to megatron through systemd daemons. The script is working as expected right now. I've updated megatron motd and the always running scripts page here.
After the MC1 osem dewhitening was fixed, I did the calibration of MC1 OSEM signals using MC_F using this notebook. A 0.1 Hz oscillation with amplitude of 1000 cts was sent to MC1 lockin2 and was kept on between 1352851381 and 1352851881. Then I read back the data from DQ channels and performed a welch with standard deviation calculation from the different segments used. From this measurement, I arrive to the following cts2um gain values that were changed in MC1 filter file. The damping remained stable after the changes:
UL: 0.09 -> 0.105(12)
UR: 0.09 -> 0.078(9)
LR: 0.09 -> 0.065(7)
LL: 0.09 -> 0.087(10)
I followed the same method for MC3 as well to get mroe meaningful error bars. This measurement was done between 1352856980 and 1352857480 using this notebook. Here are the changes made:
UL: 0.39827 -> 0.509(57)
UR: 0.33716 -> 0.424(48)
LR: 0.335 -> 0.365(40)
LL: 0.34469 -> 0.376(43)
The larger error bars could be due to more noisy MC3 osem outputs as the satellite amplifier gain is lower here.
I repeated this test for the following configuration:
The test ran for 4000 seconds between following timestamps:
start time: 1352878206
stop time: 1352882207
This script was used to run this test and can be used again in future to repeat the same test.
Repeated this for MC2 using the error measurement technique mentioned in 40m/17286 using this notebook. Following are the cts2um gain changes:
UL: 0.30408 -> 0.415(47)
UR: 0.28178 -> 0.361(39)
LR: 0.80396 -> 0.782(248)
LL: 0.38489 -> 0.415(49)
I averaged 19 samples to get these values hoping to have reached systematic error limit. The errors did not change from a trial with 9 samples except for the LR OSEM.
I followed this procedure to balance the coil strengths on ITMY. The position sensor was created by closing PSL shutter so that IR laser is free running, and locking the green laser to YARM, this makes C1:ALS-BEATY_FINE_PHASE_OUT a position sensor for ITMY. The oplev channels C1:SUS-ITMY_OL_PIT_IN1 and C1:SUS-ITMY_OL_YAW_IN1 were used for PIT and YAW sensors. Everything else followed the procedure. The coil gains were changed as follow:
C1:SUS-ITMY_ULCOIL_GAIN : 1.036 -> 1.061
C1:SUS-ITMY_URCOIL_GAIN : -1.028 -> -0.989
C1:SUS-ITMY_LRCOIL_GAIN : 0.930 -> 0.943
C1:SUS-ITMY_LLCOIL_GAIN : -1.005 -> -1.007
I used this notebook and this diaggui to do this balancing.
c1hpc has option of dithering BS now (sending excitation to BS LSC port to c1sus over IPC). This is available for demodulating BHDC and BH55 signals. Also BS is a possible feedback point, however, we would stick to using LSC screen for any MICH locking.
c1sus underwent 2 changes. All suspension models were upgraded to the new suspension model (see 40m/16938 and 40m/17165). Now the channel data rates are set in simulink model and activateDQ script is not doing anything for any of the suspension models.
I've turned off HEPA fan and all lights at
PST: 2022-11-24 11:23:59.509949 PST
UTC: 2022-11-24 19:23:59.509949 UTC
c1ioo model has been updated to acquire C1:IOO-MC2_TRANS_PIT_OUT and C1:IOO-MC2_TRANS_YAW_OUT at 512 Hz rate.
I'll update when I turn the HEPA on again. I plan to turn it on for a few hours everyday to keep the PSL enclosure clean.
Turned on HEPA again at:
PST: 2022-11-25 12:14:34.848054 PST
UTC: 2022-11-25 20:14:34.848054 UTC
However this was probably not a low noise state due to vacuum disruption mentioned here.
I tried following the steps and the method I was using converged to same output matrix upto 2 decimal points but there is still left over cross coupling as you can see in Attachment 1. With the new output matrix, WFS loop can be turned on with full overall gain of 1.
-2. 4.8 -7.3
3.6 3.5 -2.
2. 1. -6.8
3.44 4.22 -7.29
0.75 0.92 -1.59
3.41 4.16 -7.21
Note: The standard deviation on the averages was very high even after averaging for 30s. This data should be averaged after low passing high frequencies but I couldn't find the filter module medm screens for these signals, so I just proceeded with simple averaging of full rate signal using cdsultis avg command.
Fri Nov 25 12:46:31 2022
The WFS loop are unstable again. This could be due to the matrix balancing done while vacuum was disrupted. The above matrix does not work anymore.
I came today to find that PSL shutter was closed. I orginially thought some shimmer obersvations are underway in the quiet state. But that was not the case. When I tried to open the shutter, it closed back again indicating a hard compliance condition making it close. This normally happens when vacuum level is not sufficient, so I opened the vacuum screena dn indeed all gate valves were closed. This most probably happend during this interlock trip. So the main volume was just slowly leaking and reached to milli torr level today.
Lesson for future: Always check vacuum status when interlock trips.
Paco came by to help. We went to asia (the Asus laptop at vacuum workstation) but could not open the medm or find the nfs mounted files. The chiara change did something and nfs mounted directories are not available on asia of c1vac. We rebooted asia and the nfs mount was working again. We can't simply restart c1vac because it runs acromag channels for vacuum system and needs to be done more carefully, a task for Monday.
After restarting asia, we opened the the vacuum control medm screen and followed the vaccum pump down instructions (mainly opening of the gate vales as the pumps were already on). Point to keep in mind, rule of thumb, do not open valve between a turbo pump and a volume if the pressure differential is more than 3 orders of magnitude. Saving turbo pumps is the priority.. Now the main volume is pumping down.
Turned off HEPA at:
PST: 2022-11-25 15:34:55.683645 PST
UTC: 2022-11-25 23:34:55.683645 UTC
Turned on HEPA back at:
PST: 2022-11-28 11:14:31.310453 PST
UTC: 2022-11-28 19:14:31.310453 UTC
[Anchal, Paco, Yehonathan, JC]
Last night at 9:15 pm PST (Nov 27th, 2022) some kind of disruption happened to FEs. See attachment 1 to see the changes in FE state words of the IOP models. on c1lsc, c1sus and c1scex, change of 140 happend, that's 2nd, 3rd and 7th bit of the FE word was flipped, which I think is the TIM, ADC and DAC KILL (DK). When we came in morning, IMC suspensions were undamped and not responsive to coil kicks, vertex suspensions the same case, ETMX also same. The c1sus2 modelw as all in red.
To fix this, we restarted all rtcds models on all FEs by sshing into the computers and doing:
Then we burt restored all models to 27th Nov, 3:19 am point doing following on rossa:
Note: this issue was previously seen when fb1 was restarted without shutting down the FEs, and once when the martian switch was disrupted while FE models were running.
I'm not sure why this happened this time, what caused it at 9:15 pm yesterday, and why only c1lsc, c1sus and c1iscex models went to DAC KILL state. This disruption should be investigated by cds upgrade team.
I changed the script in /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/outMatFilters/createF2Afilters.py to read the measured POS resonant frequencies stored in /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMatCalc/resFreqs.yml instead of using the estimate sqrt(g/len). I then added Q = 3 F2A filters into FM1 output filter of LO1, LO2, AS1 and AS4 suspensions in anticipation of BHD locking scheme work.
In Attachment 1, I give a plan for the proposed path of AS beam into the IMC WFS heads to use them temporarily as AS WFS. Paths shown in orange are the existing MC REFL path, red for the existing AS path, cyan for the proposed AS path, and yellow for the existing IFO refl path. We plan to overlap AS beam to the same path by installing the following new optics on the table:
I request people to go through this plan and find out if there are any possible issues and give suggestions.
PS: Thanks JC for the photos. I got it from foteee google photos. It would be nice if these are also put into the 40m wiki page for photos of optical tables.
RXA: Looks good. I'm not sure if ND filters can handle the 1 W MC reflection, so perhaps add another flipper there. It would be good if you can measure the power on the WFS with a power meter so we know what to put there. Ideally we would match the existing power levels there or get into the 0.1-10 mW range.
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.
We aligned the ETMX OSEMs and ran into this issue. Looking at the SENSOR_SIDE channel, we pulled out the OSEM and determined that the open light voltage is 874 counts, so we centered it around 440 as well as we could. This is same channel as its slow counterpart SDSEN_OUTPUT (grey number immediately to the right on SUS medms).
The slow signal from the side sensor on ETMX was last seen in action sometime in May 2010! And then the frame builder has no data for a while on this channel. After that the channel shows some bistability starting Sept 2010 but has not been working. The fast channel of this sensor (C1:SUS-ETMX_SDSEN_OUTPUT) does work so the sensor is working. Probably is a loose contact... needs to be fixed.
I made a quick sketch of how to include two more RF PDs on the REFL beam, given the space we have on the table. We want to install REFL33 and REFL165, 3f signals for the the two modulation frequencies we are using. The point is to make the distance from first beam splitter the same to all PDs so that we can use only one lens before this BS to make the beam the right size. Currently there are 2 PDs on the refl beam, REFL11 and REFL55, predictably. So the drawing shows 4 PDs. Drawing is to scale but is a bit coarse. Hopefully we'll take pictures once we're done.
Reference from current BS splitting beam to the existing PDs.
Where was the AS clipping?! Ah, the suspense...
+ fixed the AS clipping issue
We need to check/fix the AS beam clipping and once it's done we will readjust the OSEM mid range and the oplevs.
Before we install the REFL 3f PDs I made a drawing of the current table layout, since there has been no update lately. Once I've incorporated the two extra PDs (now seen sitting bottom left), I will update the drawing and post in the wiki as well.
I have reconfigured the refl beam path on the AP table to include REFL33 and REFL165. Would be done if we hadn't prepared P BSs instead of S, which required some serious digging to find two others. And if someone hadn't stolen our two 3m SMA cables that Keiko and I made on our previous visit and I had left with the 3f PDs. I don't expect them to reappear but if they do, it would be grand.
Note: Refl beam from ifo looks a bit high, ~1cm on the lens 20'' from output port. Not sure what that means about ifo alignment change, I've left it as is. When we know we have a good alignment, we should be able to easily realign the beam path if necessary. If it remains the same, we might want to change the lens height.
1) REFL11 and REFL55 are now hooked up and aligned in a low power beam. (I set the power as low as I could by eye to not risk burning the PDs during alignment)
2) The required BSs and REFL33 and REFL165 are in place, powered.
3) I have set them in a configuration such that the beam is the same distance from the main beam, to adjust beam size easily for all 4.
4) Camera has been moved from main beam to behind a steering mirror, ND filters removed, centered on camera.
1) Find one more longish SMA cable.
2) Align beam on REFL33 and REFL165.
3) Check beam size carefully. (I get a plateau on the scope, and I can "hide" the beam on the PD, but it could be better. The path has become longer by ~5-8inches.)
4) Adjust power.
5) Redo layout diagram, post in wiki.
We were able to lock PRC using REFL11I after improving the MICH dark fringe a bit (moving BS) and rotating AS55 and REFL11 such that the signal was maximized in the phases we were using. The dark port is not so dark... but the lock is stable.
I had finished the whole REFL path alignment, but I didn't have a good input beam reference at the time, which is why we had to realign the PDs and the camera. We only had strength to realign 11 and 55. Otherwise, we just need to tweak and center beam on 33 and 165, figure out what's up with 55 and be done with the AP table mods. I hope.
- We aligned MICH and were successfully locked MICH using AS55Q. The other mirrors were misaligned so that the other degrees of freedom didn't exist. AS55 was fed back to BS. The f2a filters on BS suspension were required to lock, because the pos feedback was unbalanced to angle degrees of freedom.
- We tried to lock PRCL next, however, because we aligned the MICH and the REFL beam paths were changed, REFL PDs didn't have the light anymore. The REFL paths were modified now, so we will try the PRCL locking next.
- We couldn't confirm REFL55 signals although we alined the REFL paths to REFL55 PD.
I started today with a different input beam, so I had to realign the REFL path again. Then we measured the RF signal out of the 4 REFL PDs and found them to be too low. We increased the power to around 10mA for each diode, and we can see the right modulation frequency on each diode, though REFL165 is way too weak so we might need an RF amplifier on it. We will measure demod board noise tomorrow.
We had an issue with REFL165 not giving the right DC level, low by a factor of 10, even though it was receiving the same optical power as the others. We fifteen-checked clipping and alignment, then pulled it out and measured it on the test stand - found it to be ok. So I uplugged its power cable at the rack and connected it to the AS165 slot. Problem sloved. Not sure what was wrong with the other power slot.
Then we found REFL55 to be clipping on its black glass, we fixed that. But the REFL55 DC power still changes a lot with seemingly not huge motions of the PRM. We'll investigate more tomorrow.
We added a lens in the path to REFL165 because unlike the others it is a 1mm diode. All diodes have about half a turn to a full turn flatness of maximum (on tiny steering mirror).
We set the whitening gain on all four diodes to 21 db.
Not sure if we should set the power to be different on these diodes since their sensitivity is different to RF, and now REFL11 sees huge signal.
We continued the DRMI locking attempt and brought in the SRC, using AS55I to control it. It kind of works/stays locked. We did manage to get MICH and PRC better controlled than last night, but with SRC in the mix, something is wrong. We have to redo f2a filters on SRM and hopefully things will be better after Jenne's suspension work tomorrow. Oplevs not optimized yet either.
We intend to realign POY beam path so we can monitor power in cavities.
I followed Jenne's instructions, ran the matrix filler script and then set the optics to freeswing. Someone has to burt resture and damp them in the morning.
As promised, I have made a final AP table drawing, including the MC camera relocation changes by Kiwamu. I have posted it in the wiki on the tables list, and on the AP table page I've attached the inkscape .svg I used to make it, if someone needs to do small modifications.
Attached is a pdf version of it.
1) REFL beam has been split into 4, to go in equal powers and equal beam size to the now 4 REFL RFPDs, 11, 33, 55 and 165. A lens had to be added for REFL165 because it's a 1mm PD instead of 2mm like the other 3.
2) MC camera has moved.
3) I've cleaned up most of the random components on the table, put them away, and tidied up the cabling.
The scripts I wrote can be found in /users/anamaria/scripts/sensemat/
]There are two of them:
- one that sets all the switches, gains, frequencies, etc, then cycles through the various RFPDs I and Q into the LOCKIN signal, so as to see the sensing matrix.
- the second one is a matlab script that takes the crappy file tdsavg outputs and makes it into a cute mag/phase matrix.
They're quite primitive at this point, I've forgotten a lot of tcsh... may improve later. But could be useful later to someone else at least.
I don't think it's particularly the fault of the script that we can't measure the sensing matrix. We can slam on the excitation by hand, and it holds for a little while. I set a wait time for lock to adjust, and most times it just oscillates a bit for a few seconds. Also, the script turns on the excitation and it's done, the rest is just measurement, then turns it off at the end. So during the script, there's not much to deal with, except keeping the lowpass filters quiet when switching the signal to demod; but that doesn't go anywhere, so it definitely doesn't disturb the ifo. Turns out pressing the RSET clear history button needs a 2 to make it happen.
I think I might prefer to set the excitation to run, and then do the old retrieve-data-later-nds-matlab thing. I do not trust these measurements without coherence and a bit of variance study, given instabilities.
Point is... Even on carrier, the PRC lock is not stable by any means. Can barely turn on low freq boosts, every other lock. Until we fix the lock stability issue, there's not much to measure I guess.
Unfortunately, I don't know how to make that happen. Before we leave on Friday we could do a few sanity checks such as measuring the noise of the RFPDs vs ADC+whitening, which I may have said I would do; and perhaps setting up a couple OSAs, one on REFL, one on AS, to make sure we know what the sidebands are doing. Both of which Rana suggested at some point.
(There used to be a quote here from Keiko here but I got mad when it reformated my entire log to be one cluster- hence the look)
We decided we needed a DC channel to sense the gain in the PRC, so we set to align POY55. It took a while because the beam was very weak, and it comes in upwards, so we used a couple of mirrors to bring to a reasonable flat level, and put it on the PD. Then we went to read the DC out and we got 1.3V stationary! Nonsense. We also realized there is no LO for this PD, or any other 55MHz PD, aside from REFL55. Oh well, we only wanted the DC for now. POY55 is aligned (decently).
Koji told me to try swapping the power cable, so I unplugged it at the rack and plugged it in another power card. And it worked! I then moved the DC out (back of rack) to follow the front, and it turns out POY55 diode is read on the POXDC channel. I plugged and unplugged it in disbelief, but it is what it is. At least we have a readout on the power level in PRC.
I attach a picture of the power cards for the LSC RFPDs, with the 3 I found to be bad, and showing current config. I had to move REFL11 and POY55 from their assigned spot.
The two on the lower left are bad in the sense that they put an offset on the PD and make the DC readout be 1.3V for no reason (when working, for example, POY55 read 60mV). The one on the lower right I had trouble with some time ago, it made the PD not read any voltage at all (when working it would read at least 100mV). Beyond that I have not investigated what is up, since I could find working plugins.
A few comments on REFL table alignment and REFL165.
Last time we realigned the table was after the PZT work by Koji/Kiwamu; we made sure that the beam was going through optics satisfactorily and that we were reading reasonable numbers. I did use primarily a viewer to align onto PD, after which we used the voltage reading to center better around that spot. As desired, I could not see the beam once it was centered on the PD. I never touched the PBS unfortunately, so I never noticed it was not fixed. Sad.
I am very surprised to hear the reading from REFL165, since I was reading around 400mV from it a few days before. Something strange happened in the mean time. I hope not when I was plugging and unplugging at the power rack for the POY work. But I would not have needed to touch REFL165. Those cables should get some strain relief at the rack, by the way.
I thought about it, and I must admit that after we centered camera on REFL (paired with an alignment), we did not check the beam path later, even after we saw that the REFL beam had moved. We only did a quick by-viewer check that the beams were not off of the PDs.
- The REFL path has been thoroughly aligned
Many optics had the spots not on the middle of the optic, including the PBS whose post was not fixed on the post holder.
We aligned the optical paths, the RF PDs, and the CCD. The alignment of the PD required the use of the IR viewer.
One should not trust the DC output as a reference of the PD alignment as it is not enough sensitive to the clipping.
We aligned the optical paths again after the reasonable alignment of PRM is established with the interferometer.
"Next time when you see REFL spot is not at the center of the camera, think what is moved!"
- The REFL165 PD is disconnected from the power supply
I found that the REFL165 PD is producing 7.5V output at the DC monitor no matter how the beam is blocked.
As I could not recover this issue by swapping the power connector at the LSC rack, I disconnected the cable
at the RFL165 PD side. I need to go through the PD power supply circuit next week.