I have made the modifications on the other board D1100687 S2100028 as well. The measurements were taken as mentioned in 40m/15784. All conclusions remain the same as 40m/15784. The attached zip file contains all measurement data, before and after the modifications.

Edit Wed Feb 3 16:44:51 2021 :

Added zero modeled noise in the noise spectrum curves. The acquisition mode curves are in agreement with the model. The noise in Run mode is weirdly lower than predicted by zero.

Summary:

1. Swapping out the KEPCO HV supplies (linear) I was using for a pair of HP6209s I borrowed from Rich has improved the noise performance somewhat.
2. However, there is still an excess relative to the model. I confirmed that this excess originates from the PA95 part of the circuit (see details).
3. The bypass capacitors don't seem to have any effect on the measured ripple from these HP6209s. Maybe they're internally fitted with some 10uF or similar bypass caps?
4. The production version of this board, with several improvements (after discussions with Koji and Rich), are on the DCC. They're being fabbed right now and will arrive in ~1 week for more bench testing. 

Power supply bypassing [updated 10pm]:

As mentioned earlier in this thread, I prepared a box with two 10uF, 1kV rated capacitors to bypass the high-voltage rails (see inset in the plot), to see if that improves the performance. However, in measuring the voltage ripple directly with the SR785 (no load connected), I don't see any significant difference whether the decoupling caps are connected or not, see Attachment #1. For this, and all other HV measurements made, I used this box to protect the SR785. One hypothesis is that this box itself is somehow introducting the excess noise, maybe because of leakage currents of the diode pair going into the 1Mohm SR785 input impedance, but I can't find any spec for this, and anyway, these diodes should be at ground potential once the transient has settled and the DC blocking capacitor has charged to its final value.

Note that the 10uF caps have an ESR of 7.2 mOhms. The HP6209 has a source impedance "<20mOhm" when operated as a CV source, per the datasheet. So perhaps this isn't so surprising? The same datasheet suggests the source impedance is 500 mOhms from 1kHz to 100 kHz, so we should see some improvement there, but I only measured out to 2 kHz, and I didn't take much effort to reduce these crazy peaks so maybe they are polluting the measurement out there. There must also be some continuous change of impedance, it cannot be <20 mOhm until 1 kHz and then suddenly increase to 500 mOhms. Anyways, for this particular circuit, the nosie DC-1kHz is what is important so I don't see a need to beat this horse more. 

Simplified circuit testing:

I decided to see if I can recover the spec'd voltage noise curve from the PA95 datasheet. For this, I configured the PA95 as a simple G=31 non-inverting amplifier (by not stuffing the 15 uF capacitor in the feedback path). Then, with the input grounded, I measured the output voltage noise on the circuit side of the 25kohm resistor (see inset in Attachment #2). To be consistent, I used the DC blocking box for this measurement as well, even though the output of the PA95 under these test conditions is 0V. Once again, there is considerable excess around ~100 Hz relative to a SPICE model. On the basis of this test, I think it is fair to say that the problem is with the PA95 itself. As far as I can tell, I am doing everything by the book, in terms of having gain > 10, using a sufficiently large compensaiton cap, HV rail decoupling etc etc. Note that the PA95 is a FET input opamp, so the effects of input current noise should be negligible. The datasheet doesn't provide the frequency dependence, but if this is just shot noise of the 1200 pA input bias current (for 300 V rails, per the spec), this is totally negligible, as confirmed by LTspice.

In the spirit of going step-by-step, I then added the feedback capacitor, and still, measured noise in excess of what I would expect from my model + SR785 measurement noise.

Integrated circuit testing:

After the above simplified test, I stuffed a full channel as designed, and tested the noise for various drive currents. To best simulate the operating conditions, an Acromag XT1541 was used to set the DC voltage that determines the drive current through the 25 kohm resistor. The measurements were made on the circuit side of this resistor (I connected a 20ohm resistor to ground to simulate the OSEM). As shown in Attachment #3, the noise with these HP6209 supplies is significantly better than what I saw with the KEPCO supplies, lending further credence to the hypothesis that insufficient PSRR is the root of the problem here. I've added subplots in a few different units - to be honest, I think that reaching this level of measured displacement noise at the 40m at 100 Hz would already be pretty impressive.

So what's next?

The main design change is that a passive R-C-R (4k-3uF-20k) replaces the single 25kohm resistor at the output of the PA95. 

• This allows similar current drive range.
• But adds an LPF to filter out the observerd excess noise at 100 Hz. 

Let's see if this fixes the issue. Not that I've also added a pair of input protection diodes to the input of the PA95 in the new design. The idea is that this would protect the (expensive) PA95 IC from, for example, the unit being powered with the +/- 18V rail but not the +/- 300 V rail. As I type this, however, I wonder if the leakage current noise of these diodes would be a problem. Once again, the datasheet doesn't provide any frequency dependence, but if it's just the shot noise of the 1nA expected when the diodes are not reverse biased (which is the case when the PA95 is operating normally since both inputs are at nearly the same potential), the level is ~20 fA/rtHz, comparable to the input current noise of the PA95, so not expected to be an issue. In the worst case, the PCB layout allows for this component to just be omitted. 

I found a white paper  from Acromag which discusses how to read differential signal using Acromag units. The document categorically says that differential signals are always supposed to be transmitted in three wires. I provides the two options of either using the RTN to connect to the signal ground (as done in Attachment 3) or locally place 10k-100k resistors between return and IN+ and IN- both (Attachment 2).

I have provided possible scenarios for these.

Using two wires to carry differential signal (Attachment 1):

• I assume this is our preferential way to connect.
• We can also assume all single-ended inputs as differential and do a signal condition agnostic wiring.
• Attachment 3 show what were the results for different values of resistors when a 2Hz 0.5V amplitude signal from SR785 which as converted to differential signal using D1900068 was measured by acromag.
• The connection to RTN is symmetrical for both inputs.

Using three wires to carry differential signal (Attachment 2):

• This is recommended method by the document in which it asks to carry the GND from signal source and connect it to RTN.
• If we use this, we'll have to be very cautious on what GND has been shorted through the acromag RTN terminals.
• This would probably create a lot of opportunities for ground loops to form.

Using an acromag card without making any connection with RTN is basically not allowed as per this document.

I fitted zeros and poles in the measured transfer function of D1100687 S2100027 and got zeros at 130 Hz and 234 Hz and poles at 10Hz and 2845 Hz. These values are different from the aimed values in this doc, particularly the 234Hz zero which was aimed at 530 Hz in the doc.

I also took the noise measurement using the same method as described in 40m/15780. The noise in Acquisition mode seems to have gone up in 10 Hz - 500 Hz region compared to the measurement in 40m/15780 before the modifications.

All channels are consistent with each other.

Edit Mon Feb 1 12:24:14 2021:
Added zero model prediction after the changes. The measurements match with the predictions.

Edit Wed Feb 3 16:46:59 2021:

Added zero modeled noise in the noise spectrum curves. The acquisition mode curves are in agreement with the model. The noise in Run mode is weirdly lower than predicted by zero.

Summary:

1. We will need de-whitening filters for the BHD relay optics in order to meet the displacement noise requirements set out in the DRD. I think these need not be remotely switchable (depends on specifics of LO phase control scheme). SR2, PR2 and PR3 can also have the same config, and probably MC1, MC3 as well.
2. We will need de-whitening filters for the non test mass core IFO optics (PRM, SRM, BS, and probably MC2).
3. I am pretty sure we will not be able to have sufficient DAC range for the latter class of optics if we have to:
   1. Supply the DC bias.
   2. Do the LSC and ASC actuation in the presence of reasonable sensing noise levels.
   3. Engage de-whitening to low-pass-filter the DAC noise at ~200 Hz.

Details:

Attachment #1 shows the DAC noise models for the General Standards 16-bit and 18-bit DACs we are expecting to have.

• The 16-bit model has been validated by me at the 40m a few years ago.
• We have never used the 18-bit flavor at the 40m, and there are all manner of quirks apparently related to zero crossings and such. So the noise may be up to x2 higher (we won't have as much freedom necessarily as the sites to bias the DAC on one side of the zero crossing if we also need to use the same DAC channel to supply the DC bias current for alignment.

Attachment #2 shows the expected actuation range for DC optic alignment, assuming we use the entire DAC range for this purpose.

• Clearly, we need to do other things with the same DAC channels as well, so this is very much an upper bound of what will be possible.
• Let's assume we will not go lower than 100ohms.
• For all new optics we are suspending, we should aim to get the pitch balancing to within 500urad. With a 2x2m=4m optical lever arm, this corresponds to a 2mm spot shift. Should be doable.
• This could turn out to be a serious problem for PRM, BS and SRM if we hope to measure squeezing - the <AUX DOF>-->DARM coupling could be at the level of -40dB, and at 200 Hz, the DAC noise would result in PRCL/MICH/SRCL noise at the level of ~10^-15m/rtHz, which would be 10^-17m/rtHz in DARM. I don't think we can get 20dB of feedforward cancellation at these frequencies. For demonstrating locking using a BHD error signal, maybe this is not a big deal.

Attachment #3 shows the current and proposed (by me, just a rough first pass, not optimized in any way yet) de-whitening filter shapes. These shapes can be tweaked for sure.

• The existing de-whitening filter is way too aggressive. FWIW, the DRD "models" a "4th order Chebyshev low pass filter" which doesn't exist anywhere as far as I know.
• Since the DAC noise is below 1 uV/rtHz at all frequencies of interest, we never need to have >60dB de-whitening anywhere as the input referred noise of any circuit we build will exceed 1 nV/rtHz.
• I propose 3 poles, 3 zeros. In the plot, these poles are located at 30Hz, 50Hz, 2kHz, and the zeros are at 300 Hz, 300 Hz, 800 Hz. 
• The de-whitening is less agressive below 100 Hz, where we still need significant LSC actuation ability. Considering the sensing noise levels at the 40m, I don't know if we can have reasonable LSC and ASC loop shapes and still have the de-whitening.
• Once again, PRM, SRM and BS will be the most challenging.
• For the BHD relay optics, once we have the de-whitening, we won't have the option of turning on a high-frequency (~kHz) dither line because of insufficient DAC range. 

Attachment #4 puts everything into displacement noise units. The electronics noise of the coil driver / de-whitening circuit have not been included so at high frequencies, the projection is better than what will actually be realizable, but still well below the BHD requirement of 3e-17 m/rtHz.

Looks fine to me visually but the verdict can only be made once the z:p locations are quantitatively confirmed, and the noise tests pass. It would be interesting to see what kind of time-domain transient (in N of force) switching on the de-whitening introduces, i guess best done interferometrically.

I did the recommended modifications on of the boards with serial number S2100028. These included:

• R13, R27: 160 -> 75
• C11, C21: 470 nF -> 68nF
• C19: 4.7 uF -> 470 nF
• R15: 3.23 kOhm -> 1.82 kOhm

I took transfer function measurements with same method as in 40m/15774 and I'm presenting it here to ensure the modifications are correct and if I should proceed to the next board as well. I didn't have the data used to make plots in here but I think the poles and zeros have landed in the right spot. I'll wait for comments until tomorrow to proceed with changes in the other board as well. I'll do noise measurements tomorrow.

I took some steps to reduce the coupling of 60 Hz harmonics in noise measurement. The box was transferred to the floor instead of on top of another instrument. Measurement was immediately converted into single-ended using SR560 in battery mode with a gain of 10. All of the setups was covered in aluminum foil to increase isolation.

Spectrum measurement details

• Boards were powered by sorenson power supplies with +/- 18V DC.
• 36 Ohm load was connected to coil output port.
• Signal was taken out using clips from V2+, V2- and GND.
• Signal was first sent to SR560 in A-B mode with a gain of 10 in battery mode.
• The board along with SR560s were covered in aluminum foil to reduce 60Hz harmonics.
• The output from 50Ohm port was sent to SR785 and read with floating ground.
• Instrument noise was measured by shorting the clips with each other.
• Transfer function of measurement setup was measured and divided by final output.
• Measurements were taken with file D1100687_SP.yml and D1100687_SP_LF.yml.
• D1100117_S2100027_Voltage_Noise_Spectrum.pdf and D1100117_S2100028_Voltage_Noise_Spectrum.pdf shows the measured voltage noise spectrum at the output monitors when loaded with 36 Ohms.
• D1100117_S2100027_Current_Noise_Spectrum.pdf and D1100117_S2100028_Current_Noise_Spectrum.pdf shows the esitmate current noise through the coil calculated by dividing the measured voltage noise by 2436 Ohms.

Here I present few wiring diagrams when using Acromag to avoid noisy behavior and ground loops.

Case 1: Only single-ended sources

• Attachment 1 gives a functioning wiring diagram when all sources are single ended.
• One should always short the RTN to IN- pin if the particular GND carried by that signal has not been shorted before to RTN for some other signal.
• So care is required to mark different GNDs of different powersupply separately and follow where they inadvertently get shorted, for example when a photodiode output is connected to FSS Box.
• Acromag should serve as the node of all GNDs concerned and all these grounds must not be connected to Earth GND at power supply ends or in any of the signal sources.
• I think this is a bit complicated thing to do.

Case 2: Some single and some differential sources

• Connect all single ended sources same as above keeping care of not building any ground loops.
• The differential source can be connected to IN+ and IN- pins, but there should be a high resistance path between IN- and RTN. See Attachment 2.
• Why this is the case, I'm not sure since I could not get access to internal wiring of Acromag (no response from them). But I have empirically found this.
• This helps IN- to float with respect to RTN according to the negative signal value. I've found that 10kOhm resistance works good. See 40m/15778.
• If RTN is shorted to nearby Earth GND (assuming none of the other power supply GNDs have been shorted to Earth GND) shows a reduction in noise for differential input. So this is recommended.
• This wiring diagram carries all complexity of previous case along with the fact that RTN and anything connected to it is at Earth GND now.

Case 3: Signal agnostic wiring

• Attachment 3 gives a wiring diagram which mimics the high resistance shorting of RTN to IN- in all ports regardless of the kind of signal it is used for reading.
• In this case, instead of being the node of the star configuration for GND, acromag gets detached from any ground loops.
• All differences in various GNDs would be kept by the power supplies driving small amounts of current through the 10 kOhm resistors.
• This is a much simpler wiring diagram as it avoids shorting various signal sources or their GNDs with each other, avoiding some of the ground loops.

Edit Wed Jan 27 13:38:19 2021 :

This solution is not acceptable as well. Even if it is successfull in reading the value, connecting resistor between IN- and RTN will not break the ground loops and the issue of ground loops will persist. Further, IN- connection to RTN breaks the symmetry between IN-  and IN+, and hence reduces the common mode rejection which is the intended purpose of differential signal anyways. I'll work more on this to find a way to read differential signals without connecitng IN- and RTN. My first guess is that it would need the GND on the source end to be connected to EarthGND and RTN on acromag end to be connected to EarthGND as well.

Taking inspiration from SR785 on how it reads differential signal, I figured that acromag too always need a way to return current through RTN ports always. That must be the reason why everything goes haywire when RTN is not connected to IN-. Now for single ended signals, we can always short RTN to IN- and keep same GND but then we need to be careful in avoiding ground loops. I'm gonna post a wiring diagram in next post to show how if two signal sources connect to each other separately, a GND loop can be formed if we tie each IN- port to RTN on an acromag.
Coming to the issue of reading a differential signal, what SR785 does is that it connects 50 Ohm resistance between Earth GND and differential signal shields (which are supposed to signal GND). In a floating GND setting, SR785 connects a 1 MOhm resistor between input shield and Earth GND. This can be used to read a differential signal through a single BNC cable since the shiled can take arbitrary voltages thanks ti the 1 MOhm resistor.

We can do the same in acromag. Instead of shorting RTN to IN- ports, we can connect them through a large resistor which would let IN- float but will give a path for current to return through RTN ports. Attached here are few scenarios where I connected IN- to RTN throguh wire, 820 Ohms, 10kOhms and 1MOhms in two sub cases where RTN was left open or was shorted to Earth GND. In all cases, the signal was produced by a 9V battery outputing roughly 8.16V. It seems that 10kOhm resistor between RTN and IN- with RTN connected to Earth GND is the best scenario noise wise. I'll post more results and a wiring diagram soon.

For whatever reason, the autolocker didn't turn the tickle off for several hours. Seems to work okay now. The linked plot suggests that the coil balancing on MC2 is pretty lousy.

I took transfer function and noise measurement of satellite amplifier box's photodiode transimpedance circuit. For the measurement, I created a makeshift connector to convert backside DB25 into DB9 with the 4 channels for PDA input. The output was taken in differential form at the front PD Output port. To feed current to the circuit, I put in 12 kOhm resistors in series at the inputs, so the V/V transfer function measured was multiplied by 12 kOhm to get the transimpedance of the circuit.

Transfer Function Measurement details

• SR785 source out was fed into PDA input pins using a makeshift BNC-DB9-DB25 converter.
• The output from PDOut DB9 port was fed to test switch in D1900068 to separate differential signal.
• This differential signal was fed back to SR785 at input 2 in A-B configuration.
• Measurements are taken with file D1002818_TF.yml and D1002818_TF_LF.yml.
• A measurement of just cables without the DUT is taken as well.
• Commands.txt list all the commands used.
• All data is compiled and plotted in Plotting.ipynb
• D1100117_S2100029_TFandNoiseSpectrum.pdf shows all the transfer functions measured.

Spectrum Measurements

• Two pair of BNC cables were twisted together and clips were added at ends.
• One of the GND was connected to board GND. Rest were left unconnected to avoid ground loops.
• Each pair of signal was connected to PDOutP/N.
• The PDA inputs were shorted together to make zero input current to the board.
• Instrument noise with cables was measured by shorting the clips of the center cores and one of the shields of the two BNC cables together.
• Measurements were taken with file D1002818_SP.yml and D1002818_SP_LF.yml.
• Input referred current noise spectrum was calculated by dividing the output voltage noise spectrum by the measured transfer function.
• D1100117_S2100029_TFandNoiseSpectrum.pdf shows all the output votlage noise spectrum and input referred current noise spectrum measured.

Edit Wed Feb 10 15:14:13 2021 :

THE NOISE MEASUREMENT WAS WRONG HERE. SEE 40m/15799.

After fixing multiple issues, the model webviews are updating, should be done by tomorrow. It should be obvious from the timestamps on the index page which are the new ones. These new screens are better than the old ones and offer more info/details. Please look at them, and let me know if there are broken links etc. Once we are happy with this new webview, we can archive the old files and clean up the top directory a bit. I don't think this adds anything to the channel accounting effort but it's a nice thing to have up-to-date webviews, I found the LLO ones really useful in setting up the AS WFS model.

BTW, the crontab on megatron is set to run every day at 0844. The process of updating the models is pretty heavy because of whatever MATLAB overhead. Do we really need to have this run every day? I modified the crontab to run every other Saturday, and we can manually run the update when we modify a model. Considering this hasn't been working for ~3 years, I think this is fine, but if anyone has strong preference you can edit the crontab.

If someboy can volunteer to fix the MEDM screenshot that would be useful.

I have taken transfer functions and noise measurements of the two HAM-A coil driver boxes D1100687 #S2100027 and #S2100028. All transfer functions look as expected. I'm not sure about the noise measurements. If anyone sees flaw in my measurement method, please let me know. I'm not sure why in some channels I got 10Hz harmoni peaks in the noise. That was very strange. Also let me know if my current noise estimate is wrong.

Transfer Function Measurement details

• SR785 source out was connected to the differential amplifier input of D1900068.
• The one pair of two BNC outputs of this differential amplifier goes directly to the SR785 Input 1 A and B.
• The DB9 output of the differential amplifier goes to the Coil Input DB9 connector J3.
• Header W2 was shorted to provide ground to the incoming signal.
• Header P4 was shorted to enable all the channels manually.
• Normal operation is the Acquisition mode (Acq) while when pins of header P3 are shorted, we go into the Run mode for respective channel.
• The “To Satellite Box” DB25 port at the read side was conencted to a DB25 breakout circuit and pins 1-9, 3-11, 5-13 and 7-15 were connected to 36 Ohm resistor to simulate Coil load.
• The “Output Monitor” on the rear side is then connected to the test switch DB9 port on D1900068.
• The the pair of BNCs from the test switch is connected to SR785 Input 2 A and B.
• Measurements are taken with file D1100687_TF.yml and D1100687_TF_LF.yml.
• A measurement of just cables without the DUT is taken as well.
• Commands.txt list all the commands used.
• All data is compiled and plotted in Plotting.ipynb
• D1100117_S2100027_TF.pdf and D1100117_S2100028_TF.pdf shows all the transfer functions measured.

Spectrum Measurements

• All channels were kept in disabled mode (Not shorting P4) to ensure their inputs are grounded on the board.
• I ran two BNC cables with their centers connected to output monitors V2+ and V2- and one of their shields connected to board GND.
• in SR785, A-B differential mode always runs with grounded shields mode, so effectively the board GND got grounded to SR785 GND through internal 50 Ohm resistor. But all ground loops have been evaded.
• The two BNC cables were twisted together to minimize the area between the two center cores of the cables as that is the remaining pickoff possible in this measurement.
• Instrument noise with cables was measured first but shorting the clips of the center cores and one of the shields of the two BNC cables together.
• Measurements were taken with file D1100687_SP.yml and D1100687_SP_LF.yml.
• D1100117_S2100027_Voltage_Noise_Spectrum.pdf and D1100117_S2100028_Voltage_Noise_Spectrum.pdf shows the measured voltage noise spectrum at the output monitors when loaded with 36 Ohms.
• D1100117_S2100027_Current_Noise_Spectrum.pdf and D1100117_S2100028_Current_Noise_Spectrum.pdf shows the esitmate current noise through the coil calculated by dividing the measured voltage noise by 2436 Ohms.

Summary:

Installing 10uF bypass capacitors on the High Voltage power supply line for the HV coil driver circuit doesn't improve the noise. The excess bump around a few hundred Hz is still present. How do we want to proceed? 

Details

• The setup is schematically shown in Attachment #1.
• Physically, the capacitors were packaged into a box, see Attachment #2.
• This box is installed between the HVPS and the 2U chassis in which the circuit is housed, see Attachment #3.
• I measured the noise, (using the same setup as shown here to avoid exposing the SR785 input to any high voltage), for a variety of drive currents. To make a direct comparison, I took two sets of measurements today, one with the decoupling box installed and one without.
• The results are shown in Attachment #4. You can see there is barely any difference between the two cases. I've also plotted the expected noise per a model, and the measured Johnson noise of one of the 25kohm resistors being used (Ohmite, wirewound). I just stuck the two legs of the resistor into the SR785 and measured the differential voltage noise. There is a slight excess in the measured Johnson noise compared to what we would expect from the Fluctuation Dissipation theorem, not sure if this is something to be worried about or if it's just some measurement artefact.

Discussion:

So what do we do about this circuit? For the production version, I can make room on the PCB to install two 10uF film capacitors on the board itself, though that's unlikely to help. I think we've established that 

1. The excess noise is not due to the Acromag or the input Acromag noise filtering stage of the circuit, since the excess is present even when the input to the HV stage is isolated and shorted to ground.
2. There was some evidence of coherence between the supply rails and the output of the HV stage (with input isolated and shorted to ground). The coherence had the "right shape" to explain the excess noise, but the maximum value was only ~0.1 (could have been because I was not measuring directly at the PA95's supply rail pins due to space constraints).
3. The impedance of 10uF at 100Hz is ~150 ohms. idk what the impedance of the supply pins of the PA95 are at this frequency (this will determine the coupling of ripples in the HVPS output to the PA95 itself.

Do we have any better bipolar HV supply that I can use to see if that makes any difference? I don't want to use the WFS supplies as it's not very convenient for testing.

Not really related directly to this work but since we have been talking about current requirements, I attach the output of the current determining script as Attachment #5. For the most part, having 220ohm resistances on the new HAM-A coil driver boards will lead to ~half the DAC range being eaten up for the slow alignment bias. For things like MC1/MC3, this is fine. But for PRM/SRM/BS, we may need to use 100ohms. Chub has ordered all manner of resistances so we should have plenty of choices to pick from.

Not sure if 1Y1 can accommodate both c1sus2 and c1bhd as well as the various electronics chassis that will have to be installed. There may need to be some distribution between 1Y1 and 1Y3. Does Koji's new wiring also specify which racks hold which chassis?

Some minor improvements to the diagram:

1. The GPS receiver in 1X7 should be added. All the timing in the lab is synced to the 1pps from this.
2. We should add hyperlinks to the various parts datasheets (e.g. Dolphin switch, RFM switch, etc etc) so that the diagram will be truly informative and self-contained.
3. Megatron and nodus, but especially chiara (NFS server), should be added to the diagram. 

I've produced updated diagrams of the CDS layout, taking the comments in 15476 into account. I've also converted the 40m's diagrams from Omnigraffle ($150/license) to the free, cloud-based platform draw.io. I had never heard of draw.io, but I found that it has most all the same functionality. It also integrates nicely with Google Drive.

Attachment 1: The planned CDS upgrade (2 new FEs, fully replace RFM network with Gen 1 Dolphin IPC)
Attachment 2: The current 40m CDS topology

The most up-to-date diagrams are hosted at the following links:

• Planned 40m CDS topology
• Current 40m CDS topology

Please send me any further corrections or omissions. Anyone logged in with LIGO.ORG credentials can also directly edit the diagrams.

Indeed T1800302 is the document I was alluding to, but I completely missed the statement about >3 GHz speed. There is an option for 3.4 GHz processors on the X10SRi-F board, but back in 2019 I chose against it because it would double the cost of the systems. At the time I thought I had saved us $5k. Hopefully we can get the LLO machines in the near term---but if not, I wonder if it's worth testing one of these to see whether the performance is tolerable.

I confirm that PCIe 2.0 motherboards are backwards compatible with PCIe 1.x cards, so there's no hardware issue. My main concern is whether the obsolete Dolphin drivers (requiring linux kernel <=3.x) will work on a new system, albeit one running Debian 8. The OSS PCIe card is automatically configured by the BIOS, so no external drivers are required for that one.

I decided to analyze the data I took in December more carefully to see if there are any clues about the weird LSC sensing.

Attachment #1 shows the measurement setup.

• The PSL shutter was closed. All feedback to both lasers was disconnected during the measurement. I also disabled the input switch to the FSS Box - so the two laser beams being interfered shouldn't have any modulations on them other than the free running NPRO noise and the main IFO modulations.
• Everything is done in fiber as I had the beams already coupled into collimators and this avoided having to optimize any mode matching on the beat photodiode.
• The pickoff of the PSL is from the collimator placed after the triply resonant EOM that was installed for the air BHD experiment.
• The other beam is the EX laser beam, arriving at the PSL table via the 40m long fiber from the end (this is the usual beam used for ALS).
• I didn't characterize precisely the PLL loop shape. But basically, I wasn't able to increase the SR560 gain any more without breaking the PLL lock. Past experience suggests that the UGF is ~20 kHz, and I was able to get several averages on the AG4395 without the lock being disturbed.

Attachment #2 shows the measured spectrum with the PSL and EX laser frequency offset locked via PLL.

• The various peaks are identified.
• There are several peaks which I cannot explain - any hypothesis for what these might be? Some kind of Sorensen pollution? They aren't any multiples of any of the standard RF sources. They are also rather prominent (and stationary during the measurement time, which I think rules out the cause being some leakage light from the EY beam, which I had also left connected to the BeatMouth during the measurement).
• In the previous such characterization done by Koji, such spurious extra peaks aren't seen.
• Also, I can't really explain why some multiples of the main modulation are missing (could also be that my peak finding missed the tiny peaks)?
• The measuremet setup is very similar to what he had - important differences are 
  • Much of the optical path was fiber coupled.
  • Beat photodiode is NF1611, which is higher BW than the PDA10CF.
  • The second laser source was the Innolight EX NPRO as opposed to the Lightwave that was used.
  • The RF source has been modified, so relative phasing between 11 MHz and 55 MHz is different.

Fitting the measured sideband powers (up to n=7, taking the average of the measured upper and lower sideband powers to compute a least squares fit if both are measured, else just that of the one sideband measured) agains those expected from a model, I get the following best fit parameters:

To be explicit, the residual at each datapoint was calculated as

.

The numbers compare favourably with what Koji reported I think - the modulation depths are slightly increased, consistent with the RF power out of the RF box being slightly increased after I removed various attenuators etc. Note the large uncertainty on the relative phase between the two modulations - I think this is because there are relatively few sidebands (one example is n=3) which has a functional dependence that informs on phi - most of the others do not directly give us any information about this parameter (since we are just measuring powers, not the actual phase of the electric field). 

Attachment #3 shows a plot of the measured modulation profile, along with the expected heights plugging the best fit parameters into the model. The size of the datapoint markers is illustrative only - the dependence on the model parameters is complicated and the full covariance would need to be taken into account to put error bars on those markers, which I didn't do. 

Attachment #4 shows a time domain measurement of the relative phasing between the 11 MHz and 55 MHz signals at the EOM drive outputs on the RF source box. I fit a model there and get a value for the relative phase that is totally inconsistent from what I get with this fit. 

I want to lock the PRFPMI again (to commission AS WFS). Have had some success - but in doing characterization, I find that the REFL port sensing is completely messed up compared to what I had before. Specifically, MICH and PRCL DoFs have no separation in either the 1f or 3f photodiodes. 

• A sensing line driven in PRCL doesn't show up in the AS55 photodiode signal - this is good and as expected.
• For MICH - I set the MICH--->PRM actuation matrix element so as to minimize the height of the peak at the MICH drive frequency that shows up at the PRCL error point. My memory is that I used to be able to pretty much null this signal in the past, but I can't find a DTT spectrum in the elog as evidence. Anyways, the best effort nulling I can achieve now still results in a large peak at the PRCL error point. Since the sensing matrix doesn't actually make any sense, idk if it is meaningful to even try and calibrate the above qualitative statement into quantitative numbers of cross coupling in meters.
• With the PRMI locked on 1f error signals (ETMs misaligned, PRCL sensed with REFL11_I, MICH sensed with AS55_Q) - I tried tweaking the digital demod phase of the REFL33 and REFL165 signals. But I find that the MICH and PRCL peaks move in unison as I tweak the demod phase. This suggests to me that both signals are arriving optically in phase at the photodiode, which is weird.
• The phenomenon is seen also in the REFL11 signal.

I did make considerable changes to the RF source box, and so now the relative phase between the 11 MHz and 55 MHz signals is changed compared to what it was before. But do we really expect any effect even in the 1f signal? I am not able to reproduce this effect in simulation (Finesse), though I'm using a simplified model. I attach two sensing matrices to illustrate what i mean:

1. Attachment #1 is in the PRFPMI state, with the IFO on RF control (CARM on REFL11, PRCL on REFL165_I, MICH on REFL165_Q, DARM on AS55_Q). 
2. Attachment #2 is between the transition to RF control (CARM and DARM on ALS, PRCL on REFL165_I, MICH on REFL165_Q). The CARM offset is ~4nm (c.f. the linewidth of ~20pm), so the circulating power in the arm cavities is low.

Can you please provide a link to this "list of boards"? The only document I can find is T1800302. In that, under "Basic Requirements" (before considering specific motherboards), it is specified that the processor should be clocked @ >3GHz. The 3 new supermicros we have are clocked at 1.7 GHz. X10SRi-F boards are used according to that doc, but the processor is clocked at 3.6 or 3.2 GHz.

Please also confirm that there are no conflicts w.r.t. the generation of PCIe slots, and the interfaces (Dolphin, OSSI) we are planning to use - the new machines we have are "PCIe 2.0" (though i have no idea if this is the same as Gen 2). 

As for the CX4 cable - I still think it's good to have these on hand. Not good to be in a situation later where FE and expansion chassis have to be in different racks, and the copper cable can't be used.

Koji asked me assemble a detailed breakdown of the parts received from LHO, which I do based on the high-res photos that Gautam posted of the shipment.

Parts in hand:

Parts still needed:

Issue with PCIe slots in new FEs

Also, I looked into the mix-up regarding the number of PCIe slots in the new Supermicro servers. The motherboard actually has six PCIe slots and is on the CDS list of boards known to be compatible. The mistake (mine) was in selecting a low-profile (1U) chassis that only exposes one of these slots. But at least it's not a fundamental limitation.

One option is to install an external PCIe expansion chassis that would be rack-mounted right above the FE. It is automatically configured by the system BIOS, so doesn't require any special drivers. It also supports hot-swapping of PCIe cards. There are also cheap ribbon-cable riser cards that would allow more cards to be connected for testing, although this is not as great for permanent mounting.

It may still be better to use the machines offered by Keith Thorne from LLO, as they're more powerful anyway. But if there is going to be an extended delay before those can be received, we should be able to use the machines we already have in conjunction with one of these PCIe expansion options.

I think the "Rogue Master" setting on the RFM network may be doing some good. 5 mins, ago, all the CDS indicators were green, but I noticed an amber light on the c1rfm screen just now (amber = warning). Seems like at GPS time 1294691182, there was some kind of error on the RFM network. But the network hasn't gone down. I can clear the amber flag by running the global diag reset. Nevertheless, the upgrade of all RT systems to Dolphin should not be de-prioritized I think.

That's fine, we didn't actually request those. We bought and already have in hand new PCIe x4 cables for the chassis-host connection. They're 3 m copper cables, which was based on the assumption of the time that host and chassis would be installed in the same rack.

I picked the boxes up this morning. The inventory per Fil's email looks accurate. Some comments:

1. They shipped the chassis and mounting parts (we should still get rails to mount these on, they're pretty heavy to just be supported on 4 rack nuts on the front). idk if we still need the two empty chassis that were requested from Rich.
2. Regarding the fibers - one of the fibers is pre-2012. These are known to fail (according to Rolf). One of the two that LHO shipped is from 2012 (judging by S/N, I can't find an online lookup for the serial number), the other is 2011. IIRC, Rolf offered us some fibers so we may want to take him up on that. We may also be able to use copper cables if the distances b/w server and expansion chassis are short.
3. The units are fitted with a +24V DC input power connector and not the AC power supplies that we have on all the rest of the chassis. This is probably just gonna be a matter of convenience, whether we want to stick to this scheme or revert to the AC input adaptor we have on all the other units. idk what the current draw will be from the Sorensen - I tested that the boards get power, and with noi ADCs/DACs/BIOs, the chassis draws ~1A (read off from DCPS display, not measured with a DMM). ~Half of this is for the cooling fans It seems like KT @ LLO has offered to ship AC power supplies so maybe we want to take them up on that offer.
4. Without the host side OSSI PCIe card, timing interface board, and supermicro servers that actually have enough PCIe slots, we still can't actually run any meaningful test. I ran just a basic diagnostic that the chassis can be powered on, and the indicator LEDs and cooling fans run.
5. Some photos of the contents are here. The units are stored along the east arm pending installation.

    >     Koji,
    >
    >     Barebones on this order.
    >
    >        1. Main PCIe board
    >        2. Backplane (Interface board)
    >        3. Power Board
    >        4. Fiber (One Stop) Interface Card, chassis side only
    >        5. Two One Stop Fibers
    >        6. No Timing Interface
    >        7. No Binary Cards.
    >        8. No ADC or DAC cards
    >
    >     Fil Clara
    >       

I'm working on a better wiring diagram that takes into account multiple power supplies, how their GND is passed forward to the circuits or sensors using those power supplies and what possible wiring configurations on Acromag would give low noise. I think I have two configurations in mind which I will test and update here with data and better diagrams.

I took some striptool images earlier yesterday. So I'm dumping them here for further comments or inferences.

Thanks for the systematic effort.

1. Can you please post some time domain plots (ndscope perferably or StripTool) to clearly show the different failure modes?
2. The majority of our AI channels are "Referenced Single Ended Source" in your terminology. At least on the c1psl Acromag crate, there are no channels that are truly differential drive (case #3 in your terminology). I think the point is that we saw noisy inputs when the IN- wasn't connected to RTN. e.g. the thorlabs photodiode has a BNC output with the shield connected to GND and the central conductor carrying a signal, and that channel was noisy when the RTN was unconnected. Is that consistent with your findings?
3. What is the prescription when we have multiple power supplies (mixture of Sorensens in multiple racks, Thorlabs photodiodes and other devices powered by an AC/DC converter) involved?
4. I'm still not entirely convinced of what the solution is, or that this is the whole picture. On 8 Jan, I disconnected (and then re-connected) the FSS RMTEMP sensor from the Acromag box, to check if the sensor output was noisy or if it was the Acromag. The problem surfaced on Dec 15, when I installed some new electronics in the rack (though none of them were connected to the Acromag directly, the only common point was the Sorensen DCPS. And between 8 Jan and today, the noise RMS has decreased back to the nominal level, without me doing anything to the grounding. How to reconcile this?

I used an Acromag XT1221 in CTN to play around with different wiring and see what works.  Following are my findings:

Referenced Single Ended Source (Attachment 1):

• If the source signal is referenced single ended, i.e. the signal is only on the positive output and the negative side is tied to GND on the source side AND this GND is also shared by the power supply powering the Acromag, then no additional wiring is required.
• The GND common to the power supply and the source is not required to be Earth GND but if done so, it should be at one point only.
• RTN terminal on Acromag can be left floating or tied to IN- terminal.

Floating Single Ended Source (Attachment 2):

• If the source signal is floating single-ended i.e. the signal is only on the positive output and the negative output is a floating GND on the source, the the IN- should be connected to RTN.
• This is the case for handheld calibrators or battery powered devices.
• Note that there is no need to connect GND of power supply to the floating GND on the source.

Differential Source (Attachment 3):

• If the source is differential output i.e. the signal is on both the positive output and the negative output, then connect one of the RTN terminals on Acromag to Earth GND. It has to be Earth GND for this to work.
• Note that you can no longer tie the IN- of different signals to RTN as they are all carrying different negative output from the source.
• Earth GND at RTN gives acromag a stable voltage reference to measure against the signals coming in IN+ and IN-. And the most stable voltage reference is of course Earth GND.

Conclusion:

• We might have a mix of these three types of signals coming to a single Acromag box. In that case, we have to make sure we are not connecting the different IN- to each other (maybe through RTN) as the differential negative inputs carry signal, not a constant voltage value.
• In this case, I think it would be fine to always use differential signal wiring diagram with the RTN  connected to Earth GND.
• There's no difference in software configuration for the two types of inputs, differential or single-ended.
• For cases in which we install the acromag box inside a rack mount chasis with an associated board (example: CTN/2248), it is ok and maybe the best to use the Attachment 1 wiring diagram.

Comments and suggestions are welcome.

Related elog posts:

40m/14841    40m/15134

Edit Tue Jan 26 12:44:19 2021 :

Note that the third wiring diagram mentioned actually does not work. It is an error in judgement. See 40m/15762 for seeing what happens during this.

• looking better, but the CARM plot still looks weird.
• you should plot from 0.01 - 10,000 Hz
• All of the loops should have true integrators below 1 Hz.
• I don't think these loops are stable; the Bode plot is not a good way to check stability for LTI systems since you can be fooled by phase wrapping.

I dived into the alog to make the OLTFs in the MC_controls example more realistic. I was mainly inspired by these entries:

https://alog.ligo-la.caltech.edu/aLOG/uploads/47116_20190708131007_carmolg_20190702.png

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=18742

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20466

and Evan's and Dennis's Theses.

Attachment 1 shows the new OLTFs. I tried to make them go like 1/f around the UGF and fall as quickly as possible at higher frequencies. I didn't do more advanced stability checks.

I also noticed that imbalances and detunings in the MC simulation can change the plants significantly. Especially DARM, CARM, and sometimes PRCL. I added the option to fix some OLTFs throughout the simulation. At every iteration, the simulation computes the required control filter to fix the selected OLTFs such that it will match the OLTFs in the undetuned and balanced IFO.

I did this test today. The excess noise around 100 Hz doesn't show up in the green beat.

See Attachment #1. The setup was as usual:

• X-Arm cavity length stabilized to PSL frequency using the POX locking loop.
• EX laser frequency locked to the X-Arm cavity length using the AUX PDH loop.
• The "BEATX" channel records frequency fluctuations in the beat sensed on the IR beat photodiode, while the "BEATY" channel records frequency fluctuations in the beat sensed on the Green beat photodiode.
• Since the green beat frequency fluctuations are twice that of the IR beat frequency fluctuations, I scaled the former ASD by a factor of 0.5 so as to compare apples to apples.
• At low frequencies, the green beat is noisier, but that channel doesn't show the excess noise at mid frequencies you see in the IR beat. So the AUX PDH sensing noise is not to blame I think.

So, this excess appears to truly be excess phase noise on the fiber (though I have no idea what the actual mechanicsm could be or what changed between Aug and Oct 2020 that could explain it. Maybe the HEPA?

For this work, I had to spend some time aligning the two green beams onto the beat photodiode. During this time, I shuttered the PSL, disabled feedback via the FSS servo, turned the HEPA high, and kept the EX green locked to the arm so as to have a somewhat stable beat signal I could maximize. Everything has been returned to nominal settings now (obviously, since I locked the arms to get the data).

You may ask, why do we care. In terms of RMS frequency noise, it would appear that this excess shouldn't matter. But in all my trials so far, I've been unable to transition control of the arm cavity lengths from POX/POY to ALS. I suppose we could try using the green beat, but that has excess low frequency noise (which was the whole point of the fiber coupled setup). 

If the sensing noise level of the end PDH degraded for some reason, it'd make the out of loop stability worse without making the end pdh error level degraded.
It's just speculation.

I thought about it, but wouldn't that show up at the AUX PDH error point? Or because the loop gain is so high there we wouldn't see a small excess? I suppose there could be some clipping on the Faraday or something like that. But the GTRX level and the green REFL DC level when locked are nominal.

How about resurrecting the PSL table green beat for the X arm to see if the non-fiber setup shows the same level of the freq noise (e.g. the PDH locking became super noisy due to misalignment etc).

I'm also wondering why the error monitors for the X and Y loops report such wildly different spectra for the suppressed frequency noise of the AUX laser relative to the cavity length, see Attachment #1. The y-axis should be approximately Hz/rtHz. In both cases, the servo's error point monitor is connected to the DAQ system via a G=10 SR560. With the SR785, I measure for EX a nice bucket-shaped spectrum, bottoming out at ~10 uV/rtHz around 40 Hz, see Attachment #2. The SR560 should have an input-referred noise much less than this at the G=10 setting. The ADC noise level is only ~5 uV/rtHz, and indeed, the EY spectrum shows the expected shape. So what's up with the EX error mon? Tried swapping out the SR560 for a different unit, no change. And both the SR560 noise, and the ADC noise, check out when everything is checked individually. So some kind of interaction once everything is connected together, but it's only present at EX...

Today, I tried switching the EX and EY fibers going into the beat mouth, but I preserved the channel mapping after the beat mouth by switching the electrical outputs as well (the goal was to make sure that the beat photodiodes weren't the issue here, I think the electronics are already exonerated since driving the channel with a Marconi doesn't produce these noisy features). The EX spectrum remains noisy. I've switched everything back to the nominal configuration now to avoid further confusion. So it would appeat that this is real frequency noise that gets added in the EX fiber somehow. What can I do to fix this? The source of coupling isn't at the PSL table, else the EY channel would also show similar features. Visually, nothing seems wrong to me at EX either. So the problem is somehow in the cable tray along which the 40m of fiber is routed? This is already inside some nice foam/tubing setup, what can be done to improve it? Still doesn't explain why it suddenly became noisy...

Summary:

I want to get back to locking the interferometer so I can test out the newly installed AS WFS. However, the ALS noise is far too high, at least the transition of arm length control from IR to ALS fails reliably with the same settings that worked so reliably previously. I worked on investigating it a bit today.

Timeline

In the latter half of last year, I was focused on the air-BHD setup, so I wasn't checking in on the ALS noise as regularly. 

1. On Aug 17, the noise was fine.
2. But on Oct 29, the noise is bad (and it continues to remain so, to the point where I cannot lock the interferometer). 
3. Koji and Anchal confirmed nothing was touched while they were investigating the ALS system, also on Oct 29. The spectra attached in #15650 don't make any sense to me, the noise at 100 Hz cannot be <100mHz/rtHz. So, inconclusive.

Excess noise:

All tests are done with the arm cavity length locked to the PSL frequency using POX. Then, the EX laser is locked to the arm cavity length using the AUX PDH servo. The fluctuations in the beatnote between the two lasers is what is monitored as a diagnostic. See Attachment #1. The reference traces in the top pane are from a known good time. The large excess noise between ~80-200 Hz is what I'm concerned about.

A separate issue that can improve the noise is to track down the noise in the 20-80 Hz band - probably some IMC frequency noise issue.

Noise budget:

See Attachment #2. 

• I am pretty confident the electronics after the beat mouth are not to blame - I injected a 50 MHz signal from a Marconi and adjusted the signal amplitude to mimic what we get from the beat mouth. The trace labelled "DFD electronics noise" is the noise in this config.
• The unsuppressed AUX frequency noise was measured with an SR785 (converted to freqnecy noise units knowing the PDH horn-to-horn voltage and the cavity linewidth). I didn't confirm the sensing noise level (dark noise of the AUX PDH loop), but I figure that at 100 Hz (voltage noise of ~100 uV/rtHz on the SR785), we are above the sensing noise level, and so are truly measuring the in-loop frequency noise of the stabilized AUX laser. I also confirmed that the loop UGF was ~10 kHz and phase margin was ~60 degrees, which are nominal numbers.
• The fact that the excess noise is only in the X arm channel means the PSL frequency is not to blame.

So what could it be? The only things I can think of are (i) the beat mouth photodiode (NF1611) or (ii) excess noise in the fiber carrying the light from EX to the PSL table (but only on this fiber, and not on the EY fiber). Both seem remote to me - I'll test the former by switching the EX and EY fiber inputs to the beat mouth, but apart from this, I'm out of ideas... 

To avoid this kind of issue, we should really have scripted locks of all the basic IFO configs and record the data to summary pages or something - maybe something to do once Guardian is installed, it'd be pretty hacky to do cleanly with shell scripts.

I've noticed that there is some phase loss in the POX/POY locking loops - see Attachment #1, live traces are from a recent measurement while the references are from Nov 4 2018. Hard to imagine a true delay being responsible to cause so much phase loss at 100 Hz. Attachment #2 shows my best effort loop modeling, I think I've got all the pieces, but maybe I missed something (I assume the analog whitening / digital anti-whitening are perfectly balanced, anyway this wasn't messed with anytime recently)? The fitter wants to add 560 us (!) of delay, which is almost 10 clock cycles on the RTS, and even so, the fit is poor (I constrain the fitter to a maximum of 600 us delay so maybe this isn't the best diagnostic). Anyway, how can this change be explained? The recent works I can think of that could have affected the LSC sensing were (i) RF source box re-working, and (ii) vent. But I can't imagine how either of these would introduce phase loss in the LSC sensing. Note that the digital demod phase has been tuned to put all the PDH signal in the "I" quadrature, which is the condition in which the measurement was taken.

Probably this isn't gonna affect locking efforts (unless it's symptomatic of some other larger problem).

As part of the hunt why the X arm IR transmission RIN is anomalously high, I noticed that the BS Oplev Servo periodically kicks the optic around - the summary pages are the best illustration of this happening. Looking back in time, these seem to have started ~Nov 23 2020. The HeNe power output has been degrading, see Attachment #1, but this is not yet at the point where the head usually needs replacing. The RIN spectrum doesn't look anomalous to me, see Attachment #2 (the whitening situation for the quadrants is different for the BS and the TMs, which explains the HF noise). I also measured the loop UGFs (using swept sine) - seems funky, I can't get the same coherence now (live traces) between 10-30 Hz that I could before (reference traces) with the same drive amplitude, and the TF that I do measure has a weird flattening out at higher frequencies that I can't explain, see Attachment #3.

The excess RIN is almost exactly in the band that we expect our Oplevs to stabilize the angular motion of the optics in, so maybe needs more investigation - I will upload the loop suppression of the error point later. So far, I don't see any clean evidence of the BS Oplev HeNe being the culprit, so I'm a bit hesitant to just swap out the head...

[chub, gautam]

the replacement was done this afternoon. The red "Replace Battery" indicator is no longer on.

I wanted to check the functionality of the IMC WFS. I just turned on the WFS servo loops as they were. For the past two hours, they didn't run away. The servo has been left turned on. I don't think there is no reason to keep it turned off.

1. The diagram should clearly show the host machines and the expansion chassis and the interconnects between them.
2. We no longer have any Gentoo bootserver or diskless FEs.
3. The "c1lsc" host is in 1X4 not 1Y3.
4. The connection between c1lsc and Dolphin switch is copper not fiber. I don't know how many Gbps it is. But if the switch is 10 Gbps, are they really selling interface cables that have lower speed? The datasheet says 10 Gbps.
5. The control room workstations - Debian10 (rossa) is the way forward I believe. it is true pianosa remains SL7 (and we should continue to keep it so until all other machines have been upgraded and tested on Debian 10).
6. There is no "IOO/OAF". The host is called "c1ioo".
7. The interconnect between Dolphin switch and c1ioo host is via fiber not copper.
8. It'd be good to have an accurate diagram of the current situation as well (with the RFM network).
9. I'm not sure if the 1Y1 rack can accommodate 2 FEs and 2 expansion chassis. Maybe if we clear everything else there out...
10. There are 2 "2GB/s" Copper traces. I think the legend should make clear what's going on - i.e. which cables are ethernet (Cat 6? Cat 5? What's the speed limitation? The cable? Or the switch?), which are PCIe cables etc etc. 

I don't have omnigraffle - what about uploading the source doc in a format that the excellent (and free) draw.io can handle? I think we can do a much better job of making this diagram reflect reality. There should also be a corresponding diagram for the Acromag system (but that doesn't have to be tied to this task). Megatron (scripts machine) and nodus should be added to that diagram as well.

Summary:

1. There appears to be insufficient number of PCIe slots in the new Supermicro servers that were bought for the BHD upgrade.
2. Modulo a "riser card", we have all the parts in hand to put one of the end machines on the Dolphin network. If the Rogue Master doesn't improve the situation, we should consider installing a Dolphin card in the c1iscex server and connecting it to the Dolphin network at the next opportunity. 

Details:

Last night, I briefly spoke with Koji about the CDS upgrade plan. This is a follow up.

Each server needs a minimum of two peripheral devices added to the PCIe bus:

• A PCIe interface card that connects the server to the Expansion Chassis (copper or optical fiber depending on distance between the two).
• A Dolphin or RFM card that makes the IPC interconnects. 
• I'm pretty certain the expansion chasiss cannot support the Dolphin / RFM card (it's only meant to be for ADCs/DACs/BIO cards). At least, all the existing servers in the 40m have at least 2 PCIe cards installed, and I think we have enough to worry about without trying to engineer a hack.
• I attach some photos of new and old Supermicro servers to illustrate my point, see Attachment #1. 

As for the second issue, the main question is if we had an open PCIe slot on the c1iscex machine to install a Dolphin card. Looks like the 2 standard slots are taken (see Attachment #1), but a "low profile" slot is available. I can't find what the exact models of the Supermicro servers installed back in 2010 are, but maybe it's this one? It's a good match visually anyways. The manual says a "riser card" is required. I don't know if such a riser is already installed. 

Questions I have, Rolf is probably the best person to answer:

1. Can we even use the specified host adaptor, HIB25-X4, which is "PCIe Gen2", with the "PCIe Gen3" slots on the new Supermicro servers we bought? Anyway, the fact that the new servers have only 1 PCIe slot probably makes this a moot point.
2. Can we overcome this slot limitation by installing the Dolphin / RFM card in the expansion chassis?
3. In the short run (i.e. if it is much faster than the full CDS shipment we are going to receive), can we get (from the CDS test stand in Downs or the site) 
   • A riser card so that we may install the Gen 1 Dolphin card (which we have in hand) in the c1iscex server?
   • A compatible (not sure what PCIe generation we need) PCIe host to ECA kit so we can test out the replacement for the Sun Microsystems c1ioo server?
   • A spare RFM card (VMIC 5565, also for the above purpose). 
4. What sort of a test should we run to test the new Dolphin connection? Make a "null channel" differencing the same signal (e.g. TRX) sent via RFM and Dolphin? Or is there some better checksum diagnostic?

Koji fixed the problematic channel - the issue was a bad solder joint on the input resistors to the THS4131. The board was re-installed. I also made a custom 2x4-pin LEMO-->DB9 cable, so we are now recording the PMC and FSS ERR/CTRL channel diagnostics again (spectra tomorrow). Note that Ch32 is recording some sort of DuoTone signal and so is not usable. This is due to a misconfiguration - ADC0 CH31 is the one which is supposed to be reserved for this timing signal, and not ADC1 as we currently have. When we swap the c1ioo hosts, we should fix this issue.

I also did most of the work to make the MEDM screens for the revised ASC topology, tried to mirror the site screens where possible. The overview screen remains to be done. I also loaded the anti-whitening filters (z:p 150:15) at the demodulated WFS input signal entry points. We don't have remote whitening switching capability at this time, so I'll test the switching manually at some point.

The CDS model change required to get the AS WFS signals into the RTCDS system are rather invasive.

• We use VCS for these models. Linus Torvald may question my taste but I also made local backups of the models, just in case...
• Particularly, the ADC1 card on c1ioo is completely reconfigured.
• I also think it's more natural to do all the ASC computations on this machine rather than the c1lsc machine (it is currently done in the c1ass model). So there are many IPC changes as well.
• I have documented everything carefully, and the compile/install went smoothly.
• Taking down all the FE servers at 1830 local time. 
  1. To propagagte the model changes
  2. To make a hardware change in the c1rfm card in the c1ioo machine to configure it as "ROGUE MASTER 0"
  3. To clear the RFM errors we are currently suffering from will require a model reboot anyways.
• Recovery was completed by 1930 - the RFM errors are also cleared, and now we have a "ROGUE MASTER 👾" on the network. Pretty smooth, no major issues with the CDS part of the procedure to report.
• The main issue is that in the AA chassis I built, Ch14 (with the first channel as Ch1) has the output saturated to 28V (differential). I'm not sure what kind of overvoltage protection the ADC has - we frequently have the inputs exceed the spec'd +/-20 V (e.g. when the whitening filters are engaged and the cavity is fringing), but pending further investigation, I am removing the SCSI connection from the rear of the AA chassis.

In terms of computational load, the c1ioo model seems to be able to handle the extra load no issues - ~35us/60us per cycle. The RFM model shows no extra computational time. 

After this work, the IMC locking and POX/POY locking, and dither alignment servos are working okay. So I have some confidence that my invasive work hasn't completely destroyed everything. There is some hardware around the rear of 1X2 that I will clear tomorrow.

I just want to point out that if you move all the FEs to the same rack they can all be connected to the Dolphin switch via copper, and you would only have to string a single fiber to every IO rack, rather than the multiple now (for network, dolphin, timing, etc.).

I installed 4 chassis in the rack 1X2 (characterization on the E-bench was deemed satisfactory, I will upload the analysis later). I ran out of hardware to make power cables so only 2 of them are powered right now (1 32ch AA chassis and 1 WFS head interface). The current limit on the +24V Sorensens was raised to allow for similar margin to the limit with the increased current draw.

Remaining work:

1. Make 2 more power cables for ISC whitening chassis and quad demod chassis.
2. Make a 2x 4pin LEMO-->DB9 cable to digitize the FSS and PMC diagnostic channels with the new AA chassis. If RnD cables has a very short turnaround time, might be worth it to give this to them as well.
3. Connect ADC1 on c1ioo machine to new AA chassis (transfer SCSI cable from existing AA unit to the new one). This will necessarily involve some model changes as well.
4. Make a short cable to connect 55 MHz output from RFsource box to the LO input on the quad demod chassis.
5. Install the WFS head on the AS table at a suitable location. Probably will need a focusing lens as well. 
6. Connect WFS head to the signal processing electronics (the cables were already laid out by Jordan and I).
7. Make the necessary CDS model changes (WFS filters, matrices, servos etc). I personally don't see the need for a new model but if anyone feels strongly about separating the IMC WFS and AS WFS we can set up another model.
8. Commission the system.

While I definitely bumped various cables, I don't seem to have done any lasting damage to the CDS system (the RFM errors remain of course).

Our favorite (flexible) RF cable is Belden's 1671J (Jacketed solder-soaked coax cable). It is compatible RG405. I'm not sure if there is off-the-shelf SMA cables with 1671J.

I re-ordered the below cables, this time going with flexible, double-shielded RG316-DS. Jordan will pick up and return the RG-405 cables after the holidays.

Attached is the layout for the "intermediate" CDS upgrade option, as was discussed on Wednesday. Under this plan:

• Existing FEs stay where they are (they are not moved to a single rack)

• Dolphin IPC remains PCIe Gen 1

• RFM network is entirely replaced with Dolphin IPC

Please send me any omissions or corrections to the layout.

As I was working on the IFO re-alignment just now, the rfm errors popped up again. I don't see any useful diagnostics on the web interface.

Do we want to take this opportunity to configure jumpers and set up the rogue master as Rolf suggested? Of course there's no guarantee that will fix anything, and may possibly make it impossible to recover the current state...