40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 274 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  128   Wed Nov 28 04:21:46 2007 ranaUpdatePSLFSS

Rana, Tobin

We looked at the RF PD signal to the FSS (siphoning off a signal via a minicircuits directional coupler) and also took an open loop transfer function of the FSS. In the transfer function we saw the step at 100 kHz (mentioned by Rob) as well as some peculiar behavior at high frequency. The high frequency behavior (with a coupling of ~ -20 dB) turns out to be bogus, as it is still present even with the beam blocked. Rearranging the cabling had no effect; the cause is apparently inside the FSS. The step at 100 kHz turns out to be a saturation effect, as it moved as we lowered the signal amplitude, disappearing as we approached -60 dBm. (Above the step, the measurement data is valid; below, bogus.)

Transfer functions will be attached to this entry.

Some things to check tomorrow: the RF signal to the PC, RF AM generation by the PC, LO drive level into the FSS, RF reflection from the PC, efficiency of FSS optical path, quality of RF cabling.

I would also add to Tobin's entry that we believe what Rob was seeing was saturation.

With the bi-directional coupler in there, the RF signal into the FSS board clearly went UP if moved the offset slider away from zero.
With a scope looking at the IN2 testpoint, we can see that there's less than 2 mV offset at zero slider offset.

One tangential thing we noticed with the coupler is that, in lock, the amount of reflected RF is around the same as that going in to the mixer.
I have always wanted to look at this but have only had uni-directional couplers in the past. I think that the double balanced mixer is inherently
not a 50 Ohm device during the times where the diodes are being switched. IF that's the case we might do better in the future by having an RF
buffer on board just before the mixer to isolate the PD head from these reflections.
  132   Wed Nov 28 16:46:28 2007 ranaConfigurationComputersscientific linux 5.0
I tried installing Scientific Linux on Tiramisu. The installation process was so bad (really)
that I quit after 15 minutes. Its back to booting Ubuntu as if nothing had ever happened. Let
us never speak of Scientific Linux again.
  133   Wed Nov 28 17:15:26 2007 ranaConfigurationSUSETMY damping / watchdogs
Steve has noted that ETMY was often tripping its watchdog. I saw this again today.

So I checked the damping settings. Someone had set the SIDE gain to +1. The gain which gives
it a Q of ~10 is +10. I set the SIDE gain to +20. I checked and the ETMX gain is -16 so now
they're at least similar. I have updated the snapshot to reflect the new value.

Hopefully now it will be more well behaved.
  143   Thu Nov 29 19:35:14 2007 ranaHowToComputer Scripts / ProgramsGPIB Scripts

I've spent a lot of time trying to configurate the GPIB-USB interface for the HP4195. After installing 1) the Agilent libraries, 2) the drivers, 3) the matlab Instrument Toolbox, 4) Jamie script, 5) Alice's script the computer can see the HP but still they can't 'talk' to each other.
I give up. I asked Alice Wang how she managed to get data. I'm not sure she used the GPIB interace. Rob said she might have used the old fashion floppy disks that we can't read anymore here.
I would really appreciate any suggestion by anyone who happened to have the same problems.

Alice and Jamie used the USB-GPIB interface. You should just try using the black laptop which already has this capability or ask Jamie Rollins
who actually knows something.
  147   Fri Nov 30 19:11:05 2007 ranaConfigurationElectronicsETMX oplev dead again
I removed the ETMX HeNe and put in on a test table and it fired up fine. In its
previous location the light on the HeNe power supply was not lighting up. If
that's still on over the weekend we'l blame the power strip; the HeNe is a JDS
2.7 mW laser from 2002.
  148   Fri Nov 30 19:29:14 2007 ranaConfigurationSUSnew screen
Andrey is working on a new screen to show us the drift of the optics by alarming on
their osem values. You can find it under SUS as 'Drift Mon' from the site map.

To aid in this I ran the following csh commands which effect all optics:
  foreach dof (POS PIT YAW)
     ezcawrite C1:SUS-${opt}_SUS${dof}_INMON.PREC 0

This should make the DOF readouts more readable.
  149   Fri Nov 30 19:46:58 2007 ranaConfigurationComputersEPICS Time Bad again
The time on the EPICS screens is off by 10 minutes again. Por Que?

Its because the ntpd on scipe25 wasn't restarted after the last boot. If someone
knows how to put the ntpd startup into that machine, please do so.

This time I started it up by just going sshing in as controls and then entering:

sudo /usr/sbin/ntpd -c /etc/ntp.conf

which runs it as root and points to the right file.

It takes a few minutes to get going because all of the martian machines have to first fail to
connect to the worldwide pool servers (e.g. 0.pool.ntp.org) before they move on and try linux1
which has a connection to the world. Once it gets it you'll see the time on the EPICS screens
freeze. It then waits until the ntp time catches up with its old, wrong time before updating

According to the Wikipedia, this time is then good to 128 ms or less.
  152   Fri Nov 30 21:27:24 2007 ranaDAQPEMweather / stacis / c1pem1
I was trying to add some Seis BLRMS channels to the c1pem1 processor so that we could have DMT trends.

Then I found that none of the Weather channels have been working for a year or so. I could also not
telnet into it. I tried resetting it but no luck. There was no entry in the Wiki for it so I added
a place holder.

Have the weather channels ever worked? Do we have those sensors? I think I've never actually looked
for this. Seems like a fine ugrad job.
  153   Sun Dec 2 17:37:33 2007 ranaOmnistructureComputersNetwork Cabling in the Office
We all know that we've spent many integrated man hours trying to figure out why our network connections
in the office area don't work. Usually its because of the bad hub around the Tobin/Osamu desk.

I pried open some of the wall conduit today and it looks pretty easy to fish cables through. I think
its time we finally did that. It may be a little disruptive, but I propose we get Larry to come over
and figure out what needs to happen for us to get regular 100 Mbit ports on the walls. These can
then all go over and get connected to a switch in the rack that holds linux1.

Opinions / comments ?
  154   Sun Dec 2 21:02:12 2007 ranaConfigurationIOOMC SUS re-alignment
The spot on MC2 was not centered, so I put it back in the center:

  • Made sure MC trans was high with the WFS off.
  • Moved the Sliders on the MC Align screen until spot was centered (by eye)
  • Moved some more until power was maximized.
  • Unlock MC
  • Center spots on McWFS
  • Re-enable autolocker and McWFS loops.
  155   Sun Dec 2 21:07:39 2007 ranaConfigurationIOOMC SUS re-alignment
you asked for:   diff 2007/12/01,4:58:48 2007/12/03,4:58:48 utc 'MC.*COMM'
LIGO controls: differences, 2007 12/01 04:58:48 utc vs. 2007 12/03 04:58:48 utc
__Epics_Channel_Name______   __Description__________   __value1____     __value2____
C1:SUS-MC1_YAW_COMM                                    -0.273460        -0.503460
C1:SUS-MC2_PIT_COMM                                     3.624020         3.632020
C1:SUS-MC2_YAW_COMM                                    -0.936800        -1.038800
C1:SUS-MC3_YAW_COMM                                    -3.129000        -3.369000
  156   Sun Dec 2 21:13:16 2007 ranaConfigurationIOOMC SUS re-alignment
Attachment 1: e.png
  157   Mon Dec 3 00:10:42 2007 ranaDAQComputer Scripts / Programslinemon
I've started up one of our first Matlab based DMT processes as a test.

There's a matlab script running on Mafalda which is measuring the height of the 60 Hz peak
in the MC1 UL SENSOR and writing it to an unused EPICS channel (PZT1_PIT_OFFSET).

The purpose of this is just to see if such a thing is stable over long periods of time. Its
open on a terminal on linux3 so it can be killed at any time if it runs amok.

Right now the code just demods the channel and tracks the absolute value of the peak. The
next upgrade will have it track the actual frequency once per minute and then report that
as well. We also have to figure out how to make it a binary and then make a single script
that launches all of the binaries.

For now you can watch its progress on the StripTool on op540m; its cheap and easy DMT viewer.
  160   Mon Dec 3 19:06:49 2007 ranaDAQComputer Scripts / Programslinemon
I turned up my nose at Matlab's special tools. I modified the linetracker to use the
relationship phase = 2*pi*f*t to estimate the frequency each minute. The
code uses 'polyfit' to get the mean and trend of the unwrapped phase and then determines
how far the initial frequency estimate was off. It then uses the updated number as the
initial guess for the next minute.

I looked at a couple hours of data before letting it run. It looks like the phase of the
'60 Hz' peak varies at 20 second time scales but not much faster or rather anything faster
would be a glitch and not a monotonic frequency drift.

From the attached snapshot you can see that the amplitude (PZT1_PIT) varies by ~10 %
and the frequency by ~40 mHz in a couple hour span.
Attachment 1: spd64d1.jpg
  170   Wed Dec 5 19:25:07 2007 ranaDAQCDSDMF
I made a database file on C1AUX called dmf.db. It has 9 DMF EPICS channels which are also trended
so that one can now write data to those channels from a DMF Monitor and the data will be records.

New channels:

I added these to C1AUX because it doesn't do much and can be booted without having much effect.
(it controls Mech Shutters, Video, and Illuminators. It used to also do the EO Shutter but I
removed that from its startup.cmd and it will no longer load those records).
  178   Fri Dec 7 00:02:26 2007 ranaSummaryIOOMC/FSS Frequency Noise
The FSS frequency noise is not very bad.

I compared the MC_F spectra between Hanford and the 40m using DTT and its 'User NDS' option.
After Sam, Jenne, and DavidM installed the new MC Servo some time ago, the MC_F spectrum here
has had some whitening before it goes into the DAQ (on board; same as LLO & LHO). The tuning
coefficient of the VCO is also basically the same between all PSLs since everyone has the same
chip in the VCO driver.

Therefore, at the frequencies where the MC gain is more than ~4, the MC_F signal calibration is
the same here as anywhere. Since its the servo control signal, its basically a measure of the
frequency noise incident on the MC -- its just what comes out of the FSS with the table noise on
top. At low frequencies (< 100 Hz) its a measure of the motion of the MC mirrors.

Above 200 Hz ours is the same as theirs; except for the enormous power line spikes. I think that's
either all on the light. But our acoustics are better and the noise above 1 kHz levels off at the
same flat floor (the phase noise of the VCO) as H1. The huge lump around 100 Hz is the MC2 DAC noise and
it goes down to the H1 levels when we flip on the dewhites. The giant excess from 5-50 Hz is just the fact
that our stacks don't do much until 20-30 Hz.

So we can stop blaming the FSS and move on with life as soon as Tobin gets the ISS back in shape.
Attachment 1: fly.pdf
  213   Wed Dec 26 15:00:06 2007 ranaUpdateSUSETMY tripping
Steve mentioned to me that ETMY is still tripping more than ETMX. The attached DV plot
shows the trend of the watchdog sensors; essentially the RMS fluctuations of the shadow
sensors. (note** DV can make PNG format plots directly which are much better than JPG
when making plots and much smaller than PS or PDF when plotting lots of points).
Attachment 1: etm.png
  214   Wed Dec 26 15:12:48 2007 ranaUpdateSUSETMY tripping
It turned out that the ETMY POS damping gain was set to 1.0 while the ETMX had 3.8.

I put both ETMs to a POS gain of 4 and then also set the PIT, YAW and SIDE gains for
ETMY. Let's see if its more stable now.

In the next week or so Andrey should have perfected his damping gain setting technique
and the numbers should be set more scientifically.
  216   Thu Dec 27 13:08:04 2007 ranaUpdateSUSETMY tripping
Here's a trend from the last 2 days of ETMX and ETMY. You can see that the damping gain increase
has made them now act much more alike. Problem fixed.
Attachment 1: Untitled.png
  217   Thu Dec 27 18:18:56 2007 ranaUpdateComputersUpdate on GigE Camera

So I finally got the linux software to compile on mafalda. I got the software to dump all the information regarding the camera onto a file. I tried to take a tiff snap and came up empty. So I looked at the configuration file and realized that the camera thinks that the frame-rate is a nan. Am reading up the manual to fix the frame-rate manually and then will attempt to take another snap.

All the files are in a folder called Prosilica in /home/controls/ on mafalda. All the executables are in /home/controls/Prosilica/bin-pc/x86/* . On another note, I am looking for a name for the camera. Any suggestions are welcome.

Suggestion #1: put this in the target area in a directory called /prosilica/. /home/controls is not backed up.

Suggestion #2: put a readme file in there on any work that was necessary to get it to compile.

Suggestion #3: make a wiki page for the camera with all the info that camera code developers will need
  242   Wed Jan 16 18:24:41 2008 ranaUpdateSUSETMY Watchdog
Because Steve keeps complaining about ETMY, I looked at some minute trend to see if there was something exotic happening at that time. It looks like there is some tremendous seismic activity to make it happen.

The trend shows that there is nothing special happening on the ETMX accelerometer or the ETMX suspension. At the same time, however, there is a huge jump in the ETMY sensors and therefore the watchdog signal. Whenever the watchdog value goes above 140, it trips.

After Andrey moves some accelerometers over to the Y end we can see the effect more directly.
Attachment 1: A.pdf
  257   Wed Jan 23 20:52:40 2008 ranaSummaryEnvironmentFlooding from construction area
We noticed tonight around 7 PM that there was a lot of brown water in the control room and also in the interferometer area mostly concentrated around the north wall between the LSC rack and the AP table.

The leak was mainly in the NW corner of the interferometer area.

The construction crew had set up sandbags, plastic sheet, and gravel to block the drains outside of the 40m along the north wall. The rain had produced ponds and lakes outside in the construction area. Once the level got high enough this leaked through holes in the 40m building walls (these are crappy walls).

We called the on-call facilities team (1 guy). He showed up, cut through the construction fence lock, and then unblocked the drains. This guy was pretty good (although inscrutable); he adjusted the sandbags to control the flow of the lake into the drains. He went along the wall and unblocked all 3 drains; there were mini-lakes forming there which he felt would eventually start leaks all along our north wall.

In the morning we'll need volunteers to move equipment around under Steve's direction while the floor gets mopped up. There's dirt and mud all over, underneath the chambers and racks.

Luckily Alberto spotted this early and he, Jon, Andrey and Steve kept the water from spreading and then scooped it all up with a wet-vac that the facilities guy brought over.
Extra Napoleon to them for late evening mud clearing work.

Many pictures were taken: Update and pictures will appear later.
Attachment 1: Shop-Vac_Action.MOV
Attachment 2: Flooding.pdf
Flooding.pdf Flooding.pdf Flooding.pdf Flooding.pdf Flooding.pdf
  270   Fri Jan 25 21:36:40 2008 ranaUpdateCDSmDV / channel issues
Fri Jan 25 21:30:00 2008

As it turns out, the residual problem with the mDV stuff was not to do with our button pushing episode but instead fallout from the 'turning off of the computers' during the water leak caused by the rain and construction.

The /frames partition from fb0 (the FrameBuilder) is not mounted to the control machines via vfstab; it does not remount on bootup. I originally did this because Ben Johnson and Dave Barker had warned me that during a power outage, fb0 may not come up right away. This could make the control room machines hang up for awhile. I elected to have the mount be by hand.

So the thing to do is to put the mount command into the cold start procedures (Andrey). Its in an old elog entry of mine from Feb '07.
  274   Sat Jan 26 18:12:45 2008 ranaHowToComputersextra processes and crashes
There were a load of extra processes on op440m; they were all related to rogue DV processes (frameMemRead, framer4, xmgrace, etc.)

You can check this by running top. IF there's lots of them you can kill them by using 'pkill'.

I'm attaching the screen cap of a 'top' session. You can also see that the cron of updatedb is running and taking upp all the CCPU. Thee result is that the delay puts misspellings and doouble characters intoo my elog entry. Clearly wwe'll have to fix the cron setup.
  278   Sun Jan 27 21:44:48 2008 ranaUpdateCDSSeismic BLRMS on Matlab
I wrote a matlab script to produce band limited RMS trends from our accelerometers. It mimics the code written
by Ed Daw which makes the seismic FOMs at the sites.

Here's how it works:
  • Use mDV to get data by reading directly from frames.
  • Use the Matlab pwelch function to produce a power spectrum of the channels.
  • Use the Matlab find function and rms.m to get the RMS in user-defined frequency bands.
  • Makes a tdswrite command string which writes all the values to EPICS channels.
  • The EPICS channels are just a list of simple names in a database file.
  • The channel names are (will be) added to the C0EDCU.ini file so that its all trended.

The code is in the mDV/extra/C1 directory; its ~20 lines of code (excluding comments and spaces).

Next up is to add more DMF trend channels to the database and upgrade the code to use a .conf file
instead of hardcoded channel names. We should also evaluate if the bands I used are appropriate for the 40m;
I just used Ed's choices (0.1-0.3, 0.3-1, 1-3, 3-10, and 10-30 Hz).

In the medium term, we should make this compiled (like what RW did with the linetracker), and explore if we
want it to write values faster than 1/minute.
Attachment 1: seisBLRMS.m
% Seismic BLRMS Monitor
% RA 08-01-26

% 0 for no messages, 1 for debugging
debug_flag = 1;

% ------------ Build channel list
... 82 more lines ...
  282   Mon Jan 28 18:56:47 2008 ranaUpdateDMFseisBLRMS 1.0
I made all of the updates I aludded to before:

  • Expanded the dmf.db file on c1aux to include all accelerometers and the seismometer.
  • Added the channels to the C0EDCU.ini file and restarted the framebuilder daqd.
  • Modified seisBLRMS.m to use .conf files for the channels. The .conf files are now residing in the compiled matlab directory that Rob made.

I still have yet to compile and test the new version. Its running on linux3 right now, but feel free to kill it and compile it to run on Mafalda.

It should be making trends overnight and so we can finally see what the undergrads are really up to.
  283   Mon Jan 28 19:35:55 2008 ranaSummaryPEMAccelerometer and Seismometer Coherences
The attached PDF shows that there is some strange behavior at low frequencies.

From the plot it looks like to me that the Wilcoxon accelerometers (which are supposed to have good response down to 0.05 Hz) are not displaying real seismic motion below 0.3 Hz. Because the coherence length for seismic waves at those frequencies should be 100's of meters we should expect that the accelerometers would have good coherence (>0.8) down there. Instead, my guess is that its all air currents, temperature, or electronics noise. These sensors are not reliable indicators for the microseism.

The Ranger seismometer, however, seems to work fine down to just below the microseism. The Ranger is mounted down around the X end and pointing in the z-direction. The coherence I plotted between it and EX_Z is larger than any other acc/seis pair (as expected).

JM and I discussed what could be done; if we get a SURF student who's into building stuff we can ask them to make a styrofoam hut for the Wilcoxons to see if that helps anything. JM also asked what the point of all this is.

IF we want to do good Adaptive Noise subtraction then we need sensors which can sense the motion which disturbs the mirrors and they need to sense it with a good SNR to get a good subtraction ratio. If the styrofoam thing doesn't work, we should probably look into getting a Guralp 3-axis seismometer for the corner area and just move the accelerometers down to the ends. The sites have Guralp CMG-40T units (~ 8k$). I think we should check out the CMG-3T or the CMG-3ESP.

Does anyone know someone in the Geo depts that we can borrow one from?
Attachment 1: Acc.pdf
  295   Sun Feb 3 05:02:41 2008 ranaUpdatePEMSeism 4 day
Attachment 1: Screenshot.png
  301   Wed Feb 6 19:39:11 2008 ranaConfigurationCamerasRegions of Interest and max frame rate
We really need to look into making the 40m CDS network have an all GigE backbone so that we can have cooler cameras as well as collect multiple datastreams...
  319   Fri Feb 15 10:28:44 2008 ranaUpdateComputersNoise budget code changes

In cvs/cds/caltech/NB/matlab/utilities/LSCmodel.m at line 146
I have hardwired in changes to struct lsc. Please see code.

The IFOin variable (which I admit is not documented) should refer to a file called
C1IFOparams.m in the ReferenceData directory. This does not yet exist but can be
created by merging L1IFOparams.m with our knowledge of the 40m IFO.
  329   Thu Feb 21 19:55:46 2008 ranaUpdateElectronics2 BNC Cables, 1 Tee
I'm not sure where Ward and Miller went to Analyzer school, but it was probably uncredited.
I turned it on and used 2 BNC cables and a T to hook up the source to the 2 inputs and measured the always-exciting TF of cable.

Score:  HP Analyzer  1
        Rob & John   0

I have left the analyzer on in this complicated configuration. RTFM boys.

The HP 4195A network analyser may be broken, measurements below 150MHz are not reliable. Above 150MHz everything looks normal. This may be caused by a problem with its output (the one you'd use as an excitation) which is varying in amplitude in a strange way.

  349   Sun Mar 2 23:43:45 2008 ranaHowToLSCPD6 response
John's PD plotting script is superior to all of the ones we had before; lets make him post the script so we can all use it.

Looks like PD6 is not too happy after all; the 199 MHz response is not much higher than the 166 MHz response. I thought we were supposed to have them balanced to within 6 dB or so?
  353   Mon Mar 3 19:34:40 2008 ranaUpdateComputers RFM Network are down

The CODAQ_RFNETWORK are down, except C1SUSVME & AWG

All of the FE machines were found to be down this afternoon. I called Alex and he suggested several
things which didn't work (restart EPICS tasks, power cycle RFM switch, etc.).

Then he suggested that I go around and power cycle every crate!!! And that sometimes the order of this
matters!!! I think he was just recording this conversation so that he could have a laugh by playing it on Youtube.

However, power cycling all of the FE crates seemed to work. Alex's theory is that 'something goes bad in the
RFM cards sometimes'.

Its all green now.
  354   Tue Mar 4 00:42:51 2008 ranaUpdateComputersFB0 still down ?
The framebuilder is still down. I tried restarting the daqd task and resetting the RFM
switch like it says in the Wiki but it still doesn't work right. The computer itself is
running (I can ssh to it) and the daqd process is running but there's a red light for
it on the RFM screen and dataviewer won't connect to it.

If Alex isn't over by ~10 AM, we should call him and ask for help.
  356   Tue Mar 4 19:14:09 2008 ranaConfigurationCDSTDS & SVN
Matt, Rob, Rana

Today we added the TDS software to the 40m SVN repo.

First we rationalized things by deleting all the old TDS directories and taking
the tds_mevans dir and making it be the main one (apps/linux/tds).

We also deleted all of the TDS directories in the project area. It is now very
likely that several scripts will not work.
We're going to have the teething
problems of repointing everything to the nominal paths (in the apps areas).

Finally we did:
svn import tds https://40m.ligo.caltech.edu/svn/40m/tds --username rana

to stick it in. To check it out do:
svn checkout https://40m.ligo.caltech.edu/svn/40m/tds --username rana

We'll get a couple of the O'Reilly SVN books as well to supplement our verion control knowledge.
Unitl then you can use the SVN cheat sheets available at:
  357   Tue Mar 4 20:14:02 2008 ranaConfigurationIOOMC Alignment
The MC alignment was pretty far off. We were getting TEM01 mode locks only.
Rather than inspect what happened I just aligned the MC suspensions to get
the transmission higher. Now Matt should be able to lock the X arm and collect
adaptive filter data.
  361   Wed Mar 5 17:35:24 2008 ranaUpdateIOORFAM during MC lock
I used an ezcaservo command to adjust the offsets for Alberto's StochMon channels. They are all
at +2 V with no light
on the RFAM PD (MC unlocked).

Then I looked at 5 minutes of second trend around when the MC locks. Since Alberto has chosen
to use +2V to indicate zero RF and a negative gain, there is a large RF signal when the StochMon
channels approach zero

From the plot one can see that the RFAM for the 133 & 199 MHz channels is much worse than for the 33 and 166.
Its also clear that the turn on of the WFS (when the RFAMPD's DC light level goes up) makes the single demod
signals get better but the double demod get worse.
Attachment 1: rfam.pdf
  363   Fri Mar 7 00:47:54 2008 ranaConfigurationPEMRanger SS-1
Yesterday evening around 7:30 PM, I changed the Ranger seismometer from a
vertical to a horizontal seismometer. To do this I followed the instructions
in the manual.
1) Lock it down.
2) Turn it sideways. Use the leveling screws to center the bubble level.
3) Carefully loosen the hanger rod and release slowly the tension to allow
   the mass to recenter.
4) Look through the little viewhole next to the rod to make the white lines
   line up. This means the mass is centered.
5) Look at the output on a scope. It should be freely moving with a ~1 sec.

The attached plot shows the before and after spectra.
Attachment 1: ss1.pdf
  368   Tue Mar 11 23:14:01 2008 ranaConfigurationPEMAccelerometer and Seismometer movements
Steve and Matt moved the accelerometers and seismometers today.
The accelerometers are now placed around the MC and the seismometer is in-between MC1 & MC2.

We have changed the names of the acc channels to reflect whether they are close to MC1/MC3
or MC2. We tested the accelerometer to channel name mapping by switching gains at the wilcoxon
breakout box and also by tapping. It seems now that the previous setup near the ITMX/ETMX had
some few channels mislabeled which would have given some confusing results.

Alex, Jay, and Rolf came over today and installed, then de-installed some of the hardware for
sending the PEM channels over to the C1ASS machine where the adaptive filter front end will go.
Everything should be back to the way it was...hopefully, the guys will modify the ADCU PEM
code to send the signals to the new FE over the reflective memory net and then send them to the
MCL inputs of the suspensions. So the first incarnation should use the accelerometers and seismometer
to drive MC1 and/or MC3.
Attachment 1: Acc.pdf
  369   Wed Mar 12 00:36:52 2008 ranaConfigurationPEMAccelerometer and Seismometer movements
I used the MISO FIR Wiener matlab code to see how well we might do in principle.

The attached 3 page PDF file shows the MC_L control signal (force on MC2) and the residual
after subtracting off the accelerometer and seismometer using a 32 Hz sample rate and
512 taps (page 1), 1024 taps (page 2), and 2048 taps (page 3). As Matt smarmily points out,
there's not a lot to win by going beyond 512; maybe a factor of sqrt(2) for a factor of 4
tap number.
Attachment 1: finished.pdf
finished.pdf finished.pdf finished.pdf
  370   Wed Mar 12 00:40:35 2008 ranaConfigurationPEMAccelerometer and Seismometer movements
Same as above but with 2048 taps and a 128 Hz sample rate. Does much better at the 16 Hz bounce mode.
Attachment 1: mc2048-128.pdf
  371   Wed Mar 12 00:47:26 2008 ranaConfigurationPEMAccelerometer and Seismometer movements
And this is a cool snapshot showing how this operation used 16 cores on menkar !
Attachment 1: Screenshot.png
  372   Wed Mar 12 23:05:44 2008 ranaUpdateIOOMC WFS
they are bad, somewhat

please fix
  387   Thu Mar 20 17:45:36 2008 ranaSummaryASSAdaptive Filtering in the ASS system
Over the past couple weeks we (Matt, Alex, Rob, me) have worked on getting an adaptive filter
system working. We wanted to load this system into c1ass to use this processor. The dither alignment
system hasn't been employed here for awhile and so we have just used this box.

The signals are acquired in the PEM ADCU. Alex modified the code there to send the signals over to
the new system. We also get the SUS-LSC_OUT signals from each of the suspensions so that we can
try to minimize them.

The outputs of the adaptive filter go into the unused SUS-MCL inputs of all the suspensions (except
for MC2). In the current setup, we have 6 accelerometers and 1 seismometer around the MC to be used
to demonstrate the principle of the whole thing.

Much more documentation and description of everything is necessary. We'll try to get Matt, Rob, and Alex
to use the elog.
  390   Fri Mar 21 17:01:21 2008 ranaConfigurationDMFLocale change on Mafalda & seisBLRMS restart
Ever since we moved the accelerometers to be around the MC and changed their names, the seisBLRMS
has not been working. I tried to restart it today after fixing the channel names in the par file
but I ran into a PERL / UBUNTU bug.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_TIME = "en_US.ISO8859-1",
        LC_MONETARY = "en_US.ISO8859-1",
        LC_CTYPE = "en_US.ISO8859-1",
        LC_COLLATE = "en_US.ISO8859-1",
        LC_MESSAGES = "C",
        LC_NUMERIC = "en_US.ISO8859-1",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

I don't know how this crept up or when it started. There were a bunch of fixes on the Ubuntu
forums which didn't work.

In the end I just set the 'unset' environment variables via our cshrc.40m file and this seemed
to make ligotools/perl happy. Lets hope this lasts...I love Linux.
  391   Fri Mar 21 23:15:11 2008 ranaConfigurationPEMRanger SS-1: New Setup
The Ranger seismometer has been in a bad state. Its output had been sent into a SR560 without any termination.

The seismometer is, internally, just a mass on a flexure with a magnet and a pickup coil for readout.
The damping of the system depends on the resistor hooked up across the coil. With the SR560 this is
the 1 Meg input impedance of it and so the mass is undamped.

I installed a 4300 Ohm resistor in there which seems to nearly critically damp it. However, this will not
allow us to reach the ultimate quantum noise limited performance. We will have to analyze the thermal, voltage,
and current noise to get that.

I then also increased the gain from 10 to 100 on the SR560. This should now make the front end noise of the
seismometer/SR560 close to equal to the noise of the PEM ADC.
  392   Fri Mar 21 23:17:47 2008 ranaConfigurationDMFseisBLRMS restarted
I updated the seisBLRMS par file with the new channel names of the accelerometers and the seismometer and then
recompiled the code and restarted it according to Rob's elog entry. It went fine and the seisBLRMS is now back in
  416   Mon Apr 7 16:42:56 2008 ranaUpdateComputerseLog intermittent
Phil Ehrens restarted Dziban again this morning. Looks like its still crashing each Monday around 8 AM.

Here is the latest suspect:

  419   Tue Apr 15 18:44:25 2008 ranaConfigurationComputersRosalba
There is a new computer in the control room -- its called Rosalba,
in keeping with our naming convention. Its a quad-core machine that
Dmass found for cheap somewhere; we've installed the CentOS on it
that Alex recommended.

Its a 64-bit Linux and so that's going to cause some problems. Alex has done this
before and so we have some confidence that we can get our regular tools (DTT, Dataviewer)
to run on it.

I have made a new apps tree for all of our future 64-bit Linux machines. So far, there is
a 64-bit firefox and a 64-bit matlab in there. As we start using this machine some more, we
will be forced to install more 64-bit Linux stuff.

We also didn't have enough network cables to run to both linux3 and rosalba. Andrey has decided that we
should not ditch linux3 and so he will run another cable for it tomorrow.
  422   Wed Apr 16 21:11:12 2008 ranaSummaryDAQAA/AI Filters for the DAQ & FE systems
I used Foton to make up some new filters which will be used all over the project in order to downsample/upsample.

There will be 2 flavors:

  • The first one will be a downsampling filter for use in the DAQ system.
    Whenever you specify a sampling rate in the .ini files below the natural rate of the ADC,
    the data will be downsampled using this filter (called ULYAW_0 in the plot). This one was
    designed for flat bandpass and a 'good' bandstop but no care given to the phase shift.

  • The second one will be used in the FE systems to downsample the ADC signal which is often
    sampled at 64 kHz down to something manageable like 2k or 16k. This one was tweaked for
    getting less phase lag in the 'control' band (usually 3x or so below Nyquist).

Here is the associated filter file:
# DESIGN   ULYAW 0 zpk([0.512+i*1024;0.512-i*1024;2.048+i*2048;2.048-i*2048], \
#                      [515.838+i*403.653;515.838-i*403.653;318.182+i*623.506;318.182-i*623.506;59.2857+i*827.88; \
#                      59.2857-i*827.88],0.988553,"n")
# DESIGN   ULYAW 1 zpk([0.512513+i*1024;0.512513-i*1024;1.53754+i*2048;1.53754-i*2048], \
#                      [200+i*346.41;200-i*346.41;45+i*718.592;45-i*718.592],1,"n")
# DESIGN   ULYAW 2 zpk([0.768769+i*1024;0.768769-i*1024;1.53754+i*2048;1.53754-i*2048], \
#                      [194.913-i*331.349;194.913+i*331.349;53.1611+i*682.119;53.1611-i*682.119],1,"n")
###                                                                          ###
ULYAW    0 21 3      0      0 DAQAA         0.00091455950698073    -1.62010355523604     0.67259370084279    -1.84740554170818     0.99961738977942
                                                                   -1.72089534598832     0.78482029284220    -1.41321371411946     0.99858678588255
                                                                   -1.85800352005967     0.95626992044093     2.00000000000000     1.00000000000000
ULYAW    1 21 2      0      0 FEAA            0.018236566955641    -1.83622978049494     0.85804776530302    -1.84740518752455     0.99961700649533
                                                                   -1.89200532023258     0.96649324616546    -1.41346289594856     0.99893883979950
ULYAW    2 21 2      0      0 ELP             0.015203943102927    -1.84117829296043     0.86136943504058    -1.84722827171918     0.99942556512240
                                                                   -1.89339022414279     0.96048849609619    -1.41346289594856     0.99893883979950
Attachment 1: DAQ_filters_080416.pdf
ELOG V3.1.3-