I made a voltage divider using a 20.47kohm and 1.07kohm (both values measured with a DMM). The whole thing is packaged inside a Pomona box I found lying around on the Electronics bench. I have hooked it up to the ALSY_I channel and will leave it so overnight. The INMON of this channel isn't DQed, but for this test, the 16Hz EPICS data will suffice. I've locked the EX laser to the arm, enabled slow temperature servo to allow overnight lock (hopefully) and disabled LSC mode (as locking the arm to the MC tends to break the green lock)
To convert the INMON counts to RF power, I will use (based on my earlier calibration of this monitor channel, see DCC document for the demod chassis).
1AM update: Attachment #1 shows that the RF amplitude has been relatively stable (less than 10% of nominal value variation) over the course of the last hour or so. Even though there is some low frequency drift over timescales of ~20mins, no evidence of the wild ~20dB amplitude changes I saw last week. The signs are encouraging...
overnight update: See Attachment #2 - looking at the past 11 hours of second trend data during which the arm stayed locked, there actually seems to have been more significant variation in the beatnote amplitude. Swings of up to 6dBm are seen on a ~20min timescale, while there is also some longer term drift over 12 hours by a couple of dBm. There is probably a systematic error in the Y-axis, as I measured the RF power at the input of the power splitter at the LSC rack to be ~3dBm, so I expect something closer to 0dBm to be the LO input power which is what I am monitoring. So further debugging is required - I think I'll start by aligning the X fiber coupled beam to one of the fiber's special axes.
All rack power supplies labeled if their load changed.
For testing the new IR ALS noise, we had decided that we would like to use the differential output of the demodulated ALS beat signal, as opposed to a single-ended output, as measurements suggested the former to be a lower noise configuration than the latter. For this purpose, Koji and I acquired a couple of old AA boards from the WB electronics shop. These are however, rev2 of the board, whereas the latest version is v6. The main difference between v2 and v6 is that (i) the THS4131 instrumentation amplifier has the Vocm pin grounded in v6 but is floating in v2 and (ii) the buffer opamps are AD8622 in v6 but are AD8672 in v2. But in fact, the boards we have are stuffed with AD8682.
I talked to Rich on Friday, and he seemed to think the AD8672 didn't have any issues noise-wise, the main reason they changed it was because its power consumption was high, and was causing overheating when several of these 1U chassis were packed closely together in an electronics rack. But the AD8682, which is what we have, has comparable power consumption to the AD8622. It is however a JFET opamp, and the voltage noise is a bit higher than the AD8622.
I am sure there is a way to LISO model a differential output opamp like the THS4131, but I thought I'd simulate the noise in LTSPICE instead. But I couldn't get that to work. So instead, I just measured the transfer function and noise of a single channel, for which Koji had expertly hacked together a custom shorting of the THS4131 Vocm pin to ground. Attachments #1 and #2 show the measurement. All looks good. Note that the phase is 180 at DC because I had hooked up the input signal opposite to what it should have been. The voltage noise of the differential outputs (each measured w.r.t. ground, with both inputs shorted to ground by a short patch cable) at 10 Hz is <100nV/rtHz, and the ADC noise is expected to be ~1uV/rtHz, so I think this is fine.
Conclusion: I think for the ALS test, we can just use the AA board in this config without worrying too much about replacing the buffer stage opamps, even though we've ordered 100pcs of AD8622.
Addendum 7 Mar 2018 11am: As per this document, the output noise of the AA board should be <75nV/rtHz from 10 Hz-50 kHz. So maybe the AD8682 noise is a little high after all. I've gotten the LTSpice model working now, will post the comparison of modelled output noise for various combinations here shortly.
Here are the plots. Comments:
I like LTspice for such modeling - the GUI is nice to have (though I personally think that typing out a nodal file a la LISO is faster), and compared to LISO, I think that the LTspice infrastructure is a bit more versatile in terms of effects that can be modeled. We can also easily download SPICE models for OpAmps from manufacturers and simply add them to the library, rather than manually type out parameters in opamp.lib for LISO. But the version available for Mac is somewhat pared down in terms of the UI, so I had to struggle a bit to find the correct syntax for the various simulation commands. The format of the exported data is also not as amenable to python plotting as LISO output files, but i'm nitpicking...
I've gotten the LTSpice model working now, will post the comparison of modelled output noise for various combinations here shortly.
Yesterday, we installed some new DIN rail connectors at the LSC rack to provide 3 new outputs each for +24V DC and -24V DC. The main motivation was to facilitate the installation and powering of the differential receiving AA board. The regulators used inside the 1U chassis actually claims a dropout voltage of 0.5V and outputs 14V nominally, so a +/-15V DC supply would've perhaps been sufficient, but we decided to leave a bit more margin, and unfortunately, there are no +/-18V DC KEPCO linear power supplies to the LSC rack. Procedure:
The c1lsc frontend models crashed for some reason during this procedure. Now the c1sus frontend model is also behaving weirdly. It is unclear to me if/how this work would have led to these problems, but the temporal correlation (but not causation?) is undeniable.
[Jon, Gautam, Johannes]
Summary: In support of making a proof-of-concept RF measurement of the SRC Gouy phase, we've implemented a PLL of the aux. 700mW NPRO laser frequency to the PSL. The lock was demonstrated to hold for minutes time scales, at which point the slow (currently uncontrolled) thermal drift of the aux. laser appears to exceed the PZT dynamic range. New (temporary) hardware is set up on an analyzer cart beside the PSL launch table.
- Characterize PLL stability and noise performance (transfer functions).
- Align and mode-match aux. beam from the AS table into the interferometer.
- With the IFO locked in a signal-recycled Michelson configuration, inject broadband (swept) AM sidebands via the aux. laser AOM. Coherently measure the reflection of the driven AM from the SRC.
- Experiment with methods of creating higher-order modes (partially occluding the beam vs. misaligning into, e.g., the output Faraday isolator). The goal is identify a viable techinque that is also possible at the sites, where the squeezer laser serves as the aux. laser.
The full measurement idea is sketched in the attached PDF.
Some notes about the setup and work at the PSL table today, Jon can add to / correct me.
Attached are final details of the phase-locked loop (PLL) implementation we'll use for slaving the AUX 700 mW NPRO laser to the PSL.
The first image is a schematic of the electronics used to create the analog loop. They are curently housed on an analyzer cart beside the PSL table. If this setup is made permanent, we will move them to a location inside the PSL table enclosure.
The second image is the measured transfer function of the closed loop. It achieves approximately 20 dB of noise suppression at low frequencies, with a UGF of 50 kHz. In this configuration, locks were observed to hold for 10s of minutes.
this doesn't make much sense to me; the phase to frequency conversion (mixer-demod to PZT ) should give us a 1/f loop as Johannes mentioned in the meeting. That doesn't agree with your loop shape.
How about give us some more details of the setup including photos and signal/power levels? And maybe measure the LB1005 TF by itself to find out what's wrong with the loop.
[jon, steve, gautam]
Some points which Jon will elaborate upon (and put photos of) in his detailed elog about this setup:
We are now in a state where the PLL can be locked remotely from the control room by tweaking the AUX laser temperature . Tomorrow, Keerthana will work on getting Craig's/Johannes' Digital Frequency Counter script working here, I think we can easily implement a PLL autolocker if we have some diagostic that tells us if the PLL us locked or not.
Steve informed me that there is an acoustic hum inside the PSL enclosure which wasn't there before. Indeed, it is at ~295Hz, and is from the Bench power supply used to power the ZFL500HLN amplifier. This will have to go...
As I suspected, when the SR560 is operated in 1 Hz, first order LPF mode, the (electronic) transfer function has a zero at ~5kHz (!!!).
This is what allowed the PLL to be locked with this setting with UGF of ~30kHz. On the evidence of Attachment #3, there is also some flattening of the electrical TF at low frequencies when the SR560 is driving the NPRO PZT. I'm pretty sure the flattening is not a data download error but since this issue needs further investigation anyway, I'm not reading too much into it. I fit the model with LISO but since we don't have low frequency (~1Hz) data, the fit isn't great, so I'm excluding it from the plots.
We also did some PLL loop characterization. We decided that the higher output range (10Vp bs 10Vpp for the SR560) of the LB1005 controller means it is a better option for the PLL. The lock state can also be triggered remotely. It was locked with UGF ~ 60kHz, PM ~45deg.
We also measured the actuation coefficient of the NPRO laser PZT to be 4.89 +/- 0.02 MHz/V. Quoted error is (1-sigma) from the fit of the linear part of the measured transfer function to a single pole at DC with unknown gain. I used the "clean" part of the measurement that extends to lower frequencies for the fit, as can be seen from the residuals plot. Good to know that even though the LDs are dying, the PZT is still going strong :D.
Remaining loop characterization (i.e. verification of correct scaling of in loop suppression with loop gain etc.) is left to Jon.
Some other remarks:
Attached is supporting documentation for the AUX-PSL PLL electronics installed in the lower PSL shelf, as referenced in #13845.
Some initial loop measurements by Gautam and Koji (#13848) compare the performance of the LB1005 vs. an SR560 as the controller, and find the LB1005 to be advantageous (a higher UGF and phase margin). I have some additional measurements which I'll post separately.
Pickoffs of the AUX and PSL beams are routed onto a broadband-sensitive New Focus 1811 PD. The AUX laser temperature is tuned to place the optical beat note of the two fields near 50 MHz. The RF beat note is sensed by the AC-coupled PD channel, amplified, and mixed-down with a 50 MHz RF source to obtain a DC error signal. The down-converted term is isolated via a 1.9-MHz low-pass filter in parallel with a 50 Ohm resistor and fed into a Newport LB1005 proportional-integral (PI) servo controller. Controller settings are documented in the below schematic. The resulting control signal is fed back into the fast PZT actuator input of the AUX laser.
I setup a basic MEDM screen for remote control of the PLL.
The Slow control voltage slider allows the frequency of the laser to be moved around via the front panel slow control BNC.
The TTL signal slider provides 0/5V to allow triggering of the servo. Eventually this functionality will be transferred to the buttons (which do not work for now).
The screen can be accessed from the PSL dropdown menu in sitemap. We can make this better eventually, but this should suffice for initial setup.
Below is analysis of measurements I had taken of the AUX-PSL PLL using an SR560 as the servo controller (1 Hz single-pole low-pass, gain varied 100-500). The resulting transfer function is in good agreement with that found by Gautam and Koji (#13848). The optimal gain is found to be 200, which places the UGF at 15 kHz with a 45 deg phase margin.
For now I have reverted the PLL to use the SR560 instead of the LB1005. The issue with the LB1005 is that the TTL input for remote control only "freezes" the integrator, but does not actually reset it. This is fine if the lock is disabled in a controlled way (i.e., via the medm interface). However, if the lock is lost uncontrollably, the integrator is stuck in a garbage state that prevents re-locking. The only way to reset this integrator is to manually flip a switch on the controller box (no remote reset). Rana suggests we might be able to find a workaround using a remote-controlled relay before the controller.
Article from EE Times, describing why metal foil (NOT metal film) resistors are really better than wirewound when it comes to everything except high power dissipation.
Need to do some diggin to see if we can find ~1k metal foil resistors which can handle ~1W of heat.
Steve: here it is
Since we've been hijacking channels like there is no tomorrow for the AUX-PLL setup, I'm documenting the channel names here. The next time c1psl requires a reboot, I'll rename these channels to something more sensible. To find the channel mapping, Koji suggested I use this. Has worked well for us so far... We've labelled all pairs of wires pulled out of the cross connects and insulation taped the stripped ends, in case we ever need to go back to the original config.
To mitigate integrator railing
Attached are gain-variation measurements of the final, in situ AUX-to-PSL phase-locked loop (PLL).
Attachment 1: Figure of open-loop transfer function
Attachment 2: Raw network analyzer data
The figure shows the open-loop transfer function measured at several gain settings of the LB1005 PI servo controller. The shaded regions denote the 1-sigma sample variance inferred from 10 sweeps per gain setting. This analysis supercedes previous posts as it reflects the final loop architecture, which was slightly modified (now has a 90 dB low-frequency gain limit) as a workaround to make the LB1005 remotely operable. The measurements are also extended from 100 kHz to 1 MHz to resolve the PZT resonances of the AUX laser.
I took this opportunity of EX downtime to change the supply voltage for the AA unit (4-pin LEMO front panel) in 1X9 from +/-5V to +/-15V. Inside the AA board are INA134 and DRV135 ICs, which are rated to work at +/-18V. In the previous state, the inputs would saturate if driven with a 2.5Vpp sine wave from a DS345 func. gen. After the change, I was able to drive the full range of the DS345 (10Vpp), and there was no saturation seen. This AA chassis is only used for the OSEM signals and also some ALS signals. Shadow sensor levels and spectra are consistent before and after the change. The main motivation was to not saturate the Green PDH Reflection signal in the digital readout. The steps we took were:
I've been thinking about what we need to do to the de-whitening boards for the ITMs and ETMs, in order to have low noise actuators. Noting down what I have so far, so that people can comment / point out things I've overlooked.
Attachment #1: Block diagram schematic of the de-whitened signal path on D000183 as it currently exists. I've omitted the unity gain buffer stage at the output, though this is important for noise considerations.
Some considerations, in rough order of priority:
I will experiment with a few different shapes and investigate noise and de-whitened digital signal levels based on these considerations. At the very least, I guess we should remove the x3 gain on the ETM boards, they have already been bypassed for the ITMs.
You have this measurement problem when the IF bandwidth is larger than the measurement frequency. I suspect the IF bandwidth is 30kHz.
I walked down to the X end and found that the entire AUX laser electronics rack isn't getting any power. There was no elog about this.
I couldn't find any free points in the power strip where I think all this stuff was plugged in so I'm going to hold off on resurrecting this until tomorrow when I'll work with Steve.
The X arm green does not stay locked to the cavity - the alignment looks fine, and the green flashes are strong, but the lock does not hold. This shouldn't be directly connected to anything we did today since the Green PDH servo is entirely analog.
Steve and I restored the power to the EX AUX electronics rack. The power strip on the lowest shelf of the AUX rack now goes to another power strip laid out vertically along the NW corner of 1X9. The EX green locks to the arm just fine now.
We went around the LSC, PSL, IOO, and SUS racks to check how many dual backplane interfaces will be required.
Euro card modules are connected to the backplane with two DIN 41612 connectors (as you know). The backplane connectors provide DC supplies and GND connections.
In addition, they are also used for the input and output connections with the fast and slow machines.
According to the past inspection by Johannes, most of the modules just use the upper DIN41612 connector (called P1). But there are some modules exhibited the possibility of the additional use of the other connector (P2).
Tuesday afternoon Johannes and I made the list of the modules with the possible dual use. And I took a time to check the modules with DCC, Jay's schematics, and the visual inspection of the actual modules.
I think we don't need to keep Crystal Ref: we can change this into a regular Wenzel box with no outside control or monitoring.
The Contec test board with Dsub37Fs was on the top shelf of E7
For the last week, I noticed that I was unable to turn the EY chamber illuminator on using the remote python scripts. This was turning out to be really annoying, having to turn the light on/off manually. Today, I looked into the problem and found that there is a conflict in the IP addresses of the EY Ethernet Strip (which Chas assigned a static IP but did not include detailed procedures for) and the vertex area laptop, paola. The failure of the python control of the power strip coincided exactly with when Chub and I turned on paola for working at the IY chamber - but how was I supposed to know these events are correlated? I tried shutting down paola , power cycling the Ethernet power strip, and restarting the bind9 services on chiara, but remote control of the ethernet power strip remains elusive. I suspect reconfiguring the static IP for the Ethernet switch will require some serial port enabled device...
I had taken Satellite box S/N 102, from the SRM suspension, down to the Y-end as part of debugging. However, at some point, I stopped getting readbacks from the shadow sensor PDs, even with the Sat. Box tester hooked up (so as to rule out anything funky with the actual OSEMs). Today evening, I did a more systematic investigation. Schematic with component references is here.
The question remains as to what caused this failure mode - I can't think of why that particular IC was damaged during the Satellite box swapping process - is this indicative of some problem elsewhere in the ETMY OSEM/coil driver electronics chain?
To avoid the annoying excercise of having to manually toggle the illuminators, I solved the IP conflict. Made a wiki page for the ethernet power strips since the documentation was woeful (the way the power strips are mounted in the racks, you can't even see the manufacturer/model/make). All chamber illuminators can now be turned on/off by the MEDM scripts . Note that there is a web interface available too, which can be useful in case of some python socket issues. The main lesson is: avoid using the "reset" button on the power strips, it destroys the static IP config.
Unrelated to this work: The EY laptop, asia, won't boot up anymore, with a "Fan Error" message being the red flag. I've temporarily recommissioned the vacuum rack laptop, belladonna, to be the EY machine for this vent. Can we get 3 netbooks that actually work and don't need to be tethered to a power strip for the VEA?
[chub, koji, gautam]
Attachment #1 shows the signal routing near the Satellite box. Somehow, the female 64 pin IDC connector that brings the signals from the coil driver board wasn't mating well with the mail connector on the Satellite box front panel. This is a connector specific problem - plugging the female end into one of the male connectors inside the Satellite box yielded signal continuity. The problem was resolved by re-making both connections -by driving the EPICS bias slider through its full range, we were able to see the full voltage swing at the DB connectors going to the flange
This kind of flakiness could be all around the lab, and could be responsible for many of the suspension "mysteries". To re-iterate, the problem seems to be the way the female sockets of the connector mates with the male pins - while the actual crimping points may look secure, there may not be signal continuity.
Now that this problem is resolved, tomorrow we will recover the cavity alignment and possibly start a pumpdown.
Unrelated to this work - the spare satellite box (S/N #100), which had a note on it that said "low voltages", was tested. The "low voltages" referred to the OSEM shadow sensor voltages being low when the LED was completely unobscured. The reason was that the mod to increase the drive current to 25 mA had not yet been implemented on this unit. I added the appropriate 806 ohm resistors, and verified that the voltages were correct, so now we have a working spare. It is stored in the "photodiode" cabinet along the east arm, together with the tester boxes.
I've borrowed the Busby Box for a day or so. Location: QIL lab at Bridge West.
Edit Sat Apr 20 21:16:46 2019 (awade): returned.
After the X and Y arm naming conventions were changed, the labelling of the electronics in the eurocrates was not changed 😞 😔 😢 . This meant that when we hooked up the new Acromag crate, all the slow ITMX channels were in fact connected to the physical ITMY optic. I ♦️fixed♦️ the labelling now - Attachments #1 and #2 show the coil driver boards and SUS PD whitening boards correctly labelled. Our electronics racks are in desperate need of new photographs.
The "Y" arm runs in the EW direction, while the "X" arm runs in the NW direction as of April 29 2018.
ITMX was freed. ITMY is being worked on is also free..
Rich dropped by at around 3:00 PM today and picked up the VCO in Attachment #1 and left the note in Attachment #2 on Gautam's desk with the promise of bringing it back soon.
We crossed off another couple of bullets today.
It took me ~1 hour to realize that c1susaux requries the running of sudo /sbin/ifup eth0 to be run in order to see the martian network - why???
I don't understand the exact chain of causation, but during this work, the fast c1sus model crashed. I had to go through a few iterations of the scripted vertex machine rebooting, but things seem to be back in a normal state now, see Attachment #2. Should probably run the IFO test suite to make sure everything is a-okay, but for now, I am able to lock the IMC so I'm moving on.
The main task remaining here is to take new pictures of everything and upload to the wiki. Also, need to update the Sorensen labels to reflect their current values, some of them are outdated.
I looked at the PSL/IOO racks to check for which boards, if any, require an additional P2 interface, so that we can try and design a generic one for the IMC/CM boards and whatever else may require it. While searching the elog, I saw that Koji and Johannes had already done this, see Koji's elog in this thread. Some remarks:
Conclusion: Only the IMC Servo and CM boards need their P2 connectors connected to Acromag.It would be helpful to remove the TTFSS Interface board and figure out what exactly the pin-mapping for the backplane connectors are, but I didn't do this today because there is a "High Voltage" line going to the Interface Board and I'm not actually sure of the signal chain for the FSS servo.
I borrowed an old-looking Variac variable transformer from the power supplies cabinet along the y-arm. It is currently in the TCS lab.
Mon Oct 7 14:51:53 2019. I closed the PSL shutter to measure the WFS head responsivity.
I made a thru calibration as in this elog, treating laser, reference PD, and WFS RF output as a three-port device. The DC current supplied to the laser is 20.0 mA in all cases. The Agilent spectrum analyzer supplies a -10 dBm excitation to Jenne laser's AM port, and A/B is measured with 20dB attenuation on each input port. Results are in /users/aaron/WFS/data/191007/. The calibration had 100 averages, all other measurements 32 averages; other parameters found in the yml file, same folder as the data.
I normalized the result by the difference between the dark and bright DC levels of each segment.
Mon Oct 7 17:29:58 2019 opened PSL shutter.
I simulated this circuit with zero, but haven't gotten the results to match the measurements above.
It would be good if you and Shruti can look at how to change the parameters in Zero so as to do a fit to the measured data. Usually, in scipy.optimize we give it a function with some changeable params, so maybe there's a way to pass params to a zero object in that way. I think Ian and Anchal are doing something similar to their FSS Pockel's cell simulator.
In 1X1, there is a box labelled "FSS REF" below a KEPCO HV supply. This box had a power cable that wasn't actually connected to any power. I removed said cable.
[JV, JWR, YD, GV]
Jordan and I removed another 10 kg of cabling from 1X2. The c1iool0 crate now has all cabling to it disconnected - but it remains in the rack because I can't think of a good way to remove it without disturbing a bunch of cabling to the fast c1iool0 machine. We can remove it the next time the vertex FEs crash. Cross connects have NOT been removed - we will identify which cross connects are not connected to the fast system and trash those.
Do we want to preserve the ability to use the PZT driver in 1X2?
I used existing BNC cables running from the PSL table to the PSL rack and reassigned them to the PSL Shutter and PMC transmission PD channels.
The PSL shutter turned out to be a sinking channel. Jordan reconnected the PSL shutter wires to a sinking BIO Acromag. Channel list is updated.
Both channels have been tested to be working as expected.
gautam add on about EPICS:
P.S - there is a problem we noticed - if the modbus process is started with the local subnet not having a fixed IP address, then all the EPICS channels will not be responsive. The way to fix this is to run the following sequence of commands:
After discussing with Koji, I removed the PZT driver and associated AI card from the Eurocrate at 1X2. The corresponding backplane connectors were also removed from the cross connects. An additional cable going from the DAC to IDC adaptor on 1X2 was removed. Finally, some cables going to the backplane P1 and P2 connectors for slots in which there were no cards were removed.
Finally, there is the IMC WFS whitening boards. These were reconfigured in ~2016 by Koji to have (i) forever whitening, and (ii) fixed gain. So the signals from the P1 connector no longer have any influence on the operation of this board. So I removed these backplane cables as well.
Some pics attached. The only cross connect cabling remaining on the south side of 1X2 is going to the fast BIO adaptor box - I suspect these are the triggered fast whitening switching for the aforementioned WFS whitening board. If so, we could potentially remove those as well, and remove all the cross connects from 1X1 and 1X2.
Update 1720: indeed, as Attachment #2 shows, the RTCDS BIO channels were for the WFS whitening switching so I removed those cables as well. This means all the xconnects can be removed. Also, the DAC and BIO cards in c1ioo are unused.
Jon is going to write up the details of todays adventures. But the C1PSL Acromag chassis is sitting on the floor between the IMC beamtube and the 1X1 electronics rack, and is very much a trip hazard. Be careful if youre in that area.
We are going to replace the old Sun c1ioo with a modernized supermicro. At the opportunity, remove the DAC and BIO cards to use them with the new machines. BTW I also have ~4 32ch BIO cards in my office.
The C1PSL crate has now been installed in a more permanent way in the rack.
After this work, I disabled logging and restarted the modbus service (and copied the current version of the systemd service file to the target directory for backup). The PMC and IMC lock alright. The system is now ready to be tested in-situ. I will separately continue my IMC Servo board tests in the evening.
One thought about how to protect against this kind of silent failure - how about we always run the modbus service with logging enabled, and then send out a warning email and stop the service if the logfile size suddenly blows up (which is characteristic of when the communications process dies)? This should be done in addition to the ping-ing of the individual IPs.
Regarding the burt-restore step that the systemd service runs after starting up the IOC - this is not even that useful, at least in the way it is currently setup (restore the "latest" burt snapshot file). If the maintenance takes >1hour as it often does, the "latest" snapshot for the system under maintenance is just garbage. So either the burt-restore should be for a "known good time" (dangerous because this will require frequent updates of the systemd service every time we find a new safe state) or we should just do it manually (my preference). Then there is no need to install custom packages on the server machine. Anyway, for now, I have not commented this step out.
Jordan is going to take pictures of all the electronics racks and update the relevant wiki pages.
With the Acromag chassis now permanently installed, we tested the C1PSL channels going over the channel list one by one, excluding the IMC channels which Gautam is taking responsibility for (the servo board itself is also in question).
The strategy is to check the response of input channels to specific output channels for expected behaviour whenever is possible.
We marked on the channel list spreadsheet the status of the channels that were tested.
In more detail
PMC Servo Card
Unlocked the PMC by switching C1:PSL-PMC_SW1. Tweaked C1:PSL-PMC_RAMP and observed a change in C1:PSL-PMC_PZT.
We misaligned MC1 to get a measurable signal in WFS channels. NDScoped the corresponding C1:IOO-WFS*_SEG*_I&Q channels and observed a change in those channels in response to switching the attenuation on and off.
The signals were compared to previous values for consistency. Then they were unplugged from the Acromag chassis to confirm their values went to 0 and returned to the same values after being reconnected.
I am running some tests on the IMC servo board with an extender card so the IMC will not be locking for a couple of hours.
It seems like the AO path gain stages on the IMC Servo board work just fine. The weird results I reported earlier were likely a measurement error arising from the fact that I did not disconnect the LEMO IN2 cable while measuring using the BNC IN2 connector, which probably made some parasitic path to ground that was screwing the measurement up. Today, I re-did the measurement with the signal injected at the IN2 BNC, and the TF measured being the ratio of TP3 on the board to a split-off of the SR785 source (T-eed off). Attachments #1, #2 shows the result - the gain deficit from the "expected" value is now consistent with that seen on other sliders.
Note that the signal from the CM board in the LSC rack is sent single-ended over a 2-pin LEMO cable (whose return pin is shorted to ground). But it is received differentially on the IMC Servo board. I took this chance to look for evidence of extra power line noise due to potential ground loops by looking at the IMC error point with various auxiliary cables connected to the board - but got distracted by some excess noise (next elog).