40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 29 of 344  Not logged in ELOG logo
IDdown Date Author Type Category Subject
  15895   Wed Mar 10 15:00:16 2021 gautamSummaryIMCIMC free swinging prep

Did you fix this issue? It is helpful to post a screenshot of the offending MEDM screen in addition to witticisms. The elog says "sitemap>Shutter>PSL" but I can't find PSL under the dropdown for shutters from Sitemap.

# Moving on to IMC suspensions characterization:
- Closed the PSL shutter, to our suprise, the MC was still locked. We thought this would take away any light from IMC but it doesn't. Maybe the IFO Overview needs to show the schematic in a way where this doesn't happen: "No light from any laser entering the MC but it still is locked with a resonating field inside."

  15894   Wed Mar 10 11:55:22 2021 gautamUpdateSUSPRM suspension suspect

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.

  15893   Wed Mar 10 11:46:22 2021 Paco, AnchalSummaryIMCIMC free swinging prep

[Paco, Anchal]

# Initial State
- MC is locked. The PRM monitor shows some oscillations.
- POP monitor shows light flashing once in a while.
- AS monitor shows one beam along with some other flashing beam around it.
- PRM Watchdog is tripped and shutdown. Everything else is normal except for overload on SRM OpLevs.
- Donatella got a mouse promotion

# Reenabling PRM watchdog:
- The custom reEnablePRMWatchdog.py has been deleted.
- Tried enabling the coil outputs manually and switching watchdog to Normal.
- Again saw large fluctuations like yesterday.
- Probably still the same issue of how current calculated actuations to the coils is in range -600 to -900 and gives and impulse to the optics when suddenly turned on.
- Waiting for PRM to damp down a little.
- Today we plan to change the position bias on PRM C1:SUS-PRM_POS_OFFSET instead of changing biases in pitch and yaw.
- Changing C1:SUS-PRM_POS_OFFSET from 0 to +/- 100 without enabling the coils, it seems upper and lower coils are anticorrelated with just changing the position. So going back to changing pitch.
- Changing C1:SUS-PRM_PIT_OFFSET from 0 -> 780. Switched on watchdog to normal.
- PRM damped down. OpLev errors are also within range.
- Enabled both OpLevs.

# Try locking Y-Arm
- IFO>CONFIGURE>YARM>Restore YARM (POY) using Donatella. See a bunch of python error messages in the call complaining about unable to find some python 2 files. Closed it with Ctrl-C after a stuck state.
- Tried running it on Pianosa, the script ran without error but Y-Arm didn't lock.

# Try locking X-Arm
- IFO>CONFIGURE>XARM>Restore XARM (POX) on Donatella. Again a bunch of OSError messages. Donatella is not configured properly to run scripts.
- Tried running it on Piasnosa, the script ran without error but X-Arm didn't lock.
- This might mean that both arms are misaligned or the BS/PRM is misaligned.
- Moving around C1:SUS-PRM_PIT_OFFSET and C1:SUS-PRM_YAW_OFFSET in order to see if the transmitted light is misalgined. Both arms are set to acquire lock if possible. No luck.

# Hypothesis: The Arm cavity is not aligned within itself (ITM-ETM)
- Will try to lock X-Arm with green light while tuning the ETMX. Hopefully the BS and ITM are aligned so that once we align ETMX to get a green lock, the IR will also lock from the other side.
- Running IFO>CONFIGURE>XARM>Restore XARM (ALS) on Pianosa. No lock, moving forward with tunning ETMX pitch and yaw offsets. Nothing changed. Brought back to same values.

[Rana joined, Anchal moved to Rossa from Pianosa]

# Moving on to IMC suspensions characterization:
- Closed the PSL shutter, to our suprise, the MC was still locked. We thought this would take away any light from IMC but it doesn't. Maybe the IFO Overview needs to show the schematic in a way where this doesn't happen: "No light from any laser entering the MC but it still is locked with a resonating field inside."
- Shutting IMCR shutter (hoping that would unlock the IMC), still nothing happend.
- Tried shutting PSL shutter from Rossa, nothing happened to MC lock still.
- Closed shutter IOO>Lock MC> Close PSL and this unlocked the IMC. Found out that this shutter channel is C1:PSL-PSL_ShutterRqst while the one from the sitemap>Shutter>PSL changes C1:AUX-PSL_ShutterRqst. Some clarification on these medm screens would be nice.
- Disabled the MC autolocked from IOO>Lock MC screen (C1:IOO-MC_LOCK_ENABLE).
- Checked the scripts/SUS/freeswing.py to understand how kick is delivered and optic is left to swing freely.
- Next, we are looking at the C1SUS_MC1 screen to understand what channels to read during data acquisition.
- In sensor matrix, we see INMON for each sensor which is probably raw counts data from the OSEMs. Rana mentioned that OSEM data comes out in units of microns. These are C1:SUS-MC1_ULSEN_OUTPUT (and so on for UR, LL, LR, SD).

- In prep for finishing, recovered Autolocker by first opening the PSL mechanical shutter, then re-enabling the Autolocker. The IMC lock didn't immediately recover, and we saw some fuzz on the PSL-FSS_FAST trace, so we closed the shutter again, waited a minute, then re-opened it and MC caught its lock.
 

  15892   Wed Mar 10 00:32:03 2021 gautamUpdateLSCPRFPMi

The interferometer can nearly be locked again. I was unable to fully hand off control from ALS-->RF, I suspect I may be using the wrong sign on the AO path (or some such other sub-optimal CM board settings). I'll hook up the SR785 and take some TFs tomorrow, that should give more insight into what's what. With the arms held off resonance, the PRMI acquires lock nearly instantly (REFL165 I for PRCL, REFL165 Q for MICH), and can stay locked nearly indefinitely, which is what I need so I can get the RF lock going. However the sensing matrix (for vertex DoFs, arms held off resonance) still makes no sense to me. The MICH loop has ~50 Hz UGF and the PRCL loop ~150 Hz. I think the MICH loop shape can be optimized a little for better low frequency suppression, but this isn't the show-stopper at the moment. For record-keeping, the ALS performance was excellent and other subsystems were nominal tonight.

  15891   Tue Mar 9 18:49:28 2021 YehonathanUpdateSUSOSEM testing for SOSs

29 Good OSEMs, of which 1 is questionable (089) with PD voltage of 1.5V, 5 need some work (pigtailing, replace/remove/add screws). We have 4 pigtails. Schematics.

20 OK OSEMs (Slightly off-centered LED spot), of which 3 need some work (pigtailing, replace/remove/add screws).

13 Bad OSEMS (Way off-centered LED spot)

2 Defunct OSEMs

-------

Ed: KA
Good: 23 complete OSEMs +  5 good ones, which need soldering work (there are 4 pigtails and take one from a defunct OSEM).
OK:  Use good 7 OSEMs for the sides. And keep some functional OSEMs as spares.

 

  15890   Tue Mar 9 16:52:47 2021 JonUpdateCDSFront-end testing

Today I continued with assembly and testing of the new front-ends. The main progress is that the IO chassis is now communicating with the host, resolving the previously reported issue.

Hardware Issues to be Resolved

Unfortunately, though, it turns out one of the two (host-side) One Stop Systems PCIe cards sent from Hanford is bad. After some investigation, I ultimately resolved the problem by swapping in the second card, with no other changes. I'll try to procure another from Keith Thorne, along with some spares.

Also, two of the three switching power supplies sent from Livingston (250W Channel Well PSG400P-89) appear to be incompatible with the Trenton BPX6806 PCIe backplanes in these chassis. The power supply cable has 20 conductors and the connector on the board has 24. The third supply, a 650W Antec EA-650, does have the correct cable and is currently powering one of the IO chassis. I'll confirm this situation with Keith and see whether they have any more Antecs. If not, I think these supplies can still be bought (not obsolete).

I've gone through all the hardware we've received, checked against the procurement spreadsheet. There are still some missing items:

  • 18-bit DACs (Qty 14; but 7 are spares)
  • ADC adapter boards (Qty 5)
  • DAC adapter boards (Qty 9)
  • 32-channel DO modules (Qty 2/10 in hand)

Testing Progress

Once the PCIe communications link between host and IO chassis was working, I carried out the testing procedure outlined in T1900700. This performs a series checks to confirm basic operation/compatibility of the hardware and PCIe drivers. All of the cards installed in both the host and the expansion chassis are detected and appear correctly configured, according to T1900700. In the below tree, there is one ADC, one 16-ch DIO, one 32-ch DO, and one DolphinDX card:

+-05.0-[05-20]----00.0-[06-20]--+-00.0-[07-08]----00.0-[08]----00.0  Contec Co., Ltd Device 86e2
|                               +-01.0-[09]--
|                               +-03.0-[0a]--
|                               +-08.0-[0b-15]----00.0-[0c-15]--+-02.0-[0d]--
|                               |                               +-03.0-[0e]--
|                               |                               +-04.0-[0f]--
|                               |                               +-06.0-[10-11]----00.0-[11]----04.0  PLX Technology, Inc. PCI9056 32-bit 66MHz PCI <-> IOBus Bridge
|                               |                               +-07.0-[12]--
|                               |                               +-08.0-[13]--
|                               |                               +-0a.0-[14]--
|                               |                               \-0b.0-[15]--
|                               \-09.0-[16-20]----00.0-[17-20]--+-02.0-[18]--
|                                                               +-03.0-[19]--
|                                                               +-04.0-[1a]--
|                                                               +-06.0-[1b]--
|                                                               +-07.0-[1c]--
|                                                               +-08.0-[1d]--
|                                                               +-0a.0-[1e-1f]----00.0-[1f]----00.0  Contec Co., Ltd Device 8632
|                                                               \-0b.0-[20]--
\-08.0-[21-2a]--+-00.0  Stargen Inc. Device 0101
                \-00.1-[22-2a]--+-00.0-[23]--
                                +-01.0-[24]--
                                +-02.0-[25]--
                                +-03.0-[26]--
                                +-04.0-[27]--
                                +-05.0-[28]--
                                +-06.0-[29]--
                                \-07.0-[2a]--

Standalone Subnet

Before I start building/testing RTCDS models, I'd like to move the new front ends to an isolated subnet. This is guaranteed to prevent any contention with the current system, or inadvertent changes to it.

Today I set up another of the Supermicro servers sent by Livingston in the 1X6 test stand area. The intention is for this machine to run a cloned, bootable image of the current fb1 system, allowing it to function as a bootserver and DAQ server for the FEs on the subnet.

However, this hard disk containing the fb1 image appears to be corrupted and will not boot. It seems to have been sitting disconnected in a box since ~2018, which is not a stable way to store data long term. I wasn't immediately able to recover the disk using fsck. I could spend some more time trying, but it might be most time-effective to just make a new clone of the fb1 system as it is now.

  15889   Tue Mar 9 15:22:56 2021 KojiSummarySUSPRM suspension

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?

 

  15888   Tue Mar 9 15:19:03 2021 KojiUpdateSUSOSEM testing for SOSs

How were the statistics of them? i.e. # of Good OSEMs, # of OK OSEMs, etc...

  15887   Tue Mar 9 14:37:26 2021 gautamSummarySUSPRM suspension

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.

Quote:

[Paco, Anchal]

- Upon arrival, MC is locked, and we can see light in MON5 (PRM) (usually dark).

  15886   Tue Mar 9 14:30:22 2021 YehonathanUpdateSUSOSEM testing for SOSs

I finished ranking the OSEMS on the OSEM wiki page.

I also moved the OSEM data folder from /home/export/home to /users/public_html and created a soft link instead. I have done the same for the 40m_TIS folder that I uploaded there a while ago.

  15885   Tue Mar 9 12:41:29 2021 KojiSummaryElectronicsInvestigation on the invacuum Dsub cables

I believe the aLIGO style invac dsub cables and the conventional 40m ones are incompatible.
While the aLIGO spec is that Pin1 (in-vac) is connected to the shield, Pin13 (in-vac) is the one for the conventional cable. I still have to check if Pin13 is really connected to the shield, but we had trouble before for the IO TTs https://nodus.ligo.caltech.edu:8081/40m/7864.
(At least one of the existing end cables did not show this Pin13-chamber connection. However, the cables OMC/IMC chambers indicated this feature. So the cables are already inhomogenious.)

- Which way do we want to go? Our electronics are updated with aLIGO spec (New Sat amp, OMC electronics, etc), so I think we should start making the shift to the aLIGO spec.

- Attachment Top: The new coil drivers can be used together with the old cables using a custom DB25 cable (in-air).

- Attachment Mid: The combination of the conventional OSEM wiring and the aLIGO in-vac cable cause the conflict. The pin1 which is connected to the shield is used for the PD bias.

- Attachment Bottom: This can be solved by shifting the OSEMs by one pin.

Notes:
o The aLIGO cables have 12 twisted pair wires, but paired signals do not share a twisted pair.
   --- No. This can't be solved by rotating the connectors.
o This modification should be done only for the new suspension.
   --- In principle, we can apply this change to any SOSs. However, this action involves the vent. We probably want to install the new electronics for the existing suspensions before the vent.
o ^- This means that we have to have two types of custom DB25 in-air cables.
   --- Each cable should handle "Shield wire" from the sat amp correctly.

Related Links:

Active TT Pin Issue
https://nodus.ligo.caltech.edu:8081/40m/7863
and the thread

Hacky solution
https://nodus.ligo.caltech.edu:8081/40m/7869

Photo
https://photos.google.com/u/1/album/AF1QipOEDi7iBdS4EHcpM7GBbv9l6FiJx-Tkt1I2eSFA
Active TT Pin Swapping (December 21, 2012)

TT Wiring Diagram (Wiki)
https://wiki-40m.ligo.caltech.edu/Suspensions/Tip_Tilts_IO

  15884   Tue Mar 9 10:57:06 2021 Paco, AnchalSummaryIMCXARM lock and POX spectra

[Paco, Anchal]

- Upon arrival, MC is locked, and we can see light in MON5 (PRM) (usually dark).

# XARM locking
- Read through "XARM POX" script (path='/cvs/cds/rtcds/caltech/c1/burt/c1configure/c1configureXarm')
- Before running the script, we noticed the PRM watchdog is down, so we manually repeat the procedure from last time, but see more swinging even though the watchdog is active.
- Run a reEnablePRMWatchdogs.py script (a copy of reEnableWatchdogs.py with optics=['PRM']), which had the same effect. 
- We manually disable the watchdog to recover the state we first encountered, and wait for the beam in MON5 to come to rest.
    - The question is; is it fine to lock Xarm with PRM watchdog down?
    - To investigate this, we look at the effect of the offset on the unwatchdog-PRM.
    - Manually change 'PRM_POS_OFFSET' to 200, and -800 (which is the value used in the script) with no effect on the PRM swinging.
- Moving on, run IFO > CONFIGURE > ! (X Arm) > RESTORE XARM (XARM POX), and ... success.

# MC-POX noise spectra
- With XARM locked, open diaggui and take spectra for C1:LSC-POX11_I_ERR_DQ, C1:LSC-POX11_Q_ERR_DQ, C1:IOO-MC_F_DQ
- Lost XARM lock while we were figuring out unit conversions...
    - Assuming 2.631e-13 m/counts (6941) and using 37.79 m (arm length), 1064.1 nm wavelength, we get a calibration factor of 2.631e-13 * c / (2*L*lambda) ~ 0.9809 Hz/count 
    - (FAQ?, how to find/compute/measure the correct calibration factors?)
- Relock XARM, retake spectra. Attachment 1 has plots for POX11_I/Q_ERR_DQ spectrum (cts/rtHz, we couldn't find relevant calibration) and MC_F_DQ in (Hz/rtHz from referring to 15576, we couldn't get the units to show on y scale.)

# MC-POY noise spectra (attempt)
- Now, run IFO > CONFIGURE > ! (Y Arm) > RESTORE YARM (YARM POY), and XARM locks (why?)
    - Could PRM watchdog being down be the cause? 
- Try C1ASS > (YARM) ! More Scripts > ON, and looked at YARM PIT/YAW striptool. 
- C1ASS > (YARM) ! Freeze Outputs, then OFF
- Go back to IFO > CONFIGURE > ! (Y Arm) > Align YARM  (ASS ON: Unfreeze), try running this then Freeze, then OFF Zero Outputs.
- Try RESTORE YARM (POY) again, still not working.
- Try RESTORE YARM ALS, then try again after opening the shutter, but also fail to lock AUX.
    - Is the PRM WD behind some evil misalignment? Will move forward with XARM bc it is happy.

# ARM locking
- Attempted the IFO > CONFIGURE > ! (X Arm) > RESTORE Xarm (XARM ALS) but green failed to lock and we lost XARM lock.
- Try to recover XARM lock... success. It's nice to have a (repeatable) checkpoint.
- Attempt YARM lock. Not successful. It just seems like the lock Triggers are not raised (misalignment?)
    - From C1SUS_ETMY, try changing the bias "C1:SUS-ETMY_YAW_OFFSET" manually to reduce the OPLEV_YERROR. Changed from -47 to -57.
    - Retry YARM lock script... no luck
    - From C1SUS_PRM, try changing the bias "C1:SUS-PRM_PIT_OFFSET" manually to reduce OPLEV errors. Changed from 34 to 22 with no effect, then realized the coil outputs are disabled because the WD is down...
    - So we do the following BIAS changes "C1:SUS-PRM_PIT_OFFSET" = 34 > 770 and "C1:SUS-PRM_YAW_OFFSET" = 134 > -6
    - Enable all Coil Outputs, turn WD to Normal, turn OPLEVs ON, (this time the beam does not swing like crazy).
    - Fine tune BIASes "C1:SUS-PRM_PIT_OFFSET" = 770 > 805  and "C1:SUS-PRM_YAW_OFFSET" = -6 > 65
        - Saw YARM locking briefly, then unlocking, but we stopped once the OPLEV_ERRs no longer overloaded (from magnitudes > 50 to ~ 40).
- Retry YARM lock... no luck
    - From C1SUS_ETMY, try changing the bias "C1:SUS-ETMY_PIT_OFFSET" from -1 to 6. 

Stop for the day. Leave XARM locked, MC locked. 

  15883   Mon Mar 8 22:01:26 2021 gautamUpdateLSCMore PRMI

There are still many mysteries remaining - e.g. the MICH-->PRCL contribution still can't be nulled. But for now, I have the settings that keep the PRMI locked fairly robustly with REFL55I/Q or REFL165I/Q (I quadrature for PRCL, Q for MICH in both cases), see Attachment #1 and Attachment #2 respectively. For the 1f locking, the REFL55 digital demod phase was fine-tuned to minimize the frequency noise (generated by driving MC2) coupling to the Michelson readout (as the Michelson is supposed to be immune) - the coupling was measured to be ~60dB larger at the PRCL error point than MICH. There was still nearly unity coherence between my MC2 drive and the MICH error point demodulated at the drive frequency, but I was not able to null it any better than this. With the PRMI (ETMs misaligned) locked on the 1f signals, I measured Attachment #1 and used it to determine the demod phase that would best enable REFL165_I to be a PRCL sensor. Rana thinks that if there is some subtle effect in the marginally stable PRC, we would not see it unless we do a mode scan (time consuming to set up and execute). So I'm just going to push on with the PRFPMI locking - let's see if the clean arm mode forces a clean TEM00 mode to be resonant in the PRC, and if that can sort out the lack of orthogonality between MICH/PRCL in the 1f sensors (after all, we only care about the 3f signals in as much as they allow us to lock the interferometer). I'll try the PRMI with arms on ALS tomorrow eve.

I have no idea what to make of how the single frequency lines I am driving in MICH and PRCL show up in REFL11 and REFL33 - the signals are apparently completely degenerate (in optical quadrature). How this is possible even though the PRMI remains stably locked, POP22/POP110/AS110 report stable sideband buildup is not clear to me.

  15882   Mon Mar 8 20:11:51 2021 ranaFrogsComputer Scripts / Programsactivate_matlab out of control on Megatron

there were a zillion processes trying to activate (this is the initial activation after the initial installation) matlab 2015b on megatron, so I killed them all. Was someone logged in to megatron and trying to run matlab sometime in 2020? If so, speak now, or I will send the out-of-control process brute squad after you!

  15881   Mon Mar 8 19:22:56 2021 ranaSummarySUSIMC suspension characterization

Herewith, I describe an adventure

  1. Balance the OSEM input matrix using the free swinging data (see prev elogs).
  2. Balance the coil actuation by changing the digital coil gains. This should be done above 10 Hz using optical levers, or some IMC readout (like the WFS). At the end of this process, you should put a pringle vector into the column of the SUS output matrix that corresponds to one of the SUS OSC/LOCKIN screens. Verily, the pringle excitation should produce no signal in MC_F or da WFS.
  3. use the Malik doc on the single suspension to design feed-forward filters for the SUS COIL filter banks. You can get the physical parameters using the design documents on DCC / 40m wiki and then modify them a bit based on the eigenfrequencies in the free swinging data.
  4. Model the 2x2 system which includes longitudinal and pitch motion. Consider how accurate the filters must be to maintain a cross-coupling of < 3% in the 0.5-2 Hz band.
  5. Is this decoupling forsooth still maintained when you close the SUS damping loops in the model? If not, why so?
  6. Make step response measurements of the damping loops and record/plot data. Use physical units of um/urad for the y-axes. How much is the step response cross-coupling?
  7. Consider the IMC noise budget: are the low pass filters in the damping loops low-passing enough? How much damping is demasiado (considering the CMRR of the concrete slab for seismic waves)?
  8. Can we use Radhika's AAA representation to auto-tune the FF and damping filters? It would be very slick to be able to do this with one button click.

gautam: For those like me who don't know what the AAA representation is: the original algorithm is here, and Lee claims his implementation of it in IIRrational is better, see his slides.

  15880   Mon Mar 8 17:09:29 2021 gautamUpdateSUSPRM coil actuators heavily imbalanced

I realized I hadn't checked the PRM actuator as thoroughly as I had the others. I used the Oplev as a sensor to check the coil balancing, and I noticed that while all 4 coils show up with the expected 1/f^2 profile at the Oplev error point, the actuator gains seem imbalanced by a factor of ~5. The phase isn't flat because of some filters in the Oplev electronics I guess. The Oplev loops were disabled for the measurement, and the excitations were small enough that the beam stayed reasonably well centered on the QPD throughout. This seems very large to me - the values in the coil output filter gains lead me to expect more like a ~10% mismatch in the actuation strenghts, and similar tests on other optics in the past, e.g. ETMY, have yielded much more balanced results. I'm collecting some free-swinging PRM data now as an additional check. I verified that all the coils seem actuatable at least, by applying a 500 ct step at the offset of the coil output FM, and saw that the optic moved (it was such a test that revealed that MC1 had a busted actuator some time ago). If the eigenmode spectra look as expected, I think we can rule out broken magnets, but I suppose the magnets could still be not well matched in strength?

  15879   Mon Mar 8 12:54:54 2021 gautamUpdateEquipment loan40m-->Cryo
  1. Busby box
  2. SR554 transformer preamplifier
  15878   Mon Mar 8 12:40:35 2021 gautamSummarytrainingInvestigate how-to XARM locking

For the arm locking, the "Restore Xarm (XARM POX)" script from the "IFO_CONFIGURE" MEDM screen should get you there (I just checked it and it works fine). It is worth getting a hang of the PDH signal chain (read what the script is doing and map it to the signal chain) so you get a feel for where there may be offsets, saturations, what the trigger logic is etc. The LSC overview screen is supposed to be pretty intuitive (if you think it can be improved, I'd love to hear it but please don't change it without documenting) and there are also the webviews of the simulink models (these are RO so feel free to click around, for the LSC the c1lsc model is the relevant one).

  15877   Mon Mar 8 12:01:02 2021 Paco, AnchalSummarytrainingInvestigate how-to XARM locking

[Paco, Anchal]

- Started zoom stream; thanks to whoever installed it!
- Spent some time trying to understand how anything we did last thursday lead to the sensing matrix change, but still cannot figure it out. 
- Tracking back on our actions, at ~10:30 we ran burt Restore with the 08:19/.*snap and in lack of a better suspect, we blame it on that action for now.

# ARM locking??
- Reading (not running) the scripts/XARM/lockXarm.py script and try to understand the workflow. It is pretty confusing that the result was to lock Yarm last time.
- It looks like this script was a copy of lockYarm.py, and was never updated (there's a chance we ran it for the first time last thursday)
- *Is there a script to lock the Arms?* Or should we write one? To write one, we first attempt a manual procedure;
    1. No need to change RFPD InMTRX
    2. All filters inputs / outputs are enabled 
    3. Outputs from XARM and YARM in the Output matrix are already going to ETMX and ETMY
      - Maybe we can have the ARM lock engage by changing the MC directly?
    4. Change C1:SUS-MC2_POS_OFFSET from -38 to -0, and enable C1:SUS-MC2_POS_OFFSET_ON
    5. Manually scan MC2_POS_OFFSET to 250 (nothing happens), then -250, then back to -38 (WFS1 PIT and YAW changed a little, but then returned to their nominal values)
      - Or maybe we need to provide the right gain...
    6. Disabled C1:SUS-MC2_POS_OFFSET_ON (back to nominal state)
    7. Look into manually changing C1:LSC-XARM_GAIN;
      From the command line using python:
      >> import epics
      >> ch_name = 'C1:LSC-XARM_GAIN'
      >> epics.caput(ch_name, 0.155) # nominal = 0.150
      - Could be unrelated, but we noted a slow spike on C1:PSL-FSS_PCDRIVE (definitely from before we changed anything)
      - Still nothing is happening
    8. Changed the gain to 0.175, then back to 0.150, no effect... then 0.2, 0.3 ...
      - Stop and check SUS_Watchdogs (should not have changed?) and everything remains nominal
      - Revert all changes symmetrically.
      - Could we have missed enabling FM1?
      - Briefly lost MC lock, but it came back on its own (probably unrelated)

- Wrap it up for the day. In summary; no harm done to our knowledge.

  15876   Sun Mar 7 19:56:27 2021 AnchalUpdateLSCSensing matrix settings messed with

I understand this mst be frustrating for you. But we did not change these settings, knowingly atleast. We have documented all the things we did there. The only thing I can think of which could possibly change any of those channels are the scripts that we ran that are mentioned and the burt restore that we did on all channels (which wasn't really necessary). We promise to be more vigilant of changes that occur when we are present in future.

Quote:

To my dismay, I found today that somebody had changed the oscillator frequencies for the sensing matrix infrastructure we have. The change happened 2 days and 2 hours ago (I write this at ~1230 on Saturday, 3/6), i.e. ~1030am on Thursday. According to the elog, this is when Anchal and Paco were working on the interferometer, but I can find no mention of these settings being changed. Not cool guys 😒 .

This was relatively easy to track down but I don't know what else may have been messed with. I don't understand how anything that was documented in the elog can lead to this weird doubling of the frequencies.

I have now restored the correct settings. The "sensing matrix" I posted last night is obviously useless.

 

  15875   Sun Mar 7 15:26:10 2021 gautamUpdateLSCHousekeeping + more PRMI
  1. Beam pointing into PMC was tweaked to improve transmission.
  2. AS110 photodiode was re-installed on the AS table - I picked off 30% of the light going to the AS WFS using a beamsplitter and put it on the AS110 photodiode.
  3. Adjusted ASDC whitening gain - we have been running nominally with +18dB, but after Sept 2020 vent, there is ~x3 amount of light incident on the AS55 RFPD (from which the ASDC signal is derived). I want to run the dither alignment servos that use this PD using the same settings as before, hence this adjustment.
  4. Adjusted digital demod phases of POP22, POP110 and AS110 signals with the PRMI locked (sideband resonant). I want these to be useful to debug the PRMI. the phases were adjusted so that AS110_Q, POP22_I and POP110_I contain the signal (= sideband buildup) when the PRMI is locked.
  5. Ran the actuator calibration routine for BS, ITMX and ITMY - i'll try and do the PRM and ETMs as well later.
  6. With the PRMI locked (sidebands resonant), looked at the sideband power buildup. POP22 and POP110 remain stable, but there is some low frequency variation in the AS110_Q channel (but not the I channel, so this is really a time varying transmission of the f2 sideband to the dark port). What's that about? Also unsure about those abrupt jumps in the POP22/POP110 signals, see Attachment #1 (admittedly these are slow channels). I don't see any correlation in the MICH control signal.
  7. Measured the loop shapes of the MICH (UGF ~90 degrees, PM~30 degrees) and PRCL (UGF~110 Hz, PM~30 degreees) loops - stability margins and loop UGFs seem reasonable to me.
  8. Tried nulling the MICH-->PRCL coupling by adjusting the MICH-->PRM matrix element - as has been the case for a while, unable to do any better, and I can't null that line as we expect to be able to.
  9. Not expecting to get anything sensible, but ran some sensing matrix lines (at the correct frequencies this time).
  10. Tried locking the PRMI with MICH actuation to an ITM instead of the BS - I can realize the lock but the loop OLTF I measure with this configuration is very weird, needs more investigation. I may look into this later today evening.

I was also reminded today of the poor reliability of the LSC whitening electronics. Basically, there may be hidden saturations in all the channels that have a large DC value (e.g. the photodiode DC mon channels) due to the poor design of the cascaded gain stages. I was thinking about using the REFL DC channel to estimate the mode-matching into the PRC, but this has a couple of problems. Electronically, there may be some signal distortion due to the aforementioned problem. But in addition, optically, the estimation of mode-matching into the PRC by comparing REFL DC levels in single bounce off the PRM and the PRMI locked has the problem that the mode-matching is degenerate with the intra-cavity loss, which is of the same order as the mode mismatch (a percent or two I claiM). If Koji or someone else can implement the fix suggested by Hartmut for all the LSC whitening channels, that'd give us more faith in the signals. It may be less work than just replacing all the whitening filters with a better design (e.g. the aLIGO ISC whitening filter which implements the cascaded gain stages using single OP27s and more importantly has a 1 kohm series resistance with the input to the op amp (so the preceeding stage never has to drive > 10V/1kohms ~10mA of DC current) would presumably reduce distortion.

  15874   Sat Mar 6 12:34:18 2021 gautamUpdateLSCSensing matrix settings messed with

To my dismay, I found today that somebody had changed the oscillator frequencies for the sensing matrix infrastructure we have. The change happened 2 days and 2 hours ago (I write this at ~1230 on Saturday, 3/6), i.e. ~1030am on Thursday. According to the elog, this is when Anchal and Paco were working on the interferometer, but I can find no mention of these settings being changed. Not cool guys 😒 .

This was relatively easy to track down but I don't know what else may have been messed with. I don't understand how anything that was documented in the elog can lead to this weird doubling of the frequencies.

I have now restored the correct settings. The "sensing matrix" I posted last night is obviously useless.

  15873   Fri Mar 5 22:25:13 2021 gautamUpdateLSCPRMI 1f SB locking recovered

Now that the REFL55 signal chain is capable of providing balanced, orthogonal readout of the two quadratures, I was able to recover the 1f SB resonant lock pretty easily. Ran sensing lines for ~5mins, still looks weird. But I didn't try to optimize anything / do other checks (e.g. actuate MICH using ITMs instead of BS) tonight, and I'm craving the Blueberry pie Rana left me. Will continue to do more systematic tests in the next days.

  15872   Fri Mar 5 17:48:25 2021 JonUpdateCDSFront-end testing

Today I moved the c1bhd machine from the control room to a new test area set up behind (west of) the 1X6 rack. The test stand is pictured in Attachment 1. I assembled one of the new IO chassis and connected it to the host.

I/O Chassis Assembly

  • LIGO-style 24V feedthrough replaced with an ATX 650W switching power supply
  • Timing slave installed
  • Contec DO-1616L-PE card installed for timing control
  • One 16-bit ADC and one 32-channel DO module were installed for testing

The chassis was then powered on and LED lights illuminated indicating that all the components have power. The assembled chassis is pictured in Attachment 2.

Chassis-Host Communications Testing

Following the procedure outlined T1900700, the system failed the very first test of the communications link between chassis and host, which is to check that all PCIe cards installed in both the host and the expansion chassis are detected. The Dolpin host adapter card is detected:

07:06.0 PCI bridge: Stargen Inc. Device 0102 (rev 02) (prog-if 00 [Normal decode])
    Flags: bus master, fast devsel, latency 0
    Bus: primary=07, secondary=0e, subordinate=0e, sec-latency=0
    I/O behind bridge: 00002000-00002fff
    Prefetchable memory behind bridge: 00000000c0200000-00000000c03fffff
    Capabilities: [40] Power Management version 2
    Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
    Capabilities: [60] Express Downstream Port (Slot+), MSI 00
    Capabilities: [80] Subsystem: Device 0000:0000
    Kernel driver in use: pcieport

However the OSS PCIe adapter card linking the host to the IO chassis was not detected, nor were any of the cards in the expansion chassis. Gautam previously reported that the OSS card was not detected by the host (though it was not connected to the chassis then). Even now connected to the IO chassis, the card is still not detected. On the chassis-side OSS card, there is a red LED illuminated indicating "HOST CARD RESET" as pictured in Attachment 3. This may indicate a problem with the card on the host side. Still more debugging to be done.

  15871   Fri Mar 5 16:24:24 2021 gautamUpdateLSCREFL55 demod board re-installed in 1Y2

I don't have a good explanation why, but I too measured similar numbers to what Koji measured. The overall conversion gain for this board (including the +20dB gain from the daughter board) was measured to be ~5.3 V/V on the bench, and ~16000 cts/V in the CDS system (100Hz offset from the LO frequency). It would appear that the effective JMS-1-H conversion loss is <2dB. Seems fishy, but I can't find anything else obviously wrong with the circuit (e.g. a pre-amp for the RF signal that I missed, there is none).

I also attach the result of the measured noise at the outputs of the daughter board (i.e. what is digitized by the ADC), see Attachment #2. Apart from the usual forest of lines of unknown origin, there is still a significant excess above the voltage noise of the OP27, which is expected to be the dominant noise source in this configuration. Neverthelesss, considering that we have only 40dB of whitening gain, it is not expected that we see this noise directly in the digitized signal (above the ADC noise of ~1uV/rtHz). Note that the measured noise today, particularly for the Q channel,  is significantly lower than before the changes were made

  15870   Fri Mar 5 15:32:53 2021 KojiSummaryElectronicsA bunch of electronics received

The parts will be ordered by Koji The components for the additional BIO I/F have been ordered.

  15869   Fri Mar 5 15:31:23 2021 KojiUpdateLSCREFL55 demod board rework

Missed to note: The IF test was done at TP7 and TP6 using pomona clips i.e. brefore the preamp.

 

  15868   Fri Mar 5 15:03:28 2021 gautamSummaryElectronicsA bunch of electronics received

The PCBs for the D1002593 BIO I/F (5pcs ea of D1001050 and D1001266) were received (from JLCPCB) today. idk what the status of the parts (digikey?) is.

Quote:

Received additional front/rear panels. Updated the original entry and Wiki [Link]

  15867   Fri Mar 5 13:53:57 2021 gautamUpdateLSCREFL55 demod board rework

0 dBm ~ 0.63 Vpp. I guess there is ~4dB total loss (3dB from splitter and 1dB from total excess loss above theoretical from various components) between the SMA input and each RF input of the JMS-1-H mixer, which has an advertised conversion loss of ~6dB. So the RF input to each mixer, for 0dBm to the front panel SMA is ~-4dBm (=0.4 Vpp), and the I/F output is 0.34Vpp. So the conversion loss is only ~-1.5 dB? Seems really low? I assume the 0.34 Vpp is at the input to the preamp? If it's after the preamp, then the numbers still don't add up, because with the nominal 6dB conversion loss, the output. should be ~2Vpp? I will check it later.

Quote:

With LO3dBm. RF0dBm, and delta_f = 30Hz, the output Vpp of 340mV and the phase difference is 88.93deg. (Attachment 3/4, the traces were averaged)

  15866   Fri Mar 5 00:53:09 2021 KojiSummaryElectronicsA bunch of electronics received

Received additional front/rear panels. Updated the original entry and Wiki [Link]

 

  15865   Thu Mar 4 23:57:35 2021 KojiSummaryElectronicsInspection of the new custom dsub cables

I made the inspection of the new custom DSub cables (came from Texas).

The shelled version gives us some chance to inspect/modify the internal connections. (good)
The wires are well insulated. The conductors are wrapped with the foils and then everything is in the braid tube shield. The braid is soldered on one of the connectors. (Attachment  3/4 shows the soldering of the conductor by intentionally removing one of the insulations).

It wasn't clear that if the conductors are twisted or not (probably not).

  15864   Thu Mar 4 23:16:08 2021 KojiUpdateLSCREFL55 demod board rework

A new hybrid splitter (DQS-10-100) was installed. As the amplification of the final stage is sufficient for the input level of 3dBm, I have bypassed the input amplification (Attachment 1). One of the mixer was desoldered to check the power level. With a 1dB ATTN, the output of the last ERA-5 was +17.8dBm (Attachment 2). (The mixer was resoldered.)

With LO3dBm. RF0dBm, and delta_f = 30Hz, the output Vpp of 340mV and the phase difference is 88.93deg. (Attachment 3/4, the traces were averaged)

  15863   Thu Mar 4 15:48:26 2021 KojiSummaryPEMWatchdog tripped, Optics damped back

EQs seen on Summary pages
https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20210304/pem/seismic_blrms/

  15862   Thu Mar 4 11:59:25 2021 Paco, AnchalSummaryLSCWatchdog tripped, Optics damped back

Gautam came in and noted that the optics damping watchdogs had been tripped by a >5 magnitude earthquake somewhere off the coast of Australia. So, under guided assistance, we manually damped the optics using following:

  • Using the scripts/SUS/reEnableWatchdogs.py script we re-enabled all the watchdogs.
  • Everything except SRM was restored to stable state.
  • Then we clicked on SRM in SUS-> Watchdogs, disabled the Oplevs, shutdown the watchdog.
  • We changed the threshold for watchdog temporarily to 1000 to allow damping.
  • We enabled all the coil outputs  manually. Then enabled watchdog by clicking on Normal.
  • Once the SRM was damped, we shutdown the watchdog, brought back the threshold to 215 and restarted it.

Gautum also noticed that MC autolocker got turned OFF by me (Anchal), we turned it back on and MC engaged the lock again. All good, no harm done.

  15861   Thu Mar 4 10:54:12 2021 Paco, AnchalSummaryLSCPOY11 measurement, tried to lock Green Yend laser

[Paco, Anchal]

- First ran burtgooey as last time.

- Installed pyepics on base environment of donatella

ASS XARM:
- Clicked on ON in the drop down of "! More Scripts" below "! Scripts XARM" in C1ASS.adl
- Clicked on "Freeze Outputs" in the same menu after some time.
- Noticed that the sensing and output matrix of ASS on XARM and YARM look very different. The reason probably is because the YARM outputs have 4 TT1/2 P/Y dof instead of BS P/Y on the XARM. What are these TT1/2?

(Probably, unrelated but MC Unlocked and kept on trying to lock for about 10 minutes attaining the lock eventually.)

Locking XARM:
- From scripts/XARM we ran lockXarm.py from outside any conda environment using python command.
- Weirdly, we see that YARM is locked??? But XARM is not. Maybe this script is old.
- C1:LSC-TRY-OUTPUT went to around 0.75 (units unknown) while C1:LSC-TRX-OUTPUT is fluctuating around 0 only.

POY11 Spectrum measurement when YARM is locked:
- Created our own template as we couldn't find an existing one in users/Templates.
- Template file and data in Attachment 2.
- It is interesting to see most of the noise is in I quadrature with most noise in 10 to 100 Hz.
- Given the ARM is supposed to be much calmer than MC, this noise should be mostly due to the mode cleaner noise.
- We are not sure what units C1:LSC-POY11_I_ERR_DQ have, so Y scale is shown with out units.


Trying to lock Green YEND laser to YARM:
- We opened the Green Y shutter.
- We ensured that when temperature slider og green Y is moved up, the beatnote goes up.
- ARM was POY locked from previous step.
- Ran script scripts/YARM/Lock_ALS_YARM.py from outside any conda environment using python command.
- This locked green laser but unlocked the YARM POY.

Things moving around:
- Last step must have made all the suspension controls unstable.
- We see PRM and SRM QPDs moving a lot.
- Then we did burt restore to /opt/rtcds/caltech/c1/burt/autoburt/today/08:19/*.snap to go back to the state before we started changing things today.

[Paco left for vaccine appointment]

- However the unstable state didn't change from restore. I see a lot of movement in ITMX/Y. PRM and BS also now. Movement in WFS1 and MC2T as well.
 - I closed PSL shutter as well to hopefully disengage any loops that are still running unstably.
 - But at this point, it seems that the optics are just oscillating and need time to come back to rest. Hopefully we din't cause too much harm today :(.
 


My guess on what happened:

  • Us using the Lock_ALS_YARM.py probably created an unstable configuration in LSC matrix and was the start of the issue.
  • On seeing PRM fluctuate so much, we thought we should just burst restore everything. But that was a hammer to the problem.
  • This hammer probably changed the suspension position values suddenly causing an impulse to all the optics. So everything started oscillating.
  • Now MC WFS is waiting for MC to lock before it stablizes the mode cleaner. But MC autolocker is unable to lock because the optics are oscillating. Chicken-egg issue.
  • I'm not aware of how manually one can restore the state now. My only known guess is that if we wait for few hours, everything should calm back enough that MC can be locked and WFS servo can be switched on.
  15860   Wed Mar 3 23:23:58 2021 gautamUpdateALSArm cavity scan

I see no evidence of anything radically different from my PSL table optical characterization in the IMC transmitted beam, see Attachment #1. The lines are just a quick indicator of what's what and no sophisticated peak fitting has been done yet (so the apparent offset between the transmission peaks and some of the vertical lines are just artefacts of my rough calibration I believe). The modulation depths recovered from this scan are in good agreement with what I report in the linked elog, ~0.19 for f1 and ~0.24 for f2. On the bright side, the ALS just worked and didn't require any electronics fudgery from me. So the mystery continues.

  15859   Wed Mar 3 22:13:05 2021 gautamUpdateLSCREFL55 demod board rework

After this work, I measured that the orthogonality was poor. I confirmed on the bench that the PQW-2-90 was busted, pin 2 (0 degree output) showed a sensible signal half of the input, but pin 6 had far too small an output and the phase difference was more like 45 degrees and not 90 degrees. I can't find any spares of this part in the lab - however, we do have the equivalent part used in the aLIGO demodulator. Koji has kindly agreed to do the replacement (it requires a bit of jumper wiring action because the pin mapping between the two parts isn't exactly identical - in fact, the circuit schematic uses a transformer to do the splitting, but at some unknown point in time, the change to the minicircuits part was made. Anyway, until this is restored, I defer the PRMI sideband locking.

Quote:

There were multiple problems with the REFL55 demod board. I fixed them and re-installed the board. The TFs and noise measured on the bench now look more like what is expected from a noise model. The noise in-situ also looked good. After this work, my settings for the PRMI sideband lock don't work anymore so I probably have to tweak things a bit, will look into it tomorrow.

  15857   Wed Mar 3 12:00:58 2021 Paco, AnchalHowToIMCMC_F ASD

[Paco, Anchal]

- Saved BURT backup in /users/anchal/BURTsnaps/
- Copied existing code for mode cleaner noise budget from /users/rana/mat/mc. Will work on this from home to convert it inot new pynb way.

Get baseline IMC measurements (passive):
- MC_F:
  - What is MC_F? Let's find out.
  - On MC_F Cal window titled 'C1IOO-MC_FREQ', we turned off ON/OFF and back on again.
  - Using diaggui, we measured ASD of MC_F channel in units of counts/rtHz.

[Rana, Paco]

- Using diaggui, measured ASD from a template (under /users/Templates) and overlay the 1/f noise of the NPRO (Attachment 1)

[Anchal, Paco]

- WFS Master
  - Went through the schematic and tried to understand what is happening.
  - Accidentally switched on MC WF relief (python 3). Bunch of things were displayed on a terminal for a while and then we Ctrl-C it.
  - The only thing we noticed that change is a slight increase in WFS1 Yaw, and a corresponding decrease in WFS1 Pitch, WFS2 Pitch, and WFS2 Yaw.
  - We need to find out what this script does.


Future work:

  • Create an automated script for taking MC_F_DQ spectrum and refer it against reference trace.
  • Use pynb to create a noise budget for mode cleaner.
  • Identify excess noise between 10-40 Hz.
  • Configure output matrix in WFS Master to reduce the noise. Automate this process as well.
  15856   Wed Mar 3 11:51:07 2021 YehonathanUpdateSUSOSEM testing for SOSs

I finished testing the OSEMs. I put all the OSEMs back in the box. The OSEMS were divided into several bags. I put the OSEM box next to the south flow bench on the floor.

I have uploaded the OSEM catalog to the wiki. I will upload the LED spot images later.

In summary:

Total 64 OSEMS, 31 long, 33 short.

Perfectly centered LED spots, ready for C&B OSEMS: 30, 12 long, 18 short.

Perfectly centered LED spots, need some work (missing pigtails, weird screws) OSEMS: 7, 5 long, 2 short.

Slightly off-centered (subjective) LED spots, ready for C&B OSEMS: 20, 7 long, 13 short.

Slightly off-centered (subjective) LED spots, need some work (missing pigtails, weird screws) OSEMS: 4 long

Defective OSEMS or LED spot way off-center: 3.

  15855   Tue Mar 2 19:52:46 2021 gautamUpdateLSCREFL55 demod board rework

There were multiple problems with the REFL55 demod board. I fixed them and re-installed the board. The TFs and noise measured on the bench now look more like what is expected from a noise model. The noise in-situ also looked good. After this work, my settings for the PRMI sideband lock don't work anymore so I probably have to tweak things a bit, will look into it tomorrow.

  15854   Tue Mar 2 13:39:31 2021 ranaUpdateLSCPRM violin filter excessive?

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.

 

  15853   Mon Mar 1 16:27:17 2021 gautamUpdateLSCPRM violin filter excessive?

The PRM violin filter seems very suboptimal - the gain peaking shows up in the MICH OLTF, presumably due to the MICH-->PRM LSC output matrix. I plot the one used for the BS in comparison in Attachment #1, seems much more reasonable. Why does the PRM need so many notches? Is this meant to cover some violin modes of PR2/PR3 as well? Do we really need that? Are the PR2/PR3 violin modes really so close in frequency to that for the 3" SOS? I suppose it could be since the suspension wire is thinner and the mass is lighter, and the two effects nearly cancel, but we don't actuate on PR2/PR3? According to the earlier elog in this thread, this particular filter wasn't deemed offensive and was left on.

Indeed, as shown in Attachment #2, I can realize a much healthier UGF for the MICH loop with just a single frequency notch (black reference trace) rather than using the existing "PRvio1,2" filter (FM2), (live red trace). The PR violins are eating so much phase at ~600 Hz.

Quote:

We turned off many excessive violin mode bandstop filters in the LSC.

  15852   Mon Mar 1 12:36:38 2021 gautamSummaryIMCgetting familiar with IMC controls

Pretty minor thing - but PMCT and PMCR were switched on Quad 2 for whatever reason. I switched them back because I prefer the way it was. I have saved snapshots of the preferred monitor config for locking but I guess I didn't freeze the arrangement of the individual quadrants within a quad. This would be more of a problem if the ITMs and ETMs are shuffled around or something like that.

Quote:
 

- Switched channels around on video controls; changed C1:VID-MON7 to 16, back to 30, then C1:VID-QUAD2_4 to 16, to 18, then 20, back to 16, to 14 (which identified as PMCT), to 1 (IMC). Anyways, looks like IMC is locked.

  15851   Mon Mar 1 11:40:15 2021 Anchal, PacoSummaryIMCgetting familiar with IMC controls

[Paco, Anchal]

tl;dr: Done no harm, no lasting change.

Learn burtgooey

- Use /cvs/cds/caltech/target/c1psl/autoBurt.req as input to test snapshot "/users/anchal/BURTsnaps/controls_1210301_101310_0.snap" on rossa after not succeeding in donatella

- Browse /opt/rtcds/caltech/c1/burt/autoburt/snapshots/TODAY just to know where the snapshots are living. Will store our morning work specific snapshots in local user directories (e.g. /users/anchal/BURTsnaps)

Identifying video monitors

- Switched channels around on video controls; changed C1:VID-MON7 to 16, back to 30, then C1:VID-QUAD2_4 to 16, to 18, then 20, back to 16, to 14 (which identified as PMCT), to 1 (IMC). Anyways, looks like IMC is locked.

[Yehonathan, Paco, Anchal]

Unlocking MC

- From IOO/LockMC, MC_Servo, FSS --> closed PSL shutter, reopen it and see the lock recovers almost instantly. Try MCRFL shutter, no effect. Toggled PSL shutter one more time, lock recovered.

- From IOO/LockMC, MC_Servo, toggle OPTION (after IP2A), lose and recover lock in similar fashion. MCRFL gets most of the light.

- Looked at IFO_OVERVIEW just to get familiar with the various signals.

 

  15850   Sun Feb 28 22:53:22 2021 gautamUpdateLSCmore PRMI checks here: what it is ain't exactly clear

I looked into this a bit more and crossed off some of the points Rana listed. In order to use REFL 55 as a sensor, I had to fix the frequent saturations seen in the MICH signals, at the nominal (flat) whitening gain of +18 dB. The light level on the REFL55 photodiode (13 mW), its transimpedance (400 ohm), and this +18dB (~ x8) gain, cannot explain signal saturation (0.7A/W * 400 V/A * 8 ~ 2.2kV/W, and the PRCL PDH fringe should be ~1 MW/m, so the PDH fringe across the 4nm linewidth of the PRC should only be a couple of volts). Could be some weird effect of the quad LT1125. Anyway, the fix that has worked in the past, and also this time, is detailed here. Note that the anomalously high noise of the REFL55_Q channel in particular remains a problem. After taking care of that, I did the following:

  1. PRMI (ETMs misaligned) locking with sidebands resonant in the PRC was restored - REFL55_I was used for PRCL sensing and REFL55_Q was used for MICH sensing. The locks are acquired nearly instantaneously if the alignment is good, and they are pretty robust, see Attachment #1 (the lock losses were IMC related and not really any PRC/MICH problem).
  2. Measured the loop OLTFs using the usual IN1/IN2 technique. The PRCL loop looks just fine, but the MICH loop UGF is very low apparently. I can't just raise the loop gain because of the feature at ~600 Hz. Not sure what the origin of this is, it isn't present in the analogous TF measurement when the PRMI is locked with carrier resonant (REFL11_I for PRCL sensing, AS55_Q for MICH sensing). I will post the loop breakdown later. 
  3. Re-confirmed that the MICH-->PRCL coupling couldn't be nulled completely in this config either.
    • The effect is a geometric one - then 1 unit change in MICH causes a 1/sqrt(2) change in PRCL. 
    • The actual matrix element that best nulls a MICH drive in the PRCL error point is -0.34 (this has not changed from the PRMI resonant on carrier locking). Why should it be that we can't null this element, if the mechanical transfer functions (see next point) are okay?
  4. Looked at the mechanical actuator TFs are again (since we forgot to save plots on Friday), by driving the BS and PRM with sine waves (311.1 Hz), one at a time, and looking at the response in REFL55_I and REFL55_Q. Some evidence of some funkiness here already. I can't find any configuration of digital demod phase that gives me a PRCL/MICH sensing ratio of ~100 in REFL55_I, and simultaneously, a MICH/PRCL sensing ratio of ~100 in REFL55_Q. The results are in Attachments #5
  5. Drove single frequency lines in MICH and PRCL at 311.1 and 313.35 Hz respectively, for 5 minutes, and made the radar plots in Attachments #2 and #3. Long story short - even in the "nominal" configuration where the sidebands are resonant in the PRC and the carrier is rejected, there is poor separation in sensing. 
    • Attachments #2 is with the digital REFL55 demod phase set to 35 degrees - I thought this gave the best PRCL sensing in REFL55_I (eyeballed it roughly by looking at ndscope free-swinging PDH fringes).
    • But the test detailed in bullet #4, and Attachments #2 itself, suggested that PRCL was actually being sensed almost entirely in the Q phase signal.
    • So I changed the digital demod phase to -30 degrees (did a more quantitative estimate with free-swinging PDH fringes on ndscope, horn-to-horn voltages etc).
    • The same procedure of sine-wave-driving now yields Attachments #3. Indeed, now PRCL is sensed almost perfectly in REFL55_I, but the MICH signal is also nearly in REFL55_I. How can the lock be so robust if this is really true? 
  6. Attachments #4 shows some relevant time domain signals in the PRMI lock with the sidebands resonant. 
    • REFL11_I hovers around 0 when REFL55_I is used to sense and lock PRCL - good. The m/ct calibration for REFL11_I and REFL55_I are different so this plot doesn't directly tell us how good the PRCL loop is based on the out-of-loop REFL11_I sensor.
    • ASDC is nearly 0, good.
    • POP22_I is ~200cts (and POP22_Q is nearly 0) - I didn't see any peak at the drive frequency when driving PRCL with a sine wave, so no linear coupling of PRCL to the f1 sideband buildup, which would suggest there is no PRCL offset.
    • Couldn't do the analogous test for AS110 as I removed that photodiode for the AS WFS - it is pretty simple to re-install it, but the ASDC level already doesn't suggest anything crazy here.

Rana also suggested checking if the digital demod phase that senses MICH in REFL55_Q changes from free-swinging Michelson (PRM misaligned), to PRMI aligned - we can quantify any macroscopic length mismatch in the PRC length using this measurement. I couldn't see any MICH signal in REFL55_Q with the PRM misaligned and the Michelson fringing. Could be that +18dB is insufficient whitening gain, but I ran out of time this afternoon, so I'll check later. But not sure if the double attenuation by the PRM makes this impossible.

  15849   Sun Feb 28 16:59:39 2021 rana, gautamUpdateLSCmore PRMI checks here: what it is ain't exactly clear

On Friday evening we checked out a few more things, somewhat overlapping with previous tests. All tests done with PRMI on carrier lock (REFL11_I -> PRC, AS55_Q-> MICH):

  • check that PRC drive appropriately minimizes in REFL55_Q. I:Q ratio is ~100:1; good enough.
  • put sine waves around 311 and 333 Hz into PRCL and MICH at the LSC output matrix using awggui and LSC osc. not able to adjust LSC/OSC output matrix to minimize the MICH drive in REFL_I.
  • measured the TF from BS & PRM LSC drive to the REFL55_I/Q outputs. very nearly the same audio frequency phase, so the problem is NOT in the electronics || mechanical transfer functions of the suspensions.

 

Further questions:

  1. is this something pathological in the PRMI carrier lock? we should check by locking on sidebands to REFL55 and REFL165 and repeat tests.
  2. Can it be a severe mode mismatch from IMC output to PRMI mode? the cavity should be stable with the flipped folding mirrors, but maybe something strange happening. How do we measure the mode-matching to the PRC quantitatively?
  3. huge RAM is ruled out by Gautam's test of looking at REFL demod signals: dark offset vs. offset with a single bounce off of PRM (with ITMs mis-aligned)
  4. if there is a large (optical) offset in the AS55_Q lock point, how big would it have to be to mess up the REFL phase so much?
  5. what is going on with the REFL55 whitening/AA electronics?

unrelated note: Donatella the Workstation was ~3 minutes ahead of the FE machines (you can look at the C0:TIM-PACIFIC_STRING on many of the MEDM screens for a rough simulacrum). When the workstation time is so far off, DTT doesn't work right (has errors like test timed out, or other blah blah). I installed NTP on donatella and started the service per SL7 rules. Since we want to migrate all the workstations to Debian (following the party line), lets not futz with this too much.


gautam, 1 Mar 1600: In case I'm being dumb, I attach the screen grab comparing dark offset to the single bounce off PRM, to estimate the RAM contribution. The other signals are there just to show that the ITMs are sufficiently misaligned. The PRCL PDH fringe is usually ~12000 cts in REFL11, ~5000cts in REFL55, and so the RAM offset is <0.1% of the horn-to-horn PDH fringe.

P.S. I know generally PNGs in the elog are frowned upon. But with so many points, the vector PDF export by NDS (i) is several megabytes in size and (ii) excruciatingly slow. I'm proposing a decimation filter for the export function of ndscope - but until then, I claim plotting with "rasterized=True" and saving to PDF and exporting to PNG are equivalent, since both yield a rasterized graphic.

  15848   Sat Feb 27 17:25:42 2021 gautamUpdateElectronicsProduction version of the HV coil driver tested with KEPCO HV supplies

I will try the test of switching out KEPCOs one at a time for the HP. Given that the passive RC filter doesn't filter out the excess, I am wondering if the KEPCO is somehow polluting the circuit ground? The measurement was made between the circuit side of R24 (see schematic) and a ground testpoint, so the passive R23/C15 pole should filter the noise above ~15 Hz.

Quote:

This is very disappointing. Even with KEPCO linear supply with the improved HV driver circuit, the noise level is significantly higher than the 20kOhm R thermal noise.

What is special with the HP supplies? Can you replace KEPCOs with the HP supply, one by one to specify which one is making the noise bad?

  15847   Fri Feb 26 20:20:43 2021 KojiUpdateElectronicsProduction version of the HV coil driver tested with KEPCO HV supplies

This is very disappointing. Even with KEPCO linear supply with the improved HV driver circuit, the noise level is significantly higher than the 20kOhm R thermal noise.

What is special with the HP supplies? Can you replace KEPCOs with the HP supply, one by one to specify which one is making the noise bad?

  15846   Fri Feb 26 16:31:02 2021 gautamUpdateElectronicsProduction version of the HV coil driver tested with KEPCO HV supplies

Koji asked me to test the production version of the coil driver with the KEPCO HV supplies. See Attachment #1 for the results. For comparison, I've added a single trace from the measurements made with the HP supplies. I continue to see excess noise with the KEPCO supplies. Note that in the production version of the board that was tested, there are a pair of 10uF bypass capacitors on the board for the HV supply lines. It is possible that one or both KEPCO supplies are damaged - one was from the ASY setup and one I found in the little rack next to 1X2. The test conditions were identical to that with the HP supplies (as best as I could make it so).

  15845   Thu Feb 25 20:37:49 2021 gautamUpdateGeneralSetting modulation frequency and checking IMC offset

The Marconi frequency was tuned by looking at 

  1. The ~3.68 MHz (= 3*f1 - fIMC) peak at the IMC servo error point, TP1A, and
  2. The ~25.8 MHz (= 5*f1 - fIMC) peak at the MC REFL PD monitor port. The IMC error point is not a good place to look for this signal because of the post-demodulation low pass filter (indeed, I didn't see any peak above the analyzer noise floor).

The nominal frequency was 11.066209 MHz, and I found that both peaks were simultaneously minimized by adjusting it to 11.066195 MHz, see Attachment #1. This corresponds to a length change of ~20 microns, which I think is totally reasonable. I guess the peaks can't be nulled completely because of imbalance in the positive and negative sidebands. 

Then, I checked for possible offsets at the IMC error point, by injecting a singal to the AO input of the IMC servo board (using the Siglent func gen), at ~300 Hz. I then looked at the peak height at the modulation frequency, and the second harmonic. The former should be minimized when the cavity is exactly on resonance, while the latter is proportional to the modulation depth at the audio frequency. I found that I had to tweak the MC offset voltage slider from the nominal value of 0V to 0.12 V to null the former peak, see Attachment #2. After accounting for the internal voltage division factor of 40, and using my calibration of the IMC error point as 13 kHz/V, this corresponds to a 40 Hz (~50 microns) offset from the true resonant point. Considering the cavity linewidth of ~4 kHz, I think this is a small detuning, and probably changes from lock to lock, or with time of day, temperature etc.

Conclusion: I think neither of these tests suggest that the IMC is to blame for the weirdness in the PRMI sensing, so the mystery continues.

ELOG V3.1.3-