40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 2 of 354  Not logged in ELOG logo
ID Date Author Typedown Category Subject
  207   Thu Dec 20 19:10:03 2007 waldmanUpdateOMCStressful reattachment of heater
Photos may follow eventually, but for now here's the rundown. I scraped the heater clean of the thermal epoxy using a clean razor blade. Then I stuffed a small piece of lint free cloth in the OTAS bore and wrapped the OMC in tin foil. With a vacuum sucking directly from the face of the OTAS, I gently scraped the glue off the OTAS aluminum. I wiped both the OTAS and the heater down with an isoproponal soaked lint-free cloth. I put a thin sheen of VacSeal on the face of the heater, wiping off the excess from the edges with a cloth. Then I clamped the heater to the OTAS using 2" c-clamps from the tombstone back to the heater front, making sure the alignment of the OTAS was correct (connector on the absolute bottom, concentric with the OTAS outer diameter). I added a second clamp, then beaded the outside of the joint with a little bit extra VacSeal, just for kicks. I'll leave it covered at least overnight, and maybe for a day or two.

sam
  208   Thu Dec 20 21:57:34 2007 AndreyUpdateComputer Scripts / ProgramsMeasurements in XARM today

Today at 2PM I started a program, it should change the suspension gains in the interval from 1.0 to 3.8 with the step 0.2. Estimated running time is till 3.30AM coming night.

Results will be reported on Friday.

BELOW: ADDITION MADE ON FRIDAY EVENING.

Due to some unforeseen circumstances, I was unable to add results on Friday. I have so far accelerometer spectra only, which I add to this ELOG entry.

I have files with the measurement results, and I will process them after Christmas and add to this ELOG entry. I might not be in the lab on Dec. 24 and 25.
Attachment 1: Accelerom_ETMX.png
Accelerom_ETMX.png
Attachment 2: Accelerom_ITMX.png
Accelerom_ITMX.png
  210   Fri Dec 21 20:32:25 2007 tobinUpdatePhotosGigE camera
I couldn't resist any longer: I plugged in the Prosilica GC 750 GigE camera and took it for a spin. This is the little CMOS camera which sends out video over gigabit ethernet.

There were no difficulties at all in getting it running. I just plugged in the power, plugged in ethernet, and put on a lens from Steve's collection. I downloaded the "Sample Viewer" from the Prosilica website and it worked immediately.

It turns out that "Kirk's" computer has not only a gigabit ethernet card, but a little gigabit ethernet switch. I plugged the camera into this switch. The frame rate is amazing. With the camera under fluorescent lights I thought I saw some wacky automatic gain control, but I think this ~10Hz flicker is aliasing of the 60 Hz room lighting.

I put the camera on the PSL table briefly and tried viewing the image from a laptop over the (54mbs) wireless network. This didn't work so well: you could get a couple frames out of the camera, but then the client software would complain that it had lost communications. It appeared that scattered 1064nm light did show up brightly on the camera image. There is a green ethernet cable currently stashed on the roof of the PSL that appears unused. We can try mounting the gigE CMOS cable in place of one of the CCD video cameras.

I did not try the Linux software.

The camera is currently set up at Kirk's desk, using the cool little tripod Rana got from CyberGuys.

This camera looks very promising! Also, in the test image attached below, a very unusual condition has been documented.
Attachment 1: robs_desk.png
robs_desk.png
  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
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.
  215   Thu Dec 27 12:12:02 2007 pkpUpdate Update 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.
  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
Untitled.png
  217   Thu Dec 27 18:18:56 2007 ranaUpdateComputersUpdate on GigE Camera

Quote:
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
  218   Sun Dec 30 02:36:35 2007 pkpUpdateGeneralAnother update
So I followed suggestions 1 and 3 so far and have started writing up what all needs to be done in order to compile and use the camera. I wrote a program to ping the camera and get its properties and am working on a program to get an image. The reason why I want to write my own programs to do this, is that it will be easier to reuse and also to compile/use in the first place. The programs currently rest in /cvs/cds/caltech/target/Prosilica/ . Unfortunately I will be away for the next couple of days and will have another update on the 2nd.
  220   Thu Jan 3 08:53:55 2008 steveUpdateSUSetmy vs etmx
Rana have corrected sus gain damping setting of ETMY 8 days ago

gain settings: pos, pit, yaw & sd
etmx: 4,2,2,& -16
etmy: 4,2,2,& 50
Attachment 1: sus.jpg
sus.jpg
  221   Thu Jan 3 09:12:59 2008 steveUpdatePSLMZ servo
Here is MZ trend for one year and 40 days.
Now days it runs out of range on the low side.
This is the weakest link in the psl today.
Attachment 1: mz1y.jpg
mz1y.jpg
Attachment 2: mz40d.jpg
mz40d.jpg
  222   Thu Jan 3 09:55:11 2008 steveUpdateSUSetmy sus damping restored
ETMY watch dog was lost at midnight
Attachment 1: etmy12h.jpg
etmy12h.jpg
  225   Fri Jan 4 08:42:03 2008 steveUpdateSUSetmy trips again
ETMY sus damping tripped at 6am this morning
It was reset. We should put an accelerometer to the south end to see
the garbage dumping effect.
Attachment 1: etmy20m.jpg
etmy20m.jpg
Attachment 2: etmy120s.jpg
etmy120s.jpg
Attachment 3: etmysenV.jpg
etmysenV.jpg
  226   Mon Jan 7 09:01:39 2008 steveUpdateSUSBS sus damping restored
The BS sus damping was lost at 8am Sunday morning.
Attachment 1: bssdl.jpg
bssdl.jpg
  227   Tue Jan 8 15:20:17 2008 PkpUpdateCamerasGigE update
[Tobin , Pinkesh]

Finally we got the camera doing something (other than giving out its attributes). The only thing that seems to work so far is a program called AAviewer, which converts the image into an ASCII format and displays it on the screen. If you want to play around with it, log into mafalda (131.215.113.23) via rana.ligo.caltech.edu. Access /cvs/cds/caltech/target/Prosilica/bin-pc/x86/ and there should be a few programs in there, one of which is AAviewer, which requires you to get an IP address (which is 131.215.113.103) for the camera right now. (You can also get the IP information via the ListCameras program). The camera is physically in the 40m near the network rack.

Other programs dont seem to be working and its probably due to the network/packetsize issues. Since linux2 can change its packetsize to a higher number, I will get it to compile on linux2 for now and then give it a shot.
  228   Wed Jan 9 10:47:15 2008 frickeUpdateComputersethernet wiring in office/control room
The electrical people have been here for three days, installing ethernet cables and drops in the 40m office area, in the old conduits where there was power and 10base2. Soon we will have reliable ethernet connections, instead of relying on switches hanging from the ceiling, etc!
  230   Wed Jan 9 20:36:42 2008 GoUpdateTreasureMoney in lab
Go's Desk.
Attachment 1: DSC_0370.JPG
DSC_0370.JPG
  232   Thu Jan 10 10:38:02 2008 steveUpdateSUSetmy damping restored
The IST building onstruction has really started yesterday and continuing today with big heavy ground breaking
machinary. The MC is holding lock and the suspentions are hanging on.

ETMY does not like this.

SUS-MC2_LLPD_VAR monitor is a good indicator of seismic activity on this 12 days plot
Attachment 1: etmysus.jpg
etmysus.jpg
Attachment 2: sustrend16d.jpg
sustrend16d.jpg
  233   Thu Jan 10 12:08:23 2008 steveUpdateSUSwhy did the BS move?
Attachment 1: bshopped.jpg
bshopped.jpg
  234   Thu Jan 10 13:45:52 2008 PkpUpdateCamerasGLIBC Error
So, I have tried to compile the camera files which are in /cvs/cds/caltech/target/Prosilica/examples for the past 2 days now and have been unable to get rid of the following error. (specifically ListCameras.cpp, as it doesnt have any other libraries required, which unnecessarily complicates things)

../../bin-pc/x86/libPvAPI.so: undefined reference to `__stack_chk_fail@GLIBC_2.4'
collect2: ld returned 1 exit status
make: *** [sample] Error 1

I used to get this error on mafalda too, but I had fixed it by installing the latest version of the glibc libraries. Inspite of doing so on linux2, the error still persists. I suspect it had something to do with it being a FC3 machine. My own laptop, which also runs Ubuntu works fine too. The problem with these Ubuntu machines is that they dont let me set the packet sizes to 9 kb which is required by the camera. Linux2 does.

If anyone has any idea how to resolve this issue, please let me know.

Thanks
Pinkesh.
  235   Thu Jan 10 15:04:04 2008 steveUpdateSUSilluminator light effect on BS position
The bs chamber illuminator light was turned on this morning and left on.
Earlier on Rana noticed that the bs moved.
I follwed up to see what happened. I turned off oplev servo and tried to recenter on oplev pd
by adjusting pitch and yaw biases. It did not move. I looked at suspention and realized that the
illuminator was still on. I turned it off and to my amazement the the AP spot started flashing
Attachment 1: bssusilum.jpg
bssusilum.jpg
  236   Fri Jan 11 17:01:51 2008 pkpUpdateCamerasGigE again
So, here I detail all the efforts on the GigE so far

(1) The GiGE camera requires a minimum of 9 kb packet size, which is not available on mafalda or on my laptop ( both of which run Ubuntu and the Camera programs compile there). The programs which require smaller sizes work perfectly fine on these machines. I tried to statically compile the files on these machines so that I could then port them to the other machines. But that fails because the static libraries given by the company dont work.

(2) On Linux2, which lets me set a packet size as high as 9 Kb, it doesnt compile because of a GLIBC error. I tried updating the glibc and it tells me that the version already existing is the latest ( which it clearly is not). So I tried to uninstall GLIBC and reinstall it, but it wont let me uninstall (it == rpm) glibc, since there are a lot of dependencies. A dead end in essence.

Steps being taken

(1) Locally installing the whole library suites on linux2. Essentially install another version of gcc and g++ and see if that helps.
(2) IF this doesnt work, then the only course of action I can take is to cannibalize linux2's GigE card and put it on mafalda. ( I need permission for this Smile ).

Once again any suggestions welcome.
  237   Mon Jan 14 14:41:09 2008 steveUpdateSUSetmy sus damping restored & mz relocked
Tree days trend of MZ HV drift is typical these days.
So as the etmy sus inability to hold damping for longer then 2-3 days.
Attachment 1: etmysus&mzhvtrend.jpg
etmysus&mzhvtrend.jpg
  239   Tue Jan 15 13:15:27 2008 tobinUpdateEnvironmentlots of noise
They're throwing concrete around at the construction site.
  240   Wed Jan 16 14:06:24 2008 robUpdateLSCmonday's locking
rob, tobin, johnnie

We did some locking work monday night, with decent progress. Working in the PRFPMI style, we managed to get through the part of the script that hands off the offset-CARM DOF to the MCL, but were not successful in engaging the AO path.

We also confirmed the problem with tdsread which prevent it from reading from multiple TLS (Three Lettered Subsystems) at the same time. Tobin traced this to a problem with the ezca library which tds uses, but it's not clear how to fix it. For now we just split the tdsread calls so that there are no multiple TLS calls. Tobin will report further on this.
  241   Wed Jan 16 14:09:45 2008 robUpdateLSCtuesday's locking

I got a little further with the locking (PRFPMI) last night, after discovering that the cable going from the CM board to the MC board was unplugged at the MC side. This explains why we weren't able to engage the AO path last night. Tonight, I got up to the point where DARM is handed off to OMC transmission, a step which repeatedly failed.
Eventually I realized that although all the lights are the green, the OMC Trans signal was not being updated in the LSC's memory. I suspect this is because the c1ass machine was powered down. Work continues.
  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
A.pdf
  244   Thu Jan 17 14:13:20 2008 robUpdateLSCWednesday's locking
Incremental progress on locking yet again. This time the handoff of DARM to the OMC worked, and progress halted at handing off control of the common mode to REFL166.
  245   Thu Jan 17 15:11:13 2008 josephbUpdateCamerasWorking on Malfalda
1) I can statically compile the ListCamera code (which basically just goes out and finds what cameras are connected to the network) on Malfalda and use that compiled code to run on Linux2 without a problem. Simply needed to add explicit links to libpthread.a and librt.a.
(i.e. -Bstatic -L /usr/lib/ -lpthread -Bstatic -L /usr/lib -lrt)

With appropriate static libraries, it should be possible to port this code to other linux machines even if we can't get it to compile on the target machine itself.

2)I've modified the Snap.cpp file so that it uses a packet size of 1000 or less. This simply involves setting the "PacketSize" attribute with the built in functions they provide in their library. After un-commenting some lines in that code, I was able to save tiff type images from the camera of up to 400x240 pixels on Malfalda. The claimed maximum resolution for the camera is 752x480, but it doesn't seem to work with the current setup. The max number of pixels seems to about 100 times the packet size. I.e. packet size of 1000 will allow up to 400x240 (96000) but not 500x240 (120,000). Not sure if this is an issue just with snap code or the general libraries used.

3)Will be working towards getting video running over the next day or so.
  246   Thu Jan 17 18:22:14 2008 AlbertoUpdateElectronicsRF Monitor Band-pass Filter
After we finalized the schematic for the RF monitor board based on buffered LC resonators, on Richard Abbott's suggestion to avoid the complication brought in by the fast op-amps, we gave another chance to the a passive configuration of the band-pass filter based on a Chebyshev topology. Rich and Ben gave me an old but very powerful software tool to design that kind of filters and showed me the way to circumvent many hassles in making RF test boards.

I made a test circuit for the 166MHz line (see attached schematic), using tunable inductors. The TF are also attached.
We get more than 20 dB of isolation after 33MHz (with a loss of only few dB at the resonance - it could be less), which is enough for all the other frequencies (33,133,199 MHz) but we would like more for the 166. We are going to add one or two extra orders to the filter.

We also have to understand the spike at about 320Mhz and eventually somehow get rid of it.


Alberto
Attachment 1: RF166Mhz.png
RF166Mhz.png
Attachment 2: Chebyshevb.png
Chebyshevb.png
Attachment 3: Chebyshev2b.png
Chebyshev2b.png
  247   Thu Jan 17 20:50:55 2008 tobinUpdateGeneralfiber coupling
Sam, John, and I matched the beam from an NPRO into a fiber on the SP table today. In doing so we used our GigE camera for a physics application for perhaps the first time, viewing the transmitted mode from the fiber during initial alignment. (I used my laptop running Windows and a 100 megabit switch.)
  248   Fri Jan 18 11:53:50 2008 AlbertoUpdateElectronicsRF Monitor Band-pass Filter
The response is asymmetric and on the left side of the peak, we have at least 33dB within 33Mhz, which is enough for all the frequencies. We probably don't need an higher order filter but just low pass filters in series.

The spike at 320MHz doesn't depend on the circuit board. It's either the cables, their connection, or the splitters.

Note that the frequency of this test circuit has still to be tuned exactly at 166MHz (now it's 149).


Alberto



Quote:
After we finalized the schematic for the RF monitor board based on buffered LC resonators, on Richard Abbott's suggestion to avoid the complication brought in by the fast op-amps, we gave another chance to the a passive configuration of the band-pass filter based on a Chebyshev topology. Rich and Ben gave me an old but very powerful software tool to design that kind of filters and showed me the way to circumvent many hassles in making RF test boards.

I made a test circuit for the 166MHz line (see attached schematic), using tunable inductors. The TF are also attached.
We get more than 20 dB of isolation after 33MHz (with a loss of only few dB at the resonance - it could be less), which is enough for all the other frequencies (33,133,199 MHz) but we would like more for the 166. We are going to add one or two extra orders to the filter.

We also have to understand the spike at about 320Mhz and eventually somehow get rid of it.


Alberto
Attachment 1: Chebyshevb.png
Chebyshevb.png
  249   Fri Jan 18 15:31:47 2008 robUpdateLSCThursday's locking

rob, johnnie, andrey

On Thursday night we got the intereferometer fully locked in a power-recycled FPMI state. The obstacles included the REFL166 phase being wrong by 180 deg (because that's the correct phase for DRMI locking) and getting confused (again) by the "manual" mode dewhite switching at the ETMs. After turning on the dewhites and the MICH correction, we took the noise spectrum below.
Attachment 1: DARMnoise080118.png
DARMnoise080118.png
  251   Mon Jan 21 23:30:03 2008 AndreyUpdateComputer Scripts / ProgramsMatlab Program for Q-factor measurements (XARM -> ITMX and ETMX)

Finally I overcame difficulties with adapting Sonia's Matlab programs for XARM (Sonia's program was for MC),

and now there exists a Matlab program that makes a fit of a ringdown curve and calculates Q-factor for a mirror ITMX.

Specifically, this program allows to measure ringdown, fit it and calculate Q-factor for the ITMX-mirror for a specific value of
"C1:SUS-ITMX_SUSPOS_GAIN".

Attached is a plot of a ringdown curve and its fit for the value 4.0 in channel "C1:SUS-ITMX_SUSPOS_GAIN".

Calculations yield the result Q=3.7+-0.2 for the value 4.0 in channel "C1:SUS-ITMX_SUSPOS_GAIN".

As Robert started 10 minutes ago the long procedure of the whole interferometer locking,
I cannot disturb the interferometer now, so I will measure Q-factors for various combinations of suspension damping gain on Tuesday.

I will also easily modify the program for measuring Q-factors of ETMX-mirror and make measurements with ETMX on Tuesday.

The Matlab scripts are in directory /cvs/cds/caltech/users/rodionov/Q-Factors/
Attachment 1: Example-ITMX_POS_40.png
Example-ITMX_POS_40.png
  252   Tue Jan 22 02:33:45 2008 robUpdateLSCDRMI work

0) The ETMY oplev needs work/centering

1) recentered DRMI oplevs

2) Did some light DRMI locking. Looked at the loops and the DD signals. The PODD signals look flaky; the beam may not be on the diode. MICH and PRC handoffs to DD signals were spotty, but not a total disaster. Changed the PD9 phase by 115 degs. Work continues on the DD_handoff subscript.

3) John says "There are ants everywhere."

4) Andrey is now versed in the arts of decimation.
  253   Tue Jan 22 13:11:03 2008 tobinUpdateASCETMY oplev recentered
The light wasn't even on the diode.
  254   Wed Jan 23 09:27:55 2008 steveUpdate etmy sus damping restored
Seismis event trips etmy
Attachment 1: etmysus.jpg
etmysus.jpg
  255   Wed Jan 23 11:41:06 2008 steveUpdatePEMsulfur smell in 40m
Led - acid car batteries were overcharged in the machine shop next door
and sulfuric acid smell is coming over to the ifo room.

Entry room 103 is specially bad.
  258   Thu Jan 24 11:52:56 2008 steveUpdatePEMthe mud is cleaned up & MOPA shutter is opened
Safety glasses are required again!

I have just opened the mopa shutter.
One janitor came to help with muddy floor.
Rack 1x1 toward ITMX chamber and the south wall of these area
were completely covered by mud. I wiped the floor of bottom of the rack
with towels. The cables were lifted and still should be wiped.

The bottom of LSC rack got less water, only on the west side.

We are ready to bring up the computers.

Thanks to ALL with the clean up, including Alan Rice
who was really helpful.

  264   Fri Jan 25 09:22:21 2008 steveUpdatePEMburned toast award goes to
DYM for collaborating with the enemy.

In order to minimize the number of ants visiting our lab we have to take out side the lab
all food left over and organic waste. If you are eating here do not expect someone else
to clean up after you.

Thanks for your cooperation.
  268   Fri Jan 25 15:53:59 2008 AlbertoUpdateElectronics40 dB from the 3rd order Chebyschev
I managed to tune the 7 knobs in the 3rd order Chebyshev bandpass filter obtaining the tranfer function attached to this entry. We have now 40 dB of attenuation between 166 Mhz and 133 and 199. With this tuning the insertion loss is rather high. We need a better one.


Alberto
Attachment 1: 166MhzElog.png
166MhzElog.png
  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.
  273   Sat Jan 26 02:34:34 2008 AndreyUpdateComputer Scripts / ProgramsOvernight Measuremts in XARM

I am running the program for measuring RMS of peaks in XARM tonight. I just started it, and it will run for about 9 hours until noon on Saturday. Please do not disturb the interferometer. Now the XARM is locked, it should stay locked over the night.

Andrey.
  276   Sat Jan 26 22:00:03 2008 JohnUpdateGeneralLSC-TRY_OUT and ETMY-QPD
In the path from the ETM to the trans PD and QPD at the Y end I have replaced a BS1-1064-10-2037-45P with a polariser. The power falling on these diodes has been reduced. When the arm is locked in its nominal state the transmitted power is now less than 1.

This polariser should serve as an injection point for the auxiliary arm locking. I am attempting to use crossed polarisations to separate this loop from the main arm light.
  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.
  284   Tue Jan 29 14:56:39 2008 robUpdateDMFseisBLRMS 1.0

The seisBLRMS 1.0 program crashed at ~7:20 pm last night, so we didn't get data from overnight. It crashed when framecaching failed. I added
a try-catch-end statement around the call to dttfft2 to let the program survive this, then compiled it and started it on mafalda. After ~45 minutes, the compiled version encountered the same error, and while it didn't crash per se, after 20 minutes it still wasn't able to read data. We may have to dig deeper into the guts of mDV to make this stuff run more robustly.
  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
  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.
  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
ELOG V3.1.3-