In my effort to understand what's going on with the suspensions, I've kicked all the suspensions and shutdown the watchdogs at 1235366912. PSL shutter is closed to avoid trying to lock to the swinging cavity. The primary aims are
All the tests I have done so far (looking at free swinging data, resonant frequencies in the Oplev error signals etc) seem to suggest that the problem is mechanical rather than electrical. I'll do a quick check of the OSEM PD whitening unit in 1Y4 to be sure.But the fact that the same three peaks appear in the OSEM and Oplev spectra suggests to me that the problem is not electrical.
Watchdogs restored at 10 AM PST
The goal for this week is to test out the ALS system, so this is kind of a workable state since POX/POY locking is working. But the number of broken things is accumulating fast.
[Gautam/Chub/Koji] ~ Mini discussion
Maintenance / Upgrade Items
(Priority high to low)
Apr 16, 2019
Borrowed two laser goggles from the 40m. (Returned Apr 29, 2019)
Apr 19, 2019
Borrowed from the 40m:
- Universal camera mount
- 50mm CCD lens
- zoom CCD lens (Returned Apr 29, 2019)
- Olympus SP-570UZ (Returned Apr 29, 2019)
- Special Olympus USB Cable (Returned Apr 29, 2019)
The air handler on the roof of the 40M that supplies the electronics shop and computer room is out of operation until next week. Adding insult to injury, there is a strong odor of Liquid Wrench oil (a creeping oil for loosening stuck bolts that has a solvent additive) in the building. If you don't truly need to be in the 40M, you may want to wait until the environment is back to being cool and "unscented". On a positive note, we should have a quieter environment soon!
Four new 2" CVI 50/50 beamsplitters (2 for p-pol and 2 for s-pol) were delivered. They have been stored in the optics cabinet, along with the "Test Data" sheets from CVI.
The 40M jib cranes all passed inspection!
I believe this completes the non-Chub portions of the pre-vent checklist, we will start letting air into the main volume ASAP tomorrow morning after crossing off the remaining items.
Main goal of this vent is to investigate the oddness of the YARM suspensions. I leave the PSL NPRO on overnight in the interest of data gathering, it's been running ~10 hrs now - I suspect it'll turn itself off before we are ready to vent in the AM.
IMC was locked, MC2T ~ 1200cts after some alginment touch ups. The test mass oplevs indicate some drift, ~100urad. I didn't realign them.
The EY door removal will only be done tomorrow. I will take some free-swinging ETMY data today (suspension was kicked at 1241919438) to see if anything has changed (it shouldn't have). I need to think up a systematic debugging plan in the meantime.
Today, we tried to resuscitate the c1iscaux2 channels by swapping the existing, failed VME crate with the newly freed up crate from c1susaux. In summary, the crate gets power, and the EPICS server gets satrted, but I am unable to switch the whitening gain on the whitening boards. I belive that this has to do with the FAIL LEDs that are on for the XVME-220 units. We were careful to preserve the location of the various cards in the VME crates during the swap. Rather than do a detailed debugging with custom RJ45 cables and terminal emulators, I think we should just focus the efforts on getting the Acromag system up and running.
Our work must have bumped a cable to the c1lsc expansion chassis in the same rack - the c1lsc FE had crashed. I rebooted it using the script - everything came back gracefully.
There was a magnitude 6.6 earthquake just a few minutes ago. I am attaching photographs of the monitor feeds for reference here. Is there a standard protocol to be followed in this situation? I'm looking through the wiki now.
Further, the IMC seems to be misaligned and is not locking! As Koji has let me know, I really hope this is not too serious and can be fixed easily.
Last documented replacement in Nov 2018, so ~7 months, which I believe is par for the course. I am disconnecting its power supply cable.
In fact the projector is still working. The lamp timer showed ~8200hrs. I just reset the timer, but not sure it was the cause of the shutdown. I also set the fan mode to be "High Altitude" to help cooling.
I heard a popping sound in the control room; the projector lightbulb has blown out.
Optical chopper borrowed from CryoLab to 40m
Bulb replaced. Projector is back on.
The control room UPS started making a beeping noise saying batteries need replacement. I hit the "Test" button and the beeping went away. According to the label on it, the batteries were last repalced in March 2016, so maybe it is time for a replacement, @Chub, please look into this.
For some reason, rossa's Xdisplay won't start up anymore. This happened right after the UPS reset. Koji and I tried ~1.5 hours of debugging, got nowhere.
SnapPy scripts made to work on Pianosa.
Of course rossa was the only machine in the lab that could run the python scripts to interface with the GigE camera. And it is totally bricked now. Lame.
So I installed several packages. The key was to install pypylon - if you go to the basler webpage, pypylon1.4.0 does not offer python2.7 support for x86_64 architecture, so I installed pypylon1.3.0. Here are the relevant lines from the changelog:
gstreamer-plugins-bad-0.10.23-5.el7.x86_64 Sat 20 Jul 2019 11:22:21 AM PDT
gstreamer-plugins-good-0.10.31-13.el7.x86_64 Sat 20 Jul 2019 11:22:11 AM PDT
gstreamer-plugins-ugly-0.10.19-31.el7.x86_64 Sat 20 Jul 2019 11:20:08 AM PDT
gstreamer-python-devel-0.10.22-6.el7.x86_64 Sat 20 Jul 2019 10:34:35 AM PDT
pygtk2-devel-2.24.0-9.el7.x86_64 Sat 20 Jul 2019 10:34:34 AM PDT
pygobject2-devel-2.28.6-11.el7.x86_64 Sat 20 Jul 2019 10:34:33 AM PDT
pygobject2-codegen-2.28.6-11.el7.x86_64 Sat 20 Jul 2019 10:34:33 AM PDT
gstreamer-devel-0.10.36-7.el7.x86_64 Sat 20 Jul 2019 10:34:32 AM PDT
gstreamer-python-0.10.22-6.el7.x86_64 Sat 20 Jul 2019 10:34:31 AM PDT
gtk2-devel-2.24.31-1.el7.x86_64 Sat 20 Jul 2019 10:34:30 AM PDT
libXrandr-devel-1.5.1-2.el7.x86_64 Sat 20 Jul 2019 10:34:28 AM PDT
pango-devel-1.42.4-1.el7.x86_64 Sat 20 Jul 2019 10:34:27 AM PDT
harfbuzz-devel-1.7.5-2.el7.x86_64 Sat 20 Jul 2019 10:34:26 AM PDT
graphite2-devel-1.3.10-1.el7_3.x86_64 Sat 20 Jul 2019 10:34:26 AM PDT
pycairo-devel-1.8.10-8.el7.x86_64 Sat 20 Jul 2019 10:34:25 AM PDT
cairo-devel-1.15.12-3.el7.x86_64 Sat 20 Jul 2019 10:34:25 AM PDT
mesa-libEGL-devel-18.0.5-3.el7.x86_64 Sat 20 Jul 2019 10:34:24 AM PDT
libXi-devel-1.7.9-1.el7.x86_64 Sat 20 Jul 2019 10:34:24 AM PDT
pygtk2-doc-2.24.0-9.el7.noarch Sat 20 Jul 2019 10:34:23 AM PDT
atk-devel-2.28.1-1.el7.x86_64 Sat 20 Jul 2019 10:34:21 AM PDT
libXcursor-devel-1.1.15-1.el7.x86_64 Sat 20 Jul 2019 10:34:20 AM PDT
fribidi-devel-1.0.2-1.el7.x86_64 Sat 20 Jul 2019 10:34:20 AM PDT
pixman-devel-0.34.0-1.el7.x86_64 Sat 20 Jul 2019 10:34:19 AM PDT
libXinerama-devel-1.1.3-2.1.el7.x86_64 Sat 20 Jul 2019 10:34:19 AM PDT
libXcomposite-devel-0.4.4-4.1.el7.x86_64 Sat 20 Jul 2019 10:34:19 AM PDT
libicu-devel-50.1.2-15.el7.x86_64 Sat 20 Jul 2019 10:34:18 AM PDT
gdk-pixbuf2-devel-2.36.12-3.el7.x86_64 Sat 20 Jul 2019 10:34:17 AM PDT
pygobject2-doc-2.28.6-11.el7.x86_64 Sat 20 Jul 2019 10:34:16 AM PDT
pygtk2-codegen-2.24.0-9.el7.x86_64 Sat 20 Jul 2019 10:34:15 AM PDT
Camera server is running on a tmux session on pianosa. But it keeps throwing up some gstreamer warnings/errors, and periodically (~every 20 mins) crashes. Kruthi tells me that this behavior was seen on Rossa as well, so whatever the problem is, doesn't seem to be because I missed out on installing some packages on pianosa. Moreover, if the server is in fact running, I am able to take a snapshot - but the camera client does not run.
"bricked" is to mean that it has the functionality of a brick and can be tossed. But rossa seems to have just gotten some software config corruption. I spent a couple hours reinstalling SL7 today as per my previous elog notes and the X display seems to work as before.
i.e. it was fine with the default setup, except for the ole "X chrashes if the mouse goes to left side of screen". As before, I
left side of screen is safe again
This time I installed SL7.6 and followed the K Thorne wiki. But its having trouble installing cds-root because it can't find root.
I want to collect some data with the arms locked to investigate the possibility/usefullness of having seismic feedforward implemented for the arms (it is already known to help the IMC length and PRC angular stability at low frequencies). To facilitate diagnostics I modified the file /users/Templates/Seismic/Seismic_vs_TRXTRYandMC.xml to have the correct channel names in light of Lydia's channel name changes in 2016. Looking at the coherence data, the alignment of the cartesian coordinate system of the Seismometers at the ends and the global interferometer coordinate system can be improved.
I don't know if for the MISO filter design if there is any difference in using TRX/TRY as the target, or the arm length control signal.
Data collection started at 1249018179. I've setup a script running in a tmux shell to turn off the LSC enable in 2 hours.
When I put away the lenses we had used for measuring the RF transfer functions of the QPD heads, I saw that I'd removed them from the cabinet containing green endtable optics, but hadn't noticed the sign forbidding their removal. I'll talk with Koji/Gautam about what happened and what should be done.
Once Koji is done with his checkout of the whitening electronics, I will try and lock the PRMI.
I propose the following re-organization of the PDFR measurement breadboard. We have all the parts on hand, just needs ~30mins of setup work and some characterization afterwards. The fiber beamsplitter will not be PM, but for this measurement, I don't think that matters (the patch fiber from the diode laser head isn't PM anyways). We have one spare 1 GHz BW NF1611 that is fiber coupled (used to live on the ITMY in-air table, and is (conveniently) labelled "REF DET", but I'm not sure what the function of this was). In any case, we have at least 1 free-space NF1611 photodiode available as well. I suggest confirming that the FC version works as expected by calibrating against the free space PD first.
Update 245pm: Implemented, see Attachment #2. Aaron is testing it now, and will post the characterization results.
I'm curious to see if we really need the 1611, or if we can calibrate the diode laser vs. the 1611 one time and then just use that calibration to get the absolute cal for the DUT.
I'm afraid that the RF modualtion of the laser is nonlinear and the electrical and optical resoponse is dependent on the LD pumping current and RF input power. So I feel safe if we keep the reference PD. Of course, this is my feeling and it should be quantitatively tested.
I measured the RF response of the fiber-coupled NewFocus 1611, calibrating out the cable delay. The laser current was set to 20.0 mA, and the RF power going into the splitter was -10 dBm. The DC voltage was 1.87 V, and Gautam and I measured the power from the fiber at 344uW.
Something still looks very wrong -- the PD is supposed to be flat out to 1GHz, and physical units pending, need food.
The 1GHz PD has a bit more flat response, but the laser and the driving network have more frequency dependence as you saw.
I think the metric of interest here is the consistency of the AC transimpedance of the proposed new "Reference PD" (= fiber coupled NF1611) vs the old reference (free space NF1611), since everything will be calibrated against that.
The fiber-coupled PD seems to have a factor of ~1.5 difference in responsivity compared to the free-space PD. There are some differences in the two ways I made the measurement that I don't yet understand.
I measured relative responsivities of the fiber and free coupled NewFocus 1611 PDs (scaled by the Jenne AM transfer function).
I made the measurement in two ways, see attachment three. In attachment one, I show the response for separately measuring the two PDs relative to a pickoff of the source (two-port thru calibration). In attachment two I measure the relative responses directly, without picking off a reference (three-port calibration). I scaled the transfer functions by their DC voltages; both PDs have transimpedances of 700 V/A.
However, there are some clear differences in the response (overall factor of 0.5dB offset that may be explained by a miscalibrated DC level; apparent periodicity in attachment 1) that I don't yet understand.The free path of the non-fiber PD is ~5-6 inches, which accounts for the ~45 degrees of phase advance of the fiber relative to free coupled PD signal. (12.7cm / (c / 300 MHz) * 360 degrees ~ 45 degrees)
[Jon, Yehonathan, Gautam, Aaron, Shruti, Koji]
We get together on Wednesday afternoon for cleaning the lab. Particularly, we collected e-wastes: VME crates, VME modules, old slow control cables, and other old/broken electronics. They are piled up in the office area and the cage outside rioght now (Attachments 1/2). We asked Liz to come to pick them up (under the coordination with either Gautam or Koji). Eventually this will free up two office desks.
Also, we made the acromag components organized in plastic boxes. (Attachment 3)
The UPS is now incessantly beeping. I cannot handle this constant sound so I shut down all the control room workstations and moved the power strip hosting the 4 CPUs to a wall socket for tonight. Chub and I will replace the UPS batteries tomorrow.
[Liz, Gautam, Chub, Jordan, Koji]
We removed a significant amount of e-waste from the lab. The garbage was moved to the e-waste station in WB SB and are waiting for disposal.
Batteries + power cables replaced, and computers back on UPS from today ~3pm.
Some ideas that would help increase the locking duty-cycle in the short term.
I worked on the setup up for the phase modulation measurement of the X end NPRO PZT. A previous similar measurement can be found here (12077). The setup was assembled based on the schematic in Attachment1.
Mixer used: Level 7, Mini circuits ZP-3+
LPF: up to 1.9MHz
Cables exiting the PSL table:
1. LO (Marconi -> Mixer)
2. RF (PSL+X beat note -> Mixer) The cable for this was taken from the Beat Mouth (otherwise connected to the oscilloscope)
3. Ext modulator (SR560 -> Marconi)
The long cable labled 'X Green Beat' was used to connect to the PZT (from the network analyzer).
Observations: The beat note kept floating between 0 and ~100 MHz
The PLL part of the circuit was tested coarsely with the spectrum analyzer function of the Agilent, where the loop was seen to stabilize when the carrier frequency of the Marconi was close to the instantaneous beat frequency.
Were some cables from the ALS beat setup modified? I can't see the beat on the scope, and this elog doesn't say anything about cable connection rearrangement. At ~2311, I am reverting the setup to as it should be.
I symlinked the SRmeasure and AGmeasure commands to /usr/bin/ on donatella (as it is done on pianosa) so that these scripts are in $PATH and may be run without having to navigate to the labutils directory.
1. Normally I would unlock the IMC (Disabling the servo between the 'Filter' and 'Polarity' on the Mode Cleaner Servo Screen), but today I did not have to since Rana had kept it unlocked.
2. Misaligned the ITMX. This is to prevent cavity resonances from returning to the laser
3. Turned up the air on the HEPA at the PSL table to 100% during the measurement
4. Cables were connected as before (diagram shown in attachment of elog 15069)
5. The X end laser NPRO was actuated for the TF measurement using a long cable connected to TO AUX_X LASER PZT
- Reading out the error signal after amplification cannot distinguish between a locked loop or one out of its range. The error signal would be very small in both cases.
- Looking at the beat note on an oscilloscope, there also seemed to be an additional amplitude modulation that I had not noticed earlier. Rana suggested that it may have something to do with the pre-mode cleaner and the AOM being driven at 80 MHz
- Even though the TF was attempted, it seemed too noisy, suggesting that the PLL did not seem to work
- Rana also suggested that it may be a better idea to use the PZT of one of the lasers as the VCO for the PLL feedback instead of the Marconi.
Mixer used: Level 7, Mini circuits ZP-3+
LPF: up to 1.9MHz
Cables exiting the PSL table:
1. LO (Marconi -> Mixer)
2. RF (PSL+X beat note -> Mixer) The cable for this was taken from the Beat Mouth (otherwise connected to the oscilloscope)
3. Ext modulator (SR560 -> Marconi)
For a Unity Gain Frequency (UGF) of 1 kHz, assumed PZT response of 1 MHz/V, Mixer response of 25 mV/ rad, the required gain of the amplifier is
G ~ 0.8
- Measured the mixer response
- PSL laser temperature was adjusted so that beat frequency was roughly 25 MHz and the amplitude was found to be roughly -30dBm.
- At the RF port instead of the beat signal, a signal of 25 MHz + few kHz at -30 dBm was inputted. The LO was a 25 MHz signal was sent from the Marconi at 7 dBm.
- The mixer output was measured, with setup as in Attachment 1 Figure (A), on an oscilloscope. The slope near the small angle region of the sine curve would be the gain (in V/rad) and was found to be: rad
- Since from the above calculations it seemed like an amplifer gain of 1 should work for the PLL, I rearranged the set up as in Figure (B) of Attachment 1 to actuate the X end NPRO PZT, I adjusted the PSL temperature (slow control) to try and match the frequency to 25 MHz, but couldn't lock the loop. I was monitoring the error signal after amplification (50 ohm output of the SR 560) which showed oscillations when the beat frequency was near 25 MHz and nothing significant otherwise.
- I used a 20 dB attenuator at the amplifier output and saw the beat note oscillate for longer, but maybe because it was a 50 ohm component in a high impedance channel it did not work either (?). I tried other attenuator combinations with no better luck.
- Is there a better location to add the attenuator? Should I pursue amplifying the beat signal instead?
- Also, it seemed like the beat note drift was higher than earlier. Could it be because the PMC was unlocked?
There was no light entering the IFO. I worked on a few things to bring the interferometer to a somewhat usable state. The goal is to get back to PRFPMI locking ASAP.
Problem: All fast models report a "0x4000" DC error. See Attachment #1.
Solution: I think this is a "known" issue that happened last new year too. The fix was to add a hard-coded 1 second offset to the daqd config files. However, incrementing/decreasing this offset by +/- 1 second did not fix the errors for me today. I'll reach out to JH for more troubleshooting tips.
Update 15 Jan 2020 830am: The problem is now fixed. See here.
Problem: c1susaux and c1auxey were unresponsive.
Solution: Keyed c1auxey. Rebooted c1susaux and as usual, manually started the eth0/eth1 subnets. The Acromag crate did not have to be power-cycled. ITMY got stuck in this process - I released it using the usual bias jiggling. Why did c1susaux fail? When did it fail? Was there some un-elogged cable jiggling in that part of the lab?
Problem: IMC autolocker and FSS slow processes aren't running on megatron after the upgrade.
Solution: Since no one bothered to do this, I setup systemd infrastructure for doing this on megatron. To run these, you do:
and to check their status, use:
The systemd setup is currently done in a naive way (using the bash executable to run a series of commands rather than using the systemd infrastructure itself to setup variables etc) but it works. I confirmed that the autolocker can re-acquire IMC lock, and that the FSS loop only runs when the IMC is locked. I also removed the obsolete messages printed to megatron's console (by editing /etc/motd) on ssh-login, advising the usage of initctl - the updated message reflects the above instructions.
In order to do the IMC locking, I changed the DC voltage to the AOM to +1V DC (it was +0.8 V DC). In this setting, the IMC refl level is ~3.6 V DC. When using the undiffracted AOM beam, we had more like +5.6 V DC (so now we have ~65% of the nominal level) from the IMC REFL PD when the IMC was unlocked. IIRC, the diffraction efficiency of the AOM should be somewhat better, at ~85%. Needs investigation, or better yet, let's just go back to the old configuration of using the undiffracted beam.
There was also an UN-ELOGGED change of the nominal value of the PMC servo gain to 12.8, and no transfer function measurement. There needs to be a proper characterization of this loop done to decide what the new nominal value should be.
I'm going to leave the PSL shutter open and let the IMC stay locked for stability investigations. Tomorrow, I'll check the single-arm locking and the ALS system.
Single arm locking using POX and POY has been restored. After running the dither alignment servos, the TRX/TRY levels are ~0.7. This is consistent with the IMC transmission being ~11000 counts with the AOM 1st order diffracted beam (c.f. 15000 counts with the undiffracted beam).
Tomorrow, I'll check the single-arm locking and the ALS system.
Per Yehonathan's request, I removed one PDA10CF from a pickoff of REFL on the AS table (it was being used for the mode spectroscopy project). I placed a razor beam dump where the PD used to be, so that when the PRM is aligned, this pickoff is dumped. This is so that team ringdowns can use a fast PD.
With Gautam's help today the PLL managed to be be locked for a few brief moments. Turns out the signal power of the beat was an issue.
What was changed prior to/ during the experiment:
1. The PSL shutter was closed so not light goes into the input mode cleaner.
2. HEPA turned up (will be turned back down to ~30%)
3. AOM driver offset voltage decreased from 1V to ~100 mV (this will be reverted to 1V by the end of today). This increases the beat signal by deflecting the zeroth order beam to create the beat.
4. Output of servo SR 560 sent to the PZT of the X NPRO laser (the cable was disconnected from the pomona box at the X end)
5. The SR560, mixer, LPF and cables required for connections were moved into the PSL enclosure.
6. The error and control signals were hooked up to the oscilloscope where the beat outputs were visible (the setup has been reverted back to the original).
Elog 14687 has a detailed description of the conditions that provide a stable lock. I was told that the PI controller (LB1005) may be a better servo than the SR560, but today it was not used.
1) Parameters during the more successful attempts:
LPF: 5 MHz, Mixer: ZP-3+
Gain set at SR560: varied, but generally 200
Filter at SR560: 1 Hz low pass (single pole? at least by the label)
2) The LO had to be very close (<2 MHz) to the beat frequency in order to achieve a lock for ~30s
- Also, it seemed like the beat note drift was higher than earlier. Could it be because the PMC was unlocke
- No more SR 560, upgraded to LB1005 P-I controller. Because: Elog 14687. Schematic of new setup shown in Attachment 1.
- For this, the Marconi was moved to the other (east) side of the PSL table and a power supply was also placed in the enclosure.
I think that the RF power at the mixer in this new configuration is 0 dBm (since the spectrum analyzer read ~ -20 dBm)
- Turned up the HEPA to 100%, closed the PSL shutter, misaligned the ITMX, connected the LB1005 to the PZT. [The PZT has been reconnected to the X arm PDH servo, HEPA back to 20-30%]
- Tried to look for the PSL+X beat, but it was not there. Gautam identified the flipmount in the path which sorted it out (eventually), but there was no elog about it.
- After much trial, the loop seemed to lock with PI corner 1 kHz, gain ~2.9 (as read on knob), LFGL set to 90 dB. The beat note looked quite stable on the oscilloscope, but the error signal had an rms of ~100 mV (Rana pointed out that it could be the laser noise) and the lock lasted for ~1 min each time.
The parameters were similar to that in elog 14687. Why do we require such a high PI corner frequency and LFGL?
The 24 V Sorenson (2nd from bottom) in the small rack west of 1x2 was repurposed to 12V 600 mA, and was run to a terminal block on the north side of 1X1. Cables were routed underneath 1X1 and 1X2 to the terminal blocks. 12V was then routed to the PSL table and banana clip terminals were added.
Over the past few days, I have been trying to make measurements of the phase modulation transfer function by modulating the X end laser PZT via PLL.
The setup was modified every time during the experiment in the same manner as mentioned in elog 15148.
I could not make the PLL lock for long enough to take a proper TF measurement, resulting in TFs that look like Attachment 1. The next step would be to use the method of a delay line frequency discriminator instead of the PLL.
Comments about locking with LB1005 PI controller:
Today I began working on a TF measurement based on the delay line frequency discriminator setup in elog 4254 using a single mixer (without the 'I' and 'Q' readout).
For this, I re-organised the setup for the PLL measurement of the transfer function (elog 15148), increasing the HEPA for the initial changes while the PSL door was open, and then reverting it back to ~30%:
With the above setup the power that was seen at each channel of the delay line was <1dBm, which is not ideal for the any of the available mixers.
After the group meeting, I changed the amplifer to ZHL-3A (that is near the beat mouth) instead of a ZFL-500HLN because it had a higher gain (~28dB as opposed to ~19dB of the latter). The power seen at each of the delay line channels is over 5.5 dBm. This is consistent with the estimation 0 dBm beat -> -20 dBm after 20dB coupler -> 8 dBm after amplifier -> 5 dBm after splitter with insertion loss of 3 dB.
Is this sufficient enough for the mixer to work? In Attachment 1: A shows the mixer output (point B in Attachment 2) when the IMC is locked, in B the IMC is unlocked at the middle of the spectrum, and each of the dips show the DC voltage being sent to the PSL temperature servo being decreased by 0.01 V.
Gautam pointed me to the location of a few other RF amplifiers (ZHL-32A+, ZHL-1A) which don't possess a higher gain but can be used without disrupting the ALS related work (I was told).
For shorter duration changes that I made later, I opened and closed the PSL enclosure doors without changing the HEPA.
Attachment 2 shows the current setup as is, but I might add a PSL servo tomorrow to stabilise its frequency corresponding to a null mixer output without driving anything else.
yes, its fine to use this with a level 3 or level 7 mixer; let's see some PM transfer functions !
Is this sufficient enough for the mixer to work?
I could not find any level 3 mixers, but by adjusting the beat frequency the power in each of the delay line channels rose to almost 6.5 dBm.
Transfer function measurement: (Refer Attachment 1)
Everything about the setup remained as I had left it earlier: described in elog 15174
I did not use a slow servo, but took individual sweeps adjusting the PSL temperature each time to bring the error voltage between +/-25 mV. The beat frequency was over 100 MHz.
For the plot posted in Attachment 1, the measurement paramters are the following. Will do further measurements/analysis tomorrow.
# AG4395A Measurement - Timestamp: Jan 30 2020 - 21:58:00
# Parameter File: TFAG4395Atemplate.yml
#---------- Measurement Parameters ------------
# Start Frequency (Hz): 50000.0, 50000.0
# Stop Frequency (Hz): 1000000.0, 1000000.0
# Frequency Points: 801, 801
# Measurement Format: LOGM, PHAS
# Measuremed Input: AR, AR
#---------- Analyzer Settings ----------
# Number of Averages: 1
# Auto Bandwidth: Off, Off
# IF Bandwidth: 1000.0, 1000.0
# Input Attenuators (R,A,B): 0dB 0dB 0dB
# Excitation amplitude = -20.0dBm