Good to see that misofw.m is still alive and well. Todo:
Good catch; that was some seriously bad programming on my part. I had some undeclared variable garbage going on. I fixed it and re-implemented the script in CRON on megatron. The log file shows that it has detected no problems for the last several checks. I'll check it again tomorrow to see if its doing good or bad.
I was wondering about the design of the BLRMS fitlers for the seismic channels since the STS ones seem to have so little gain compared to the Guralps.
Here are some plots of the Bode magnitude and impulse responses of the bandpass filters (before the low passing). There's a bunch of entries from Masha on this from her SURF summer. Can anyone comment on why they are all so different?
One of the old Masha entries speaks of designing the lowpass filter in an intelligent way: by adjusting the filter order until the power in the stopband is less than 1% of the power in the passband. Seems like we could do that for bandpass too. For now I have made the names reasonable and changed all of the BP filters to 4th order Butterworth.
Also, it turns out that the Vel2Vel (gain ~0.02) filters were mistakenly on in the STS BP filter banks. The GUR inputs have a gain to scale the counts to velocity, but the STS seem to already be in microns/sec (where is this gain?) so I turned off and deleted the Vel2Vel filters; in any case the gain should not be done seperately in each BP bank, but altogether before the BP filtering.
I think that the real clue was that the dropouts are in some channels and not in others:
As it turns out, the channel with no dropouts is the RAW PSL RMTEMP channel. All the others are the minute trends. So something is up with the trend making or the trend reading in the cluster.
There's a few hours so far after today's c1cal shut off that the summary page shows no dropouts. I'm not yet sure that this is related, but it seems like a clue.
I will move it back. We need to fix our scripts to not use any users/ libraries ever again.
PRM watchdog tripped, but the damprestore.py script wouldn't run.
It turns out the script tries to import some ezca stuff from /users/yuta (), which had been moved to /users/OLD/yuta ().
I've moved the yuta directory back to /users/ until I fix the damprestore script.
Looks like a very handy code, especially with the real statistical tests.
I would make sure to use much smaller excitation amplitudes. Since the coupling is nonlinear, we expect that its only a good noise budget estimator when the excitation amplitude is less than a factor of 3 above the quiesscent excitation.
You are plotting the STS channels, not Guralp. These are for the Trillium 240 seismometer.
Also, you cannot tell if the seismometer is working by plotting the MEAN trend. That just gives the average and we need the fluctuations. Better off looking at the spectrum like I did last time.
And....its not good enough to just do the bubble. You have to do the mass centering procedure that you and I did last time with the breakout paddle.
Additionally, we want to have some set of tests and diagnostics, to make sure we have not introduced unwanted behavior.
To this end I will create some test models and DTT templates, where a series of measurements can be run, like
I'll run these test before touching anything, and make sure I understand all of the results, so that an apples-to-apples comparison can be made after the upgrade is complete.
I got goosebumps just imagining this.
after re-aligning the beam into the PMC, I touched up the steering mirros into the IOO QPDs so that the beams are now centered again. Please don't adjust these references without prior authorization and training.
This plot shows the 10-minute trends for these QPDs over the last 400 days.
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.
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.
Wilcoxon. Not Wilconox or Wilco or Wilcoxen. Have some pity on future keyword searchers.
In any case, this signal difference is not big, so we should not need a different amplifier chain for the two signals. The 20 dB of amplification in the BeatBox was a fine way, but not great in circuit layout.
The BBPD has an input referred current noise of 10 pA/rHz and a transimpedance of 2 kOhm, so an output voltage noise of 20 nV/rHz (into 50 Ohms). This would be matched by an Amp with NF = 26 dB, which is way worse than anything we could bur from mini-circuits, so we should definitely NOT use anything like the low-noise, low output power amps used currently (e.g. ZFL-1000LN....never, ever use these for anything). We should use a single ZHL-3A-S (G = 25 dB, NF < 6 dB, Max Out = 30 dBm) for each channel (and nothing else) before driving the cables over to the LSC rack into the aLIGO demod board. I just ordered two of these now.
The RMS in both channels mostly comes from a whole mess of 60Hz harmonics. I'll see what I can do by taking better care of the delay line cables, but it is kind of weird that this would be worse now, given that there was little care given to them before either.
Well, green looks better than blue, but it makes the PCDRIVE go high, which means its starting to saturate the EOM drive. So we can't just maximize the phase margin in the PZT/EOM crossover. We have to take into account the EOM drive spectrum and its RMS.
Also, your gain bump seems suspicious. See my TF measurements of the crossover in December. Maybe you were saturating the EOM in your TF ?
Lets find out what's happening with FSS servos over in Bridge and then modify ours to be less unstable.
I made a measurement of the MC2 actuator transfer function by injecting noise from 1-100Hz into LSC_MC2_EXC for about 15 minutes, then estimating the TF from MC2_OUT to IOO_MC_L with CSD/PSD. The inverse of this TF will be applied to their Wiener target data to give us the direct subtration filter we want.
I think what happened here is you forgot to undo the MC_F whitening filter which is the Generic Pentek Interface board next to the MC servo board. I suggest you guys measure this on Monday so you can correctly estimate the MC length noise. And then perhaps undo the whitening in the anti-whitening filter of this filter bank so that the signal which is recorded is in units of kHz.
This should allow your online subtraction filter to be more correct: roughly speaking, the phase shift below a pole or zero is going to be 45*(f/fp) deg. Since we expect there to be 2 zeros at 15 Hz, it would be 9 deg phase shift at 1.5 Hz and limit the subtraction to ~80%.
To help find out if Steve really melted the inside of our precious seismometer, lets hook it up using the handheld seismo wand and see if it produces volts when we shake the ground.
Also, please stop using names like GurA or Gur1 or GurSuzy. We have GurX and GurY because they are at those ends. Anything else is confusing.
Somehow it seems like the ELOG makes all of the thumbnails way too big by default. Did we get some sneaky upgrade recently?
I would only plot your results below 50 Hz. We don't care about the RMS at high frequencies and it can make the RMS misleading.
We definitely need to include one vertical Wilconox at each MC chamber so that it can subtract all of that junk at 10-20 Hz.
I'm not totally sure, but by eyeball, this seems like the best online MCL reduction we've ever had. Nice work.
The 3 Hz performance is the same as usual, but we've never had such good 1 Hz reduction in the online subtraction.
I would like to see a plot of the X & Y arm control signals with only the MCL filter ON/OFF. This would tell us how much of the arm signals were truly frequency noise.
Let's order a pair of 35.5 MHz Wenzel for this guy and package like Rich has done for the WB low noise oscillators.
WE're only sending 6 dBm into it now and its using a 13 dBm mixer. Bad for PMC stability.
Also, if anyone has pix of the servo card, please add them to the DCC page for the PMC.
The IMC often was making that scratchy noise when first catching lock and sometimes breaking. Thinking of the crappy crossover sit that EQ showed in his latest plots, I decided that it didn't make sense to acquire lock with an unstable PZT/EOM crossover, so I have changed mcdown to acquire with +13 dB Fast Gain and its much fast now and no longer makes that sound.
I also changed the caput command from 'caput -l' to 'caput -c -l' to see if the async 'wait for callback' feature will insure that the commands get sent. I witnessed the mcdown not actually writing all of its commands once or twice tonight. With the MC Boost left on its never going to lock.
mcdown has been committed to SVN. Please, if you have recently edit mcup and Autolock, commit them to the SVN or else I will delete them and do an svn up.
ran the ON script several times and it kept pulling it away from good alignment, even when TRX was > 0.9.
Also, for what reason was this model run at 16 kHz?? Makes no sense to me to have a low frequency servo system run so high. Only makes for more digital precision noise, more CPU time, etc. Of course, running it at 2k would mean having to think about all of the AA filtering needed to go up/down from 2k to 16k.
Back in 2011, JoeB wrote some entries on how to automatically update the Simulink webview stuff.
Somehow, the cron broke down over the years. I reran the matlab file by hand today and it worked fine, so now you can see the up to date models using the internet.
I experimented with removing somethings here and there to reduce the c1cal runtime. Eventually I deleted the LSC Sensing Matrix from it.
After removing sensing matrix, the run time is now down to 6 usec.
added the cron script for this to megatron to run at 8:44 AM each morning. Here's the new MegaCron attached :-()-
** it takes ~13 minutes to complete on megatron
# m h dom mon dow command
#0 */1 * * * bash /home/controls/public_html/summary/bin/c1_summary_page.sh > /dev/null 2>&1
#15 5 * * * /ligo/apps/nds2/nds2-megatron/test-restart
# MEDM Screen caps for the webpage
2,13,25,37,49 * * * * /cvs/cds/project/statScreen/bin/cronjob.sh
# op340m transplants -ericq
Since Andrey's SUS Drift mon screen back in 2007, we've had several versions which used different schemes and programming languages. Diego made an update back in January.
Today I added his stuff to the SVN since it was lost in the NFS disks somewhere. Its in SUS/DRIFT_MON/.
Since we've been updating our userapps directory recently to pull in the screens and scripts from the sites, we also got a copy of the Thomas Abbott drift mon stuff which is better (Diego actually removed the yellow/red functionality as part of the 'upgrade'), but more complicated. For now we have the old one. I updated the good values with all optics roughly aligned just a few minutes ago.
Q and Ignacio were taking a second look at the Pentek interface board which we're using to acquire the POP QPD, ALS trans, and MCF/MCL channels. It has a differential intput, two jumper able whitening stages inside and some low pass filtering.
I noticed that each channel has a 1.5 kHz pole associate with each 150:15 whitening stage. It also has 2 2nd order Butterworth low pass at 800 Hz. Also there's a RF filter on the front end. We don't need all that low passing, so I started modifying the filters. Tonight I moved the 800 Hz poles to 8000 Hz. Tomorrow we'll move the others if Steve can find us enough (> 16) 1 nF SMD caps (1206 NPO).
After this those signals ought to have less phase lag and more signal above 1 kHz. Since the ADC is running at 64 kHz, we don't need any analog filtering below 8 kHz.
Nice going. I think the LLO / LHO scheme is to acquire on 1F and then cdsutils avg to get the 3F offsets. The thinking is that that 1F signals have less intrinsic offset than the 3F signals, so we want to be use digital offsets for the 3F locks.
Frustrated by the single pixel width of the windows and how hard that makes it to drag things around, I explored StackExchange:
which showed how there is a .xml file which can be edited to increase this. I've changed the border size to 4 pixels on Rossa - its nice.
The new stage missed the right height by ~2 mm.
Even if I completely bottom out the (New Focus 9071) 4-axis stage, its not short enough. So I removed the AOM from the beam and re-aligned into the PMC.
Steve, please get the aluminum piece remachined to go down by 2.5 mm so we can have some height adjustment room.
New stage can hold the correct polarization.
Also, the turning mirror mount just after the EOM and before the AOM is a U-100 and we want it to be a Suprema for stability - let's not forget to swap that after Steve gets the mount fixed.
As it turned out, the "STS" BLRMS filters were all a mess, so I fixed them up today:
The "C1:PEM-SEIS_STS_1" filter banks are currently empty, so the signal is just in ADC counts. However, by amazing luck, this seems to be the right gain (within a factor of 2) to put the signal into units of microns / second. According the the schematic (D1000749), the default gain of 110 can be switched to make the whole box just have a gain of 2 (differential in, differential out). I wonder if anyone, like Jenne, knows if this is what we have? There's no elog I found about setting the gain switch.
According to the manual, the gain is ~1175 V/(m/s). Our ADC gain should be (2^16)/(40). So:
cal_gain = 1175 * 2 * 65536 / 40 ==>> 0.26 (m/s)/counts
I have put this into the STS_1_X,Y,Z filter modules in c1pem so that these channels are now calibrated. I also put the first few s-domain poles/zeros into the filter based on the manual so that the magnitude in the 10-30 Hz band is correct-ish now.
* Does anyone know how to center the masses on this thing?
I converted our MC WFS relief from CSH to BASH today. I also added 'wait' commands and 'echo' commands so that all DoFs run in parallel nicely. It can be accessed from the MC WFS screen.
I increased the overall MC WFS gain input slider from 0.02 to 0.1 (its in the mcwfson script). The MC Trans loops now have a time constant of ~30 seconds. The relief script relieves ~90% of the MC WFS control signals in the 2 minutes that its allowed to run.
On the next upgrade, we should make it python and have it kill the relief process if the MC loses lock before relief is applied via the alignment sliders.
We looked at the DRMI noise spectrum and chose new excitation frequencies such that the lines are lower in frequency than before (~300 Hz instead of 800 Hz) and also not in some noisy region.
New filters is saved and loaded for all LSC DOFs.
When making the Wiener filter OFF/ON comparisons, we want to use the median PSD estimates, not the mean (which is what pwelch gives you).
cf. Sujan's note and Evan's follow-up
The median will be less sensitive to the transients / gltiches and will show more improvement I think.
I turned on the MCF FF in the OAF today (we need to fix the labeling of the 'ON' buttons on the RHS of the screen). The performance is still good; before / after attached.
Not only is the 1 Hz performance in the MC still good, but the X & Y arm noise reduction is ~1 order of magnitude. Good to know that the filters aren't changing much with time.
Can we just leave this on all the time now? Seems to be OK and there's no visible increase in the arm noise with this on.
Also did some updates to the summary pages and added a CDS FEC tab for CPU times.
Please take a look at the summary pages and bring a list of demands to the Wednesday meeting.
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.