Came across this while looking up the BIO situation at 1Y2. For reference, the fix Koji mentions can be seen in the attached screenshot (one example, the other BIO cards also have a similar fix). The 16th bit of the BIO is grounded, and some bit-shifting magic is used to implement the desired output.
Yutaro talked about the BIO bug in KAGRA elog. http://klog.icrr.u-tokyo.ac.jp/osl/?r=9536
I think I made the similar change for the 40m model somewhere (don't remember), but be aware of the presense of this bug.
New DIMM cards have arrived. I stored them in the digital cabinet along y arm.
Here is the procedure for setting up the three new BHD front-ends (c1bhd, c1sus2, c1ioo - replacement). This plan is based on technical advice from Rolf Bork and Keith Thorne.
The overall topology for each machine is shown here. As all our existing front-ends use (obsolete) Dolphin PCIe Gen1 cards for IPC, we have elected to re-use Dolphin Gen1 cards removed from the sites. Different PCIe generations of Dolphin cards cannot be mixed, so the only alternative would be to upgrade every 40m machine. However the drivers for these Gen1 Dolphin cards were last updated in 2016. Consequently, they do not support the latest Linux kernel (4.x) which forces us to install a near-obsolete OS for compatibility (Debian 8).
I used an Acromag XT1221 in CTN to play around with different wiring and see what works. Following are my findings:
Floating Single Ended Source (Attachment 2):
Differential Source (Attachment 3):
Comments and suggestions are welcome.
Related elog posts:
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.
Thanks for the systematic effort.
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.
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.
Here I present few wiring diagrams when using Acromag to avoid noisy behavior and 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.
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 an acromag card without making any connection with RTN is basically not allowed as per this document.
- Saved BURT backup in /users/anchal/BURTsnaps/
- Copied existing code for mode cleaner noise budget from /users/rana/mat/mc. Will work on this from home to convert it inot new pynb way.
Get baseline IMC measurements (passive):
- What is MC_F? Let's find out.
- On MC_F Cal window titled 'C1IOO-MC_FREQ', we turned off ON/OFF and back on again.
- Using diaggui, we measured ASD of MC_F channel in units of counts/rtHz.
- Using diaggui, measured ASD from a template (under /users/Templates) and overlay the 1/f noise of the NPRO (Attachment 1)
- WFS Master
- Went through the schematic and tried to understand what is happening.
- Accidentally switched on MC WF relief (python 3). Bunch of things were displayed on a terminal for a while and then we Ctrl-C it.
- The only thing we noticed that change is a slight increase in WFS1 Yaw, and a corresponding decrease in WFS1 Pitch, WFS2 Pitch, and WFS2 Yaw.
- We need to find out what this script does.
Today we had some trouble launching an excitation on C1:IOO-MC_LSC_EXC from awggui. The error read:
awgSetChannel: failed getIndexAWG C1:SUS-MC2_LSC_EXC ret=-3
What solved this was the following :
awg free 37008
IFOcad model/video of the AEI 10m interferometer:
One goal of our sysID study is to improve the aLIGO L2A feedforward. Our algorithm currently improves only the statistical uncertainty and assumes the systematic errors are negligible. However, I am currently baffled by how to fit a (nearly) realistic suspension model...
My test study uses the damped aLIGO QUAD suspension model. From the Matlab model I extract the L2 drive in [N] to L3 pitch in [rad] transfer function (given by a SS model with the A matrix having a shape of 103x103). I then tried to use VectFIT to fit the noiseless TF. After removing nearby z-p pairs (defined by less than 0.2 times the lowest pole frequency) and high-frequency zeros, I got a model with 6 complex pole pairs and 4 complex zero pairs (21 free parameters in total). I also tried to fit the TF (again, noiseless) with an MCMC algorithm assuming the underlying model has the same number of parameters as the VectFIT results.
Please see the first attached plots for a comparison between the fitted models and the true one. In the second plot, we show the fractional residual
| TF_true - TF_fit | / | TF_true |,
and the inverse of this number gives the saturating SNR at each frequency. I.e., when the statistical SNR is more than the saturating value, we are then limited by systematic errors in the fitting. And so far, disappointingly I can only get an SNR of 10ish for the main resonances...
I wonder if people know better ways to reduce this fitting systematic... Help is greatly appreciated!
We have been discussing how does the parameter estimation depends on the length per FFT segment. In other words, after we collected a series of data, would it be better for us to divide it into many segments so that we have many averages, or should we use long FFT segments so that we have more frequency bins?
My conclusions are that:
1). We need to make sure that the segment length is long enough with T_seg > min[ Q_i / f_i ], where f_i is the resonant frequency of the i'th resonant peak and the Q_i its quality factor.
2). Once 1) is satisfied, the result depends weakly on the FFT length. There might be a weak hint preferring a longer segment length (i.e., want more freq bins than more averages) though.
To reach the conclusion, I performed the following numerical experiment.
I considered a simple pendulum with resonant frequency f_1 = 0.993 Hz and Q_1 = 6.23. The value of f_1 is chosen such that it is not too special to fall into a single freq bin. Additionally, I set an overall gain of k=20. I generated T_tot = 512 s of data in the time domain and then did the standard frequency domain TF estimation. I.e., I computed the CSD between excitation and response (with noise) over the PSD of the excitation. The spectra of excitation and noise in the readout channel are shown in the first plot.
In the second plot, I showed the 1-sigma errors from the Fisher matrix calculation of the three parameters in this problem, as well as the determinant of the error matrix \Sigma = inv(Fisher matrix). All quantities are plotted as functions of the duration per FFT segment T_seg. The red dotted line is [Q_1/f_1], i.e., the time required to resolve the resonant peak. As one would expect, if T_seg <~ (Q_1/f_1), we cannot resolve the dynamics of the system and therefore we get nonsense PE results. However, once T_seg > (Q_1/f_1), the PE results seem to be just fluctuating (as f_1 does not fall exactly into a single bin). Maybe there is a small hint that longer T_seg is better. Potentially, this might be due to that we lose less information due to windowing? To be investigated further...
I also showed the Fisher estimation vs. MCMC results in the last two plots. Here each dot is an MCMC posterior. The red crosses are the true values, and the purple contours are the results of the Fisher calculations (3-sigma contours). The MCMC results showed similar trends as the Fisher predictions and the results for T_seg = (32, 64, 128) s all have similar amounts of scattering << the scattering of the T_seg=8 s results. Though somehow it showed a biased result. In the third plot, I manually corrected the mean so that we could just compare the scattering. The fourth plot showed the original posterior distribution.
Koji and I have prepared the vacuum system for the power outage on Saturday.
From here, we shutdown electronics.
/sbin/shutdown -h now
Koji and I began starting that Vacuum system up.
- Once the FRG gauge readings are back (see next elog by Tega), I could open V1 to pump down the main vacuum manifold.
- TP2/TP3 were brought back to stand-by mode (slower spinning)
- V7 was closed to separate the annuli side and TP1
During the vacuum recovery, I saw TPs were automatically turned on as soon as the backing pumps were engaged. I could not figure out what caused this automation.
Also, I saw some gate valve states changed while I was not touching them. e.g. V7 was close / VM3 was open / etc
I really had no idea what/who was handling these.
As of ~18:00 local, the main volume pressure is ~2e-5 torr and ready to open the PSL shutter.
[Paco, Chris Stoughton, Leo -- remote]
This morning Chris came over to the 40m lab to help us get the RFSoC board going. After checking out our setup, we decided to do a very basic series of checks to see if we can at least get the ADCs to run coherently (independent of the DACs). For this I borrowed the Marconi 2023B from inside the lab and set its output to 1.137 GHz, 0 dBm. Then, I plugged it into the ADC1 and just ran the usual spectrum analyzer notebook on the rfsoc jupyter lab server. Attachment #1 - 2 shows the screen captured PSDs for ADCs 0 and 1 respectively with the 1137 MHz peaks alright.
The fast ADCs are indeed reading our input signals.
Before this simple test, we actually reached out to Leo over at Fermilab for some remote assistance on building up our minimally working firmware. For this, Chris started a new vivado project on his laptop, and realized the rfsoc 2x2 board files are not included in it by default. In order to add them, we had to go into Tools, Settings and add the 2020.1 Vivado Xilinx shop board repository path to the rfsoc2x2 v1.1 files. After a little bit of struggling, uninstalling, reinstalling them, and restarting Vivado, we managed to get into the actual overlay design. In there, with Leo's assistance, we dropped the Zynq MPSoC core (this includes the main interface drivers for the rfsoc 2x2 board). We then dropped an rf converter IP block, which we customized to use the right PLL settings. The settings, from the System Clocking tab were changed to have a 409.6 MHz Reference Clock (default was 122.88 MHz). This was not straightforward, as the default sampling rate of 2.00 GSPS was not integer-related so we had to also update that to 4.096 GSPS. Then, we saw that the max available Clock Out option was 256 MHz (we need to be >= 409.6 MHz), so Leo suggested we dropped a Clocking Wizard block to provide a 512 MHz clock input for the rfdc. The final settings are captured in Attachment # 3. The Clocking Wizard was added, and configured on its Output Clocks tab to provide a Requested Output Freq of 512 MHz. The finall settings of the Clocking wizard are captured in Attachment #4. Finally, we connected the blocks as shown in Attachment #5.
We will continue with this design tomorrow.
I sketched up a quick drawing with estimated length for the IMC reflected beam. This includes the distances and focal length. Distances are from optic to optic.
Here is the Yuta's Alignment Scheme from elog 17056 with these slight adjustments:
Current alignment scheme:
Current alignment scheme I figured out is the following.
- Check Y green. If it is transmitted at good spot on GTRY camera, Yarm is OK. If not, tweak ITMY/ETMY. alignment.
- Mis-align AS4, align TT1, TT2, LO1 to have BHDC_A_OUT of ~115 and BHDC_B_OUT of ~95.
- Align PR3, PR2 to maximize TRY_OUT to ~1.0
- Tweak ITMY/ETMY if the beam spot on them are not good.
- Align BS, ITMX to have good MICH fringe and TRX_OUT to ~1.0.
- Tweak ITMX/ETMX if the beam spot on them are not good.
- Misalign ETMY, ETMX, ITMY to have LO-ITMX fringe in BHD DCPDs. From Sitemap --> BHD --> Homodyne Phase Ctrl --> LO_PHASE --> Turn ON LO Phase Servo (This will lock LO and ITMX fringe) --> align AS beam with SR2 and AS4 differentially, with ratio of AS4/SR2=3.6 for YAW, with ratio of AS4/SR2= 4.5 for PITCH to have BHDC_A_OUT ~ 50.
- Restore ITMY alignment, and lock MICH.
I found this interesting entry by Rana in the old (deprecated) elog : here
I wonder if Rolf has ever written the mentioned GUI that explained the rationale behind the test point number mapping.
I'm just trying to add the StochMon calibrated channels to the frames. Now I remember why I kept forgetting of doing it...
At ITMX, on the CES side, 5 Ft from the wall the jackhammer is on. The susses are holding well.
We are celebrating Rob's promotion to thesis poetry. These pictures were taken on December 9, 2009
Rob has finished all his measurements in the lab and is officially well prepared to graduate.
There is a planned power outage tomorrow, Saturday from 7am till midnight.
I vented all annulies and switched to ALL OFF configuration. The small region of the RGA is still under vacuum.
The vac-rack: gauges, c1vac1 and UPS turned off.
It turns out that we perfecly timed the big one
In the process of finding the signal of the big chilean earthquake I just realized that we were all off
There's several more of the this vintage in one of the last cabinets down the new Y-arm.
Hold on, did the arms get re-baptized?
John Miller has arrived from Australia with 3 bags of Wagonga Coffee. Trade bargaining has started on
250 mgs of Sumatran Mandehling, Timur and Papua New Guine.
I'm cleaning out to make room for our new optical cabinet. Are we keeping these? There are ~20 pieces of 10" od 1" wide tapes and large number of cassettes.
AJW, Zucker, Stuart A and Koji were notified in this matter.
Alan suggested to save data of Bruce Allen paper of observation of binary neutron stars in the 40m on 1994 November 14-20 and save back up tapes of his period in the 40m.
Mike: reels are not readable any more, it is time to let go
After Kiwamu set the REFL11 phases in the PRMI configuration (maximized PRM->REFL11I reesponse) I tried to measure the MC length and the 11 MHz frequency missmatch by modulating the 11 MHz frequency and measuring the PM to AM conversion after the MC using the REFL11Q signal. The modulation appears in the REFL11Q with a good snr but the amplitude does not seem to go through a clear minimum as the 11 MHz goes through the MC resonance.
We could not relock the PRMI during the day so I resorted to a weaker method - measuring the amplitude of the 11 MHz sideband in the MC reflection (RF PD mon output on the demod board) with a RF spectrum analyzer. The minimum frequency on the IFR is 11.065650 MHz while the nominal setting was 11.065000 MHz. The sensitivity of this method is about 50 Hz.
Elog crashed a couple times, restarted it a couple times.
Just a reminder that a film crew will be here Monday morning, filming Christian Ott for some Discovery channel show.
They are slated to be here from 8am to 12:30pm or so. They will take a couple of shots inside the lab, and the rest of the filming should be of Christian in the control room (which they will "clean up" and fit with "sexy lighting"). I will try to be here the whole time to oversee everything.
Also, according to Steve, there will be some crane guys for fixing the Y end crane issue (#5124) Monday morning.
a film crew will be here Monday morning. They are slated to be here from 8am to 12:30pm or so.
Konecrane Fred was early this morning. He diagnosed the ETMY crane horizontal drive gear box dead and left just before the film crew showed up.
New gear box should be here by the end of this week for installation.
The lab air quality is high ~20,000 counts of particles of 0.5 micron. Keep an eye on this before you open the chamber.
Elog did not respond despite running the /cvs/cds/caltech/elog/start-elog.csh script two times.
It worked the after the third restart.
It seems like there is some confusion---or disagreement---amongst the lab about how to proceed with the RAM work (as Rana mentioned at the TAC meeting, we will henceforth refer to it only as "RAM" and never as "RFAM"; those who refuse to follow this protocol will be taken out back and shot).
I would like to provide a rough outline and then request that people reply with comments, so that we can get a collective picture of how this should work. I have divided this into two sections: 1) Methodology, which is concerned with the overall goal of the testing and the procedure for meeting them, and 2) General Issues, which are broadly important regardless of the chosen methodology.
There are two broad goals:
The question is: which is our goal? The first, the second, or both? If both, what priority is given to which and can/should they be done in parallel? Also, task distribution.
2. General Issues
These are loosely related, so they are in random order:
There are probably many other issues I have neglected, so please comment on this rough draft as you see fit!
Since no one has made any comments, I will assume that everyone is either 100% satisfied with the outline or they have no interest in the project. Under this assumption, I will make decisions on my own and begin planning the individual steps in more detail.
In particular, I will assume that our goal comprises BOTH characterization of RAM levels and mitigation, and I will try to find the best way that both can be achieved as simultaneously as possible.
I know it's really hard to remember, but our future selves will thank us dearly if we remember to commit all of our code changes to the svn with nice log messages. At the moment there's a LOT of modified stuff in the userapps working directory that needs to be committed:
controls@pianosa:/opt/rtcds/userapps/release 0$ svn status | grep '^M'
This doesn't even include things that haven't even been added yet. It doesn't take much time. Just copy and paste what you elog about the changes.
Let's see if the ripples observed in the MC ringdown can be due to tilt motion of the mirrors.
The time it takes to produce a phase shift corresponding to N multiples of 2*pi is given by:
t = sqrt(2*N*lambda/(L*omega_T^2*(alpha_1+alpha_2)))
L is the length of the MC (something like 13m), and alpha_1, alpha_2 are the DC tilt angles of the two mirrors "shooting into the long arms of the MC" produced by the MC control with respect to the mechanical equilibrium position. omega_T is the tilt eigenfrequency of the three mirrors (assumed to be identical). lambda = 1.064e-6m;
The time it takes from N=1 to N=2 (the first observable ripple) is given by: tau1 = 0.6/omega_T*sqrt(lambda/L/(alpha_1+alpha_2))
The time it takes from N=2 to N=3 is given by: tau2 = 0.77*tau1
First, we also see in the measurement that later ripples are shorter than early ripples consistent with some accelerated effect. The predicted ripple durations tau seem to be a bit too high though. The measurements show something like a first 14us and a late 8us ripple. It depends somewhat on the initial tilt angles that I don't know really.
In any case, the short ripple times could also be explained if the tilt motions start a little earlier than the ringdown, or the tilt motion starts with some small initial velocity. The next step will be to program a little ringdown simulation that includes mirror tilts and see what kind of tilt motion would produce the ripples exactly as we observe them (or maybe tilt motion cannot produce ripples as observed).