agreed, seems excessive. I always prefer bandstop over notch in case the eigenfrequency wanders, but the bandstop could be made to be just a few Hz wide.
The procedure is that the optic is kicked to excite it, and allowed to ring down for ~1ksec, with damping turned off. The procedure is repeated 15 times for some averaging.
Attachment #1 - sensor spectra from yesterday.
Attachment #2 - peaks using the naive diagonalization matrix from yesterday.
Attachment #3 - Data from ~1 year ago.
The y-axis in all plots is labelled as "cts/rtHz" but these are the DQed channels, which come after a "cts2um" CDS filter - so if that filter is accurate, them the y-axes may be read as um/rtHz.
I wonder if the September 2020 earthquake somehow damaged the PRM suspension, as this experiment would suggest that the problem is not only with the actuation. The data was gathered with the neutral position of the PRM (between kicks) being well aligned for PRMI, and the DC values of all the shadow sensors in this position is close to half-light (~1V, except for side which was more like 4V). Hard to say what exactly is happening since only the PIT DoF has the weird asymmetric peak shape instead of the expected Lorentzian - I would have thought that a damaged wire or broken magnet would affect all 4 DoFs but the F.C. spring experience on ETMY showed that anything is possible.
While I was trying to lock the PRMI this evening, I noticed that I couldn't move the REFL beamspot on the CCD field of view by adjusting the slow bias voltages to the PRM. Other suspensions controlled by c1susaux seem to respond okay so at first glance it isn't a problem with the Acromag. Looking at the OSEM sensor input levels, I noticed that UL is much lower than the others - see Attachment #1, seems to have happened ~100 days ago. I plugged the tester box in to check if the problem is with the electronics or if this is an actual shorting of some pins on the physical OSEM as we had in the past. So PRM watchdog is shutdown for now and there is no control of the optic available as the cables are detached. I will replace the connections later in the evening.
Since I couldn't find anything wrong, I plugged the suspension back in - and voila, the suspect UL PD voltage level came back to a level consistent with the others! See Attachment #2.
Anyway, I had some hours of data with the tester box plugged in - see Attachment #3 for a comparison of the shadow sensor readout with the tester box (all black traces) vs with the suspension plugged in, local damping loops active (coloured traces). The sensing noise re-injection will depend on the specifics of the local damping loop shapes but I suspect it will limit feedforward subtraction possibilities at low frequencies.
However, I continue to have problems aligning the optic using the slow bias sliders (but the fast ones work just fine) - problem seems to be EPICS related. In Attachment #4, I show that even though I change the soft PITCH bias voltage adjust channel for the PRM, the linked channels which control the actual voltages to the coils take several seconds to show any response, and do so asynchronously. I tried restarting the modbus process on c1susaux, but the problem persists. Perhaps it needs a reboot of the computer and/or the acromag chassis? I note that the same problem exists for the BS and PRM suspensions, but not for ITMX or ITMY (didn't check the IMC optics). Perhaps a particular Acromag DAC unit is faulty / has issues with the internal subnet?
Sigh... hard loch
The PRM got tripped ~5AM this morning. The cause is unclear - the seismometer reports elevated activity ~10 minutes before the ringdown starts (as judged using the OSEMs). But the other optics didn't seem to receive as much of an impulse (I only show the BS sensors here as it sits on the same stack as the PRM). Anyway it certainly wasn't me trying to make life difficult for the morning team.
I was able to restore the damping with reEnableWatchdogs.py. I am now running some suspension tests on the PRM by letting it swing freely so please let that finish. I plan to attempt some locking this evening.
- Upon arrival, MC is locked, and we can see light in MON5 (PRM) (usually dark).
I just saw the PRM watchdog tripped at ~15:20 local (23:20UTC). I restored the PRM but I saw only the side watchdog tripped.
Again at 15:27
17:55 I found the PRM was oscillating while the watchdogs were not tripped. I turned off the OPLEV servos and this made the PRM calmed down. But I didn't turn on the OPLEVs for the past two trips. How were the OPLEVs turned on???
Ah, I'm sorry, I missed the line that Gautam was running the free-swinging test on the PRM.
The two kicks starting from 23:08:50 and from 23:26:31 were spoiled. Did it make the measurement completely waisted?
The standoff glued. The incandescent lamp set for curing the epoxy.
Jenne and Suresh did the balancing job. The next job was to glue it.
They ran out of the clear epoxy, and tried to use the grey epoxy which we used on the other suspensions for the upgrade.
They found that the solution A with grey color one was dried out and grainy.
We made a test piece of the grey epoxy (mixed with the solution B) in order to see the glue is still usable or not.
After the PMA party, we found that the glue was not stiffening but brittle. We judged that the grey epoxy is no longer useful.
Steve found a pack of Vac Seal in the chemical fridge. We decided to use this one for the gluing of the standoff.
After the gluing, we set an incandescent lamp to make the glue warm.
Finally, we wrapped the suspension tower with Al foils and turned the HEPA fans again.
I'm starting to lock for the night, and I noticed that PRM is very, very pitched. Why? The PRM pitch slider is 5 full integer units higher than the backup (and the backup value is about where I like it, around -0.2).
I am not aware of any scripts that touch the PRM slider values. The PRM ASS (which I haven't used in ages) offloads the biases to the SUS screen fast channels, so even if someone turned that on and then saved the values, it wouldn't leave the PRM so very, very misaligned.
I have restored it, and relocked the PRMI, so all is well, but it's very weird to have found it so misaligned.
PRM was released from the fixuture without any trouble. This was the last magnet gluing until ETMs are delivered.
The below is the up-to-date Jenne stat table.
The clean room is getting too narrow. I am thinking that we should install ITMs to the chamber so that we can accommodate SRM/PRM suspensions.
I think the crane repair guy accidentally stepped on the BSC support beam.
PRM side is not coming down.
I think the crane repair guy accidentally stepped on the BS support beam.
Seems fine now.
IR off for 11 minutes. The PRM face sensors are effected. The PRM side and the rest of the SUS OSEMS are not effected.
Yesterday Q noticed that PRM_sensor_LR was 0.098V This actually went to ~ zero on 7-3
Yesterday, we placed the new PRM to BS chamber and the beam reached PR2 at ITMX chamber.
Today, we lead the PRM reflected beam back to AP table.
Also, we aligned PRs so that the beam hits ITMX and ITMY.
What we did:
1. Aligned PR2 at ITMX chamber and PR3 at BS chamber so that the beam hits ITMY.
2. Aligned ITMX using IFO_ALIGN sliders so that the reflected beam overlaps at BS.
3. Aligned BS using IFO_ALIGN sliders so that the splitted beam to ITMX overlaps the green beam from the X-end.
4. Roughly aligned ITMY using IFO_ALIGN sliders so that the reflected green goes to far x-end.
5. From yesterdays in-vac work, the reflected beam from PRM reached the Faraday.
Aligned 2 steering mirrors in MC chamber so that the beam reaches AP table.
6. Found the beam is double-spotted by a steering mirror at just after the Faraday symmetric port.
The mirror is Y1-2037-45S. The beam is hitting it in ~10deg, so we have to replace it.
- replace the steering mirror right next to the Faraday symmetric port.
- recyled Michealson
We had to use "ITMX" channels to align ITMY. We have to fix and check X-Y confusion.
Also, damping servo for ITMs does not seem to work. We have to check this.
Over the weekend, Bob and Daphen gave the PRM a 48hr. vacuum bake. This afternoon Suresh and I placed it back in the wire in the tower. We used the microscope-on-translation-stage technique to make sure the scribe lines on each side of the optic are at the same height, and then secured the PRM using all of the EQ stops. It is wrapped in foil, and ready for its journey into the IFO room. When we next have the BS chamber open, we should put the PRM in, and move the current PRM to its final place on the ITMY table as the SRM.
PRM is aligned. IFO is not locked. It is just flashing, including arms. Olympus SP570UZ camera used without IR blocker. Note: PRM side OSEM does not show IR effect.
I will take more pictures with IOO IR blocked and HeNe oplev blocked tomorrow morning.
It crossed my mind that, from these pictures, it could be glow from the oplev scattered light that is causing the problem. However, that seems not possible, since the power fluctuations that we see depend on the presence of the IR light - if it were the oplev light, then when I close the PSL shutter, I should see the same amount of kick, which I don't. Also, the amount of fluctuation increases with increased stored power in the cavities. Also, also, Steve reminds me that some of the MC mirrors see similar kicks in their OSEM signals, but they don't have oplevs.
So, I don't believe that the oplev light is causing the problem, but I wanted to write down why I don't think that's it.
Investigations into OSEM and oplev loops to get rid of the kicks are continuing.
Nice camera work Steve! I will use these for publicity photos.
Now we need to get one of the video cameras hooked into the MUX so that we can see the flashing and do some image subtraction.
Can't we somehow hook up this camera to the MUX with the movie mode?
I think both the MUX and the sensoray are compatible with the color video signal.
Only the old CRT is B/W.
[Kiwamu, Yuta, Koji]
We went to the new metrology lab at Downs subbasement (Rm014) in order to measure the phase map of the delivered PRMs.
It's brand-new. So we had to measure the reference phase map, calibration as well as the phase map of our mirrors (3 PRMs and 1 spare SRM). It took a whole day...
What not to do:
The PRM oplev servo was left on and it was driving this oscillation overnight.
Yuta claims he fixed the PRM oplev by centering it the other day, but no one has left it on and watched it for a long while, to make sure it's okay. We watched it now for ~2 min, and it was good, but we're leaving the oplevs off anyway for the night. Tomorrow we should restore PRM (it's currently restored), turn on the oplevs, and let it sit to make sure it doesn't go crazy.
PRM oplev servo was turned on with PITgain 0.5 and YAWgain -0.7
Note: gain settings were PIT 1.0 and YAW --0.5 on Jun 1, 2012 that I measured Feb 23, 2012
It is still oscillating. Gains turned down to zero.
Earthquake test our suspensions PRM damping restored. Oplev servo gains turned to zero.
The PRM was pointing totally the wrong way, so there was no light on the oplev PD. I restored the PRM, turned the gains back to (0.15, -0.3) as per Yuta's elog 6952, and it seems just fine to me.
I want to check the data from last night / the weekend to see when the mispointing happened, but dataviewer can't connect to the fb, since Jamie is still working his magic. I'm pretty sure I restored all of the optics after Eric finished playing with MICH Friday night, but it's possible that I forgot one, I suppose. If it wasn't me, then I'm curious when it happened.
I centetered PRM oplev, lowered gain and PRM oplev servo is not oscillating any more.
It is OK for more than a softball practice.
C1:SUS-PRM_OLPIT_GAIN = 0.15 (was 0.5)
C1:SUS-PRM_OLYAW_GAIN = -0.3 (was 0.7)
Openloop transfer function:
Oplev Pitch: gain ~ 12 at 0.69 Hz resonance
Oplev Yaw: gain ~ 18 at 0.83 Hz resonance
I adjusted the gain so that oplev damps resonance as much as possible, but not introduce additional noise. I did no calculation, but just measured OSEM spectra (SUSPIT and SUSYAW). Below, you can see the noise reduces at resonance when oplev servo is on, and not increasing at other frequencies. It was introducing noise before. Someone should do more systematic adjustment of oplev servos for all the optics.
In the process of figuring out what we can do to fix our PRM motion problem, I am looking at the PRM oplev.
Eventually (as in, tomorrow), I'd like to be able to simulate some optic motion as a result of an impulse, and see what the oplev loops do to that motion. (For starters, I'll take the impulse response of the OSEM loop as my time series that the oplev loop sees).
One thing that I have done is look at the oplev model that Rana put together, which is now in the noisebudget svn: /ligo/svncommon/NbSVN/aligonoisebudget/trunk/OpLev/C1
This script plots the open loop gain of the modeled oplev:
This should be compared to the pitch and yaw measured transfer functions:
In the YAW plot, there are 2 transfer functions. The first time around, the UGF was ~2.5Hz, which is too low, so I increased the gain in the C1:SUS-PRM_OLYAW filter bank from -3 to -9.
The shapes of the measured and modeled transfer functions look reasonably similar, but I haven't done a plot overlay. I suspect that the reason I don't see the same height peak as in the model is just that I'm not taking a huge number of points. However, if the other parts of the TF line up, I'll assume that that's okay.
I want to make sure that the modeled transfer function matches the measured ones, so that I know I can trust the model. Then, I'll figure out how to use the time series data with the simulated loop. Ideally, I'd like to see that the oplev loop can fully squish the motion from the OSEM kicks. Once I get something that looks good (by hand-tweaking the filter shape), I'll give it a try in the actual system. We should, as soon as I get the optimal stuff working, redo this in a more optimal way. Both now, and after I get an optimal design, I'll look at the actual step and impulse responses of the loop, to make sure there aren't any hidden instabilities.
Other thoughts for the night:
Rana suggests increasing the gain in some of the oplev QPD heads (including PRM), so that we're getting more than a few hundred counts of power on each quadrant. Since our ADCs go to 32,000 counts, a few hundred is very small, and keeping us close to our noise limits.
Also, just an observation, but when I watch the REFL camera along with POP and AS, it's clear that the PRM is getting kicked, and I don't have the ETMs aligned right now, so this is just PRMI flashes. There is also a lot of glow in the BS chamber during flashes (as seen on the PRM face video camera).
I have created a new filter for the PRM oplev damping loops. The biggest change is an increase in the gain between 0.4 - 7 Hz.
Here is a plot of the old, and my new modelled open loop gain:
When I look at my step and impulse response time series, the notches for the bounce and roll were causing some ringing, so for now they are turned off, both in the model and in the real time system. Also, the "OLG orig" trace has a 4th order elliptic lowpass at 75 Hz, but the real system had a 4th order elliptic low pass at 35 Hz. When we use 35 Hz in the model, we get lots of ringing. So, we have moved both model and real system to 55 Hz 4th order elliptic low passes. Also, also, we haven't been using the 3.3 Hz resonant gain, so I removed that from the modelled loop.
I have put the "boost" for the .4-7 Hz emphasis into FM 7 of the PRM oplev filters. I also removed several old filters that are never used. So, for now, the PRM oplevs should have engaged: FM 1, 7, 9. Pitch gain is +5, yaw gain is -9. We can consider re-implementing the bounce-roll notches, and the stack resgain if it looks like those are getting rung up, and causing trouble.
Here is a set of spectra, showing the improvement. It's unclear why yaw is worse than pitch below 4Hz, and why pitch is so much worse than yaw between 4-15 Hz, however for each of pitch and yaw, the before (reference pink and cyan traces) is higher than the improved (dark red, dark blue traces) between a few tenths of a Hz up to 3ish Hz. And, we're not causing more noise elsewhere. We do want to monitor to make sure we're not ringing up the bounce and roll modes, but for now they seem fine.
I forgot how we could turn on the PRM oplev servo and the PRM ASC servo at the same time without conflict.
It seems that this new oplev servo covers 0.04 to 8Hz. It's pretty broadband. Do we inject the ASC signal to the oplev error?
I forgot how we could turn on the PRM oplev servo and the PRM ASC servo at the same time without conflict.
It seems that this new oplev servo covers 0.04 to 8Hz. It's pretty broadband. Do we inject the ASC signal to the oplev error?
Right now all 3 servos that control PRM angle (OSEM damping, Oplev, and ASC) run in parallel, and they're all AC coupled.
PRM oplev gains set to zero from PIT 0.15 and YAW -0.3 and damping restored
Put them back to normal.
The PRC (locked on carrier so far today), is pretty wobbly. It'll stay locked on carrier, but it's wobbling. The ASC was over-ridden during the vent. While I was looking around for that, I noticed that the PRM oplev sum is very low.
I went into the lab, and turned off / blocked all oplev beams except the PRM beam. I can't tell what it's clipping on, but there is definitely some red glow in the BS chamber (not as much as the stuff that's coming from the ITMY or SRM oplev hitting a tip tilt suspension - that giant spot went away when I turned off the ITMY/SRM oplev laser). The beam going into the vacuum is nice and strong, but the beam coming out is very weak, and has a horizontal line of scatter through it, like it's clipped somewhere in pitch. The PRM oplev sum is currently ~150 cts, when it should be closer to 2,000.
So far, this seems to be livable, but it's definitely disappointing.
PRM oplev beam was not hitting on the QPD since Jun 1, so I centered it. I reverted the oplev servo gains and now oplev servo looks fine.
C1:SUS-PRM_OLPIT_GAIN = 1.0
C1:SUS-PRM_OLYAW_GAIN = -0.7
There's SIDE to UL/UR/LL/LR coil element in PRM TO_COIL matrix. They were 0 until Mar 31, 2012, but someone changed them to -0.160. I couldn't find elog about it.
Same thing happened to BS on Mar 13, 2012 (see elog #6409), so I think somebody did the same thing to PRM.
After last week's work on the BS/PRM oplev table, I think the PRM oplev got centered while the PRM was misaligned. With the PRM aligned, the oplev spot was not on the QPD. It has been centered.
The returning spot diameter on the qpd ~10 mm. In order to reduce the spot size I moved the f 1145 mm lens toward the PRM ~ 25 cm. The spot size was reduced to ~8 mm, 3200 counts.
I'll try to find an other lens tomorrow.
We had to work on redesigning the oplev layout in BSC when I found that the positions of the mirrors were clipping IPPOS and the green beam while updating the CAD layout.
To avoid any clipping, the prm oplev beam is steered into the vacuum by an oplev mirror and out of vacuum through 3 steering mirrors. The table weights had to be moved to allow room for the oplev mirrors. Hence table had to be re-leveled. I will update the CAD drawing with the current position of the mirrors and will reconfirm that the new mirrors are not in the way of any of the beams. In-vac photos are updated in picasa.
Nic and Evan put the ISS together (elog 9376), and we used an injection into the error point (?) to modulate the laser power before the PMC (The AOM had a bias offset, but there is no loop). This gives us some RIN, that we can try to correlate with the PRM OSEM sensors.
We injected several lines, around 100, 200, 500 and 800 Hz. For 100, 200 and 800 Hz lines, we see a ratio between POPDC and the OSEM sensors of 1e-4, but at 500 Hz, the ratio was more like 1e-3. We're not sure why this ratio difference exists, but it does. These ratios were true for the 4 face OSEMs. The side OSEM saw a slightly smaller signal.
For these measurements, the PRMI was sideband locked, and we were driving the AOM with an amplitude of 10,000 counts (I don't know what the calibration is between counts and actual drive, which is why we're looking at the POPDC to sensor *ratio*).
To get a more precise number, we may want to consider locking the PRMI on carrier, so we have more power in the cavity, and so more signal in the OSEMs.
These ratios look, by eye, similar to the ratios we see from the time back on 30 Oct when we were doing the PRMI+2arms test, and the arms were resonating about 50 units. So, that is nice to see some consistency.
This time series is from 1067163395 + 27 seconds, from 30 Oct 2013 when we did the PRMI+2arms.
Ideas to go forward:
We should think about chopping the OSEM LEDs, and demodulating the PD sensors.
We should also take a look in the chamber with a camera from the viewport on the north side of the BS chamber, to see if we see any flashes in the chamber that could be going into the OSEMs, to see where we should maybe put aluminum foil shields.
Some more words about the ISS -> OSEM measurement:
The calibration of the OSEMs have been done so that these channels are each in units of microns. The SIDE channel has the lower noise floor because Valera increased the analog gain by 5x some time ago and compensated with lower digital gain.
The peak heights in the plot are:
So that tells us that the coupling is not uniform, but mostly coming in from the left side (which side is the the SIDE OSEM on?).
Jenne and I discussed what to do to mitigate this in the loops. Before we vent to fix the scattering (by putting some covers around the OSEMs perhaps), we want to try to tailor the OSEM damping loops to reduce their strength and increase the strength of the OL loops at the frequencies where we saw the bulk of the instability last time.
Jenne is optimizing OL loops now, and I'm working on OSEM tweaking. My aim is to lower the overall loop gains by ~3-5x and compensate that by putting in some low Q, resonant gain at the pendulum modes as we did for eLIGO. We did it here at the 40m several years ago, but had some troubles due to some resulting instability in the MC WFS loops.
In parallel, Steve is brainstorming some OSEM shields and I am asking around LIGO for some AC OSEM Satellite modules.
* Still need to finish calculating what could be causing our big arm power fluctuations (Test mass angular motion? PRM angular motion? ALS noise?) (Calculation)
I think that our problem of seeing significant arm power fluctuations while we bring the arms into resonance during PRMI+arms tests is coming from PRM motion. I've done 3 calculations, so I will describe below why I think the first two are not the culprit, and then why I think the PRM motion is our dominant problem.
ALS length fluctuations
Arm length fluctuations seem not to be a huge problem for us right now, in terms of what is causing our arm power fluctuations.
What I have done is to calculate the derivative of the power in the arm cavity, using the power buildup that optickle gives me. The interferometer configuration I'm using is PRFPMI, and I'm doing a CARM sweep. Then, I look at the power in one arm cavity. The derivative gives me Watts buildup per meter CARM motion, at various CARM offsets. Then, I multiply the derivative by 60 nm, which is my memory of the latest good rms motion of the ALS system here at the 40m. I finally divide by the carrier buildup in the arm at each offset, to give me an approximation of the RIN at any CARM offset.
I don't know exactly what the calibration is for our ALS offset counts, but since we are not seeing maximum arm cavity buildup yet, we aren't very close to zero CARM offset.
From this plot, I conclude that we have to be quite close to zero offset for arm length fluctuations to explain the large arm power fluctuations we have been seeing.
AS port contrast defect from ETM motion
For this calculation, I considered how much AS port contrast defect we might expect to see given some ETM motion. From that, I considered what the effect would be on the power recycling buildup.
Rather than doing the integrals out, I ended up doing a numerical analysis. I created 2 Gaussian beams, subtracted the fields, then calculated the total power left. I did this for several separations of the beams to get a plot of contrast defect vs. separation. My simulated Gaussian beams have a FWHM of 1 unit, so the x-axis of the plot below is in units of spot motion normalized by spot size.
Unfortunately, my normalization isn't perfect, so 2 perfectly constructively interfering beams have a total power of 0.3, so my y-axis should all be divided by 0.3.
The actual beam separation that we might expect at the AS port from some ETM motion (of order 1e-6 radians) causing some beam axis shift is of the order 1e-5 meters, while the beam spot size is of the order 1e-3 meters. So, in normalized units, that's about 1e-2. I probably should change the x-axis to log as well, but you can see that the contrast defect for that size beam separation is very small. To make a significant difference in the power recycling cavity gain, the contrast defect, which is the Michelson transmission, should be close to the transmission of the PRM. Since that's not true, I conclude that ETM angular motion leading to PRC losses is not an issue.
I still haven't calculated the effect of ITM motion, nor have I calculated either test mass' angular effect directly on arm cavity power loss, so those are yet to be done, although I suspect that they aren't our problem either.
I think that the PRM moving around, thus causing a loss in recycling gain, is our major problem.
First, how do I conclude that, then some thoughts on why the PRM is moving at all.
theta = 12e-6 radians (ref: oplev plot from elog 9338 last week)
L = 6.781 meters
g = 0.94
a = theta * L /(1-g) = 0.0014 meters axis displacement
w0 = 3e-3 meters = spot size at ITM
a^2/w0^2 = 0.204 ==>> 20% power loss into higher order modes due to PRM motion.
That means 20% less power circulating, hitting the ITMs, so less power going into the arm cavities, so less power buildup. This isn't 50%, but it is fairly substantial, using angular fluctuation numbers that we saw during our PRMI+arms test last week. If you look at the oplev plot from that test, you will notice that when the arm power is high (as is POP), the PRM moves significantly more than when the carrier buildup in the cavities was low. The rms motion is not 12 urad, but the peak-to-peak motion can occasionally be that large.
So, why is that? Rana and I had a look, and it is clear that there is a difference in PRM motion when the IFO is aligned and flashing, versus aligned, but PSL shutter is closed. Written the cavities flash, the PRM gets a kick. Our current theory is that some scattered light in the PRC or the BS chamber is getting into the PRM's OSEMs, causing a spike in their error signal, and this causes the damping loops to push on the optic.
We should think a little more on why the PRM is moving so much more that any other optic while the power is building up, and if there is anything we can do about the situation without venting. If we have to, we should consider putting aluminum foil beam blocks to protect the PRM's OSEMs.
Interesting results. When you compute the effect of ETM motion, you maybe should also consider that moving around the arm cavity axis changes the matching of the input beam with the cavity, and thus the coupling between PRC and arms. But I believe this effect is of the same order of the one you computed, so maybe there is only one or two factors of two to add. This do not change significantly the conclusion.
Instead, the numbers you're giving for PRM motion are interesting. Since I almost never believe computations before I see that an experiment agrees with them, I suggest that you try to prove experimentally your statement. The simplest way is to use a scatter plot as I suggested the past week: you plot the carrier arm power vs PRM optical lever signals in a scatter plot. If there is no correlation between the two motions, you should see a round fuzzy ball in the plot. Otherwise, you will se some non trivial shape. Here is an example: https://tds.ego-gw.it/itf/osl_virgo/index.php?callRep=18918
Oplev servo turned off and sus damping restored. What is kicking up the PRM?
The PRM oscillation stopped by turnig off oplev servo.
Do not turn Oplev Servo on when PRM is missaligned !
Set the PRM OL servo gains to zero until someone can take care of this. Turning off the buttons doesn't help anything if people run the alignment scripts.
C1:SUS-PRM_OLPIT_GAIN 1.0 -> 0
C1:SUS-PRM_OLYAW_GAIN -0.7 -> 0
A few things tonight. Locked both arms simultaneously (IR only). Locked MICH, Locked PRMI, although it doesn't like staying locked for more than a minute or so, and not always that long.
Locking PRCL was possible by getting rid of the power normalization. We need to get some triggering going on for the power norm. I think it's a good idea for after the cavity is locked, but when PRCL is not locked, POP22 is ~0, so Refl33/Pop22 is ~inf. The PRCL loop kept railing at the Limit that was set. Getting rid of the power normalization fixed this railing.
I took some spectra of PRM's oplev, while PRMI was locked, and unlocked. The PRM is definitely moving more when the cavity is locked. I'm not sure yet what to do about this, but the result was repeatable many times (~6 or 7 over an hour or so). The OpLev spectra when PRMI was locked didn't depend too strongly on the PRM's alignment, although I think that's partly because I wasn't able to really get the PRM to optimal alignment. I think POP22I is supposed to get to 7 or so...last week with Koji it was at least flashing that high. But tonight I couldn't get POP22I above 4, and most of the time it wouldn't go above 3. As I was aligning PRM and the circulating SB power increased, POP22I fluctuations increased significantly, then the cavity unlocked. So maybe this is because as I get closer, PRM gets more wiggly. I tried playing 'chicken' with it, and took spectra as I was aligning PRM (align, get some improvement, stop to take spectra, then align more, stop to take spectra....) but usually it would fall out of lock after 1-2 iterations of this incremental alignment and I'd have to start over. When it relocked, it usually wouldn't come back to the same level of POP22I, which was kind of disappointing.
In the PDF attached, pink and light blue are when the PRMI is locked, and red and dark blue are no PRCL feedback. The effect is more pronounced with Pitch, but it's there for both Pitch and Yaw.
Also, I need to relook at my new restore/misalign scripts. They were acting funny tonight, so I'm taking back my "they're awesome, use them without thinking about it" certification.
Is this enhancement of spectrum caused by the lock? Or by the actuation?
If this is also seen with approximately same amount of actuation to PRM POS,
this is just a suspension problem.
If this is only seen with the PRM locked, this is somehow related to the opt-mechanical coupling.