• 10m PM1064 cable was installed. I tried a double shielding approach (photos tmrw here), but I suspect the real weak point is where the fiber is plugged into the collimator - it's hard to imagine we can stabilize this sort of arrangement to better than 100um absolute length over long periods of time, I'd think thermal/mechanical strains in the fiber will modulate the length by ~mm (?). Anyways, let's see what the heterodyne measurement tells us.
• This work required (i) realignment at the input coupler and (ii) change of position of mode matching lenses in the LO path on the AS table to see any interference with the IFO beam. This indicates something was seriously wrong with the old patch cable, as the collimator should set the mode. The MFD of the two fibers may have been different, but I don't know if that alone can account for it.
• As of now, I have fringes between the ITM single bounce and the LO, but the fringe pk-pk is only 10% of the theoretical pk-pk based on DC values of the LO and AS beams. So the mode matching can be improved significantly (I preivously had ~60%).

To be continued tomorrow. I think it's a good idea to let the newly installed fiber relax into some sort of stable configuration overnight.

Summary:

After replacement of the fiber delivering the LO beam to the airBHD setup (some photos here), I repeated the measurement outlined here. There may be some improvement, but overall, conclusions don't change much.

Details:

The main addition I made was to implement a digital phase tracker servo (a la ALS), to make sure my arctan2 usage wasn't completely bonkers (the CDS block can be deleted later, or maybe it's useful to keep it, we will see). I didn't measure it today, but the UGF of said servo should be >100 Hz so the attached spectrum should be valid below that (loop has not been done, so above the UGF, the control signal isn't a valid representative of the free running noise). Attachment #1 shows the result. The 1 Hz and 3 Hz suspension resonances are well resolved. Anyways, what this means is that the earlier result was not crazy. I don't know what to make of the high frequency lines, but my guess is that they are electronic pickup from the Sorensens - I'm using clip-mini-grabbers to digitize these signals, and other electronics in that rack (e.g. ALS signals) also show these lines.

It is pretty easy to keep the simple Michelson locked for several minutes. Attachment #2 shows the phase-tracker servo output over several minutes. The y-axis units are degrees. If this is to be believed, the relative phase between the two fields is drifting by 12um ove an hour. This is significantly lower than my previous measurement, while the noise in the ~0.5-10 Hz band is similar, so maybe the shorter fiber patch cable did some good?

I think there is also correlation between the PSL table temperature, but of course, the evidence is weak, and there are certainly other effects at play. At first, I thought the abrupt jumps are artefacts, but they don't actually represent jumps >360 degrees over successive samples, so maybe they are indicative of some real jump in the relative phase? Either fiber slippage or TT suspension jumps? I'll double check with the offline data to make sure it's not some artefact of the phase tracker servo. If you disagree with these conclusions and think there is some meaurement/analysis/interpretation error, I'd love to hear about it.

Next steps:

1. Budget the offline inferred phase noise spectrum, overlay a seismic noise model, to see if we can disentangle the contributions from the suspensions and that from the LO fiber.
2. I'll see if I can setup an LO pickup with some RF sidebands on it in parallel to this setup so we can try some of the ideas discussed on the call this week. There are several beams available, but the question is whether I can get this into a fiber without 1 week of optical layout work.

I have left the heterodyne electronics setup at the LSC rack, but it is not powered (because there are some exposed wires). Please leave it as is.

The vac controls are going down now to pull and test software changes. Will advise when the work is completed.

The vac work is completed. All of the vacuum equipment is now running on the new 120V UPS, except for TP1. The 230V TP1 is still running off wall power, as it always has. After talking with Tripp Lite support today, I believe there is a problem with the 230V UPS. I will post a more detailed note in the morning.

Summary

Yesterday's UPS switchover was mostly a success. The new Tripp Lite 120V UPS is fully installed and is communicating with the slow controls system. The interlocks are configured to trigger a controlled shutdown upon an extended power outage (> ~30 s), and they have been tested. All of the 120V pumpspool equipment (the full c1vac/LAN/Acromag system, pressure gauges, valves, and the two small turbo pumps) has been moved to the new UPS. The only piece of equipment which is not 120V is TP1, which is intended to be powered by a separate 230V UPS. However that unit is still not working, and after more investigation and a call to Tripp Lite, I suspect it may be defective. A detailed account of the changes to the system follow below.

Unfortunately, I think I damaged the Hornet (the only working cathode ionization gauge in the main volume) by inadvertently unplugging it while switching over equipment to the new UPS. The electronics are run from multiple daisy-chained power strips in the bottom of the rack and it is difficult to trace where everything goes. After the switchover, the Hornet repeatedly failed to activate (either remotely or manually) with the error "HV fail." Its compatriot, the Pirani SuperBee, also failed about a year ago under similar circumstances (or at least its remote interface did, making it useless for digital monitoring and control). I think we should replace them both, ideally with ones with some built-in protection against power failures.

New EPICS channels

Four new soft channels per UPS have been created, although the interlocks are currently predicated on only C1:Vac-UPS120V_status.

These new readbacks are visible in the MEDM vacuum control/monitor screens, as circled in Attachment 1:

Continuing issues with 230V UPS

Yesterday I brought with me a custom power cable for the 230V UPS. It adapts from a 208/120V three-phase outlet (L21-20R) to a standard outlet receptacle (5-15P) which can mate with the UPS's C14 power cable. I installed the cable and confirmed that, at the UPS end, 208V AC was present split-phase (i.e., two hot wires separated 120 deg in phase, each at 120V relative to ground). This failed to power on the unit. Then Jordan showed up and suggested to try powering it instead from a single-phase 240V outlet (L6-20R). However we found that the voltage present at this outlet was exactly the same as what the adapter cable provides: 208V split-phase.

This UPS nominally requires 230V single-phase. I don't understand well enough how the line-noise-isolation electronics work internally, so I can think of three possible explanations:

1. 208V AC is insufficient to power the unit.
2. The unit requires a true neutral wire (i.e., not a split-phase configuration), in which case it is not compatible with the U.S. power grid.
3. The unit is defective.

I called Tripp Lite technical support. They thought the unit should work as powered in the configuration I described, so this leads me to suspect #3.

@Chub and Jordan: Can you please look into somehow replacing this unit, potentially with a U.S.-specific model? Let's stick with the Tripp Lite brand though, as I already have developed the code to interface those.

UPS-host computer communications

Unlike our older equipment, which communicates serially with the host via RS232/485, the new UPS units can be connected with a USB 3.0 cable. I found a great open-source package for communicating directly with the UPS from within Python, Network UPS Tools (NUT), which eliminates the dependency on Tripp Lite's proprietary GUI. The package is well documented, supports hundreds of power-management devices, and is available in the Debian package manager from Jessie (Debian 8) up. It consists of a large set of low-level, device-specific drivers which communicate with a "server" running as a systemd service. The NUT server can then be queried using a uniform set of programming commands across a huge number of devices.

I document the full set-up procedure below, as we may want to use this with more USB devices in the future.

How to set up

First, install the NUT package and its Python binding:

$ sudo apt install nut python-nut

This automatically creates (and starts) a set of systemd processes which expectedly fail, since we have not yet set up the config. files defining our USB devices. Stop these services, delete their default definitions, and replace them with the modified definitions from the vacuum git repo:

$ sudo systemctl stop nut-*.service
$ sudo rm /lib/systemd/system/nut-*.service
$ sudo cp /opt/target/services/nut-*.service /etc/systemd/system
$ sudo systemctl daemon-reload

Next copy the NUT config. files from the vacuum git repo to the appropriate system location (this will overwrite the existing default ones). Note that the file ups.conf defines the UPS device(s) connected to the system, so for setups other than c1vac it will need to be edited accordingly.

$ sudo cp /opt/target/services/nut/* /etc/nut

Now we are ready to start the NUT server, and then enable it to automatically start after reboots:

$ sudo systemctl start nut-server.service
$ sudo systemctl enable nut-server.service

If it succeeds, the start command will return without printing any output to the terminal. We can test the server by querying all the available UPS parameters with

$ upsc 120v

which will print to the terminal screen something like

battery.charge: 100
battery.runtime: 1215
battery.type: PbAC
battery.voltage: 13.5
battery.voltage.nominal: 12.0
device.mfr: Tripp Lite 
device.model: Tripp Lite UPS 
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productid: 2010
driver.parameter.vendorid: 09ae
driver.version: 2.7.2
driver.version.data: TrippLite HID 0.81
driver.version.internal: 0.38
input.frequency: 60.1
input.voltage: 120.3
input.voltage.nominal: 120
output.frequency.nominal: 60
output.voltage.nominal: 120
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.mfr: Tripp Lite 
ups.model: Tripp Lite UPS 
ups.power.nominal: 1000
ups.productid: 2010
ups.status: OL
ups.timer.reboot: 65535
ups.timer.shutdown: 65535
ups.vendorid: 09ae
ups.watchdog.status: 0

Here 120v is the name assigned to the 120V UPS device in the ups.conf file, so it will vary for setups on other systems.

If all succeeds to this point, what we have set up so far is a set of command-line tools for querying (and possibly controlling) the UPS units. To access this functionality from within Python scripts, a set of official Python bindings are provided by the python-nut package. However, at the time of writing, these bindings only exist for Python 2.7. For Python 3 applications (like the vacuum system), I have created a Python 3 translation which is included in the vacuum git repo. Refer to the UPS readout script for an illustration of its usage.

2PM: Arrived at the 40m. Started the work for the coupling of the RF modulated LO beam into a fiber. -> I left the lab at 10:30 PM.

The fiber coupling setup for the phase-modulated beam was made right next to the PSL injection path. (See attachment 1)

• For the alignment of the beam, the main PSL path, including the alignment of the 2" PO mirror, has not been touched.
• There are two PO beams with the optical power of 0.8mW (left) and 1.6mW (right). Both had been blocked but the right one was designed to be used for PSL POS and ANG. For the fiber coupling, the right beam was used.
• The alignment/mode-matching work has been done with a short (2m?) fiber patch cable from Thorlabs. The fiber is the same as the one used for LO delivery.
• I tried to have a mode-matching telescope in the LO path. I ended up having no lens for the best result. The resulting transmitted power is 1.21mW out of 1.64mW incident (~74%). These powers were measured with the Ophir power meter. (Note that Thorlabs' fiber power meter indicated 1.0mW transmission.)

Some notes

• After the PSL activity, the IMC locking was checked to see if I messed up the PSL alignment. It locks fine and looks fine.
  • The input shutter (left closed after Jon's vacuum work?) was opened.
  • The alignment was not optimal and had some pitch misalignment (e.g. TEM03).
  • After some MC SUS alignment, the automatic locking of TEM00 was recovered. Mainly MC3 pitch was moved (+0.17).
  • I've consulted with Gautam and he thinks this is with the level of regular drift. The AS beam was visible.
• The IMC and MI were moving so much, but this seemed just the usual Saturday night Millikan shake.
• During the activity, the PSL HEPA was turned up to 100 and it was reverted to 33 after the work.
• I have been wearing a mask and gloves throughout the work there.

Now that the old APC Smart-UPS 2200 is no longer in use by the vacuum system, I looked into whether it can be repurposed for the framebuilder machine. Yes, it can. The max power consumption of the framebuilder (a SunFire X4600) is 1.137kW. With fresh batteries, I estimate this UPS can power the framebuilder for >10 min. and possibly as long as 30 min., depending on the exact load.

@Chub/Jordan, this UPS is ready to be moved to rack 1X6/1X7. It just has to be disconnected from the wall outlet. All of the equipment it was previously powering has been moved to the new UPS. I have ordered a replacement battery (APC #RBC43) which is scheduled to arrive 9/09-11.

On Friday, I grabbed the Zurich Instruments HF2LI lock-in amplifier and brought it home. As time permits, I will work towards developing a similar readout script as we have for the SR785.

Summary:

Over the last couple of days, I've been working towards getting the infrastructure ready to test out the scheme of sensing (and eventually, controlling) the homodyne phase using the so-called RF44 scheme. More details will be populated, just quick notes for now before I forget.

• LO beam with RF sidebands needed to be re-coupled into collimator, it wasn't seated tightly and just touching the fiber completely destroyed the alignment.
• HWP installed before said collimator - IMC wants s-polarized light whereas the IFO field is p-polarized.
• After my work, the numbers were: ~1.47mW input to collimator, ~1.07mW out of collimator on AS table, ~1mW making it to the BHD board. All seem like reasonable numbers to me.
• 44 MHz signal synthesis - for now, I use a Marconi (10 MHz synced to Rb clock), I think we could also use a mixer+SLP50 to mix 11 and 55 MHz signals (which are easily available at the LSC rack) to generate this. I looked at Wenzel quadruplers, the specs don't suggest a quadrupler will do much better.
• CDS model was modified to accept the phase-tracker output as an error signal for the homodyne phase control servo. Compile and install went smooth but I opted against a model restart tonight, I'll do it tmrw.
• Some trials were done with the Michelson locked to a dark fringe (as was done for the case of the DC LO field beating with the 55 MHz sideband). While the overall spectrum lines up fairly well with earlier trials, the signal looks somewhat more "discontinuous" in its traversal of I/Q space, and it never quite goes to 0. Some offset? What does this mean for locking? More investigations needed....

- Loose fiber coupler: Sorry about that. I could not detect something was loose there, although some of the locks were not tightened.

- S incident instead of P: Sorry about that too. I completely missed that the IMC takes S-pol.

I edited /diskless/root.jessie/home/controls/.bashrc so that I don't have to keep doing this every time I do a model recompile.

Summary:

1. With the Michelson locked on a dark fringe, the f2-f1 signal at ~44 MHz does not seem to ever vanish, it seems to bottom out at ~2mV DC. Is this just an electronics offset? Not sure of the implications on using this as a locking signal for the homodyne phase yet.
2. The inferred relative phase fluctuations between the LO and RF fields using this 44 MHz signal is consistent with that from previous tests.
3. The laying out of the new, shorter, fiber patch cable seems to have helped to reduce the phase drift over minute time scales.
4. So far, I have not had any success in using the 44 MHz signal to close a servo loop and keep the homodyne phase locked for more than a few seconds at a time, and even then, the loop shape is sub-optimal as the in-loop error signal is not clean. Maybe some systematic loop shaping will help, but I think the dynamic range requirement on the actuator is too high, and I'm not sure what to make of the fact that the error signal does not vanish.

Details:

Attachment #1 shows the optical setup currently being used to send the LO field with RF sidebands on it to the air BHD setup.

• You can find a video of the large power fluctuations mentioned in my previous elog here. After tightening the collimator in the mount, the arrangement is still rather sensitive, but at least I was able to see some light on the DCPD on the AS table, at which point I could use this signal and tweak the alignment to maximize it.
• It is well known that the input beam to the IMC drifts during the day, either due to temperature fluctuations / PMC PZT stroke L2A / some other reason (see Attachment #4 for the power drift over ~12 hours, it is not monotonic with temperature). The fact that our collimating setup is so sensitive to the input pointing isn't ideal, but I noticed the power had only degraded by ~5% today compare to yesterday, so maybe the occassional touch up is all that is required.

Attachment #2 shows spectra of the relative phase drift between LO and IFO output field (from the Dark Michelson). 

• I still haven't overlaid a seismic model. There was some discussion about the TTs having a 1/f roll-off as opposed to 1/f^2, I don't know if there was any characterization at the time of installation, but this SURF report seems to suggest that it should in fact be 1/f^2 because the passive eddy current dampers are mounted to the main suspension cage on springs rather than being rigidly attached. 
• The noise at ~100 Hz is ~x2 higher if the spectra is collected during the daytime, when the seismic activity is high. Although this shouldn't really matter at 100 Hz? 
• There are also huge power-line harmonics - I suspect these are making it difficult to close a feedback loop, as I couldn't add a 60 Hz comb which doesn't affect the loop stability for a UGF of ~30-50 Hz. But if they aren't notched out, the control signal RMS is dominated by these frequencies.

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.

• Koji asked me about the 55 MHz signal and why it doesn't vanish - for the dark Michelson, where the ITMs don't apply any relative phase on reflection to the carrier and RF sideband fields, we expect that the upper and lower sidebands cancel, and so there should be no intensity modulation at 55 MHz (just like we don't expect any for a pure phase modulated light field incident on a photodiode).
• However, from the I/Q demodulated data that is collected, it would appear that while the size of the signal does vary, it doesn't ever completely vanish. This implies some asymmetry in the sidebands (or at least, the transmission of the sidebands by the Michelson). I didn't estimate the effect of the Schnupp asymmetry, or if this asymmetry is coming from elsewhere, but the point is that for the conclusions drawn from Attachment #2 remain valid even though both the amplitude and phase of the 55 MHz signal is changing. 
• I also plot the corresponding histogram for the 44 MHz signal. You can see that it never goes to 0 (once I fix the x-label ticks). I don't know if this is consistent with some electronics offset.

Attempts to close a feeddback loop to control the homodyne phase:

• A digital PLL (a.k.a. Phase Tracker) servo was used to keep the demodulated 44 MHz signal in one (demodulated) quadrature, which can then be used as an error signal.
• Unlike the ALS case, the quantity to be servoed to 0 is the magnitude of the 44 MHz signal, and not its phase, so that's how I've set up the RTCDS model.
• I played around with the loop shape to try and achieve a stable lock by actuating on the PZT mounted mirror in the LO path - however, I've not yet had any success so far.

As promised some time ago, I've obtained input noise spectra from the sites calibrated to physical units. They are located in a new subdirectory of the BHD repo: A+/input_noises. I've heavily annotated the notebook that generates them (input_noises.ipynb) with aLOG references, to make it transparent what filters, calibrations, etc. were applied and when the data were taken. Each noise term is stored as a separate HDF5 file, which are all tracked via git LFS.

So far there are measurements of the following sources:

• L1 SRCL
• H1 SRCL
• L1 DHARD PIT
• L1 DSOFT PIT
• L1 CSOFT PIT
• L1 CHARD PIT

These can be used, for example, to make more realistic Hang's bilinear noise modeling [ELOG 15503] and Yehonathan's Monte Carlo simulations [ELOG 15539]. Let me know if there are other specific noises of interest and I will try to acquire them. It's a bit time-consuming to search out individual channel calibrations, so I will have to add them on a case-by-case basis.

15:30
- PSL HEPA was running at 33% and is now at 100%
- South End HEPA was not on and is now running
- Yarm Portable HEPA was not running and is now running at max speed: the power was taken beneath the ITMY table. It is better to unplug it when one uses the IFO.
- Yend Portable HEPA was not running and is now running (presumably) at max speed

Particle Levels: (Not sure about the unit. The convention here is to multiply x10 of the reading)

Before running the HEPAs at their maximum
9/10/2020 15:30 / 0.3um 292180 / 0.5um 14420
(cf 9/5/2020 / 0.3um 94990 / 0.5um 6210)
==>
After running the HEPAs at their maximum
The number gradually went down and now became constant at about half of the initial values
9/10/2020 19:30 / 0.3um 124400 / 0.5um 7410

Turns out what was causing the instability in the aLIGO plots were the lock commands which I forgot to remove before running the simulation. Removing these also made the simulation much faster.

Other than that I improved other stuff in the simulations:

• The LO phase in the aPlus simulation is now optimized for the lowest noise at 100Hz.
• Added RF PDs diagnostics (see attachments 8 for aPlus and 9 for aLIGO). The thresholds (red dashed lines in attachments 8,9) for cutting marginal simulations are set such that roughly 30% of the simulations are discarded.
• Removed DHARD because it jacks up the RF PD readings in aPlus for some reason.
• Fixed the sign of laser frequency shift in response to CARM offset.

Still need to do:

• Incorporate Jon’s noise curves.
• Add phase noise for LO beam.
• Add arm reflectivity imbalance.
• Add mirror curvature imbalance.
• Include feedback loops using Pytickle.

Feel free to add to the todo list.

The PMC has been unlocked since September 11 sometime (summary pages are flaky again). I re-locked it just now. I didn't mess with the HEPA settings for now as I'm not using the IFO at the moment, so everything should be running in the configuration reported here. The particulate count numbers (both 0.3um and 0.5um) reported is ~x5-8 of what was reported on Thursday, September 10, after the HEPA filters were turned on. We don't have logging of this information in any automated way so it's hard to correlate things with the conditions in Pasadena. We also don't have a working gauge of the pressure of the vacuum envelope.

The RGA scanning was NOT enabled for whatever reason after the vacuum work. I re-enabled it, and opened VM1 to expose the RGA to the main volume. The unit may still be warming up but this initial scan doesn't look completely crazy compared to the reference trace which is supposedly from a normal time based on my elog scanning (the timestamp is inherited from the c0rga machine whose clock is a bit off).

Update 1500: I checked the particle count on the PSL table and it barely registers on the unit (between 0-20 between multiple trials) so I don't know if we need a better particle coutner or if there is negligible danger of damage to optics due to particulate matter.

The unit was repaired and returned to the 40m. Now, with a DMM, I measure a DC offset value that is ~1% of the AC signal amplitude. I measured the TF of a simple 1/20 voltage divider and it looks fine. In FFT mode, the high frequency noise floor levels out around 5-7nV/rtHz when the input is terminated in 50 ohms.

I will upload the repair documents to the wiki.

These were delivered to the 40m today and are on Rana's desk

There was an abrupt change in the MC_F spectrum between August 4 and August 5, judging by the summary pages - the 1 and 3 Hz resonances are no longer visible in the spectrum. Possibly, this indicates some electronics failure on the MC servo board / whitening board, the CDS settings don't seem to have changed. There is no record of any activity in the elog around those dates that would explain such a change. I'll poke around at 1X2 to see if anything looks different.

Update 1740: I found that the MCL / MCF cables were disconnected. So since August 5, these channels were NOT recording any physical quantity. Because their inputs weren't terminated, I guess this isn't a clean measurement of the whitening + AA noise, but particularly for MC_F, I guess we could use more whitening (see Attachment #1). Probably also means that the wandering ~10-30Hz line in the spectrogram is a electronics feature. The connections have now been restored and things look nominal again.

that's a very curious disconnection

the "Pentek" whitening board that carries the MC channels has jumpers to enable either 1 or 2 stages of 15:150 whitening. Looks lik MC_F has 2 and MC_L has 1.

I guess the MC_F signal is so low because of the high gain on the FSS board.  We could lower the FSS common gain and increase the IMC board's VCO gain to make up for this. Maybe 6 dB would be enough. IF that is risky, we could also up the analog gain on the whitening board.

Summary:

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.

Details:

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.

This elog suggests that there is uniformly 1 stage engaged across all channels. I didn't look at the board to see what the jumper situation is, but only 1 stage of whitening is compensated digitally for both _F and _L. The Pomona box attached to the NPRO PZT input is also compensated digitally to convert counts to frequency.

I tried the gain re-allocation between VCO gain and FSS COMM (and also compensated for the cts to Hz conversion in MCF), but it doesn't seem to have the desired effect on the MCF SNR in the 5-50Hz band. Since the IMC stays locked, and I had already made the changes to mcup, I'll keep these gains for now. We can revert to the old settings if the IMC locking duty cycle is affected. Explicitly, the changes made were:

VCO gain: +7dB ---> +13 dB

FSS COMM: +6 ddB ---> +0 dB

The mcdown script wasn't modified, so the lock acquisition gains are the same as they've been. 

Assembled is the list of dead pressure gauges. Their locations are also circled in Attachment 1.

For replacements, I recommend we consider the Agilent FRG-700 Pirani Inverted Magnetron Gauge. It uses dual sensing techniques to cover a broad pressure range from 3e-9 torr to atmosphere in a single unit. Although these are more expensive, I think we would net save money by not having to purchase two separate gauges (Pirani + hot/cold cathode) for each location. It would also simplify the digital controls and interlocking to have a streamlined set of pressure readbacks.

For controllers, there are two options with either serial RS232/485 or Ethernet outputs. We probably want the Agilent XGS-600, as it can handle all the gauges in our system (up to 12) in a single controller and no new software development is needed to interface it with the slow controls.

I had to make a CDS change to the c1lsc model in an effort to get a few more signals into the models. Rather than risk requiring hard reboots (typcially my experience if I try to restart a model), I opted for the more deterministic scripted reboot, at the expense of spending ~20mins to get everything back up and running.

Update 2230: this was more complicated than expected - a nuclear reboot was necessary but now everything is back online and functioning as expected. While all the CDS indicators were green when I wrote this up at ~1800, the c1sus model was having frequent CPU overflows (execution time > 60 us). Not sure why this happened, or why a hard power reboot of everything fixed it, but I'm not delving into this.

The point of all this was that I can now simultaneously digitize 4 channels - 2 DCPDs, and 2 demodulated quadratures of an RF signal.

eSummary:

I don't think the proposed scheme for sensing and controlling the homodyne phase will work without some re-thinking of the scheme. I'll try and explain my thinking here and someone can correct me if I've made a fatal flaw in the reasoning somewhere.

Field spectrum cartoon:

Attachment #1 shows a cartoon of the various field components.

• The input field is assumed to be purely phase modulated (at 11 MHz and 55 MHz) creating pairs of sidebands that are in quadrature to the main carrier field.
• The sideband fields are drawn with positive and negative imaginary parts to indicate the relative negative sign between these terms in the Jacobi-Anger expansion.
• For our air BHD setup, the spectrum of the LO beam will also be the same.
• At the antisymmetric (= dark) port of the beamsplitter, the differential mode signal field will always be in the phase quadrature.
• I'm using the simple Michelson as the test setup:
  • The ITMs have real and (nearly) identical reflectivities for all frequency components incident on it.
  • The sideband fields are rotated by 90 degrees due to the i in the Michelson transmission equation.
  • The Schnupp asymmetry preferentially transmits the 55 MHz sideband to the AS port compared to the 11 MHz sideband - note that in the simple Michelson config, I calculate T(11 MHz) = 0.02%, T(55 MHz) = 0.6% (both numbers not accounting for the PRM attenuation).
• I think the cartoon Hang drew up is for the DRFPMI configuration, with the SRC operated in RSE.
  • The main difference relative to the simple Michelson is that the signal field picks up an additional 90 degrees of phase propagating through the SRC.
• For completeness, I also draw the case of the DRFPMI where the SRC is operated at nearly the orthogonal tuning.
  • I think the situation is similar to the simple Michelson

So is there a 90 degree relative shift between the signal quadrature in the simple Michelson vs the DRFPMI? But wait, there are more problems...

Closing a feedback loop using the 44 MHz signal:

We still need to sense the 44 MHz signal with a photodiode, acquire the signal into our CDS system, and close a feedback loop.

• The 44 MHz signal is itself supposed to be generated by the interference between the TEM00 55 MHz sideband from the IFO output with the TEM00 11 MHz sideband from the LO field (let's neglect any mode mismatch, HOMs etc for the moment).
• By splitting this beat signal photocurrent in two, mixing each part with an electrical 44 MHz signal, and digitizing the IF output of said mixers, we should in principle be able to reconstruct the magnitude and phase of the signal.
• The problem is that we know from other measurements that this signal is going to go through multiple fringes, and hence, we don't have a signal that is linear in the quantity we would like to control, namely the homodyne phase (either quadrature signal can be a candidate linear signal around a zero crossing, but when the signals are going through multiple fringes, neither signal stays linear).
• One possible way to get around this problem is to use a phase tracker servo - basically, close a purely digital feedback loop, using one of the demodulated quadratures as an error signal, and changing the demodulation phase digitally such that the signal stays entirely in the orthogonal quadrature. However, such a scheme relies on the signal magnitude remaining constant. If the "error signal" goes to zero for multiple reasons (rotation out of the quadrature being considered, or just that the signal itself goes to zero), then this technique won't work. Of course, the phase tracker doesn't know what the "phase" of the signal is, when it's magnitude is (nearly) zero.
• It is true that we always expect a "background" level of 44 MHz signal, from the 11 MHz and 55 MHz sidebands in the LO beam directly interfering, but this doesn't contain any useful information, and in fact, it'd only contaminate the phase tracker error signal I think.
• So we can't rely on the error staying in one quadrature (like we do for the regular IFO PDH signals, where there is no relative phase propagation between the LO and RF sideband optical fields and so once we set the demodulation phase, we can assume the signal will always stay in that quadrature, and hence we can close a feedback loop), and we can't track the quadrature. What to do? I tried to dynamically change the phase tracker servo gain based on the signal magnitude (calculated in the RTCDS code using sqrt(I**2 + Q^2), but this did not yield good results...

Next steps:

I don't have any bright ideas at the moment - anyone has any suggestions?🤔

Aside:

I wanted to check what kind of signal the photodiode sees when only the LO field is incident on the photodiode. So with the IFO field blocked, I connected the PDA10CF to the Agilent analyzer in "Spectrum" mode, through a DC block. The result is shown in Attachment #2. To calculate the PM/AM ratio, I assumed a modulation depth of 0.2. The RIN was calculated by dividing the spectrum by the DC value of the PDA10CF output, which was ~1V DC. The frequencies are a little bit off from the true modulation frequencies because (i) I didn't sync the AG4395 to a Rb 10 MHz signal, and (ii) the span/BW ratio was set rather coarsely at 3kHz.

I would expect only 44 MHz and 66 MHz peaks, from the interference between the 11 MHz and 55 MHz sideband fields, all other field products are supposed to cancel out (or are in orthogonal quadratures). This is most definitely not what I see - is this level of RIN normal and consistent with past characterization? I've got no history in this particular measurement. 

M4.5 EQ in LA 2020-09-19 06:38:46 (UTC) / -1d 23:38:46 (PDT) https://earthquake.usgs.gov/earthquakes/eventpage/ci38695658/executive

I only checked the watchdogs. All watchdogs were tripped. ITMX and ETMY seemed stuck (or have the OSEM magnet issue). They were left tripped. The watchdogs for the other SUSs were reloaded.

the seismometers obviously saturated during the EQ, but the accelerometers captured some of it. It looks like there's different saturation levels on different sensors.

Also, it seems the mounting of the MC2 accelerometers is not so good. There's some ~10-20 Hz resonance its mount that's showing up. Either its the MC2 chamber legs or the accelerometers are clamped poorly to the MC2 baseplate.

Sun Sep 20 00:02:36 2020 edit: fixed indexing error in plots

* also assuming that the sensors are correctly calibrated in the front end to 1 count = 1 um/s^2 (this is what's used in the summ pages)

I came to the campus and Gautam notified that he just had received the alert from the vac watchdog.

I checked the vac status at c1vac. PTP3 went up to 10 torr-ish and this made the diff pressure for TP3 over 1torr. Then the watchdog kicked in.

To check the TP3 functionality, AUX RP was turned on and the manual valve (MV in the figure) was opened to pump the foreline of TP3. This easily made PTP3 <0.2 torr and TP3 happy (I didn't try to open V5 though).

So the conclusion is that RP for TP3 has failed. Presumably, the tip-seal needs to be replaced.

Right now TP3 was turned off and is ready for the tip-seal replacement. V5 was closed since the watchdog tripped.

the EQ was ~14 km south of Caltech and 17 km deep

I'm amazed at how much higher the noise is on the MC2 accelerometer. Is that really how much amplification of the ground motion we're getting? If so, its as if the MC has no vibration isolation from the ground in that band. We should put one set on the ground and make the more direct comparison of the spectra. Also, perhaps do some seismic FF using this sensor - I'm not sure how successful we've been in this band.

Attaching the coherence plot from ldvw.ligo.caltech.edu (apparently it has access to the 40m data, so we can use that as an alternative to dtt or python for remote analysis):

It would be interesting to see if we can use the ML based FF technology from this summer's SURF project by Nadia to increase the coherence by including some slow IMC alignment channels.

I supplied a bottle of hand soap. Don't put water in the bottle to dilute it as it makes the soap vulnarable for cotamination.

There were two SUSs which didn't look normal.

- ITMX was easily released by the bias slider -> Shake the pitch slider and while all the OSEM values are moving, turn on the damping control (with x10 large watchdog threshold)

- ETMY has UR OSEM 0V output. This means that there is no light. And this didn't change at all with the slider move.
- Went to the Y table and tried to look at the coils. It seems that the UR magnet is detached from the optic and stuck in the OSEM.

We need a vent to fix the suspension, but until then what we can do is to redistribute the POS/PIT/YAW actuations to the three coils.

Disconcerting because those tip seals were just replaced [15417]. Maybe they were just defective, but if there is a more serious problem with the pump, there is a spare Varian roughing pump (the old TP2 dry pump) sitting at the X-end.

I reset the interlock error to unfreeze the vac controls (leaving V5 closed).

While I stopped by the lab this morning to pick up some things, I took the opportunity to continue the recovery.

• IMC suspensions were sufficiently misaligned that the autolocker couldn't re-acqurie the lock. I manually recovered the alignment and now the IMC is locked again.
• ETMY illuminator was left ON, I turned it off. In the process, I modified the illuminator ON/OFF script to be compatible with python3, but unfortunately, it was written in a way that doesn't permit backward compatibility, so now the illuminators can't be turned ON/OFF via the MEDM screen on pianosa (since the default python is 2.7 on that machine). But it does work on rossa, which I'm using as my primary workstation now (hence the change).
• ITMX watchdog trip threshold was manually reset to the nominal value - the rampdown script was working, but the threshold was ~1400cts (normally ~200 cts) even at 1130am this morning (>12 hours after Koji's work yesterday evening), so I just accelerated the process.
• Suspension realignment - using a mix of green and IR beams and the various cameras/photodiodes as diagnostics, I roughly restored the alignment of all the suspensions, except ETMY. I can see IR resonances in the X arm now.

At some point, we should run the suspension eigenmode routine (kick optics, let them ringdown, measure peak locations and Qs) to confirm that the remaining suspensions are okay, will also help in actuation re-allocation efforts on ETMY. But I didn't do this today.

Leaving the lab at 1150.

See Attachment #1.

• The original ETMY actuation matrix was the naive one so I simply retuned everything by adding the butterfly mode appropriately.
• The cross coupling between the DOFs has not been characterized, but the local damping, Oplev loops, POX/POY locking, simpel Michelson locking, and ASS dither alignemnt all seem to work so I'm thinking this is good enough for now.
• A copy of the ETMYaux.db file was made, and the slow bias voltage was redistributed among the three available face OSEMs - note that the magnet polarity has to be taken into account.
• The series resistance on the slow path was reduced from 430 ohms, 1W to 100 ohms, 3W, to allow DC alignment of the cavity axis to the beam axis.
• Vertex Oplevs were re-centered on their respective QPDs after locking POX/POY and running the ASS dither alignment.
• The AS spot was a little low on the camera - presumably the SR2/SR3 got macroscopically misaligned. I re-centered the beam on the camera on the AS table (by moving the camera, the beam path was not disturbed).

The beam spot on ETMY looks weird (looks almost like a TEM10 mode), but the one on ITMY seems fine, see Attachment #2. Wonder what's going on there, maybe just a focusing problem?

I removed the forepump (Varian SH-110) for TP3 today to see why it had failed over the weekend. I tested it in the C&B lab and the ultimate pressure was only ~40torr. I checked the tip seals and they were destroyed. The scroll housing also easily pulled off of the motor drive shaft, which is indicative of bad bearings. The excess travel in the bearings likely led to significant increase in tip seal wear. This pump will need to be scrapped, or rebuilt.

I tested the spare Varian SH-110 pump located at the X-end and the ultimate pressure was ~98 mtorr. This pump had tip seals replaced on 11/5/18, and is currently at 55163 operating hours. It has been installed as the TP3 forepump.

Once installed, restarting the pump line occured as follows: V5 Closed, VA6 closed, VASE Closed, VASV closed, VABSSCI closed, VABS closed, VABSSCO closed, VAEV closed, VAEE closed,TP3 was restarted and once at normal operation, valves were opened in same order.

The pressure differential interlock condition for V5 was temporaily changed to 10 torr (by Gautam), so that valves could be opened in a controlled manner. Once, the vacuum system was back to normal state the V5 interlock condition was set back to the nominal 1 torr. Vacuum system is now running normally.

The HEPA filters on the PSL enclosure are no longer running. I tried cycling the power switch on the NW corner of the enclosure, and also turned the dial on the Variac down to zero and back up to maximum, no effect. Judging by the indicator LED on it, the power is making it to the Variac - bypassing the Variac and directly connecting the HEPA to the AC power seems to have no effect either.

I can't be sure, but I'm almost certain I heard them running at max speed an hour ago while I was walking around inside the VEA. Probably any damage that can happen has already been done, but I dialled down the Innolight injection current, and closed its shutter till the issue can be resolved.

I came to the lab. The control room AC was off -> Now it is on.

Here is the setting of the AC meant for continuous running

I got some feedback from Koji who pointed out that the phase tracker is not required here. This situation is similar to the phase locking of two lasers together, which we frequently do, except in that case, we usually we offset the absolute frequencies of the two lasers by some RF frequency, and we demodulate the resulting RF beatnote to use as an error signal. We can usually acquire the lock by simply engaging an integrator (ignoring the fact that if we actuate on the laser PZT, which is a frequency actuator, just a proportional feedback will be sufficient because of the phase->frequency conversion), the idea being that the error signal is frequently going through a zero-crossing (around which the sinusoidal error signal is approximately linear) and we can just "catch" one of these zero crossings, provided we don't run of actuation range.

So the question here becomes, is the RF44 signal a suitable error signal such that we can close a feedback loop in a similar way? To try and get more insight, I tried to work out the situation analytically. I've attached my thinking as a PDF note. I get some pretty messy complicated expressions for the RF44 signal contributions, so it's likely I've made a mistake (though Mathematica did most of the heavy lifting), it'll benefit from a second set of eyes. 

Anyways, I definitely think there is some additional complications than my simple field cartoon from the preceeding elog would imply - the relative phases of the sidebands seem to have an effect, and I still think the lack of the PRC/SRC make the situation different from what Hang/Teng et. al. outlined for the A+ homodyne phase control analysis. Before the HEPA failed, I had tried closing the feedback loop using one quadrature of the demodulated RF44 signal, but had no success with even a simple integrator as the loop (which the experience with the PLL locking says should be sufficient, and pretty easily closed once we see a sinusoidally oscillating demodulated error signal). But maybe I'm overlooking something basic conceptually?

Gautam reported that the PSL HEPA stopped running (ELOG 15592). So I came in today and started troubleshooting.

It looks like that the AC power reaches the motors. However, both motors do not run. It looks like the problem exists in the capacitors, the motors, or both.
Parts specs can be found in the next ELOG.

Attachment 1 is the connection diagram of the HEPA. The AC power is distributed by the breaker panel. The PSL HEPA is assigned to use M22 breaker (Attachment 2). I checked the breaker switch and it was (and is) ON. The power goes to the junction box above the enclosure (Attachment 3). A couple of wires goes to the HEPA switch (right above the enclosure light switch) and the output goes to the variac. The inside of the junction box looked like this (Attachment 4).

By the way, the wires were just twisted and screwed into a metal threaded (but isolated) caps (Attachment 5). Is this legit? Shouldn't we use stronger crimping? Anyway, there was nothing wrong with the caps w.r.t the connection for now.

I could easily trace the power up to the variac. The variac output was just fine (Attachment 6). The cord goes from the variac to the junction box (and then HEPAs) looked scorched. The connection from the plug to HEPAs was still OK, but this should be eventually replaced. Right now the cable was unplugged after the following tests for the safety reason.

The junction box for each HEPA unit was opened to check the voltage. The supply voltage came to the junction boxes and it was just fine. In Attachments 8 & 9, the voltages look low but this is because I just turned the variac only a little.

At the (main) junction box, the resistances of the HEPAs were checked with the Fluke. As the HEPA units are connected to the AC in parallel, the resistances were individually checked as follows.

The coils were not disconnected (... I wonder if the wiring of South HEPA was flipped? But this is not the main issue right now.)
 

By removing the pre-filters, the motors were inspected Attachments 10 & 11. At least the north HEPA motor was warm, indicating there was some current before. A capacitor was connected per motor. When the variac was tuned up a bit, one side of the capacitor could see the voltage. I could not judge which has the issue between the capacitor and the motor.

Dimensions / Specs

- HEPA unit dimentions
- HEPA unit manufacturer
- Motor
- Capacitor

The interlocks tripped at ~630am local time. Jordan reported that TP2 was supposedly running at 52 C (!).

V1 was already closed, but TP2 was still running. With him standing by the rack, I remotely exectued the following sequence:

• VM1 closed (isolates RGA volume).
• VA6 closed (isolates annuli from being pumped).
• V7 opened (TP3 now backs TP1, temporarily, until I'm in the lab to check things out further).
• TP2 turned off.

Jordan confirmed (by hand) that TP2 was indeed hot and this is not just some serial readback issue. I'll do the forensics later.

Here is the timeline. This suggests TP2 backing RP failure.

1st line: TP2 foreline pressure went up. Accordingly TP2 P, current, voltage, and temp went up. TP2 rotation went down.

2nd line: TP2 temp triggered the interlock. TP2 foreline pressure was still high (10torr) so TP2 struggled and was running at 1 torr.

3rd line: Gautam's operation. TP2 was isolated and stopped.

Between the 1st line and 2nd line, TP2 pressue (=TP1 foreline pressure) went up to 1torr. This made TP1 current increased from 0.55A to 0.68A (not shown in the plot), but TP1 rotation was not affected.

I removed the forepump to TP2 this morning after the vacuum failure, and tested in the C&B lab. I pumped down on a small volume 10 times, with no issue. The ultimate pressure was ~30 mtorr.

I re-installed the forepump in the afternoon, and restarted TP2, leaving V4 closed. This will run overnight to test, while TP3 backs TP1.

In order to open V1, with TP3 backing TP1, the interlock system had to be reset since it is expecting TP2 as a backing pump. TP2 is running normally, and pumping of the main volume has resumed.

gautam 2030:

1. The monitor (LCD display) at the vacuum rack doesn't work - this has been the case since Monday at least. I usually use my laptop to ssh in so I didn't notice it so it could have been busted from before. But for anyone wishing to use the workstation arrangement at 1X8, this is not great. Today, we borrowed the vertex laptop to ssh in, the vertex laptop has since been returned to its nominal location.
2. The modification to the interlock condition was made by simply commenting out the line requiring V4 to be open for V1 to be opened. I made a copy of the original .yaml file which we can revert to once we go back to the normal config.
3. I also opened VM1 to allow the RGA scans to continue to be meaningful.
4. At the time of writing, all systems seem nominal. See Attachment #2. The vertical line indicates when we started pumping on the main volume again earlier today, with TP3 backing TP1.

​Unclear why the TP2 foreline pump failed in the first place, it has been running fine for several hours now (although TP2 has no load, since V4 isolates it from the main volume). Koji's plots show that the TP2 foreline pressure did not recover even after the interlock tripped and V4 was closed (i.e. the same conditions as TP2 sees right now).

I was in the lab from 1630-1830. I have located and visually inspected all the parts required for the magnet regluing / optic cleaning parts of the planned vent, except the fresh batches of scpectroscopic grade solvents. I was in the cleanroom part of the clean and bake lab from 1630-1700.

[JV, GV]

The HEPAs work again. After running the HEPAs for ~1 hour, I checked the particle count on the PSL table - the meter registered 0 for both 0.3 um and 0.5 um. So I decided to turn the NPRO back on, at ~1730 local time. The PMC and IMC were readily locke, so the basic interferometer functionality is returned, and we can now go ahead with (i) vent prep (ii) air BHD tests and (iii) IMC debuggin as was discussed on the call today. The earth is shaking, but nothing serious so far, I will resume alignment of the interferometer later in the evening when hopefully things have calmed down a bit more...

Procedure:

1. Turned off mains switch on the NW corner of the PSL enclosure. Then, disconnected the power cables from mains to Variac and from Variac to HEPAs. Made sure both HEPAs were set to "OFF".
2. With confidence that no AC power was reaching the motors, I removed the pre-filters, and removed the old startup capacitors. These don't have a polarity, but I marked the cable that was connected to the left terminal of the capacitor when the cap is viewed with the label facing you, in the interest of changing as few things as possible.
3. The two new capacitors were measured with the LCR meter - the meter registered ~7.5 uF, as expected. Unsurprisingly, the old capacitors that were removed didn't register any reading on the LCR meter. The terminals weren't shorted, but I don't know what the failure mode for this kind of capacitor is.
4. The two new capacitors were installed. Then, I tested the system by undoing all the changes in bullet #1. We found that the Variac needs to be set to 100% for the motors to startup.
5. The motor speed was found to vary as the Variac dial was turned. FWIW, at the "nominal" setting of 33% on the Variac (when we run the interferometer), I could see both fan blades were turning, but the flow was low enough that you couldn't hear any wind (at least, neither Jordan nor I could).
6. Turned off the mains agian, and cleaned up - restored the insulating rubber sleeve on the capacitor leads, and re-installed the pre-filters on the HEPA blowers. Then we turned both blowers back on. 

Note that the many other issues Koji noted in the preceeding elog (e.g. flaky wiring) have not been addressed.

Flow measurements:

Chub kindly provided us with an electronic anemometer. With the meter held directly against the HEPA filter inside the enclosure, we measured ~700 cfm of airflow on each of the two HEPAs, with the Variac set to 100% and the HEPAs themselves set to "High". With the Variac at 50%, the flow drops to ~160 cfm. At the nominal setting of 33%, the meter didn't register any flow. I don't know what the spec'd flow rate is for this combination of blower + filter, but Jordan says similar units in Downs register ~1500 cfm at the "High" setting. The two protable (similarly sized) HEPA units in the 40m, one at ITMY and one at ETMY, register ~900 cfm and ~1100 cfm respectively, when set to high. So we may want to revisit what the "nominal" HEPA setting should be, in case the filters have become clogged over time. 

Some photos of the HEPA blowers with the pre-filters off and the capacitors switched out may be found here.

it would be a good idea for us to have an auto-reminder to have us check the flow of all the HEPAs in the lab and elog it once a year so that we can replace filters and pre-filters appropriately.

The optomechanics stock in the lab was in a sad state. We have obtained the following from Thorlabs in the last two months:

1. 6 pcs each of DT12 and DT12B compact translation stages (for lens mode matching).
2. 3pcs each KM100PM + PM3 cube beamsplitter mounts (for polarization control).
3. 1 Post / spacer kit for height adjustment.
4. 3 pcs ea of K6XS + AD11F + F220APC for fiber applications.

I have used some of these for the ari BHD setup. The unused items are stored in the shelves that house the optomechanics ~halfway down the east arm. I'm wondering what's a good setup to document the stock of this stuff so we can always have a healthy stock of optomechanics (at least the non speciality ones like posts, spacers etc). It sucks to realize at 0000hrs that you're missing a 3mm shim or 250mm converging lens or something.

Attachment #1 shows that the ITMX, ETMY and beamsplitter Oplev light levels have decayed significantly from their values when installed. In particular, the ETMY and ITMX sum channels are now only 50% of the values when a new HeNe was installed. ELOG search revealed that ITMY and ETMX HeNes were replaced with newly acquired units in March and September of last year respectively. The ITMX oplev was also replaced in March 2019, but the replacement was a unit that was being used to illuminate our tourist attraction glass fiber at EX.

We should replace these before any vent as they are a useful diagnostic for the DC alignement reference.

2x500 ml bottles of spectroscopic grade isopropanol were delivered. I marked them with today's date and placed them in the solvent cabinet. In the process, my shoulder bumped the laser interlock switch by the door to the VEA in the drill press area, which turned the PSL NPRO off. I turned it back on just now. The other NPROs are not connected to the interlock and so were unaffected.

Attachment #1 shows that the c1rfm model isn't able to receive any signals from the front end machines at EX and EY. Attachment #2 shows that the problem appears to have started at ~430am today morning - I certainly wasn't doing anything with the IFO at that time.

I don't know what kind of error this is - what does it mean that the receiving model shows errors but the sender shows no errors? It is not a new kind of error, and the solution in the past has been a series of model reboots, but it'd be nice if we could fix such issues because it eats up a lot of time to reboot all the vertex machines. There is no diagnostic information available in all the places I looked. I'll ask the CDS group for help, but I'm not sure if they'll have anything useful since this RFM technology has been retired at the sites (?).

In the meantime, arm cavity locking in the usual way isn't possible since we don't have the trigger signals from the arm cavity transmission. 

Update 1500 4 Oct: soft reboots of models didn't do the trick so I had to resort to hard reboots of all FEs/expansion chassis. Now the signals seem to be okay.