• Aligned IFO to IR.
  • Ran dither alignment to maximize arm transmission.
  • Centered Oplev reflections onto their respective QPDs for ITMs, ETMs and BS, as DC alignment reference. Also updated all the DC alignment save/restore files with current alignment. 
• Undid the first 5 bullets of elog13325. The AUX laser power monitor PD remains to be re-installed and re-integrated with the DAQ.
  • I stupidly did not refer to my previous elog of the changes made to the X end table, and so spent ages trying to convince Johannes that the X end green alignment had shifted, and turned out that the green locking wasn't going because of the 50ohm terminator added to the X end NPRO PZT input. I am sorry for the hours wasted 
  • GTRY and GTRX at levels I am used to seeing (i.e. ~0.25 and ~0.5) now. I tweaked input pointing of green and also movable MM lenses at both ends to try and maximize this. 
  • Input green power into X arm after re-adjusting previously rotated HWP to ~100 degrees on the dial is ~2.2mW. Seems consistent with what I reported here.
  • Adjusted both GTR cameras on the PSL table to have the spots roughly centered on the monitors.
  • Will update shortly with measured OLTFs for both end PDH loops.
  • X end PDH seems to have UGF ~9kHz, Y end has ~4.5kHz. Phase margin ~60 degrees in both cases. Data + plotting code attached. During the measurement, GTRY ~0.22, GTRX~0.45.

Next, I will work on commissioning the BEAT MOUTH for ALS beat generation. 

Note: In the ~40mins that I've been typing out these elogs, the IR lock has been stable for both the X and Y arms. But the X green has dropped lock twice, and the Y green has been fluctuating rather more, but has mangaged to stay locked. I think the low frequency Y-arm GTRY fluctuations are correlated with the arm cavity alignment drifting around. But the frequent X arm green lock dropouts - not sure what's up with that. Need to look at IR arm control signals and ALS signals at lock drop times to see if there is some info there.

After some more tweaking, I feel like I may be getting closer to a cost-function definition that works.

• The main change I made was to effectively separate the BR-bandstop filter poles/zeros and the rest of the poles and zeros.
• So now the input vector is still a list of highest pole frequency followed by frequency separations, but I can specify much tighter frequency bounds for the roots of the part of the transfer function corresponding to the Bounce/Roll bandstops.
• This in turn considerably reduces the swarming area - at the moment, half of the roots are for the notches, and in the (f0,Q) basis, I see no reason for the bounds on f0 to be wider than [10,30]Hz.

Some things to figure out:

1. How the "force" the loop to be AC coupled without explicitly requiring it to be so? What should the AC coupling frequency be? From the (admittedly cursory) sensing noise measurement, it would seem that the Oplev error signal is above sensing noise even at frequencies as low as 10mHz.
2. In general, the loops seem to do well in reducing sensing noise injection - but they seem to do this at the expense of the loop gain at ~1Hz, which is not what we want.
   • I am going to try and run the optimizer with an excess of poles relative to zeros
   • Currently, n(Poles) = n(Zeros), and this is the condition required for elliptic low pass filters, which achieve fast transition between the passband and stopband - but we could just as well use a less rapid, but more monotonic roll-off. So the gain at 50Hz might be higher, but at 200Hz, we could perhaps do better with this approach.
3. The loop shape between 10 and 30Hz that the optimizer outputs seems a but weird to me - it doesn't really quite converge to a bandstop. Need to figure that out.

Five mechcanical traps set inside of boxes. Red-white warning tape on top of each.

MC autolocker got stuck (judging by wall StripTool traces, it has been this way for ~7 hours) because c1psl was unresponsive so I power cycled it. Now MC is locked.

I've been observing this for a few days: ETMX's DC alignment seems to drift by so much that the previously well aligned X arm cavity is now totally misaligned.

The wall StripTool trace shows that both the X and Y arms were locked with arm transmissions around 1 till c1psl conked out - so in the attached plot, around 1400 UTC, the arm cavity was well aligned. So the sudden jump in the OSEM sensor signals is the time at which LSC control to the ETM was triggered OFF. But as seen in the attached plot, after the lockloss, the Oplev signals seem to show that the mirror alignment drifted by >50urad. This level of drift isn't consistent with the OSEM sensor signals - of course, the Oplev calibration could be off, but the tension in values is almost an order of magnitude. The misalignment seems real - the other Oplev spots have stuck around near the (0,0) points where I recentered them last night, only ETMX seems to have undergone misalignment.

Need to think about what's happening here. Note that this kind of "drift" behaviour seems to be distinct from the infamous ETMX "glitching" problem that was supposed to have been fixed in the 2016 vent.

I should've put in the SUSPIT and SUSYAW channels in the previous screenshot. I re-aligned ETMX till I could see IR flashes in the arm, and also was able to lock the green beam on a TEM00 mode with reasonable transmission. As I suspected, this brought the Oplev spot back near the center of it's QPD. But the answer to the question "How much did I move the ETM by" still varies by ~1 order of magnitude, depending on if you believe the OSEM SUSPIT and SUSYAW signals, or the Oplev error signals - I don't know which, if any, of these, are calibrated.

Best to just calibrate the ETM OL in the usual way. I bet the OSEM outputs have a cal uncertainty of ~50% since the input matrix changes as a function of the DC alignment. Still, a 30 urad pitch mis-alignment gives a (30e-6 rad)(40 m) ~ 1 mm beam spot shift. This would be enough to flash other modes, but it would still be easy to lock on a TEM00 like this. I also doubt that the OL calibration is valid outside of some region near zero - can easily check by moving the ETM bias sliders.

What we still don't know is if this is due to Johannes/Aaron working at the ETMX rack (bumping some of the flaky coil cables and/or bumping the blue beams which support the stack). Adding or substracting weight from the stack supports will give us an ETM mis alignment.

This evening I transitioned the slow controls to c1auxex2.

1. Disconnected satellite box
2. Turned off c1auxex
3. Disconnected DIN cables from backplace connectors
4. Attached purple adapter boards
5. Labeled DSub cables for use
6. Connected DSub cables to adapter boards and chassis
7. Initiated modbus IOC on c1auxex2

Gautam and I then proceeded to test basic functionality

1. Pitch bias sliders move pitch, yaw moves yaw.
2. Coil enable and monitoring channels work
3. Watchdog seems to work. We set the treshold for tripping low, excited the optic, watchdog didn't disappoint and triggered.
4. All channels Initialize with "0" upon machine/server script restart. This means the watchdog happens to be OFF, which is good . It would be great if we could also initialize PIT and YAW to retain their value from before to avoid kicking the optic. This is not straightforward with EPICS records but there must be a way.
5. We got the local damping going .
6. There is some problem with the routing of the fast BIO channels through the new chassis - so the ANALOG de-whitening filter seems to be always engaged, despite our toggling the software BIO bits . Something must be wrongly wired, as we confirmed by returning only the FAST BIO wiring to the pre-acromag state (but everything else is now controlled by acromag) and didn't have the problem anymore. Or some electrical connection is not made (I had to use gender changers on these connectors due to lack of proper cabling)
7. The switches for the QPD gain stages did not work. I suspect a wiring problem, since the switching of the coil enables did work.

Arms are locked, have been for ~1hour with no hickups. We will leave it like this overnight to observe, and debug further tomorrow.

Good going Johannes!

I did a cursory check of the ALS signal chain in preparation for commissioning the IR ALS system. The main elements of this system are shown in my diagram in the previous elog in this thread.

Questions I have:

1. Does anyone know what exactly is inside the "Delay Line" box? I can't find a diagram anywhere.
   • Jessica's SURF report would suggest that there are just 2 50m cables in there.
   • There are two power splitters taped to the top of this box.
   • It is unclear to me if there are any active components in the box.
   • It is unclear to me if there is any thermal/acoustic insulation in there.
   • For completeness, I'd like to temporarily pull the box out of the LSC rack, open it up, take photos, and make a diagram unless there are any objections.
2. If you believe the front panel labeling, then currently, the "LO" input of the mixer is being driven by the part of the ALS beat signal that goes through the delay line. The direct (i.e. non delayed) output of the power splitter goes to the "RF" input of the mixer. The mixer used, according to the DCC diagram, is a PE4140. Datasheet suggests the LO power can range from -7dBm to +20dBm. For a -8dBm beat from the IR beat PDs, with +24dB gain from the ZHL3A but -3dB from the power splitter, and assuming 9dB loss in the cable (I don't know what the actual loss is, but according to a Frank Seifert elog, the optimal loss is 8.7dB and I assume our delay line is close to optimal), this means that we have ~4dBm at the "LO" input of the demod board. The schematic says the nominal level the circuit expects is 10dBm. If we use the non-delayed output of the power splitter, we would have, for a -8dBm beat, (-8+24-3)dBm ~13dBm, plus probably some cabling loss along the way which would be closer to 10dBm. So should we use the non-delayed version for the LO signal? Is there any reason why the current wiring is done in this way?

I have just received the scheduling of the PSL self work for tomorrow. Gautam and I agreed that if it is needed I will shut the laser off and cover the hole table with plastic.

I've noticed this a couple of times today - when the autolocker runs the mcdown script, sometimes it doesn't seem to actually change the various gain sliders on the PSL FSS. There is no handshaking built in to the autolocker at the moment. So the autolocker thinks that the settings are correct for lock re-acquisition, but they are not. The PCdrive signal is often railing, as is the PZT signal. The autolocker just gets stuck waiting to re-acquire lock. This has happened today ~3 times, and each time, the Autolocker has tried to re-acquire lock unsuccessfully for ~1hour.

Perhaps I'll add a line or two to check that the signal levels are indicative of mcdown being successfully executed.

After labeling cables I would disconnect, I pulled the box out of the LSC rack. Attachment #1 is a picture of the insides of the box - looks like it is indeed just two lengths of cabling. There was also some foam haphazardly stuck around inside - presumably an attempt at insulation/isolation.

Since I have the box out, I plan to measure the delay in each path, and also the signal attenuation. I'll also try and neaten the foam padding arrangement - Steve was showing me some foam we have, I'll use that. If anyone has comments on other changes that should be made / additional tests that should be done, please let me know.

20180111_2200: I'm running some TF measurements on the delay line box with the Agilent in the control room area (script running in tmux sesh on pianosa). Results will be uploaded later.

Some suggestions of checks to run, based on the rightmost colum in the wiring diagram here - I guess some of these have been done already, just noting them here so that results can be posted.

1. Oplev quadrant slow readouts should match their fast DAQ counterparts.
2. Confirm that EX Transmon QPD whitening/gain switching are working as expected, and that quadrant spectra have the correct shape.
3. Watchdog tripping under different conditions.
4. Coil driver slow readbacks make sense - we should also confirm which of the slow readbacks we are monitoring (there are multiple on the SOS coil driver board) and update the MEDM screen accordingly.
5. Confirm that shadow sensor PD whitening is working by looking at spectra.
6. Confirm de-whitening switching capability - both to engage and disengage - maybe the procedure here can be repeated.
7. Monitor DC alignment of ETMX - we've seen the optic wander around (as judged by the Oplev QPD spot position) while sitting in the control room, would be useful to rule out that this is because of the DC bias voltage stability (it probably isn't).
8. Confirm that burt snapshot recording is working as expected - this is not just for c1auxex, but for all channels, since, as Johannes pointed out, the 2018 directory was totally missing and hence no snapshots were being made.
9. Confirm that systemd restarts IOC processes when the machine currently called c1auxex2 gets restarted for whatever reason.

We'd like to setup the recording of the PSL diagnostic connector Acromag channels in a more robust way - the objective is to assess the long term performance of the Acromag DAQ system, glitch rates etc. At the Wednesday meeting, Rana suggested using c1ioo to run the IOC processes - the advantage being that c1ioo has the systemd utility, which seems to be pretty reliable in starting up various processes in the event of the computer being rebooted for whatever reason. Jamie pointed out that this may not be the best approach however - because all the FEs get the list of services to run from their common shared drive mount point, it may be that in the event of a power failure for example, all of them try and start the IOC processes, which is presumably undesirable. Furthermore, Johannes reported the necessity for the procServ utility to be able to run the modbusIOC process in the background - this utility is not available on any of the FEs currently, and I didn't want to futz around with trying to install it.

One alternative is to connect the PSL Acromag also to the Supermicro computer Johannes has set up at the Xend - it currently has systemd setup to run the modbusIOC, so it has all the utilities necessary. Or else, we could use optimus, which has systemd, and all the EPICS dependencies required. I feel less wary of trying to install procServ on optimus too. Thoughts?

Both issues were fixed. In both cases it was two separate causes that prevented them from working.

The QPD gain stage switch software channels were assigned to wrong physical pins of the Acromag, and additionally their DSub cable was swapped with a different one.

The BIO switching had its signal and ground wires swapped on ALL connections, and part of it was also suffering from the cable-mixup.

Both issues were fixed. All backplane signals are now routed through the Acromag chassis.

Gautam and I did notice that occasionally ETMX alignment will start drifting as evident from the OpLev. I want to set up a diagnostic channel to see if the DAC voltages coming from the Acromag are responsible for this.

Measurements for good fit were made. The new shelf will be installed on next Tuesday at 2pm

The reference cavity ion pump is in the way  so the cavity will be moved 5" westward. The shelf height space will be 10"  Under shelf working height 18" to optical table.

After much googling, I figured out how to install pip on SL7:

Next, I installed git:

Turns out, actually, pip can be installed via yum using

Steve and I removed c1auxex from 1X9 today to make space for the DAQ chassis. Steve installed rails for mounting. To install the box I had to remove all cabling, for which I used the usual precautions (disconnect satellite box etc.)

On reconnect c1auxex2 didn't initialize the physical EPICS channels (the 'actual' acromag channels), apparently it had trouble communicating. A reboot fixed this. It's possible that this is because of the direct cable connection without a network switch that exists
between the Acromags and c1auxex. The EPICS server was started automatically on reboot.

Currently the channel defaults need to be loaded manually after every EPICS server script restart with burt. I'm looking for a good way to automate this, but the only compiled burt binaries for x86 (that we can in principle run on c1auxex2 itself) on the martian network are from EPICS version 3.14.10 and throw a missing shared object error. Could be that simply some path variable is missing.

The burt binaries are not distributed by the lscsoft or cdssoft packages, so alternatively we would need to compile it ourselves for x86 or get it working with the older epics version.

Looks like this problem presisted over the weekend - Attachment #1 is the wall StripTool trace for PSL diagnostics, seems like the control signal to the NPRO PZT and FSS EOM were all over the place, and saturated for the most part.

I traced down the problem to an unresponsive c1iool0. So looks like for the IMC autolocker to work properly (on the software end), we need c1psl, c1iool0 and megatron to all be running smoothly. c1psl controls the FSS box gains through EPICS channels, c1iool0 controls the MC servo board gains through EPICS channels, and megatron runs the various scripts to setup the gains for either lock acquisition or in lock states. In this specific case, the autolocker was being foiled because the mcdown script wasn't running properly - it was unable to set the EPICS channel C1:IOO-MC_VCO_GAIN to its lock acquisition value of -15dB, and was stuck at its in-lock value of +7dB. Curiously, the other EPICS channels on c1iool0 seemed readable and were reset by mcdown. Anyways, keying the c1iool0 crate seems to have fixed the probelm.

While moving the RefCav to facilitate the PSL shelf install, I bumped the power cable to the AOM driver. I will re-solder it in the evening after the shelf installation. PMC and IMC have been re-locked. Judging by the PMC refl camera image, I may also have bumped the camera as the REFL spot is now a little shifted. The fact that the IMC re-locked readily suggests that the input pointing can't have changed significantly because of the RefCav move.

[ Johannes, Rana, Mark and Steve ]

On the second trial the shelf was installed. Plastic cover removed. South end door put back on and 2W Inno turned on.

Shelf 10 " below the existing one:   92" x 30" x 3/4" melamine (or MDF) covered with white Formica.  200 lbs it's max load. Working distance to top of the table 18"

Johannes informed me that he touched up the PMC REFL camera alignment. I am holding off on re-soldering the AOM driver power as I could use another pair of hands getting the power cable disentangled and removed from the 1X2 rack rails, so that I can bring it out to the lab and solder it back on.

Is anyone aware of a more robust connector solution for the type of power pins we have on the AOM driver?

With Johannes' help, I re-installed the box in the LSC electronics rack. In the end, I couldn't find a good solution to thermally insulate the inside of the box with foam - the 2U box is already pretty crowded with ~100m of cabling inside of it. So I just removed all the haphazardly placed foam and closed the box up for now. We can evaluate if thermal stability of the delay line is limiting us anywhere we care about and then think about what to do in this respect. This box is actually rather heavy with ~100m of cabling inside, and is right now mounted just by using the ears on the front - probably should try and implement a more robust mounting solution for the box with some rails for it to sit on.

I then restored all the cabling - but now, the delayed part of the split RF beat signal goes to the "RF in" input of the demod board, and the non-delayed part goes to the back-panel "LO" input. I also re-did the cabling at the PSL table, to connect the two ZHL3-A amplifier inputs to the IR beat PDs in the BeatMouth instead of the green BBPDs.

I didn't measure any power levels today, my plan was to try and get a quick ALS error signal spectrum - but looks like there is too much beat signal power available at the moment, the ADC inputs for both arm beat signals are overflowing often. The flat gain on the AS165 (=ALS X) and POP55 (=ALS Y) channels have been set to 0dB, but still the input signals seem way too large. The signals on the control room spectrum analyzer come from the "RF mon" ports on the demod board, and are marked as -23dBm. I looked at these peak heights with the end green beams locked to the arm cavities, as per the proposed new ALS scheme. Not sure how much cable loss we have from the LSC rack to the network analyzer, but assuming 3dB (which is the Google value for 100ft of RG58), and reading off the peak heights from the control room analyzer, I figure that we have ~0dBm of RF signal in the X arm. => I would expect ~3dBm of signal to the LO input. Both these numbers seem well within range of what the demod board is designed to handle so I'm not sure why we are saturating.

Note that the nominal (differential) I and Q demodulated outputs from the demod board come out of a backplane connector - but we seem to be using the front panel (single-ended) "MON" channels to acquire these signals. I also need to update my Fiber ALS diagram to indicate the power loss in cabling from the PSL table to the LSC electronics rack, expect it to be a couple of dB.

1. I take back what I said about the OSEM PD mon at the meeting - there does seem to be to be some overall calibration factor (Attachment #1) that has scaled the OSEM PD readback channels, by a factor of (20000/2^15), which Johannes informs me is some strange feature of the ADC, which he will explain in a subsequent post.
2. The coil redback fields on the MEDM screen have a "30Hz HPF" text field below them - I believe this is misleading. Judging by the schematic, we are monitoring, on the backplane (which is what these channels are reading back from), the coil to the voltage with a gain of 0.5. We can reconfirm by checking the ETMX coil driver board, after which we should remove the misleading label on the MEDM screens.

This happened because there are multiple ways to scale the raw value of an EPICS channel to the desired output range. In the CryoLab I was using one way, but the EPICS records I copied from c1auxex were doing it differently. Basically this:

If the "LINR" field is set to "LINEAR", the fields EGUF and EGUL are used to convert the raw value to the channel value VAL. To use them, one needs to enter the voltages that return the maximum and minimum values expected for the given data type. It used to be +10V and -10V, respectively, and was copied that way but that doesn't work with the data type required for the Acromag units. For -some- reason, while the the ADC range is -10V to +10V, this corresponds to values -20000 to +20000, while for the DAC channels it's -30000 to +30000. I had observed this before when setting up the DAQ in the CryoLab, but there we were using "NO CONVERSION", which skips the EGUF and EGUL fields, and used the ASLO and AOFF for manual scaling to get it right. When I mixed the records from there with the old ones from c1auxex this got lost in translation. Gautam and I confirmed by eye that this indeed explains the different levels well. This means that the VMon channelsfor the coils are also showing the wrong voltages, which will be corrected, but the readback still definitely works and confirms that the enable switches do their job.

Summary:

I am facing two problems:

1. The X arm beat seems to be broadband noisier than the Y arm beat - see Attachment #1. The Y-axis calibration is uncertain, but at least the Y beat has the same profile as the reference traces, which are for the green beat from a time when we had ALS running. There is also a rather huge ~5kHz peak, which I confirmed isn't present in the PDH error/control signal spectra (with SR785).
2. The Y-arm beat amplitude, at times, "breathes" in amplitude (as judged by control room analyzer). Attachment #2 is a time-lapse of this behaviour (left beat is X arm beat, right peak is the Y arm peak) - I caught only part of it, the the beat note basically vanishes into the control room noise floor and then comes back up to almost the same level as the X beat. The scale is 10dB/div. During this time, the green (and IR for that matter) stay stably locked to the arm - you'll have to take my word for it as I have no way to sync my video with StripTool Traces, but I was watching the DC transmission levels the whole time. The whole process happens over a few (1< <5) minutes - I didn't time it exactly. I can't really say this behaviour is periodic either - after the level comes back up, it sometimes stays at a given level almost indefinitely.

More details:

• Spent some time today trying to figure out losses in various parts of the signal chain, to make sure I wasn't in danger of saturating RF amplifiers. Cabling from PSL table -> LSC rack results in ~2dB loss.
• I will upload the updated schematic of the Beat-Mouth based ALS - I didn't get a chance to re-measure the optical powers into the Beat Mouth, as someone had left the Fiber Power Meter unplugged, and it had lost all of its charge .
• The Demod boards have a nice "RF/LO power monitor" available at the backplane of the chassis - we should hook these channels up to the DAQ for long term monitoring.
  • The schematic claims "120mV/dBm" into 50ohms at these monitoring pins.
  • I measured the signal levels with a DMM (Teed with 50ohm), but couldn't really make the numbers jive - converting the measured backplane voltage into dBm of input power gives me an inferred power level that is ~5dBm higher than the actual measured power levels (measured with Agilent analyzer in Spectrum Analyzer mode).
• Looking at the time series of the ALS I and Q inputs, the signals are large, but we are well clear of saturating our 16-bit ADCs.
• In the brief periods when both beats were stable in amplitude (as judged by control room analyzer), the output of the Q quadrature of the phase tracker servo was ~12,000 cts - the number I am familiar with for the green days is ~2000cts - so naively, I would say we have ~6x the RF beat power from the Beat Mouth compared to green ALS.
• I didn't characterize the conversion efficiency of the demod boards so I don't have a V (IF)/V (RF) number at the moment.
• I confirmed that the various peaks seen in the X arm beat spectrum aren't seen in the control signal of the EX Green PDH, by looking at the spectrum on an SR785 (it is also supposedly recorded in the DAQ system, but I can't find the channel and the cable is labelled "GCX-PZT_OUT", which doesn't match any of our current channels).
  Note to self from the future: the relevant channels are: C1:ALS-X_ERR_MON_IN1 (green PDH error signal with x10 gain from an SR560) and C1:ALS-X_SLOW_SERVO_IN1 (green PDH control signal from monitor point - I believe this is DC coupled as this is the error signal to the slow EX laser PZT temp control). I've changed the cable labels at the X end to reflect this reality. At some point I will calibrate these to Hz.
• The control room analyzer signals come from the "RF mon" outputs on the demod board, which supposedly couple the RF input with gain of -23dBm. These are then routed reverse through a power splitter to combine the X and Y signals, which is then plugged into the HP analyzer. The problem is not local to this path, as during the "breathing" of the Y beat RF amplitude, I can see the Q output of the phase tracker also breathing.

Next steps (that I can think of, ideas welcome!):

1. For Problem #1 - usual debugging tactic of switching X and Y electronics paths to see if the problem lies in the light or in the electronics. If it is in the electronics, we can swap around at various points in the signal chain to try and isolate the problematic component.
2. For Problem #2 - hook up the backplane monitor channels to monitor RF amplitudes over time and see if the drifts are correlated with other channels.
3. There is evidence of some acoustic peaks, which are possibly originating from the fibers - need to track these down, but I think for a first pass to try and get the red ALS going, we shouldn't be bothered by these.

c1psl, c1susaux, and c1auxey today

I swapped the inputs to the ZHL-3A at the PSL table - so now the X beat RF signals from the beat mouth are going through what was previously the Y arm ALS electronics. From Attachment #1, you can see that the Y arm beat is now noisier than the X. The ~5kHz peak has also vanished.

So I will pursue this strategy of switching to try and isolate where the problem lies...

Somebody had forgotten to turn the HEPA variac on the PSL table down. It was set at 70. I set it at 20, and there is already a huge difference in the ALS spectra

Rendered the SOS assembly (D960001) with correct materials and all and it looks very nice. Will extend this to the building cad later.

[rana, kevin, udit, gautam]

quick notes of some discussions we had today:

1. Earlier in the day, Udit and I measured (with a 20dB coupler and AG4395) ~20dBm of RF beat power at input to power splitter (just before delay line box) at the LSC rack. This means that we have ~17dBm going into the LO input of the demod board. The AP1053 can only really handle a max of 16dBm at the input. After discussion with Rana, I put a 3dB attenuator at the input to the power splitter so as to preserve the LO/RF ratio in the demod circuit.
2. Need to make a detailed optical and RF power budget for both arms.
3. The demod circuit board is configured to have gain of x100 post demod (conversion loss of the mixer is ~-8dB). This works well for the PDH cavity locking type of demod scheme, where the loop squishes the error signal in lock, so most of the time, the RF signal is tiny, and so a gain of x100 is good. For ALS, the application needs are rather different. So we lowered the gain of the "Audio IF amplifier" stage of the circuit from x100 to x10, by effecting the resistor swaps 10ohms->50ohms, 1kohm->500ohms (more details about this later).
4. There is some subtlety regarding the usage of the whitening interface boards - I need to look at the circuit again and understand this better, but Rana advised against running with the whitening gain at low values. Point #3 above should have helped with this regard.
5. I wanted to test the new signal chain (with 3dB attenuation and modified IF gain) but ETMX is not happy now, and is making it impossible to keep the X arm locked. Will try again tomorrow.
6. Eventually: need to measure the mode of the fiber, and up the MM efficiency to at least 80%, which should be doable without using any fancy lenses/collimators.
7. Udit and I felt that the back panel RF power monitor wasn't working as expected - I will re-investigate this when I have the board out again to make the IF gain change permanent with the right footprint SMD resistors.

RXA: 0805 size SMD thin film resistors have been ordered from Mouser, to be shipped on Monday. **note that these thin film resistors are black; i.e. it is NOT true that all black SMD resistors are thick film**

We use D990694 in various places. Today, Rana alerted me to an important consideration to be kept in mind when we use this board, which I found quite interesting. I still don't understand the problem at the BJT level, but I think one can appreciate the problem without going to the transistor design of the LT1125. I'm attaching an annotated schematic of the whitening section in question. If the following assumptions are valid, then I think my picture is valid.

1. The switch used to bypass the various whitening gain stages, namely the ADG333ABR, has infinite impedance in the "OFF" state, such that when the 24dB gain stage is bypassed, U28A (or in general one of the 4 quad op-amps) is forced to drive it's output voltage across 1.0665 kohms of resistance.
2. The individual LT1125 Op Amps can drive a maximum of 30mA of current.

Then, as one can see in the attached schematic, when we set the gain of any input to <24dB, we must ensure that the input voltage is less than approximately 2V. Otherwise, by asking too much of the first stage op-amp in the quad IC LT1125, we may be messign around with all the 4 op amps in the quad! Even the 0dB setting is not immune to this problem, as it uses one of the 4 op amps.

I don't think the usual rules of calculating the gain of a non-inverting amplifier (G = 1 + Rf/Ri) remain valid even when the op-amp is forced to drive more output current than it can, and I don't have a way to quantify the possible interference between the 4 op amps in the quad - but does this seem like a valid conclusion? If so, we must check signal levels of various LSC signals. AS55 signals currently have the 0dB gain setting - I had turned this down from 6dB some months ago, because it seemed like the ADC was saturating at the 6dB gain setting, which suggests that the input voltage is ceratinly > 2V, and AS55_Q is what is used for MICH control in the DRMI. All of my noise budgeting work over the last few months used this setting, I wonder if they are all invalid 

Now that I think about this a bit more - this problem shouldn't be significant for the usual LSC degrees of freedom when in lock, as the huge DC gain of the loop should squish large DC values of the error signals, and so there shouldn't be any danger of overloading the LT1125. But I don't know if we are being hurt by this effect when flashing through resonances, when the PDH horn-to-horn voltage can be quite high (which is in principle a good thing?). I don't know if there is any "hysterisis" effect where the overloaded quad IC has some relaxation time before it returns to normal operation, and if we are being limited in our ability to catch lock because if this effect. 

The concerns remain valid for th ALS demodulated error signals though, for which the signals will remain large throughout.

this is the note from Hartmut Grote on this topic from 2004

After some research: -the- reason for the reduced +/- 20,000 swing in raw values is a default setting for having support for legacy devices enabled when using the acromag proprietary i2o peer-to-peer protocol. So this is doubly unnecessary because a) we don't have any legacy devices at all and b) we're using pure modbus/TCP and no i2o. To change the setting I have to connect via the USB configuration utility. In addition, I want to understand the averaging feature of the acromag units better, which is also configured via USB, and lets one set a fixed amount of samples to be averaged before updating the read-register value. The documentation says that the 8 channels are multiplexed into a single ADC, and that new input data is available after 10 ms for each channel, suggesting a sampling rate of 100 Hz per channel and that the multiplexing happens faster, but is not super-clear about this, so I want to test it in the cryo lab first before unleashing it onto c1auxex2.

Furthermore, the standard timing options for updating epics records are 10s, 5s, 2s, 1s, 0.5s, 0,2s, and 0.1s. On the previous c1auxex, the monitoring channels were set to 0.1s, but that clashes with the 16 Hz global EPICS rate, resulting in partial double-sampling. One can manually provide the option 0.0625s for 16Hz update rate. I will test this and how it deals with the averaging in the cryolab too.

After discussing with Koji, we looked at the aLIGO incarnation of this board. Interestingly, it too has a similar topology of 4 switchable gain stages with gains of 24, 12, 6 and 3dB. The main differences are that they use single Op27 ICs instead of the quad LT1125s, and also, they use a different combination of feedback resistors to realize the various gains. 

We considered upping the feedback resistance (R15, R143) on the 24dB gain stage of our boards from (1k, 66.5ohms) to (3k, 200ohms) as on the aLIGO boards - but this doesn't really help? Because KCL demands that the same current flow in R15 and R143, and so the output Vsat of the op amp and its max current driving capabilities in combination determine if the inverting input can follow the non inverting input?

As Hartmut points out in his note, he was able to access the full range of ADC voltages when the gain was set to 3dB, despite the fact that the LT1125 was still getting internally saturated. Operating with minimum 24dB whitening gain doesn't really solve the problem either because the problem just gets shifted to the next gain stage in the chain, and we still have saturation. I also don't have a feeling for how much differential voltage these LT1125s can sustain before they are damaged - I guess the planned THD check will reveal if they are okay or not.

It seems to me like the only way to truly fix this problem of one stage saturating and screwing up the others is to use single Op27s (or equivalent) in place of the quad LT1125s. The aLIGO design also has a series resistance to the non-inverting input - this can help prevent current overdraw from the previous stage (due to a lowered input impedance of the OpAmp - but I wonder how low this can go?).

I have acquired 5 pieces of the Teledyne AP1053 from Koji - these are now at the 40m. I will determine an appropriate location for storage of these and update. We are also looking to acquire 5 more of these. The combination of high power output (26dBm), low gain (10dB), and low noise figure (1.5dB) are quite uncommon in an amplifier and so these should be used only when such properties are required simultaneously.

*Steve informs me that these amps have been stored in the RF cabinet E6 along the east arm.

Steve's note: Teledyne rf amp product selection guide

                   Teledyne rf low noise amp guide

I did some work on the PSL table today. Main motivations were to get a pickoff for the BeatMouth PSL beam before any RF modulations are imposed on it, and to improve the mode-matching into the fiber. Currently, we use the IR light reflected by the post doubling oven harmonic separator. This has the PMC modulation sideband on it, and also some green leakage. 

So I picked off ~8.5mW of PSL light from the first PBS (pre Faraday rotator), out of the ~40 mW available here, using a BS-80-1064-S. I dumped the 80% reflected light into the large beam dump that was previously being used to dump this PBS reflection. Initially, I used a R=10% BS for S-pol that I found on the SP table, but Koji tipped me off on the fact that these produce multiple reflected beams, so I changed strategy to use the R=80% BS instead.

The transmitted 20% is routed to the West edge of the PSL table via 2 1" Y1-1037-45S optics, towards the rough vicinity of the fiber coupler. For now it is just dumped, tomorrow I will work on the mode matching. We may want to cut the power further - ideally, we want ~2.5mW of power in the fiber - this is then divided by 4 inside the beat mouth before reaching the beat PD, and with other losses, I expect ~500mW of PSL power and comparable AUX light, we will have a strong >0dBm beat.

Attachment #1 is a picture of my modifications. For this work, I

• Closed PSL shutter, turned HEPA up 
• Moved HP GHz spec analyzer to the side for ease of access to the table.
• Moved several optics that look to me as to have once been part of the RefCav setup - I don't think this would have been a useful alignment reference in any case as we moved the RefCav in a non-deterministic way for the PSL secondary shelf install.
• Used one 1" 45 deg S-pol optic from the optics cabinet - remaining optics were scavenged from PSL table and SP table.
• Removed an SMA cable connected to an EOM, whose other end wasn't connected to anything.
• Turned HEPA back down, IMC locks fine now.

I plan to do some characterization of this problem. The plan is to use THD as a metric for whether we are having hidden saturations. Pg 9 of the LT1125 datasheet tells us what fraction of THD to expect. I will use one of the several unused DAC channels available at the LSC rack to drive a 100Hz sine wave into one of the inputs of the whitening chassis, and measure the THD up to a reasonable harmonic number (will probably be set by the ADC noise) for (i) various whitening gain settings and (ii) various input signal amplitudes.

The motivation is to attempt to quantify the problem better:

1. How bad is it to have one or more of the OpAmps in the quad IC either saturated to its voltage rails, or max output current?
2. Can we reproduce Hartmut's observations?
3. Are the OpAmps already irreversibly damaged because of extended abuse?

Then we can decide what, if anything, to do about this issue.

On Friday, while Udit and I were doing some characterization of the EX+PSL IR beat at the LSC rack, I noticed that there were sidebands around the main beat peak at 20dBm lower level. These were offset from the main peak by ~200kHz - I didn't do a careful characterization but because of the symmetric nature of these sidebands and the fact that they appeared with the same offset from the main peak for various values of the central beat frequency, I hypothesize that these are from the modulation sidebands we use for PDH locking the EX laser to the arm cavity. So we can estimate the modulation depth from the relative powers of the main beat peak and the ~200kHz offset sidebands.

Since the IR light is used for the beat and we directly couple it to the fiber to make the beat, there is no green or IR cavity pole involved here. 20dBm in power means . And so the modulation depth, . I will do a more careful meaurement of this, but this method of measuring the modulation depth can give us a precise estimate - for what it's worth, this number is in the same ballpark as the measurement I quote in elog12105.

What is the implication of having these sidebands on our ALS noise? I need to think about this, effectively the phase noise of the SR function generators we use to do the phase modulation of the EX laser is getting imprinted on the ALS noise? Is this hurting us in any frequency range that matters?

I was looking into the physics of polarization maintaining fibers, and then I was trying to remember whether the fibers we use are actually polarization maintaining. Looking up the photos I put in the elog of the fibers when I cleaned them some months ago, at least the short length of fiber attached to the PD doesn't show any stress elements that I did see in the Thorlabs fibers. I'm pretty sure the fiber beam splitters also don't have any stress elements (see Attached photo). So at least ~1m of fiber length before the PD sensing element is probably not PM - just something to keep in mind when thinking about mode overlap and how much beat we actually get.  

I replaced the two remaining D-Sub M/M cables that still had gender-changers with M/F cables today, completing the mechanical and wiring work on the ETMX rack. All backplane adapter boards were secured to a cross-strut of the crate using zip ties. This was necessary because the adapter boards don't fit the crate with their panels attached ( the ETMX eurocrate is the only one with slightly different dimensions from all the others), and the we can't mount them to the strut using the panels. This won't be an issue on any of the other crates.

In other news:

I disabled the legacy support in the three Acromag ADC units and set the input averaging to 10 samples via the USB configuration utility. The documentation is unfortunately a little sparse about what this actually means. The manual states that "fresh input data is available to the network every 10ms", so the sampling rate is for sure faster than 100Hz. Since the IOC updates its channels every .1 seconds I assume that an averaging value of 10 to reduce the input noise is safe. The maximum value the configuration tool permits is 200. I tried this using the CryoLab DAQ and set all input channels to 200 and used StripTool to look at the time series of a slow oscillation (.1Hz) with a large amplitude (16Vpp) and looked for missed data points, indicating too long wait times for channels updates. There was no such qualitative difference between 1 sample, 10 samples, and 200 samples, so even pushing the averaging value to max seemed okay. I went with the conservative value of 10 for the ETMX DAQ, but we can likely increase this if noise on the slow inputs becomes an issue.

The input scaling of the ADC channels has been corrected. I changed the conversion method in the EPICS records from manual using the ASLO and AOFF fields to using engineering units via EGUF and EGUL. This required a little attention. The Acromags scale the dynamic input range of +/- 10V to +/- 30,000 raw value, but the EPICS IOC interprets the data type as ranging from -32767 to +32768, so the EGUF and EGUL fields must be set to -10.923 and +10.923 to achieve proper scaling. I also changed the SCAN field on all ADC channels to 0.1 seconds. This has been done for all ADC and DAC channel records.

I compiled the burt binaries on c1auxex2 which took a little fiddling with dependencies and paths but nothing too major. The complete local epics folder (/opt/epics/) which contains the base epics binaries, modbus and burt for 32-bit linux has been copied to the shared drive at /opt/rtapps/epics-3.15.5. They belong to the most recent stable release. This was so we can now automatically call burt after the IOC initialization on c1auxex2 to restore the backed-up channel values.

I also copied the database definition and modbus instruction files to /cvs/cds/caltech/target/c1auxex2, from where they are now being read upon IOC initialization. This is an excerpt of the service file:

Note 1) I removed the logging to file for now because I noticed that if there are Acromag communication issues the logfile tends to grow in size VERY fast. In the cryo lab is had gotten to over 70GB just over the winter break. I don't think it's absolutely necessary to have it, and if diagnostics are needed we can easily uncomment it temporarily.

Note 2) I modified the static EPICS records of the four OSEM bias adjust channels so they won't start updating as soon as the IOC starts up (and before the channel defaults are restored by burt). This was done by setting the OMSL (output mode select) field from "closed_loop" to "supervisory". Sample record:

Now, on reboort/IOC re-initialization the physical DAC channels are performing a one-time readback of the last stored value in the Acromag's register, then idle until the last StartPost statement executes the script ETMXaux.sh, which changes their OMSL field back to "closed_loop". This causes them to start updating their output from the calc records defined in their DOL field (which have by then recovered their default values curtesy of burt). The result is a smooth transition from idling to the controlled state with no sudden or large offset changes.

[Gautam, Johannes]

While checking how smooth the transition is we still noticed significant motion of ETMX by looking at the locked green laser and OpLevs. We found that this motion was not caused by interruption of the slow offset adjust, but rather the Watchdog being re-initialized to its OFF state, which cuts the fast channels OFF. On other optics this is observed too, but not as severe. The cause is a rather large offset on the LR coil coming from the fast DAQ, which was reported as 50mV by the slow readback channel (while other readback values are <10mV). It is present even when turning the output of the CDS model OFF, but vanishes when the watchdog is triggered. This helped us trace it to an offset of the DAC output itself: it is present at the output of the AI board but vanishes when the DAC is disconnected. The actual offset is ~40mV, as opposed to other channels on the same board, which ahve offsets in the range 3-7mV.

While we can compensate for this offset in software - it made us  wonder if the DAC channel is somehow busted and if that's what causing the 'wandering' of ETMX that we have been observing recently. There are two free DAC channels on the AI chassis that has the side coil and the green temperature control signals. We could re-route the LR signal through a different DAC channel to fix this.

gautam: 40mV offset at the AI board output gets multiplied by 3 in the dewhitening board, so there is a 120mV DC offset going to the coil (measured at dewhite board output with DMM). The offset itself isn't hurting us, but the fact that it is several times larger than other channels led us to wonder if it could be drifting around as well. From my SOS pitch balancing forays, in my head I have the number 30mrad as being the full range of the OSEM actuation - so if the offset swings by 120mV, that's ~150urad of motion, which is quite large, and is of the order of magnitude I'm used to seeing ETMX move around by.

M4 local earthquake at 10:10 UTC    There is no sign of damage.

....here is an other one.........M5.8 Ferndale, CA at 16:40 UTC

We started the actual heating test today and it seems to be working so far. Hoping to heat it to about 40C. We also set up another temperature sensor to measure the lab temperature and connected it to J7, bottom.

I was looking at this a little more closely. As I understand it, the purpose of the audio differential IF amplifier is:

1. To provide desired amplification at DC-audio frequencies
2. To low pass the 2f component of the mixer output

Attachment #1 shows, the changes to the TF of this stage as a result of changing R19->50ohm, R17->500ohm. For the ALS application, we expect the beat signal to be in the range 20-100MHz, so the 2f frequency component of the mixer output will be between 40-200MHz, where the proposed change preserves >50dB attenuation. The Q of the ~500kHz resonance because of the series LCR at the input is increased as a result of reducing R17, so we have slightly more gain there. 

At the meeting yesterday, Koji suggested incorporating some whitening in the preamp itself, but I don't see a non-hacky way to use the existing PCB footprint and just replace components to get whitening at audio frequencies. I'm going to try and measure the spectrum of the I and Q demodulated outputs with the actual beat signal to see if the lack of whitening is going to limit the ALS noise in some frequency band of interest.

Does this look okay?

After almost 3 hours the temperature rose by about 3.5C. Seems a bit slow, but we can drive it more if necssary. The heating curve itself is exponentiial, which is a good sign.

The final temperature reached in about 4.5 hours is 30.5C, while the starting temperature is about 24C. I can't seem to screenshot the data for some reason.

Also, I will calibrate the lab temperature sensor to Celcius in the near future so that we would have a working sensor inside the lab.

I tried to couple the PSL pickoff into the fiber today for several hours, but got nowhere really, achieved a maximum coupling efficiency of ~10%. TBC tomorrow... Work done yesterday and today:

• I changed the collimator from the fixed focal length but adjustable lens position CFC-2X-C to the truly fixed F220-APC-1064 recommended by johannes.
• Used a pair of irises to level the beam out at 4" with two steering mirrors.
• Used a connector on the PSL table to couple the EX laser light to the PSL fiber - then measured the mode using the beam-scanner (beam is ~300uW) 
• Measured the mode of the PSL pickoff beam, also using the beam scanner. 
• Per specs on the Thorlabs website, the F220-APC-1064 has a divergence angle of 0.032 degrees. So expected waist is ~1200um, and the Rayleigh range is ~4.3m, so this is not a very easy beam to measure and fit. I may be thinking about this wrong?
• Measured beam 1/e^2 dia over ~0.65m, and found it to be fairly constant around 1800um (so waist of 900um) - beam is also pretty symmetric in x and y directions, but I didn't attempt an M^2 measurement.
• The pickoff from the PSL also did not yield a very clean beam profile measurement, even though I measured over ~1m z-propagation distance. Nevertheless, this looked more like a Gaussian beam, and I confirmed the fitted waist size/location approximately by placing the beam profiler at the predicted waist location and checking the spot size.
• Used jammt to calculate a candidate mode-matching solution - the best option seemed to be to use a combination of a f=150mm and f=-75mm lens in front of the collimator. 
• Despite my best efforts, I couldn't get more than ~500uW of light coupled into the fiber - out of the 8mW available, this is a paltry 12.5% 
• Because the mode coming out of the fiber is relatively large, and because I have tons of space available on the PSL table, this shouldn't be a hard mode-matching problem, should be doable without any fast lenses - perhaps I'm doing something stupid and not realizing it. I'm giving up for tonight and will try a fresh assault tomorrow. 

I think part of the problem was that the rejected beam from the PBS was not really very Gaussian - looking at the spot on the beam profiler, I saw at least 3 local maxima in the intensity profile. So I'm now switching strategies to use a leakage beam from one of the PMC input steering optics- this isn't ideal as it already has the PMC modulation sideband on it, and this field won't be attenuated by the PMC transmission - but at least we can use a pre-doubler pickoff. This beam looks beautifully Gaussian with the beam profiler. Pics to follow shortly...