40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 320 of 326  Not logged in ELOG logo
ID Date Author Type Category Subject
  335   Fri Feb 22 14:45:06 2008 steveUpdateMOPAlaser power levels

At the beginning of this 1000 days plot shows the laser that was running at 22C head temp
and it was send to LLO

The laser from LHO PA#102 with NPRO#206 were installed at Nov. 29, 2005 @ 49,943 hrs
Now,almost 20,000 hrs later we have 50% less PSL-126MOPA_AMPMON power
Attachment 1: lpower1000d.jpg
lpower1000d.jpg
  334   Fri Feb 22 11:13:15 2008 robUpdateElectronicsRF Monitor (StocMon)

Quote:
It took some times because the written procedure to start the chiller is not very precise.


It is actually very precise. Precisely wrong.
  333   Fri Feb 22 11:11:00 2008 robUpdateElectronicsREFLDD problem found

I used a network analyzer that actually works to find a problem in the REFLDD electronics chain. There was loose (=bad) SMA-BNC adaptor on the output of channel one of the HP RF Amplifier. It worked intermittently, so going onto the ISCT and fiddling with cables could sometimes temporarily fix the problem. The bad adaptor has been given to Andrey to discard.
  332   Fri Feb 22 08:33:18 2008 AlbertoUpdateElectronicsRF Monitor (StocMon)

Quote:
I put the amplifiers next to the monitor on the PSL table, layed the power and the RF SMA cables out to the rack. I'm powering the box and the amplifiers with the power supply, waiting for someone to show me tomorrow how to connect it to the Sorensen (Steve, Ben?).

I'm ready to hook up the channels into EPICS.


With Ben, we hooked up the RF Monitor box into the PSL rack and created 4 EPICS channels for the outputs:

C1:IOO_RF_STOC_MON_33
C1:IOO_RF_STOC_MON_133
C1:IOO_RF_STOC_MON_166
C1:IOO_RF_STOC_MON_199

The power cable bringing +15V to the preamplifier on the PSL table should be replaced eventually.
  331   Fri Feb 22 08:29:07 2008 AlbertoUpdateElectronicsRF Monitor (StocMon)

Quote:
I put the amplifiers next to the monitor on the PSL table, layed the power and the RF SMA cables out to the rack. I'm powering the box and the amplifiers with the power supply, waiting for someone to show me tomorrow how to connect it to the Sorensen (Steve, Ben?).

I'm ready to hook up the channels into EPICS.


Me and Ben Abbot were plugging the cables that power that RF Monitor box into the PSL rack when inadvertently we made some arcs spark between the pins on the back of one of the ADC. Somehow that made the laser shut down although the MOPA stayed on. We also notice some smell of burn.

Later on, after several failed attempts, Rob, Ben and Steve could restart the laser. It took some times because the written procedure to start the chiller is not very precise.
  330   Fri Feb 22 02:51:20 2008 AndreyUpdatePEMAccelerometer ITMX seems to be broken

As people probably know,

I am trying (for a long time) to create a computational program that calculates the evolution of accelerometer time-domain data through stacks and pendulum transfer functions to test masses, and calculate the RMS of differential arm lenght spectrum.

I noticed on Tuesday that time-domain signals from the two accelerometers (one is near ETMX, the other one is near ITMX) seem to have different amplitudes of fluctuations around the mean value. I suspected that this is the main reason why I cannot get the awaited result of minimum of RMS for equal values of Q-factors for ETMX and ITMX suspensions (because we subtract two very different numbers, so we cannot get anything close to zero). I took amplitude spectra of the accelerometer data (dttfft2), and they look very differently for ETMX and ITMX accelerometers. I believe that spectrum of ETMX accelerometer represents seismic noise, but accelerometer ITMX seems to provide us with irrelevant and wrong data. No peaks, just almost monotoneous decreasing curve, and 10 times smaller amplitude. Therefore, ITMX seems to be broken.

I will try tomorrow to clap my hands, shout, yell, near the broken accelerometer to confirm that the accelerometer is broken (more precisely, that either accelerometer itself is broken,
or cable connections, or DAQ channel, but something is wrong). Now it is very late, and I am going home.

See attached figures: time-scale is 10^(-1), 10^0, 10^1, 10^2 Hz.
Attachment 1: Accelerom-EYMX-Feb22.jpg
Accelerom-EYMX-Feb22.jpg
Attachment 2: Accelerom-ITMX-Feb22.jpg
Accelerom-ITMX-Feb22.jpg
  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.


Quote:
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.

Analyzer
  328   Thu Feb 21 18:29:28 2008 JohnSummaryGeneralHP Network Analyser Analyzer
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.

Analyzer
  327   Thu Feb 21 09:56:26 2008 steveUpdatePSLthe laser is back
The laser and the psl recovered.
The water chiller temp is 19.98C and head temp 18.4C
Power 3.2W
PMC_T 3.1

c1iovme was restarted and the mc is locking now
Attachment 1: laserisback.jpg
laserisback.jpg
  326   Wed Feb 20 16:24:37 2008 steveUpdatePSLthe laser is recovering slowly
Head temp is still 20.5C and decreasing slowly.
Power output 2.9W
NPRO power 22 mW is increasing as head is cooling down
Attachment 1: laserecoverring.jpg
laserecoverring.jpg
  325   Wed Feb 20 11:34:17 2008 steveUpdatePSLlaser head temp is up
MOPA head temp is running at 20.3C now
Nomally it is at 18.5C
Attachment 1: htempup.jpg
htempup.jpg
  324   Tue Feb 19 18:28:41 2008 JohnUpdatePEMMore seismic in Baja California
Steve spotted more activity from the same quake.

Reset watchdog on ETMY.
  323   Tue Feb 19 15:21:47 2008 AndreyUpdateSUSEarthquake tripped watchdogs in ETMY, ITMY

According to the web-page http://earthquake.usgs.gov/eqcenter/recenteqsus/Quakes/ci14351140.php ,

there was a 5.0 earthquake in northern Baja California in Mexico at 02.41PM earlier today.

This earthquake made an effect on our watchdogs for ETMY and ITMY (their currents exceeded maximal values).
Watchdogs for ITMY are now restored back,
and it is taking more time for a "side degree" for ETMY to calm down,
it is still (40 minutes after the kick) swinging a lot with amplitude ~ 200mV.
  322   Tue Feb 19 10:14:13 2008 steveUpdateVACrga logging needs help
The rga head and controller are running fine, but the data logging is not.
  321   Mon Feb 18 12:04:39 2008 AlbertoUpdateElectronicsRF Monitor (StocMon)
I put the amplifiers next to the monitor on the PSL table, layed the power and the RF SMA cables out to the rack. I'm powering the box and the amplifiers with the power supply, waiting for someone to show me tomorrow how to connect it to the Sorensen (Steve, Ben?).

I'm ready to hook up the channels into EPICS.
Attachment 1: DSC_0443.JPG
DSC_0443.JPG
  320   Fri Feb 15 22:16:04 2008 AndreyUpdateComputersMATLAB is not working: "Licence checkout failed"

For some unknown to me reason,

Matlab stopped working about 20 minutes ago on all computers in the control room (both UNIX control machines and Windows).

It says: "License checkout failed. License Manager Error -15. MATLAB is unable to connect to the license server."

I do not know how to revive Matlab.

At the same time, I consider that I made a significant progress in building my theoretical/computational model in the last 2 days. I was able to compute the time-evolution of accelerometer signals through stacks and pendulums using Matlab command "lsim", and I am now able to calculate RMS of spectrum of differential arm length in different frequency intervals. It seemed to me that everything is ready in my program to make the three-dimensional theoretical/computational plot (RMS as a function of Q-factors of ETMX and ITMX), but unfortunately Matlab stopped working. It seemed to me that all that was remaining was to run a loop with all possible values of Q-factors. Let's hope that Matlab will be working after the weekend.

Andrey.
  319   Fri Feb 15 10:28:44 2008 ranaUpdateComputersNoise budget code changes

Quote:
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.
  318   Thu Feb 14 17:21:53 2008 Max JonesUpdateComputersNoise 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.
  317   Thu Feb 14 15:05:18 2008 robDAQDMFseisBLRMS 1.1
> 
> Also, for reasons of aesthetics, I changed the data delay from 6 minutes to 5 minutes.  We'll see if that's enough.

5 minutes didn't work.  
  316   Thu Feb 14 15:04:53 2008 robDAQDMFDMF delay

Sometime ago I edited seisBLRMS to keep of track of how long it was taking to write RMS data (that is, the delay between the accelerometer data and the write of the EPICS rms data). Here's a plot of that info, showing how the delay increases over time. I think this indicates a logical flaw in the timing of the seisBLRMS program, which sort of relies on everything running well consistently; this should not be difficult to fix. I'll maybe try increasing the delay to ~10 minutes, and making it relatively inflexible.
Attachment 1: DMFdelay.png
DMFdelay.png
  315   Wed Feb 13 20:37:11 2008 JohnUpdateLSCFibre locking - Fiber
Sam and I observed fringes in the light reflected from the Y arm. These fringes are due to the sidebands and not the carrier. To improve matters we plan to reduce the RF AM and increase our modulation index.
  314   Wed Feb 13 11:41:00 2008 AlbertoUpdateElectronicsSome characterization of the RF Monitor Box (StocMon)
I'm attaching a table with some measurements and the power spectrum from the pd to help evaluate the numbers.

The box output ranges from 0.5V to 2.1V. The coefficient between power and voltage is negative so higher voltage means lower power.

The red numbers are the outputs from each channel at their resonant frequencies. As one can see these are not very well centered on the dynamic range of the power detectors.

The cross coupling seems to be not a problem.

Even if the 166 filter, which handles the smallest of the frequencies and is also the most lossy (for construction reason), mounts a preamplifier, the output is still rather small. this explain also the high bias due to the noise amplification at the maximum power (13dB). A better insertion loss either remaking the filter or re-tuning that one would simplify many problems, i.e. there is not much room in the metal pomona box to fit the amplifier. I might want to consider, after everything else is ready and if I have time before leaving next week, to work on a new 166 filter.
Attachment 1: CircuitCharacterization.png
CircuitCharacterization.png
Attachment 2: alberto.spectrum3.png
alberto.spectrum3.png
  313   Tue Feb 12 16:39:52 2008 robUpdateLockingreport

Did some locking work on DRFPMI on sunday and (with John) on monday nights. So far progress has not been terribly encouraging.

Problems include the DD_handoffs not working and the CARM->MCL handoff not working so well. To get around the DD signals trouble, I decided for now to just ignore 67% of the DD signals. We should be able to run with PRC & MICH on single demod signals, and SRC on a DD signal. This seems to work well in a DRMI state, and it also works well in a DRMI+2ARMs state.

The CARM->MCL handoff actually works, but it doesn't take kindly to the AO path and it doesn't work very stably. I guess this was always the most fragile part of the whole locking procedure, and it's fragility is really coming to light now. Investigation continues.
  312   Tue Feb 12 16:34:07 2008 robDAQDMFseisBLRMS 1.1
The compiled version of seisBLRMS had been running ~2 weeks without crashing as of last night, when I killed it
so it wouldn't interfere with alignment scripts.  I added an EPICS channel C1:DMF-ENABLE, and updated the DMF
executables to check this channel while running.  So far it seems to work.  When you're running alignment acripts,
simply click the DISABLE button on the C1DMF_MASTER.adl screen, and then re-ENABLE when the scripts finish. 
It's not clear why this is necessary though.  Theories include the constant disk access is keeping the
framebuilder busy, reducing its ability to deal with ezcademod commands and DMF programs just flooding the
network with so much traffic that ezcademod-related packets run late and get ignored.

Also, for reasons of aesthetics, I changed the data delay from 6 minutes to 5 minutes.  We'll see if that's enough.
  311   Tue Feb 12 16:18:29 2008 robConfigurationComputer Scripts / Programsautoburt cron moved to op340m

I moved the autoburt cron job from op440m to op340m. For some reason, burtrb requires gcc to run (I gather it uses the C-preprocessor to parse input files), so I had to install that on op340m to get it to work properly.

There are no more cron jobs running on op440m now.
  310   Tue Feb 12 13:53:27 2008 robOmnistructureVACReturn of the RGA

The new RGA head was installed a few days ago. I just ran the RGAlogger script to see if it works, which it does. I also edited the crontab file on op340m to run the RGAlogger script every night at 1:25 AM. It should run tonight.
Attachment 1: RGA-080212.png
RGA-080212.png
  309   Mon Feb 11 22:44:29 2008 robConfigurationDAQChange in channel trending on C1SUS2

I removed the MC2 optical lever related channels from trends, and the SRM POUT and YOUT (as these are redundant if we're also trending PERROR and YERROR). I did this because the c1susvme2 processor was having bursts of un-syncy lateness every ~15 seconds or so, and I suspected this might interfere with locking activities. This behaviour appears to have been happening for a month or so, and has been getting steadily worse. Rebooting did not fix the issue, but it appears that removing some trends has actually helped. Attached is a 50 day trend of the c1susvme2 sync-fe monitor.
Attachment 1: srm_sync.png
srm_sync.png
  308   Mon Feb 11 14:24:19 2008 steveUpdatePEMmore earthquakes
ITMX and ITMY sus damping restored after Baja earthquake 5.1 mag at 10:29 this morning.

The ground preparation for The ITS building is almost finished.
Activity is winding down, however the Baja California_ Mexico earthquake zone
"Guadala Victoria" started acting up on Friday.

http://earthquake.usgs.gov/eqcenter/recenteqsus/Maps/special/California_Nevada_eqs.php
Attachment 1: eqfeb11.jpg
eqfeb11.jpg
  307   Sun Feb 10 21:43:16 2008 robConfigurationIOOMC alignment tweaked

I adjusted the alignment of the free hanging mode cleaner to best transmit the PSL beam.
  306   Sun Feb 10 20:47:01 2008 AlanSummarySUSAll watchdogs tripped
A moderate earthquake occurred at 11:12:06 PM (PST) on Friday, February 8, 2008.
The magnitude 5.1 event occurred 21 km (13 miles) NW of Guadalupe Victoria, Baja California, Mexico.
http://quake.wr.usgs.gov/recenteqs/Quakes/ci14346868.html
  305   Sat Feb 9 13:32:07 2008 JohnSummarySUSAll watchdogs tripped
When I arrived this afternoon the watchdogs had tripped on all optics. I reset them and enabled the coil currents.

I had to adjust the alignment of the mode cleaner to get it to lock.
  304   Sat Feb 9 13:05:48 2008 JohnSummaryIOOPMC camera/ HEPA
I replaced the Gig-E camera on the PMC trans beam. The PZT was close to railing and I wanted to adjust it. I just did a quick job, there is a little scattered light on the image. If Joe is finished with the Gig-E I'll take another look at it.

The HEPA in the PSL table was turned off for some reason. I turned it back on.
  303   Fri Feb 8 17:55:53 2008 joshConfigurationPEMPEM-AS_MIC now in PSL enclosure
I have moved the microphone to the PSL enclosure, hanging near the south (Y) side from a support rod for the overhanging storage area so that it's reasonably close to the PMC. I've fastened it in many places using cable ties to make sure that it won't fall.

Alberto helped me solder together a female BNC-female 3.5 mm stereo adapter so that I can use the DAQ to output through BNC to PC speakers. My plan is do sweep sine output through PC speakers to find the transfer function of sound from outside the enclosure to inside the enclosure and by moving the microphone more centrally over the PSL table, check if there are any strong resonances. Hopefully I can use this technique at other places around the interferometer or measure the effect of installing acoustic foam.
  302   Fri Feb 8 17:09:52 2008 Max JonesUpdateComputersChanges to NoiseBudget
Today I altered the following files

caltech/NB/matlab/utilities/get_dtt_dataset
In DARM_CTRL case I changed the second channel name to DARM_ERR. Messy but it may be effective.

caltech/NB/matlab/noise/getUGF.m
I commented out lines of code specifically pertaining to non-existent DARM_DAQ channel. Marked in
code around approximately line 60.

Please address all comments or concerns to me (williamj(at symbl)caltech.edu). Thank you.
  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...
  300   Wed Feb 6 16:50:47 2008 josephbConfigurationCamerasRegions of Interest and max frame rate
The Snap code has once again been modified such that setting the -l option to 0 will take images as fast as possible. Also, the -H and -W options set the height and width, while in principle the -Y and -X options set the position in pixels of the top edge and left edge of the image. It also seems possible to set these values such that the saved image wraps around. I'll be adding some command checking so that the user can't do this in the near future.

Doing some timed runs, using a -H 350 and -W 350 (as opposed to the full 752x480), 100 images can be saved in roughly 8 seconds, and 1000 images took about 73 seconds. This corresponds to a frame rate of about 12-13 frames per second (or a 12-13 Hz display). The size of this area was sufficient to cover the current PMC transmission beam.

The command line I used was

time ./Snap -l 0 -m 1000 -f 'test' -W 350 -H 350 -Y 50 -X 350 -E 2000

Interestingly enough, there would be bursts of failed frame saves if I executed commands in another terminal (such as using ls on the directory where the files were being stored).

As always, this code is available in /cvs/cds/caltech/target/Prosilica/40mCode/.
  299   Wed Feb 6 09:17:31 2008 steveUpdatePEMIST building construction continoues
The bulldosers at work
Attachment 1: seismic8d.jpg
seismic8d.jpg
Attachment 2: seisioo.jpg
seisioo.jpg
  298   Tue Feb 5 17:39:05 2008 jweinerConfigurationPEMPEM-AS_MIC taken down from AS table, will put in PSL enclosure soon
I took down the microphone that Andrey hung above the AS table his first week in lab. I want to hang the microphone above the PMC to check the effect of acoustic noise on the PMC. The cables were a little more tangled than I thought so I've only taken the microphone down and haven't hung it back up yet, but on Thursday I'll have enough time to carefully put it up inside the PSL and see what I can find out about acoustic noise inside the PSL. I think the microphone should be sensitive enough for the frequencies we're interested in, and I'll hopefully find out if it's sufficient once I put it up in the PSL. The microphone cable and microphone are on top of the PSL for now.
  297   Tue Feb 5 15:32:29 2008 josephbConfigurationCamerasPMC and the GigE Camera
The PMC transmission video camera has been removed and replaced with the GigE GC750 camera for the moment.

A ND4.0 filter has been added in the path to that camera to reduce saturation for the moment.

The old camera has been placed on the elevated section inside the enclosure, and the cable for it is still on the table proper.

The Gige camera is currently running the Snap code on Linux3 with the following command line:

./Snap -E 2000 -l 60 -m 1440 -f './pmc_trans/pmc_trans'

So its going to be taking tiff images every minute for the next 24 hours into the cvs/cds/caltech/target/Prosilica/40mCode/pmc_trans/ directory.

Attached is an example image with exposure set to 2000, loaded into matlab and plotted with the surf command. 2500 microseconds looked like it was still saturating, but this seems to be a good level (with a max of 58560 out of 65535).
Attachment 1: pmc_trans.jpg
pmc_trans.jpg
  296   Mon Feb 4 22:01:57 2008 JohnSummaryLSCFibres auxiliary locking - Fibers
I managed to couple ~75% of the light transmitted from the y arm, through the fibre, back to the SP table. I hoped that this would be a good way to match the beam from the fibre into the arm. Still no flashes. It looks like the cameras just aren't sensitive enough.
  295   Sun Feb 3 05:02:41 2008 ranaUpdatePEMSeism 4 day
Attachment 1: Screenshot.png
Screenshot.png
  294   Sat Feb 2 14:11:27 2008 JohnSummaryComputersOPTLEVmaster screen
I changed the layout of the optlev master screen. The old version is /cvs/cds/caltech/medm/old/C1ASC_OPTLEVmaster080202.adl
  293   Fri Feb 1 17:17:05 2008 JohnSummaryPSLMach-Zender tweaking
I helped Rob adjust the alignment of the Mach-Zender to try and reduce any AM on the laser light. Our goal was to reduce the large offsets in the DD signals.

We reduced the MZ refl from 0.54 to 0.39. We were able to re-lock the mode cleaner without problems. We then centred the WFS heads.

No change in the DD signal offsets.
  292   Fri Feb 1 15:04:54 2008 josephbConfigurationCamerasSnap with looping functionality available
New GiGE camera code is available in /cvs/cds/caltech/target/Prosilica/40mCode/. Currently only runs on Mafalda.

Snap has expanded functionality to continuously loop infinitely or for a maximum number of images set by the user. File names generated with the loop option have the current Unix time and .tiff appended to them. So -f './test' will produce tiff files with format "test1234567.tiff". The -l option sets the number of seconds between images.

"./Snap -l 5 -i -f './test' " will cause the program to infinitely loop, saving images every 5 seconds. Using "-m 10" instead of "-i" will take a series of 10 images every 5 seconds (so taking a total of 50 seconds to run).

It also now defaults to 16-bit (in reality only 10 bit) output instead of 8 bit output. You can select between the two with -F 'Mono8' or -F 'Mono16'.

Use --help for a full list of options.

Note that if you ctrl-c out of the loop, you may need to run ./ResetCamera 131.215.113.104 (or whatever the IP is - use ./ListCameras to determine IP if necessary) in order to reset the camera because it doesn't close out elegantly at the moment.
  291   Fri Feb 1 12:37:39 2008 robUpdateDMFseisBLRMS trends

Here are DV trends of the output of seisBLRMS over the last ~36 hours (which is how long it's been running), and another of the last 2 hours (which show the construction crew taking what appears to be a lunch break).
Attachment 1: seis36hours.png
seis36hours.png
Attachment 2: seis2hours.png
seis2hours.png
  290   Fri Feb 1 10:43:05 2008 JohnUpdateEnvironmentConstruction work
The boys next door have some bigger noisier toys.
Attachment 1: DSC_0433.JPG
DSC_0433.JPG
  289   Thu Jan 31 16:53:41 2008 josephbConfigurationCamerasImproving camera user interface
There's a new and improved version of Snap program at the moment people are free to play with.

Located in /cvs/cds/caltech/target/Prosilica/40mCode/

The program Snap now has a -h or --help option which describes some basic command line arguments. The height (in pixels), width (in pixels), exposure time (in micro seconds), file name to be saved to (in .tiff format), and packet size can all be set. The format type (i.e. pixel format such as Mono8 or Mono16) doesn't work at the moment.

At the moment, it only runs on mafalda.

Currently in the process of adding a loop option which will take images every X seconds, saving them to a given file name and then appending the time of capture to the file name.

After that need to add the ability to identify and choose the camera you want (as opposed to the first one it finds).

Lastly, I've been finding on occassion that the frame fails to save. However if you try again a few seconds later with the exact same parameters, it generally does save the second time. Not sure whats causing this, whether on the camera or network side of things.

I've attached two images, the first at default exposure time (15,000 microseconds) and the second at 1/5th that time (3,000 microseconds).
The command line used was "./Snap -E 3000 -F 'Camera_exp_3000.tiff' "
Attachment 1: Camera_exp_15000.tiff
Attachment 2: Camera_exp_3000.tiff
  288   Thu Jan 31 12:39:14 2008 JohnConfigurationGeneralY arm test mass cameras
I've adjusted the test mass cameras on the y arm to make the beam injected through ETMY more visible.
  287   Wed Jan 30 20:39:31 2008 robUpdateDMFseisBLRMS


In order to reduce the probability of seisBLRMS crashing due to unavailability of data, I edited seisBLRMS.m so that it displays data from 6 minutes in the past, rather than 3. After compiling, this version ran for ~8 hours without crashing. I've killed the process now because it seems to interfere with alignment scripts that use ezcademod, causing "DATA RECEIVING ERROR 4608" messages. These don't cause ezcademod to crash, but so many of them are spit out that the scripts don't work very well. I guess running DMF constantly is just making the framebuilder work too hard with disk access. In the near term, we can maybe work around this by having DMF programs check the AutoDithering bit of the IFO state vector, and just not try to get data when we're running these sorts of scripts.
  286   Wed Jan 30 13:09:55 2008 AndreyUpdateSUSNew results for XARM (pdf)

See attachments: pdf-presentation with plots in "true" axes Q_ETMX and Q_ITMX, and seismic backgound measurement.

Results that were shown a week ago turned out to be not sad at all!
Attachment 1: New_Results_XARM.pdf
New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf
Attachment 2: Accel-Seismic_10AM.pdf
Accel-Seismic_10AM.pdf
ELOG V3.1.3-