40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 76 of 341  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  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
  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
Attachment 2: sustrend16d.jpg
  233   Thu Jan 10 12:08:23 2008 steveUpdateSUSwhy did the BS move?
Attachment 1: 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.

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

Attachment 1: RF166Mhz.png
Attachment 2: Chebyshevb.png
Attachment 3: 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).


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.

Attachment 1: 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
  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

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

Attachment 1: 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.

  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
  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
  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
Attachment 2: seis2hours.png
  295   Sun Feb 3 05:02:41 2008 ranaUpdatePEMSeism 4 day
Attachment 1: Screenshot.png
  299   Wed Feb 6 09:17:31 2008 steveUpdatePEMIST building construction continoues
The bulldosers at work
Attachment 1: seismic8d.jpg
Attachment 2: seisioo.jpg
  302   Fri Feb 8 17:09:52 2008 Max JonesUpdateComputersChanges to NoiseBudget
Today I altered the following files

In DARM_CTRL case I changed the second channel name to DARM_ERR. Messy but it may be effective.

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

Attachment 1: eqfeb11.jpg
  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.
  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
Attachment 2: alberto.spectrum3.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.
  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.
  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.
  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.

  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
  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.
  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.
  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.
ELOG V3.1.3-