All the details are in E2000436, and documents linked from there, I think an elog would be much too verbose. In summary, a workable setup consisting of
Last night, I locked the PRMI with the carrier resonant, and convinced myself that the DCPD null stream was sensing the MICH degree of freedom (while it was locked on AS55_Q) with good SNR below ~60 Hz. Above ~60 Hz, in this configuration, the ADC noise was dominating, but by next week, I'll have a whitening board installed that will solve this particular issue. With the optical gain of MICH in this configuration, the ADC noise level was equivalent to ~500 nrad/rtHz of phase noise above ~60 Hz (plots later).
Now, I can think about how to commission this setup interferometrically.
The variable delay line has been setup for practical use. The hardware and basic software are ready.
The delay time is given by [512-1-mod(C1:LSC-BO_1_0_SET, 512)]*(1/16) ns
Giving 511 (LLLL LLLH HHHH HHHH) to C1:LSC-BO_1_0_SET makes the delayline shortest (+0ns).
Giving 0 (LLLL LLLL LLLL LLLL) to C1:LSC-BO_1_0_SET makes the delayline longest (~32ns).
The SR785 was removed from the rack for our access >> Eric
- Three CONTEC DO-32L-PE cards are found in the Yarm digital cabinet. (I brought a card from WB, but will bring it back).
- The card was installed in the C1LSC chassis.
- The models for c1x04 and c1lsc were modified to include the card. Once they are restarted, the card was recognized without problem.
The frame builder also needed to be restarted (Attachment 1&2). The changes were committed to the repository.
- MEDM screen "CDS_BO_STATUS.adl" has been modified to include the bit monitors for the new DO card. (Attachment 3)
Epics values "C1:LSC-BO_1_0_SET" and "C1:LSC-BO_1_1_SET" are hooked up to the DO block.
- The DO board has DB37(F). I made a I/F cable with a DB37(M) crimp connector, DB25 breakout board, and a ribbon cable.
Pin 1 is connected to pin 14 of the DB25 (GND of the delayline circuit).
Pin 2~10 are connected to pin 1~9 of the DB25 (Switch 1~9 of the delayline circuit)
Pin 18 is connected to X01 (external = spare) (Attachment 4)
- [CONFESSION] A bench +15V power supply was prepared to power the transisters of the DO (Attachment 6). The hot side is connected to X01 (not connected to the DB25),
and the cold side is connected to pin 14 of the DB25. Once we find this is a useful setup we need to make a dedicated interface unit to convert DB37
into DB25 (and provide more connectivities).
- A DB25 M-F cable was installed on the cable tray above the LSC racks.
Delay line unit
- The delay line box was mounted on 34H of the LSC analog rack (Attachment 5).
- The side cross connect power supply was not available (to be described later). Therefore we decided to use the same +15V supply as the one for the DO card.
- Checked the functionarity of the local switches using a function generator @30MHz and the front panel switches. The maximum (~32ns) delay was confirmed.
(Just not enough to have 360 deg shift).
- Now the delay line function was tested with the front panel swicth at "ext". We confirmed that the delay time changes with the number given to C1:LSC-BO_1_0_SET.
What we need further
- Implement delay time slider control (511 = 0ns, 0 = 31.94ns). The delay time is given by
[512-1-mod(C1:LSC-BO_1_0_SET, 512)]*(1/16) ns
- Some independent RF issues I found. (Next entry)
See Attachment #1.
The beam spot on ETMY looks weird (looks almost like a TEM10 mode), but the one on ITMY seems fine, see Attachment #2. Wonder what's going on there, maybe just a focusing problem?
We need a vent to fix the suspension, but until then what we can do is to redistribute the POS/PIT/YAW actuations to the three coils.
Work Completed :
- Transfer Function
- Quantization Noise Estimation
EPICS and Channel Readout:
Frequency Offset Locking(FOL) Box Design and Plan:
Work Plan for Upcoming Weeks:
1) Debugging transimpedance calculations in the PDFR
Requires presence of an expert whenever I get inside the lab to take DC measurements or check the illuminating fibers.
2) Creating and incorporating canonical data plots with every measurement of PDFR.
3) Transfer function fitting for transimpedance
4) Improve the Spectrum analyzer scan scripts as mentioned in my elog.
Now that the .db files were prepared, I wanted to test for errors. So I did the following:
All the Acromags are seen on the 192.168.114 subnet on c1iscaux3 - however, when I run the modbusIOC process, I see various errors in the logfile , so more debugging is required. Nevertheless, progress.
Update 2245: Turns out the errors were indeed due to a copy/paste error - I had changed the IP addresses for the ADCs from the .115 subnet c1susaux was using, but forgot to do so for the DACs and BIOs. Now, if I turn off the existing c1iscaux so that there aren't any EPICS clashes, the EPICS server initializes correctly. There are still some errors in the log file - these pertain to (i) the mbbo notation, which I have to figure out, and (ii) the fact that this version of EPICS, 7.0.1, does not support channel descriptions longer than 28 characters (we have several that exceed this threshold). I think the latter isn't a serious problem.
Getting closer... Note that I turned off the c1iscaux VME crate to prevent any EPICS server clashes. I will turn it back on tomorrow.
Razib and I were attempting to get the output of a photodiode (PD55A in this case) recorded, so that we could independently measure the slow (~1-10 Hz) fluctuations of the light incident on the camera. This would then allow us to subtract those fluctuations out, letting us get at the camera noise in the case with signal present (as opposed to just a dark noise measurement when we look at the noise with no signal present).
Originally I was thinking of using one empty patch panel BNCs used for PEM channels down by the 1Y7 rack and go through a 110B, although Alberto pointed out he had recently removed some monitoring equipment, which watched the amplitude modulation at various frequencies of the RF distribution (i.e. 33 MHz, etc). This equipment output a DC voltage proportional to the amplitude of the RF signals. The associated channel names were C1:IOO-RFAMPD_33MHZ, C1:IOO-RFAMPD_33MHZ_CAL, C1:IOO-RFAMPD_133MHZ, etc. These are slow channels, so I presume they enter in via the slow computers, probably via pentek (I didn't check that, although in hindsight I probably should have taken the time to find exactly where they enter the system). The connections them selves were a set of BNCs on the south side, half way up the 1Y2 rack.
We simply chose one, the 33 MHz channel in this case, and connected. At around this time, the MC did become unlocked, although it looked like it was due to the MC2 watchdog tripping. The initial theory was we had bumped the Mode Cleaner while looking around for some BNC cables, although from what Rana had to do last night, it probably was the connection. We were able to restore the watchdog and confirm that the optic started to settle down again. Unfortunately, I had to leave about 5 minutes later, and didn't do as thorough an investigation as was warranted.
Before I left, I disconnected the PD55, so the 33 MHz channel wasn't physically connected to anything!!! Only one end of the wire was connected to the rack while the other was free...
So it wasn't the PD connection that is responsible for MC tripping at the later time...
A rough time-table and the various tasks are given below:
Note: 700mW NPRO sitting on AP table (Model No: 126-1064-700, Sl No. 415) = Alberto's laser
Temperature dependence of frequency of Alberto's laser:
a) Shifting Alberto's Laser (AL) to the PSL table and setting up a beat frequency measurement between AL and PSL
b) Determining the frequency vs Temperature curve for the AL
Repositioning the optics on the Y-end table and relocating Alberto's laser ( at this point it will be rechiristened as Y-End-NPRO )
Here is my work plan for this week:
1) Help Steve clean small table for experiment
2) Remove aluminum base from TT suspension
3) Mount shaker onto table base
4) Mount horizontal slider onto table base
5) Connect TT suspension, shaker, and horizontal slider
1) Begin building circuit for displacement photosensors
2) Calibrate photosensor using linear regions of power versus distance curves
3) Circuit box for photosensors?
Wiring of the power, Ethernet, and indicator lights for the vacuum Acromag chassis is complete. Even though this crate will only use +24V DC, I wired the +/-15V connector and indicator lights as well to conform to the LIGO standard. There was no wiring diagram available, so I had to reverse-engineer the wiring from the partially complete c1susaux crate. Attached is a diagram for future use. The crate is ready to begin software developing on Monday.
I've attached a schematic for how we will connect the Acromag mosules to the slow channel I/O curently going to c1auxex. The following changes are made:
I installed a NETGEAR Wireless Router (WPN824N) today on the 131 network. The admin password for it as well as the wireless access password are in the usual places.
The SSID is 40EARTH. I have set it to allow WPA as well as WPA2 access, so the speed is only 54 Mbps for now. In a year or so, we can turn off the WPA support and up the speed.
This router was confiscated by the GC guys this morning around ~10am. They barged in and said that someone at the 40m had connected a new router, and we had magically taken down half of the GC network. The cable was plugged in to the wrong port on the back of the router.
Junaid / Christian said that they would "secure" the router, and then reinstall it. Apparently just having a password didn't satisfy them. This was the compromise, versus them just taking the router and never bringing it back.
I retrieved the newly "secured" router from Junaid. It had apparently been hooked up to the GC network via it's LAN port, but it's LAN services had no been shut off. It was therefore offering a competing DHCP server, which will totally hose a network. A definite NONO.
The new SSID is "40mWiFi", it's WPA2, and the password is pasted to the bottom of the unit (the unit is back in it's original spot on the office computer rack.
After poking around for a few minutes several facts became clear:
1) At least one GPIB interface has a hard ethernet connection (and does not currently go through the wireless).
2) The wireless on the laptop works fine, since it can connect to the router.
3) The rest of the martian network cannot talk to the router.
This led to me replugging the ethernet cord back into the wireless router, which at some point in the past had been unplugged. The computers now seem to be happy and can talk to each other.
When Alberto was parting the Red Sea this morning, and turning it green, he noticed that the wireless had gone sketchy.
When I checked it out, the ethernet light was definitely blinking, indicating that it was getting signal. So this was not the usual case of bad cable/connector which is a known problem for our wireless (one of these days we should probably relay that ethernet cable....but not today). After power cycling and replugging the ethernet cable, the light for the 2.4GHz wireless was blinking, but the 5GHz wasn't. Since the wireless still wasn't working, I checked the advanced configuration settings, as described by Yoichi's wiki page: 40m Network Page
The settings had the 5GHz disabled, while Yoichi's screenshots of his settings showed it enabled. Immediately after enabling the 5GHz, I was able to use the laptop at Alberto's length measurement setup to get online. I don't know how the 5GHz got disabled, unless that happened during the power cycle (which I doubt, since no other settings were lost), but it's all better now.
[Kiwamu, Jenne, Alberto, Steve, Bob, Koji]
We finished wiping of four test masses without any trouble. ITMY looked little bit dusty, but not as much as ITMX did.
We confirmed the surface of the ITMX again as we worked at vertex a lot today. It still looked clean.
We closed the light doors. The suspensions are left free tonight in order to check their behavior.
Tomorrow morning from 9AM, we will replace the door to the heavy ones.
Eric and Steve,
We removed Wilcoxon Accelerometer PS and Amplifier unit under the BS optical tabel yesterday. The six cabels going to DAQ were labeled and left in place. Gain setting were 100, except channel 3 was 10.
The ~ 40 m long 2 sets of 3 cables were very happy to get their kinks out. Especially the set going just south of ITMX optical table.
We have to take better care of these cables! Your data will be useless this way.
I've set up the Wilcoxon accelerometers on the SP table for a huddle test, to estimate their noise levels.
They're clamped down to the table along the same axis, and their housings are in good contact, in hopes to make them as correlated as possible.
Steve helped me move the DAQ cables from under the BS/PRM oplev table, to dropping from the cable tray above the POX table, so I could get them plugged in at the SP table. This also helps reduce the rats nest by the access connector, and is a fine location for when the accelerometers are attached at MC1 & MC2.
A quick glance at DTT shows coherence of >0.9 from about 2-100Hz for all six. A three-corner-hat deal will provide an easy estimate of the noise floor of each one. If we feel like being fancy / accounting for possible gain differences, we could try some MISO wiener action, but that is probably overkill.
Here are some results for the 3-corner hat subtraction for the six accelerometers, from ~1 hour of data that didn't look to have any sharp features/glitches from human activity in the lab.
I used the python uncertainties package to try and get an estimate of the uncertainty in the subtracted noise floor, by taking into account every possible possible combination of 3 sensors and the fluctuations in the spectrograms of the subtracted signals. I've attached the python code if anyone is interested in the implementation.
I pulled out the accelerometer data sheets to read their slightly varying V/g calibration (which differs on the order of a few percent from unit to unit). This improved the subtraction factor from ~20 to over 100 at some frequencies. I've edited the filter modules such that the OUT_DQ channels are already calibrated into m/s^2.
To improve our sensor noise estimate, the ACC cables should be clamped using a rubber pad and a big dog clamp on the SP tabletop before exiting the table. Also the sensors themselves should be covered with a foam box or a double cardboard box. The high-frequency acoustic noise may limit the 10 Hz performance since piezos are not very linear.
I've set up the Wilcoxen accelerometers on the SP table for a huddle test, to estimate their noise levels.
Wilcoxon. Not Wilconox or Wilco or Wilcoxen. Have some pity on future keyword searchers.
Updated: On Thursday/Friday (sorry for late elog) I was messing with Eric's Wilcoxon 731A accelerometer huddle test data that was taken without the box and cables being adjusted properly. Anyways, I performed the three cornered hat analysis as he had done but I also performed a six cornered hat method as well instead of permuting around in pairs of three accelerometers. The following plots of the ASD's show the results,
It is interesting to note the improvement at low frequencies when six accelerometers are used instead of six while at higher frequencies we can clearly see how the results are worst than the three hat results.
I decided to take a mean of all six accelerometers measured ground signal as well as that for their computed selfnoises, this is plotted below,
Notice the obvious improvement along the entire frequency band of the measurements when all accelerometers are used in the data analysis.
I also performed some Wiener filtering of this data. There was an obvious improvement in the results,
The mean of the signals is also plotted below, just as I did with the cornered hat methods,
I also compared the mean self noise of the accelerometers against the manufacturers calculated selfnoise that Rana put up on Github. Both methods are compared against what the manufacturer claims,
As expected the measured noise curves of the Wilcoxon is not as good as what the manufactures stated. This should improve once we redo the huddle test with a better experimental setup. We have some pretty interesting results with the six cornered hat method at around 5 Hz, it is surprisingly accurate given how rough the calculations seemed to be.
I have attached my code for reference: code_accel.zipselfnoise_allsix.png
SEE attachments for better plots of the six accelerometers...
I've added a new page in the wiki which describes the current naming scheme for the .mdl model files used for the real time code generator. Note, that these model names do not necessarily have to be the names of the channels contained within. Its still possible to make all suspension related channels start with C1:SUS- for example. I'm also allocating 1024 8 byte channels for shared memory address space for each controller and each simulated plant.
The wiki page is here
Name suggestions, other front end models that are needed long term (HEPI is listed for example, even though we don't have it here, since in the long run we'd like to port the simulated plant work to the sites) are all welcome.
Over the weekend and today, the wifi was acting bad with frequent disconnections and no internet access. I tried to log into the web interface of the ASUS wifi but with no success.
I pushed the reset button for several seconds to restore factory settings. After that, I was able to log in. I did the automatic setup and defined the wifi passwords to be what they used to be.
Internet access was restored. I also unplugged and plugged back all the wifi extenders in the lab and moved the extender from the vertex inner wall to the outer wall of the lab close to the 1X3.
Now, there seems to be wifi reception both in X and Y arms (according to my android phone).
Ug, factory resets... Caltech IMSS announced that there was an intermittent network service due to maintenance between Sept 19 and 20. And there seemed some aftermath of it. Check out "Caltech IMSS"
Since we are using Wiener filtering in our project, we studied the derivation of Wiener-Hopf equations. Whatever we understood we have written it as a pdf document which is attached below...
I have put the Wiener filter scripts into /opt/rtcds/caltech/c1/scripts/Wiener/ . They are under version control.
The idea is that you should copy ParameterFile_Example.m into your own directory, and modify parameters at the top of the file, and then when you run that script, it will output fitted filters ready to go into Foton. (Obviously you must check before actually implementing them that you're happy with the efficacy and fits of the filters).
Things to be edited in the ParameterFile include:
I think that's everything that is required.
Quick update on my wiener filtering status:
Joe has been helping me get on the GRID, so I now have a grid certificate, and accounts on most/all of the clusters.
Joe also helped me get menkar to get S5 data so that I can do wiener filtering to the back-data.
I've been running the wiener filtering algorithm, and right now, it doesn't do anything to improve the DARM_CTRL data. I am confident that this is because something is funky in the wiener filtering algorithm somewhere. The indicator of this is that the wiener filtering calculation takes the same amount of time (~95 seconds) to calculate a filter for 64 seconds of data as for 1 hour of data (both for N = 2000 taps).
For reference, attached are my plots for the wiener filtering result for (1) 64 seconds of S5 data, and for (2) 3600 seconds of S5 data.
These plots were made using H1:DARM_CTRL as the signal to minimize, with 4 seismometers as the witness channels (EX_SEISX, EY_SEISY, LVEA_SEISX, LVEA_SEISY)
I'm working on figuring out what's going on with the filtering algorithm, and why it does work for C1:MC_L minimization, but does not work for H1:DARM_CTRL minimization.
Tried the wiener filter with the TF from p.5900
Tried it out with the TFs from p.5900:
Adding a filter element that compensates the acutator TF makes the MC lose lock.
Wiener Filtering was applied on the data collected from the X-arm during the time: GPS time-996380715 (Aug 02, 2011. 21:25:00. PDT) to GPS time-996382215 (Aug 02, 2011. 21:50:00. PDT) for a duration of 1500 seconds. During this time the X-arm was locked, we checked it by acquiring data from channel C1:LSC-TRX_OUT_DQ .
The seismometers were near the beam splitter (guralp2) and near MC2 (guralp1).
Target data was obtained from channel C1:LSC-XARM_IN1_DQ.
Following graphs were obtained after applying the Wiener filter:
1.Seismic data acquired from Guralp1 (X and Y) and Guralp2 (X and Y) 2.Seismic data acquired from Guralp2 X 3.Seismic data acquired from Guralp2 Y
These graphs were obtained with srate = 2048 (sample rate) and N = 20000 (order of the filter).
Graph 1 is the best because the black (residual) line is below the red (target) line for low frequencies since we used seismic data from 4 channels. Graph 3 is the worst because we used seismic data from only one Y channel (Y axis of Guralp2) that is less related with the X-arm mirrors' motion since they are oriented orthogonally.
I have measured a wideband response of the fast PZT in the LWE NPRO 700mW in the Alberto's setup.
This is a basic measurement to determine how much phase modulation we can obtain by actuating the fast PZT,
primarily for the green locking experiment.
1. Locked the PLL of for the PSL-NPRO beating at 20MHz.
2. Added the modulation signal to the NPRO PZT input.
I used the output of the network analyzer sweeping from 100kHz to 1MHz.
3. Measured the transfer function from the modulation input to the PLL error signal.
The PLL error is sensitive to the phase fluctuation of the laser. Found that the first resonance is at 200kHz.
The TF is not valid below 3kHz where the PLL suppresses the modulation.
4. Single frequency modulation: Disconnected the PLL setup.
Plug Marconi into the fast PZT input and modulate it at various frequencies.
Observing with the RF spectrum analyzer, I could see strong modulation below 1MHz.
It turned out later that the TF measurement missed the narrow peaks of the resonances due to the poor freq resolution.
Also the modulation depth varies frequency by frequency because of the resonances.
Scanned the frequency to have local maximum of the modulation depth. Adjusted the
modulation amplitude such that the carrier is suppressed (J0(m)=0 i.e. m~2.4). As I could not obtain
the carrier suppression at above 1MHz, the height of the carrier and the sidebands were measured.
The modulation frequency was swept from 100kHz to 10MHz.
5. Calibration. The TF measured has been calibrated using the modulation depth obtained at 100Hz,
where the resonance does not affect the response yet.
The responce of the PZT was ~10MHz/V below 30kHz. Looks not so strange although this valure is
little bit high from the spec (2MHz/V), and still higher than my previous experience at TAMA (5MHz/V).
Note that this calibration does not effect to the modulation depth of the single freq measurement as they are independent.
The model of our martian wifi router (NETGEAR R6400) was found in the FBI router list to be rebooted asociated with the malware "VPNFilter" issue.
I checked the attached devices and found bunch of (legit) devices blocked to access the wifi router. This is not an immediate problem as most of the packets do not go through the wifi router. But potentially a problem in some cases like Wifi enables GPIB adapters. So I marked them to be "allowed".
In this opprtunity, I have updated the firmware of the wifi router and this naturally involved rebooting of the device.
The VEA laptop asia was configured to be able to connect to too many WiFi networks - it was getting conflicted in its default position at the vertex and trying to hop between networks, for some reason trying to connect to networks that had poor signal strength. I deleted all options from the known networks except 40MARS. Now the network connection seems much more stable and reliable.
When adding the ETMX DAQ channels using the daqconfig gui (located in /opt/rtcds/caltech/c1/scripts/) on C1SCX.ini, we forgot to set the acquire flag to 1 from 0.
So the frame builder was receiving the data, but not recording it.
We have since then added ETMX and the C1SCX.ini file to Yuta's useful "activateDAQ.py" script in /opt/rtcds/caltech/c1/chans/daq/, so that it now sets the sensor and SUSPOS like channels to be acquired at 2k when run. You still need to restart the frame builder (telnet fb 8087 and then shutdown) for these changes to take effect.
The script now also properly handles files which already have had channels activated, but not acquired.
DTT has only SUS and "X02" channels under C1 in the drop down channel selection menu. Basically, we can't measure any fast channels with DTT. I keep getting the error: "Unable to select testpoints." Sadface.
Similar things are true for DataViewer. The same limited number of fast channels, and no data found:
Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek
Is this a framebuilder problem? Is this something that the CDS team has on the to-do list?
Test points for the SUS channels should be there. They have been working previously this week. Possibly break down points include awgtpman, mx_streams, and the fb itself. I'll look into that.
As far as other fast channels, there are no other fast front ends running than the suspensions ones we have. Until additional channels get connected to the front ends and the models updated, those are the channels we have available. However I am working on getting c1ioo up and running, and we can try connecting in some PEM channels today to the c1sus front end's 4th ADC.
I tried starting a fresh instance of the frame builder, but when I brought the old copy down, it left a pair of zombie or dead mx_stream processes running on c1sus . Basically c1mcs and c1rms were still running, while c1x02 and c1sus came down. I tried to kill the processes but this caused the c1sus machine to crash. In the past I've killed left over mx_stream processes running after the frame builder has gone down, but I've never seen them crash the computer. I'm unsure why this happened since we haven't done any updates of the code, just updated models and daq configuration files.
Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek
We use D990694 in various places. Today, Rana alerted me to an important consideration to be kept in mind when we use this board, which I found quite interesting. I still don't understand the problem at the BJT level, but I think one can appreciate the problem without going to the transistor design of the LT1125. I'm attaching an annotated schematic of the whitening section in question. If the following assumptions are valid, then I think my picture is valid.
Then, as one can see in the attached schematic, when we set the gain of any input to <24dB, we must ensure that the input voltage is less than approximately 2V. Otherwise, by asking too much of the first stage op-amp in the quad IC LT1125, we may be messign around with all the 4 op amps in the quad! Even the 0dB setting is not immune to this problem, as it uses one of the 4 op amps.
Now that I think about this a bit more - this problem shouldn't be significant for the usual LSC degrees of freedom when in lock, as the huge DC gain of the loop should squish large DC values of the error signals, and so there shouldn't be any danger of overloading the LT1125. But I don't know if we are being hurt by this effect when flashing through resonances, when the PDH horn-to-horn voltage can be quite high (which is in principle a good thing?). I don't know if there is any "hysterisis" effect where the overloaded quad IC has some relaxation time before it returns to normal operation, and if we are being limited in our ability to catch lock because if this effect.
The concerns remain valid for th ALS demodulated error signals though, for which the signals will remain large throughout.
this is the note from Hartmut Grote on this topic from 2004
After discussing with Koji, we looked at the aLIGO incarnation of this board. Interestingly, it too has a similar topology of 4 switchable gain stages with gains of 24, 12, 6 and 3dB. The main differences are that they use single Op27 ICs instead of the quad LT1125s, and also, they use a different combination of feedback resistors to realize the various gains.
We considered upping the feedback resistance (R15, R143) on the 24dB gain stage of our boards from (1k, 66.5ohms) to (3k, 200ohms) as on the aLIGO boards - but this doesn't really help? Because KCL demands that the same current flow in R15 and R143, and so the output Vsat of the op amp and its max current driving capabilities in combination determine if the inverting input can follow the non inverting input?
As Hartmut points out in his note, he was able to access the full range of ADC voltages when the gain was set to 3dB, despite the fact that the LT1125 was still getting internally saturated. Operating with minimum 24dB whitening gain doesn't really solve the problem either because the problem just gets shifted to the next gain stage in the chain, and we still have saturation. I also don't have a feeling for how much differential voltage these LT1125s can sustain before they are damaged - I guess the planned THD check will reveal if they are okay or not.
It seems to me like the only way to truly fix this problem of one stage saturating and screwing up the others is to use single Op27s (or equivalent) in place of the quad LT1125s. The aLIGO design also has a series resistance to the non-inverting input - this can help prevent current overdraw from the previous stage (due to a lowered input impedance of the OpAmp - but I wonder how low this can go?).
I plan to do some characterization of this problem. The plan is to use THD as a metric for whether we are having hidden saturations. Pg 9 of the LT1125 datasheet tells us what fraction of THD to expect. I will use one of the several unused DAC channels available at the LSC rack to drive a 100Hz sine wave into one of the inputs of the whitening chassis, and measure the THD up to a reasonable harmonic number (will probably be set by the ADC noise) for (i) various whitening gain settings and (ii) various input signal amplitudes.
The motivation is to attempt to quantify the problem better:
Then we can decide what, if anything, to do about this issue.
For whitening electronics noise for WFS1, I get (attachment). This doesn't seem right, right?
With the chosen transimpedance of 300 ohms, in order to be able to see the shot noise of 10 mW of light in the digitized data streams, we'd need all 3 stages of whitening. If we want to be shot noise limited with 1 mW of LO light, we'd need to increase said transimpedance I think.
The measurements were taken with
Of course, it's unlikely we're going to be shot noise limited for any configuration in the short run. But this was also a test of
All 3 tests passed.