Tonight we noticed that the REFL_DC signal has gone bipolar, even though the whitening gain is 0 dB and the whitening filter is requested to be OFF.
We should check out the switch operation of several ofthe LSC channels in the daytime - where is the procedure for this diagnostic posted?
While investigating the BIO situation with the LSC machine and the iscaux2 processor last night, we wondered if maybe the Anti-Aliasing filters were mistakenly disabled. But why do we need these anyway?
Our ADCs digitize at 64 kHz and there is a digital lowpass in the IOP at 5 kHz before we downsample to 16 kHz. So mainly we're trying to prevent some aliasing at the 64 kHz IOP rate. But our analog AA filter is a 8th order ELP at 7570 Hz, so its overkill.
So, I propose that we bypas the AA via hardwiring the board and implement a 10 kHz pole in the whitening board (D990694) before the whitening by turning R127, etc. into a 0.1 uF cap. Along with the 100 Ohm series resistor, this will make a pole at ~15 kHz. Probably ought to check that the input resistor is metal film. Also, if we replace C158/C159, etc. with a 0.47 nF cap, we'll get 2 poles at 35 kHz to limit the higher frequencies from saturating.
I added the 0.1 uF and 47 nF caps that I mentioned so that we can now bypass the AA filters for these channels. (mistakenly installed 47 instead of 0.47 nF on the first round and we got 350 Hz poles instead of 35 kHz)
Gautam and I checked out the AA sit and it seems that the XYCOM-220 cable which ought to allow switching of the AA filter is not connected on the XYCOM side, so the LSC AA filters are always ON. In order to bypass them, we'll need to just short the bypass control pins or just set the +5V on the board to GND, by lifting the EMI3 filter and shorting C6.
I have so far only made the changes on s/n 115 (used for AS55, REFL55, and REFL165), other 2 boards to follow soon.
Before making the AA change, we want to measure the HF spectrum the ADC for each of our main signals in the PRFPMI state. In lieu of that, we'll measure the spectrum at the I/Q mon ports of the demod boards via SR785 and then use matlab to propagate the signals to the ADC to make our estimate of how much anti-aliasing we need.
Changes relative to D990694-B:
I also looked at the noise in a few different configurations to see what we ought to do next.
BLACK: AS55I_IN1 with 0 dB whitening gain and whitening filter OFF, so its all just ADC noise
RED: same but with +45 dB whitening gain and WF ON, so above 10 Hz this is now the noise of the PD / demod chain
BLUE: RED w/ the anti-WF applied
PURPLE: in-loop POX11_I spectrum with x-arm locked
The conversion from counts to volts 0.0006, so the black trace is ~5 uV/rHz as expected. Its clear that we would be sort of OK for most of our channels if we just had 1 stage of whitening. I think we ought to convert the input stage into a 100:20 stage and also change the other whitenings into a 100:20 instead of 150:15. Then we'll have less gain at 15 Hz, but more at 100 Hz.
Steve and I turned on the box this morning so that the IMC would lock again.
For future reference, remember that one should turn off the Marconi output before turning off the RF distribution box. Don't drive the input of unpowered RF amps.
Trying to download some data using matlab today, I found that my ole mDV stuff doesn't work because its MEX files were built for AMD64...
Tried to rebuild the NDS1 MEX according to 7 year old instructions didn't work; our GCC is 'too' new.
From the Remote Data Access wiki (https://wiki.ligo.org/RemoteAccess/MatlabTools) I got the new 'get_data.m' and 'GWdata.m'. These didn't run, so I updated the nds2-client and matlab-nds2-client on Donatella.
Still doesn't run to get 40m data. It recognizes that we're C1, but throws some java exception error. Maybe it doesn't work on the NDS1 protocol of our framebuilder?
So then I noticed that our NDS2 server on megatron is no longer running...thought it was supposed to run via init.d. Found that the nds2 binary doesn't run because it can't find libframecpp.so.5; maybe this was blown away in some recent upgrade? We do have versions 3, 4, 6, 7, & 8 of this library installed.
So now, after an hour or two, I'm upgrading the nds2 server on megatron (plus a hundred dependencies) as well as getting a newer version of matlab to see if there's some kind of java version issue there.
Of course python still works to get data, but doesn't have any of the wiener filter calculating code that matlab has...
One the Wiki (https://wiki-40m.ligo.caltech.edu/40mHomePage), we have a Mech Resonance page for mechanical frequencies and a PEM page where we want to list the sources of all of our environmental lines. So please put in an entry when you find out what's at this frequency. This reminds me that I need to upload my MC2 COMSOL eigenmode analysis.
NDS2 restarted after hours long upgrade process; testing has begun. Let's try to get some long stretches of MC locked with MCL FF ON this weekend so's I can test out the angular FF idea.
I modified the perl script which does our hourly autoburt so that it can run on megatron instead of op340m (old Solaris machine). Nothing major, just some path stuff. That was the last function of op340m that I know of, so after a week of watching this we ought to be able to power it off and send it to e-waste.
Seems to work so far. It complains about some models that aren't running but mostly it reports successful snapshot taking based on the .req files.
Unfortunately, it seems that its only doing the new target directory, so its missing all of our old VME machines which still use the /cvs/cds/caltech/target area.
But I think Gautam and Jamie and Aidan have volunteered to start our slow controls upgrade by moving the EX slow controls to Acromag and into the new target area. We ought to modify the CRON to point at the old directory for now, but its a temporary fix hopefully.
I was going to suggest using a software PLL, but perhaps averaging gives the same result. The same ADC signal can be fed to multiple blocks with different averaging times and we can just use whichever ones seems the most useful.
I don't see any evidence of it getting more stable. It seems there was a big step in January, but the problem we were talking about - the suspension shifting when it gets a big kick - can't be proven to be gone or not by just looking at the trends. The real issue is whether or not it slips when we put in a large step in the LSC.
We have talked about the drift of ETMX sus on the Wednesday meeting.
It has stopped moving on Jan 8, 2015 and it has been reasanable stable since than.
Use LISO - see what it tells you. I would think that you should make a differential RC filter to get the right behavior. (e.g. 1K on each leg and 1 uF between them)
Each leg of the diff input of the board has a 4k input impedance.
But surely the AO input to the MC servo should also make sense independently.
Give us a lockloss or other kind of time series plot so we can bask in the glory.
None of the links here seem to work. I forgot what the story is with our special apache redirect
in addition to Koji's words I feel like we should also thank those who made small but positive contributions. Its hard not to notice that this locking only happened after the new StripTool PEM colors were implemented...
From the times series plot I guess that the fuzz of the in-loop DARM is 1 pm RMS (based on memory). This means that the ALS was holding the DARM at 10 pm from the RF resonances.
There is no significant shift in the DRMI error signals, so new weird CARM effect. Would be interesting to see what the 1f signals do in the last 60 seconds before RF lock.
For documentation, perhaps Gautam can post the loop gain measurements of the 5 loops on top of the Bode plots of the loop models.
The OSEMs cannot be used for coil balancing above ~10 Hz. The main coupling path from OSEM drive to sensor is not through the mirror motion, but instead direct electrical coupling of the drive wires to the sensing wires.
I put this in the elog every ~1-2 years since people keep trying it, but it keeps coming back like a zombie.
Better to use the MC angular sensors for L2A decoupling. Not perfect, but better than OSEMs. For the TMs we can use the OLs.
How many volts does it take to pitch the ETM by 5 urad?
Although this noise is bad, we have always had these kind of humps around the bounce mode. Our interpretation in the past was that this was due to poor alignment of the OSEM in the frame, leading to a large vertical to horizontal coupling. Once you implement the BLRMS for the SUS channels, we'll be able to trend the noise over long periods of time.
controls@nodus|~ > df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/nodus2--vg-root 355G 69G 269G 21% /
udev 5.9G 4.0K 5.9G 1% /dev
tmpfs 1.2G 308K 1.2G 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 5.9G 0 5.9G 0% /run/shm
/dev/sda1 236M 210M 14M 94% /boot
chiara:/home/cds 2.0T 1.5T 459G 77% /cvs/cds
fb:/frames 13T 11T 1.6T 88% /frames
OMG. Please try to use larger fonts and PDF so that we can read the plots.
Based on elog 1403, I calibrated the oplevs for ITMY/ETMY.
I'm not sure that these calibration measurements are reliable. I would feel better if Steve can confirm them using our low accuracy method of moving the QPD by 1 mm and doing trigonometry.
On the demod board there is a 10 dB attenuator (AT1), which lowers the level to -10 dBm before the ERA-5. Then it should be 10 dBm before going to the rest of the parts. But I guess the ERA-5 chips which come later on in the circuit could be decaying like the ones in the PMC LO board.
Later at home, I thought this nominal LO level of 0dBm could have been wrong.
Hmmm. Very non-standard demod. From the photo, looks like someone did some surgery with the attenuators (AT1, AT2, AT3) in the LO path. (might be me from a long time ago).
-8 dBm input to a circuit is a not a low noise situation. It would be best to remove the amplifiers in the I&Q paths and just have a single amplifier in the main path. Ideally we want the LO to never go below -3 dBm and certainly not below 0 dBm while outside of the board.
I doubt that all of the LSC demods were modified in this way - this one ought to get some sharpie or stickers to show its difference.
Perhaps we can replace T1 with a mini-circuits hybrid 0-90 deg splitter and then remove the trim caps. (JSPQ-80, JYPQ-30, SCPQ-50)
I need some more hints to understand the improvement, although its generally good to re-build it considering the sad state of the assembly/installation that you found.
I see that the current design brings the 11 MHz signal to -2 dBm before intering the first ZHL-2+, but since that has a NF of 9 dB, that seems to only degrade the phase noise to -2 - (-174 +9) = -163 dBc. That seems OK since we only need -160 dBc from this system. Probably the AM noise is worse than this already (we should remember to hook up a simple AM stabilizer in 2016, as well as the ISS).
What else are the main features of this improvement? I can reward a good summary with some Wagonga.
Let Loren help you make your Oplev data readable to humans.
NDS2 and the usual ports so that we can use optimus as a comsol server.
I don't think there are any other ports we need open, but I could be wrong. Let me know if I broke something you need!
Here's how we should diagnose the EX laser:
This LHO log indicates that EPICS slow down could be due to NFS activity. Could we make some trend of NFS activity on Chiara and then see if it correlates with EPICS flatlines?
I wonder if our EPICS issues frequency is correlated to the Chiara install.
The EOM upstream of the PMC is used as the phase corrector for the FSS/IMC servo. It is also used to apply the 35.5 MHz PDH RF sidebands for the PMC locking. There is a Pomona box which is used to merge the two signals onto a single cable for the EOM.
Does this circuit make sense to anyone?
Fire alarm went off several minutes ago. Talked to security and they said there was no fire. It beeped twice again just now. No one has been working on the IFO today.
The problem here is that the MC displacement noise is leading to large frequency excursions of the PSL beam. Options
In the modern times, people use glue traps to catch rats instead of springs. They are less hazardous to people and don't spread rat fluid on the floor.
Unless this is the limit from the way you guys set up the PLL, it seems like there's no difference between the two lasers that's of any import. So then the locking problem has been something else all along - perhaps its noise in the X-PDF lock somehow? PDH box oscillations?
Just not just pedagogical ! Freq domain MISO coherence based subtraction estimation is much faster than calculating MISO WF. And since each bin is independent of each other, this gives us an estimate of how low the noise can go, whereas the Wiener filter is limited by Kramers-Kronig. We should be able to use this on the L1 DARM channel to do the noise hunting as well as estimating the subtraction efficacy of the pseudo channels that you and Rory come up with.
If you can code up a noise hunter example using DARM + a bunch of aux channels, we could implement it in the summary pages code.
Is the black ref spectrum from this year or from May of 2015 or ?
I wonder if the noise is a bunch of fast spikes or if its a true broadband rumble. Maybe we can tell by looking at the analog DFD or PLL outputs?
The PDA photodetectors are DC coupled, so you cannot use them to go directly into the analyzer. Must use the DC block so that you can reduce the input attenuation on the B channel and then lower the drive amplitude.
Good policy for TF measurements: drive as softly as you can and still measure in a reasonable amount of time, but no softer than that.
I didn't really appreciate this measurement until just now. IF you can save the DTT .xml file with all the traces in it (i.e. NOT just the plots), we should save this data for comparison plotting later. Perhaps Gautam can post the gzipped xml file for you into the log.
The accelerometers don't read any real noise below ~3 Hz, so we can't judge the difference down low, but this seems like a good measurement in the 5 - 100 Hz band.
I don't think there's any evidence that the noise eater is bad. That would change the behavior of the relaxation oscillation which is at 1 MHz ?
Sorry, that was me; taking some photos of the PSL and EX mirrors.
PSL Table doors were open, and the laser shutter was closed.
Doors have been closed, laser has been opened.
Why is the transmission of X green so low? Perhaps you can phase lock the IR and then scan the X frequency, using the X arm as the analyzer. i.e. put a slow ramp into MC2 to pull the PSL frquency and thus the green frequency. You can record a movie of the scan using the framegrabber and record the green transmission peaks to see how big the mode match is exactly (which modes are so big)
Its not a good idea to use green mounts with green lasers. Steve should be able to get another copy of the EY doubler mount made up if we really don't have another one sitting in the Manasa end table box which Koji mentioned.
Found it locked on TEM01 mode.
Sweets in the fridge for non-PhD holders, courtesy of the highest levels of Caltech.
Something seems not right. The Guralp response should be flat in velocity from 0.05-30 Hz. Why is there any feature at 1 Hz? Saturation of some kind?
Bah, we need ruby slippers for all future suspensions. Prism with curved backside and smooth grooves.
No aluminum, no cry.
Earth quake stops need viton tips.
Wirestandoffs are still aluminum.
OK - but give us a circuit diagram and the expected before/after loop plots. Got to make sure we keep the right impedance from PD to mixer. Some of the Thorlabs PDs have a 50 Ohm instead of 0 Ohm source impedance. Maybe you can try it out now since the green arm is ready.
Steve sent 4 of our 1" diameter G&H HR mirrors to Josh Smith at Fullerton for scatter testing. Attached photo is our total stock before sending.
Antonio/Gautam are now developing a more up to date Finesse model of our recycling cavities to see what we can have there before our power recycling gain or cavity geometric stability is compromised. Expect that we will here a progress report on the model on Wednesday.
All seems very fishy. Its not good to put attenuators and filters in nilly-willy.
Seems weird to design a PD lowpass with a corner at the modulation frequency. Recall what our strategy is with the other photodetectors we use for PDH servos: bandpass, not low-pass, and the band has to be wide enough to not effect the phase of the servo.