I set up a photodiode (PDA10CF) in the IFO REFL beampath and the Agilent NA is sitting on the east side of the PSL enclosure. This was meant to be just a first look, maybe the PDA10CF isn't suitable for this measurement. The measurement condition was - PRM aligned so we have a REFL beam (DC level = 8.4V measured with High-Z). Both ITMs and ETMs were macroscopically misaligned so that there isn't any cavity effects to consider. I collected noise around 11 and 55 MHz, and also a dark measurement, plots to follow. The optics were re-aligned to the nominal config but I left the NA on the east side of the PSL enclosure for now, in anticipation of us maybe wanting to tune something while minimizing a peak.
Attachment #1: Results of a coarse sweep from 5 MHz to 100 MHz. The broadband RIN level is not resolvable above the dark noise of the photodiode, but the peaks at the modulation frequencies (11 MHz, 55 MHz and 29.5 MHz) are clearly visible. Not sure what is the peak at ~44 MHz or 66 MHz. Come to think of it, why is the 29.5 MHz peak so prominent? The IMC cavity pole is ~4kHz so shouldn't the 29.5 MHz be attenuated by 80dB in transmission through the cavity?
Attachment #2: Zoomed in spectra with finer IF bandwidth around the RF modualtion frequencies. From this first measurement, it seems like the RIN/rad level is ~10^5, which I vaguely remember from discussions being the level which is best achieved in practise in the 40m in the past.
Check the RAM due to the EOM? Perhaps the pointing / polarization control into the EOM got degraded.
Tried a bunch of things tonight.
One possibility is that the arm buildup is exerting some torque on the ITMs, which can also change the PRC cavity axis - as the buildup increases, the dominant component of the circulating field in the PRC comes from the leakage from the overcoupled arm cavity. We used to DC couple the ITM Oplev servos when locking the PRMI. The TRX level of 1 corresponds to ~5W of circulating power in the arm cavity, and the static radiation pressure force due to this circulating power is ~30 nN, rising up to 300nN as the TRX level hits 10. So for 1mm offset of the spot position on the ITM, we'd still only exert 300 pN m of torque. I don't see any transient in the Oplev error signals when locking the arm cavity as usual with POX/POY, but on timescales of several seconds, the Oplev error point shows ~3-5 urad of variation.
Some short notes, more details tomorrow.
Attachment #1 shows time series of some signals, from the time I ramp of ALS CARM control to a lockloss. With this limited set of signals, I don't see any clear indication of the cause of lockloss, but I was never able to keep the lock going for > a couple of mins.
Attachment #2 shows the CARM OLTF. Compared to last week, I was able to get the UGF a little higher. This particular measurement doesn't show it, but I was also able to engage the regular boost. I did a zeroth order test looking at the CM_SLOW input to make sure that I wasn't increasing the gain so much that the ADC was getting saturated. However, I did notice that the pk-to-pk error signal in this locked, 5kHz UGF state was still ~1000 cts, which seems large?
Attachment #3 shows the DTT measurement of the relative gains of DARM A and B paths. This measurement was taken when the DARM_A gain was 1, and DARM_B gain was 0.015. On the basis of this measurement, DARM_B (=AS55) sees the excitation injected 16dB above the ALS signal, and so the gain of the DARM_B path should be ~0.16 for the same UGF. But I was never able to get the DARM_B gain above 0.02 without breaking the lock (admittedly the lockloss may have been due to something else).
Attachment #4 shows a zoomed in version of Attachment #1 around the time when the lock was lost. Maybe POP_YAW experienced too large an excursion?
Some other misc points:
Yesterday I plugged the geophone and accelerometer output into the ADC, rather than the SR785, so I could collect for longer and take more data at once.
As per Rana's suggestion, I am also now taking the geophone output after the first op-amp in the circuitry following the geophone (a low-noise op-amp, OPA227). It acts as a buffer so I'm not just measuring other local noise sources (which explains why the geophone noise curve sort of matched the SR785 noise curve in my old plots).
With these changes, I remeasured the accelerometer and geophone noises as well as collected an ASD of a geophone sitting on the STACIS in open loop operation. I also looked up the noise specs for the various op-amps in the geophone pre-amp and high voltage board; everything I found, I added in quadrature to come up with an approximate op-amp noise value for the STACIS. All of this is plotted below:
I left the y-axis in V/rtHz instead of converting it to m/s/rtHz so that the op-amp noise could be compared to the other noises. All sensor data was taken with the sensors horizontal (noise data taken in granite and foam).
The accelerometer and geophone noise still appear to be similar, and the op-amp noise, at least according to specs, is low compared to the other noises. This implies there's not much to gain from switching the geophones with accelerometers nor with swapping out the op-amps for lower-noise components (unless the ones I couldn't find specs for were high-noise, though it seems like mainly low-noise components were used).
Looks like you're just measuring the ADC noise. You should add ADC noise to your plot. To compare the geophones with the accelerometers, you have to correct for the preamp gain and plot them both in the same units.
To get above the ADC noise you can use an SR560 preamp. (AC Coupled, G = 100)
Based on Rana's comment I have gone through and moved all of the corner frequencies for the high pass filters in the SUS damping controllers to 30 Hz. I did this for all optics (MC1, MC1, MC3, BS, ITMX, ITMY, PRM, SRM, ETMX, ETMY) all degrees of freedom (POS, PIT, YAW, SIDE).
Rana also suggested I turn off all of the BounceRoll filters until we get a chance to tune those individually for all the suspensions.
Finally, I normalized the MC SUSXXX filter banks to look just like all the other suspensions.
All damping filter banks for all degrees of freedom for all single suspensions should all be the same now (modulo the differences in the BounceRoll filters, which are now turned off).
This is getting closer, but with the whitening left OFF and the cts2um filter also OFF, none of the suspensions are working correctly. I'm shutting down all the watchdogs until someone gets around to setting the damping gains and filters correctly.
I'm attaching a screenshot of some of the problems I see so far with MC3.
I'm going to try to get the MC suspensions working OK for tonight so that we can use them for the PRMI locking work.
Update #1: None of the MC SUS DAQ channels are found by dataviewer....SUS debugging speed reduced by 10x. Tue Jul 05 21:38:17 2011
Update #2: POS/PIT/YAW BIAS sliders now seem to work, but are ~1000x too weak to do anything. Tue Jul 05 21:41:38 2011
I tried to fix all of the problems that I could identify in this screen shot:
Attachment #1 shows the optical setup currently being used to send the LO field with RF sidebands on it to the air BHD setup.
Attachment #2 shows spectra of the relative phase drift between LO and IFO output field (from the Dark Michelson).
Attachment #3 shows the signal magntiude of the signals used to make the spectra in Attachment #2, during the observation time (10 minutes) with which the spectra were computed. The dashed vertical lines denote the 1%, 50% and 99% quantiles.
Attempts to close a feeddback loop to control the homodyne phase:
After more trials, I think the phase tracker part used to provide the error signal for this scheme needs some modification for this servo to work.
Attachment #1 shows a block diagram of the control scheme.
I was using the "standard" phase tracker part used in our ALS model - but unlike the ALS case, the magnitude of the RF signal is squished to (nearly) zero by the servo. But the phase tracker, which is responsible for keeping the error signal in one (demodulated) quadrature (since our servo is a SISO system) has a UGF that is dependent on the magnitude of the RF signal. So, I think what is happening here is that the "plant" we are trying to control is substantially different in the acquisition phase (where the RF signal magnitude is large) and once the lock is enabled (where the RF signal magnitude becomes comparitively tiny).
I believe this can be fixed by dynamically normalizing the gain of the digital phase tracking loop by the magnitude of the signal = sqrt(I^2 + Q^2). I have made a modified CDS block that I think will do the job but am opting against a model reboot tonight - I will try this in the daytime tomorrow.
I'm also wondering how to confirm that the loop is doing something good - any ideas for an out-of-loop monitor? I suppose I could use the DCPD - once the homodyne phase loop is successfully engaged, I should be able to drive a line in MICH and check for drift by comparing line heights in the DCPD signal and RF signal. This will requrie some modification of the wiring arrangement at 1Y2 but shouldn't be too difficult...
The HEPAs, on the PSL table and near ITMY, were dialled down / turned off respectively, at ~8pm at the start of this work. They will be returned to their previous states before I leave the lab tonight.
[Koji, Steve, Kiwamu, Alberto]
- This afternoon we installed a few new optics on the BS table: GR_PBS, GRY_SM2, GRY_SM1.
- We pulled up the cables so that we had more freedom to move one of the cable towers farther South.
- Then we re-leveled the table. PRM OSEMs were adjusted to be nominal insertions.
- Koji released the earthquake stops on BS but the readout of the OSEMs was apparently frozen on the MEDM screens.
Initially we thought it was a software problem. a nuclear reboot didn't solve it. We spent the following three hours investigating the cause.
Eventually it turned out that the earthquake stops on BS weren't actually fully released.
We opened the tank and accessed to BS. Releasing the earthquake stops in full solved the issue. The OSEMs readout went back to normal.
July 29 Thu [Steve, Alberto, Kiwamu, Koji]
We placed some optics in the BS chamber.
The chambers are ready to be pumped down on Friday once the heavy door is placed.
- Clean room work
- In the chamber
- After closing the chamber
- Koji released the earthquake stops on BS but the readout of the OSEMs was apparently frozen on the MEDM screens.
Initially we thought it was a software problem. a nuclear reboot didn't solve it. We spent the following three hours investigating the cause.
Eventually it turned out that the earthquake stops on BS weren't actually fully released.
More photos were taken. Will post Monday, because too hungry now.
Have eaten. Here's a PDF with all the pictures to-date, along with a few notes.
Also, the first thing we did on Saturday was to fix the yaw pointing of MMT1, so that the beam hit the center of MMT2. Then we had to touch PZT2 to compensate. We put the iris target on the BS, and adjusted PZT2 until the beam went nicely through there. The resulting beam looks good on the SRM, and teh beam is still hitting the AS camera.
I'm back to terrorize the PSL table again. The pictures I took yesterday were rubbish--today I'm using a clamp that Steve was nice enough to loan me. I'm starting now, at 10:09 am.
See Attachment #1 for the projected control signal ASDs. The main assumption in the above is that all other control loops can be low-passed sufficiently such that even with anti-dewhitening, we won't run into saturation issues.
DARM control loop:
De-whitening and Anti-De-whitening:
It remains to add the control signals for Oplev, local damping, and ASC to make sure we have sufficient headroom, but given that current projections are predicting using up only ~1000cts of the ~23000cts (RMS) available from the DAC, I think it is likely we won't run into saturations. Need to also figure out what the implication of the reduced actuation range will be on handling the locking transient.
I think "OLG" trace is not labeled right; it would be good to see the actual OLG in addition to whatever that trace actually is.
Based on the first plot, however, my conclusion is that:
I was a bit hasty in posting the earlier plots. In the earlier plot, the "OLG" trace was OLG * anti dewhitening as Rana pointed out.
Here are the updated ones, and a cartoon (Attachment #5) of the loop topology I assumed. I've excluded things like violin filters, AA/AI etc. The overall gain scaling I mentioned in the previous elog amounts to changing the optical sensing response in this cartoon. I now also show the DARM suppression (Attachment #4) for this OLG and the DARM linewidths for RSE. I don't think the conclusions change.
Note that for Signal Recycling, which is what Kevin tells us we need to do, there is a DARM pole at ~150 Hz. I assume we will cancel this in the digital controller and so can achieve a similar OLG shape. This would modify the control signal spectrum a little around 150Hz. But for a UGF on the loop of ~150 Hz, we should still be able to roll-off the control signal at high frequencies and so the RMS shouldn't be dramatically affected.
Steve is looking into acquiring 4.5kohm Vishay Wirewound resistors with 1% tolerance. Plan is to install two in parallel (so that we get 2kohm effective resistance) and then snip off one once we are convinced we won't have any actuation range issues. Do these look okay? They're ~$1.50ea on mouser assuming we get 100. Do we need the non-inductive winding?
Good question! I've never calculated what the resonance frequency would be if had an inductive resistor with our cable capacitance (~50 pF/m I guess).
I connected to the serial port using screen (through Terminal) and using Arduino's serial monitor and basically received the same strings that were received through python, so it's not a python issue. Checked the other TC 200 module and was also receiving nonsense, but it was all question marks instead of mostly K's and ['s.
This rules out a few possible reasons for the weird data. Next steps are to set up and configure the Raspberry Pi (which has been interfaced before) and see if the problem continues.
I acquired several spare OSEMs (in unknown condition) from Paco. They are stored alongside the shipment from UF.
[Jenne, Koji, Rana]
Thanks to turning off the AS55 analog whitening as well as the 1k:6k lead filter that Koji put into Darm's FM7, the DARM transition was more stable early in the evening.
The AS55 gain and offset did not change noticeably when we switched the AA on or off (switching happened while *not* using AS for any feedback). Earlier in the evening, we did also check what happened with PRMI and REFL33 AA on vs. off, and REFL33 did have a many tens of counts offset on both the I and Q input channels. I have turned the AA filters back on, but run LSCoffsets before trying to lock.
I'm not sure what was up, but somehow I couldn't lock the PRMI for about half an hour or so. Very frustrating. Eventually after futzing around, I was able to get it to lock with REFL33 in PRMI-only, and after that it worked again in PRFPMI with REFL165.
With FSS slow around 0.5, MC has been a bit fussy the last hour. Also frustrating.
Later on in the evening, I started taking out a bunch of the "sleep" commands from the up script, and many of the "press enter to continue" spots, but I think it might be moving too fast. That, or I'm just not catching where I have too much gain. Anyhow, near the middle/end of the CARM transition I am getting severe gain peaking at several hundred Hz. I think I need to use a lower final gain.
So, progress on DARM, but maybe a little more fine-tuning of CARM needed.
Here's a DARM loop measurement, taken after both CARM and DARM were RF-only:
I have modified the DARM model from elog 11133, to include the fact that these are digital filters.
I have also extracted the data from elog 11143, and it together with the model.
The modeled loop has an arbitrary gain factor, to make it have the same 234Hz UGF as the measured data.
The modeled loop includes:
There is a 1.5 degree phase discrepancy at 100Hz, and an 11 degree phase discrepancy at 900Hz, but other than that, the modeled and measured loops match pretty well.
For the measured frequencies, here are the residuals:
- Today the spots were moving more than the usual. The OPLEV screens showed that the spots are too much off from the center.
- Each vertex OPLEVs were checked and OPLEV wonderland was discovered: Other than the usual misalignment of the spots,
it was found that PRM/ITMX/ITMY beams were clipped somewhere in the paths, BS/PRM oplevs had many loose components
including the input lenses (they are still clamped by a single dog clamp THIS SHOULD BE FIXED ASAP).
- On the ITMY table there were so many stray optics. They were removed and put on the wagon next to the ITMY table.
THIS SHOULD BE CLEARED ON THE WEDNESDAY CLEANING SESSION.
- During this OPLEV session, LSCoffset nulling was run.
- After the OPLEV session, the locking became really instantaneous. We wonder which of the OPLEV cleaning, LSC offset nulling,
and the usual seismic activity decay in the evening was effective to make it better.
- Initially the lock was attempted with REFL33I/Q and some ~10sec lock streches were obtained. During this lock,
the optical gain of AS55Q was measured in relative to REFL33Q. In deed they were calibrated to be the same
gain at the input matrix.
- After the MICH signal source was switched to AS55Q, the lock streches became more regular and the minutes long.
We precisely tuned the phase of AS55 and REFL55 in terms of the differential excitation of ITMX/Y using lockin (FREQ 250, AMP 1000).
- We noticed that the AS port spot with AS55Q MICH was darker than the REFL33Q MICH. This suggests the existence of residual offset
in REFL33Q. In deed we observed +30cnt offset in REFL33Q when the PRMI is locked with AS55Q MICH.
- Phases and relative gains of the signals were as follows:
PRCL: REFL33I 1.00 =REFL55I +0.4
MICH: AS55Q 29deg x1.00 = REFL33Q -14deg x1.00 = REFL55Q 118deg 0.03?
- We tried to lock PRMI with AS55Q. The acquisition was not as easy as that with REFL33I. This might be from the saturation of the
REFL55I signal. This configuration should tested with different whitening gain. Handing off using the input matrix went well once the
lock was obtained by REFL33I.
- Handing off from AS55Q to REFL55Q was not successful.
- At the end of the session, Jenne told me that the POP PD still has a large diameter beam. (and a steering mirror with a peculiar reflection angle.)
==> THIS SHOULD BE FIXED ASAP because the normalization factor can be too much susceptible to the misalignment of the spot.
- The configuration of the filters:
PRCL FM3/4/5/6 G=+0.05 / NORM 0.04 POP110I
MICH FM4/5 G=-5.00 / NORM 0.01 POP110I (or none)
I locked each arm, and the Michelson last night, no problems after I increased the Yarm gain from 0.1 to 0.2 . I checked the green beam alignment just before going home, and both of the green beams are locking on ~03 or 04 modes, so aligning them is on the list for today.
I now think the excess noise in this circuit could be coming from the KEPCO switching power supply (in fact, the supplies are linear, and specd for a voltage ripple at the level of <0.002% of the output - this is pretty good I think, hard to find much better).
All component references are w.r.t. the schematic. For this test, I decided to stuff a fresh channel on the board, with new components, just to rule out some funky behavior of the channel I had already stuffed. I decoupled the HV amplifier stage and the Acromag DAC noise filtering stages by leaving R3 open. Then, I shorted the non-inverting input of the PA95 (i.e. TP3) to GND, with a jumper cable. Then I measured the noise at TP5, using the AC coupling pomona box (although in principle, there is no need for this as the DC voltage should be zero, but I opted to use it just in case). The characteristic bump in the spectra at ~100Hz-1kHz was still evident, see the bottom row of Attachment #1. The expected voltage noise in this configuration, according to my SPICE model, is ~10 nV/rtHz, see the analysis note.
As a second test, I decided to measure the voltage noise of the power supply - there isn't a convenient monitor point on the circuit to directly probe the +/- HV supply rails (I didn't want any exposed HV conductors on the PCB) - so I measured the voltage noise at the 3-pin connector supplying power to the 2U chassis (i.e. the circuit itself was disconnected for this measurement, I'm measuring the noise of the supply itself). The output is supposedly differential - so I used the SR785 input "Float" mode, and used the Pomona AC coupling box once again to block the large DC voltage and avoid damage to the SR785. The results are summarized in the top row of Attachment #1.
The shape of the spectra suggests to me that the power supply noise is polluting the output noise - Koji suggested measuring the coherence between the channels, I'll try and do this in a safe way but I'm hesitant to use hacky clips for the High Voltage. The PA95 datasheet says nothing about its PSRR, and seems like the Spice model doesn't include it either. It would seem that a PSRR of <60dB at 100 Hz would explain the excess noise seen in the output. Typically, for other Op-Amps, the PSRR falls off as 1/f. The CMRR (which is distinct from the PSRR) is spec'd at 98 dB at DC, and for other OpAmps, I've seen that the CMRR is typically higher than the PSRR. I'm trying to make a case here that it's not unreasonable if the PA95 has a PSRR <= 60dB @100 Hz.
So what are the possible coupling mechanisms and how can we mitigate it?
What do the analog electronics experts think? I may be completely off the rails and imagining things here.
Update 2130: I measured the coherence between the positive supply rail and the output, under the same conditions (i.e. HV stage isolated, input shorted to ground). See Attachment #2 - the coherence does mirror the "bump" seen in the output voltage noise - but the coherence is. only 0.1, even with 100 averages, suggesting the coupling is not directly linear - anyways, I think it's worth it to try adding some extra decoupling, I'm sourcing the HV 10uF capacitors now.
Yes. The datasheet has a recommendation circuit with 10uF caps. Companies are careful to show reproducible, reliably functional circuit examples on datasheets. So, if the caps are there you should try to replicate the design.
Additional bypass capacitors? I use 0.1 uF, 700V DC ceramic capacitors as bypass capacitors close to the leads of the PA95, as is recommended in the datasheet. Can adding a 10uF capacitor in parallel provide better filtering? I'm not sure if one with compatible footprint and voltage rating is readily available, I'll look around.
true. also try to choose a cap with a goow high frequency response. In the Electronics Noise book by Ott there's some graph about this. I bet you good do a Bing search and also find something more modern. Basically we want to make sure that the self resonance is not happening at low frequencies. Might be tought to find one with a good HF response, a high voltage rating, and > 1uF.
I'm still having issues with the STACIS oscillating uncontrollably with the slightest extra vibration, but with some more added weight both x and z direction are stable if you don't disturb the setup.
I took more transfer functions of the STACIS. In the last data I took Jenne pointed out that the geophone signals were not correlated well with the driving signal, so I increased the amplitude of the driving signal and am looking in x and y too instead of just z.
Details of the driving signal: 25 mV, swept sine from 0.1 to 100 Hz from the SR785.
NOTE: The data below was all transferred from the SR785 using netGPIB, which works fine, if anyone was interested in using it.
Open loop in the y direction, taken with the y geophone (magnitude on top, phase on bottom):
Open loop in the x direction, taken with the x geophone (with some extra weight to try to make the closed loop more stable):
Open loop in the x direction, taken with accelerometer instead of geophone:
The vac controls system is going down for migration from Python 2.7 to 3.4. Will advise when it is back up.
I've converted all the vac control system code to run on Python 3.4, the latest version available through the Debian package manager. Note that these codes now REQUIRE Python 3.x. We decided there was no need to preserve Python 2.x compatibility. I'm leaving the vac system returned to its nominal state ("vacuum normal + RGA").
Five Agilent pressure gauges were delivered to the 40m. It is stored with the controller and cables in the office area. This completes the inventory for the gauge replacement - we have all the ordered parts in hand (though. not necessarily all the adaptor flanges etc). I'll see if I can find some cabinet space in the VEA to store these, the clutter is getting out of hand again...
in addition, the spare gate valve from LHO was also delivered today to the 40m. It is stored at EX with the other spare valves.
It is stored along with the cables that arrived a few weeks ago, awaiting the gauges which are now expected next week sometime.
I'm trying to get more of the simplant models running so that we (me and Sasha Surf) can get a full real-time cavity simplant running. As I reported last week, c1spx is running again on c1iscex.
The two new simplant models are c1sup, which holds the simplant for ITMX, and c1lsp, which holds the IFO simplant, specifically the one we're working on for XARM.
Here's the relevant info:
model host dcuid cpu
c1spx c1iscex 61 4
c1sup c1sus 62 6
c1lsp c1lsc 60 6
c1spx and c1sup will be running the sus_single_plant parts for ETMX and ITMX simplant. All the simplant suspension channels will be names "SUP" (as opposed to "SUS" for control).
c1lsp is now running, but c1sup won't run for unknown reasons. The c1sup model is not very complicated, and in fact is more-or-less identical to c1spx. It compiles and installs and even loads, but it completely unresponsive after loading. Unfortunately I've had enough CDS bullshit for today, so I'll try to figure out what's going on tomorrow.
Sanjit has been working today on trying to get the OAF coefficients to save properly. Alex got us most of the way, but right now it's looking like the filter that is being saved is totally constant (all the values are the same). We're poking around trying to figure out why this is.
Also, we're starting again (as we should have been for the last week or so since Alex came in to help us) to check in the TOP_XFCODE whenever we make changes to it, and when we recompile the front end code.
We are manually restarting assepics, but the terminal logs us out after sometime and ass may crash. I set autologout=0 in the terminal for the time being. Once the testing process is over, assepics will start automatically when the computer is turned on, so we wont have to worry about this.
(if ass crashes tonight, it is not unexpected!)
I made some changes in the code (all commented in the installed and SVN version) to print the filter coefficients. I got crazy output. Sometimes memory bugs lead to such crazy behavior. So far I could not find any bugs, but will have to spend more time on it.
I made some changes in the code (all commented in the installed and SVN version) to print the filter coefficients. I got crazy output. Sometimes memory bugs lead to such crazy behavior. So far I could not find any bugs, but will have to spend more time on it
Something strange was going on in the OAF code, printf would print a double precision number in %f format but not in %lf or %e format!
Since we know this problem now, we can move forward, but it will be important to know why printf was restricted and if there are other such constraints which we should remember while making changes in the codes.
1) Filled in the C1SUS_BS_OLMATRIX properly so as to make the BS oplev work for Steve.
2) Turned on the ITMX damping. Apparently it had tripped this morning, possibly due to work in the lab area.
3) The ETMX FE controller (c1scx) had ADC timed out and died sometime around 8:30 am. The c1x01 (the IOP on the ETMX computer) was also indicating a FB status error (mismatch in DAQ channels).
The reported error in dmesg on c1iscex was:
[1628690.250002] c1spx: ADC TIMEOUT 0 3541 21 3605
[1628690.250002] c1scx: ADC TIMEOUT 0 3541 21 3605
Just to be safe, I rebuilt the c1x01 and c1scx models, ran ./activateDAQ.py, and used the scripts killc1spx, killc1scx, and killc1x01.
I finally restarted the process with startc1x01, startc1scx, and startc1spx. Everything is currently alive and indicating all green.
I am putting a little bit of brain power into reviving the ASS, and I want to write down what the motivation is, and what the short and long-term plans are.
The IFO IR is not optimally aligned right now. While we were at atmosphere, we should have taken the time to align the green beams to the arms until the greens were both resonating TEM00. We were lazy, and excited to pump down, so we decided that locking on higher order modes was good enough to ensure the beams came out of vacuum. Once we were pumped down, ITMY and ETMY were aligned to the green beam axis. Then, the IR was aligned to this new Yarm cavity axis. This would have been okay, and pretty close, if we had aligned the green beam all the way (used only the outside steering mirrors to resonate TEM00, after the cavity mirrors were aligned for flashing IR). After the IR was aligned to the Ygreen axis, the rest of the IFO was aligned to this slightly-incorrect input pointing. We want to measure the IR spot positions on ITMY and ETMY so that we can tweak the input pointing until we hit the center of both ITMY and ETMY. Then we will align Ygreen's input pointing to this proper IR cavity axis. The rest of the IFO alignment will also have to be redone. This calls for a functioning A2L system, so the measurement part of the ASS.
The immediate motivation for measuring the spot positions is that the current Xarm IR axis is not at all very close to the Xgreen axis. The other day while we were fixing up the Xend table (note in elog 8162), we found that the TRX beam to the TRX PD and the trans camera was clipped on the 2" harmonic separator (which is the first optic that the transmitted IR beam sees on the end tables). It was clipping on the left side of the optic, if you are looking at the face of the optic. This is the more east-erly side of the optic. We moved that optic to the side so that we were not clipping. Then, today when Manasa was trying to align the Xgreen beam, she found that it was clipping on the right side of the harmonic separator, the more west-erly side. I remember seeing that the green beam was roughly centered on the harmonic separator when we were at atmosphere, so this clipping is certainly due to Yuta, Evan and my moving of the harmonic separator. Since the end green steering optics are not very orthogonal in angle/translation, it is very difficult to translate the beam by a significant amount. If we keep the current IR alignment, which surely isn't good anyway (you can see on the ETMXF camera that the beam isn't centered), we would probably have to move the Xgreen steering optics, which would be a total pain. It seems that the better plan is to leave them where they are, and get the IR pointing in the correct direction, and move the harmonic separator back to where it was originally.
Short term (< few days):
Write the arm section of the existing MeasureSpotPositions.py script (in ....../scripts/ASS). Write a wrapper script that, like ...../scripts/ASS/MC/mcassMCdecenter, calls sets up the lockins, runs MeasureSpotPositions.py, and calculates the calibrated spot positions. Use this information to hand tweak the input pointing, then realign the cavities to the new IR, and the greens to the new cavity axes.
All of the infrastructure for this is already in place in the c1ass model. The only drawback to the current situation is the LSC output matrix only has one row for ASS, and so only one cavity can be measured at a time. To make things faster, we could consider increasing the size of the LSC output matrix so that the 2 arms could be measured simultaneously. This change is low priority for now.
Make the full ASS system work.
A major change from the current situation is that the current ASS cannot actuate on the input pointing (TT1 and TT2 for Yarm, BS for Xarm). We want a low bandwidth servo to force the input beam to follow the cavity axis. Implementing this will require some changes to the ASS model.
Remeasure sensing matrix, test system.
I have modified the MeasureSpotPositions.py script to accept the arms as valid cavities (it used to give an error "Sorry, this only works for MC right now").
There is still no wrapper script to turn on lockins and turn them off after the measurement, so I have not tested the arm A2L yet. But I should be able to tomorrow, or whenever the IFO is next available.
* Write the wrapper script (analog of mcassMCdecenter).
* Fix arm assOff, assDown, assOn, assUp scripts to match the current channel names (which were changed long ago to be human-readable, versus mysterious numbers).
Andri and I mounted the Raicol Crystal #724 in one of the new Covesion Ovens. The procedure was the same as before - see elog entry here.
There was one issue - the glass plate that goes on top of the crystal is coated on one side with ITO (Indium-Tin Oxide) and it's not 100% certain that this was mounted in the correct orientation. It is virtually impossible to tell which side of the glass is coated.
The base plate of the oven was tapped for an M3 hole. We retapped it for an 8-32 and bolted it to a post and that one of the New Focus 4-axis translation stage. The assembly is currently bolted to the PSL table, awaiting use.
I mounted the new projector to the pipe where the old projector was attached. The mounting hardware wasn't designed for attaching to a pipe, but with Steve's help I mounted the projector. The projector is angled away from the area of the wall designated as the screen, and I am going to meet with Steve Monday to fix this.
Because of the network interference we've had from the CLIO system for the past 3-4 days, I asked the guys to remove
the test stand from the 40m lab area. It is now in the 40m control room. Since it needed an ethernet connection to get out
for some reason we've let them hook into GC. Also, instead of using a real timing signal slaved to the GPS, Jay suggested
just skipping it and having the Timing Slave talk to itself by looping back the fiber with the timing signal. Osamu will enter
more details, but this is just to give a status update.
I moved the RCG to the advLigoRTS-2.5 tag:
controls@c1iscey ~ 0$ ls -al /opt/rtcds/rtscore/release
lrwxrwxrwx 1 controls 1001 19 Jul 30 12:02 /opt/rtcds/rtscore/release -> tags/advLigoRTS-2.5
controls@c1iscey ~ 0$
There are only very minor differences between what we were running on the the 2.5 branch. I have NOT rebuilt all the models yet.
I was hoping that there was something in the tagged release that might fix this hard-crash-on-filter-load issue that we're seeing in the c1tst model. It didn't. Still have no idea what's going on there.
I moved the RCG to the advLigoRTS-2.5 tag
After that RFM -> OAF communication through PCIE became bad again. Inside CommData2.c cache flushing is not allowed
// If PCIE comms show errors, may want to add this cache flushing
if(ipcInfo[ii].netType == IPCIE)
clflush_cache_range (ipcInfo[ii].pIpcData->dBlock[sendBlock][ipcIndex].data, 16);
As a result, a significant part of MC_F and other signals is lost during RFM -> OAF transmission (270 - 330 out of 2048 per second)
Last time when I replaced 0 for 1, it suspended SUS machine because of the code bug. Alex modified a couple of files in the old version and it started to work. Do you know if this bug is fixed in the new version?
We moved chiara to 1X7 above nodus and powered with same UPS from a battery backed port. The UPS is at 40% load capacity. The nameserver and nfs came back online automatically on boot up.