40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 298 of 329  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  67   Tue Nov 6 10:42:01 2007 robConfigurationIOOmode cleaner locked
Increased the power exiting the PSL by turning the half-wave plate after the MOPA, opened the PSL shutter, and aligned the mode cleaner to the input beam. It wasn't that hard to find the beam with the aperture open all the way on the MC2 camera. The transmitted power is now 2.9 arbitrary units, while the input power is 1.2 arbitrary units. Not sure yet if that's an increase or decrease in efficiency, since no one posted numbers before the vent. Also turned on the input-steering PZTs and saw a REFL beam on the camera.
  69   Tue Nov 6 15:36:03 2007 robUpdateLSCXARM locked
Easily, after resetting the PSL Uniblitz shutters. There's no entry from David or Andrey about the recovery from last week's power outage, in which they could have indicated where the procedure was lacking/obscure. Tsk, tsk.
  70   Tue Nov 6 15:37:34 2007 robConfigurationSUSrampdown script
/cvs/cds/caltech/scripts/SUS/rampdown.pl is now in the crontab for op340m, running every half-hour at 15&45. It checks the suspension watchdog trip levels, and reduces them by 20 if they are above 150.
  78   Wed Nov 7 13:54:44 2007 robConfigurationIOOMode Cleaner transfer function
I performed the same procedure described here, and re-measured the transfer function of the mode cleaner to see the effect of the drag-wiping. The results are attached in a pdf. We don't seem to have done any damage, but the improvements are barely measurable.

WhatThenNow
pole frequency3.789kHz3.765kHz
loss per optic99ppm91ppm
finesse14601470
trans86.7%87.7%
Attachment 1: mctf.pdf
mctf.pdf
  89   Fri Nov 9 17:33:33 2007 robConfigurationPSLISS

The 3.7 MHz is actually on the light. It's the beat between the 29.5 MHz sidebands and the 33.2 MHz sidebands. There are pads in the ISS PCB for a filter to notch this frequency--John is working on it.

I also found a 1.2 ND filter on the lens which focuses the beam on the ISS diodes. I replaced it with a 0.6 ND filter, which brought the ISS DC level (on the screen) up to ~4.2 (it saturates at 5). Once John finishes the filter we should be able to crank up the gain.
  90   Fri Nov 9 21:36:14 2007 robConfigurationPSLFSS
rob, rana

We looked at the FSS a bit today. The most we could get out of it with the gain sliders was a UGF of around 95kHz. After a bit of tweaking the waveplate after the AOM, this got up to ~115kHz. We should be able to get at least 500kHz. This system needs a fair amount of work.
  94   Mon Nov 12 14:09:19 2007 robDAQGeneraltpman dead on fb40m
The testpoint manager was dead on fb40m. I know I re-started it sometime after the power outage, so something must have killed it. If you get an error from DTT like
"diagnostic kernel does not support: testpoints", then log into fb40m as root, check for the tpman with a ps -ef | grep tpman. If it's not there, then run /usr/controls/tpman & and close the terminal window.
  95   Mon Nov 12 15:05:49 2007 robConfigurationPSLFSS

Spent a bit of time fiddling with the FSS again today. In a not-particularly-systematic manner, I raised the input-side of the 21.5MHz PC, adjusted the half-wave plate in front of it, touched up the RC alignment and the alignment onto the transmitted and reflected diodes. This got us a ~15% increase in
transmitted light, and I was able to push the UGF to 140kHz with the common gain slider at 30dB and the FAST gain slider at 22dB. The next options include adjusting the AOM setup, mode matching into the RC, and just increasing the pickoff fraction right from the getgo.
  96   Mon Nov 12 15:18:34 2007 robUpdatePSLISS

After John soldered a 3.7 MHz notch filter onto the ISS board, I took a quick TF and RIN measurement. The out-of-loop RIN is attached, including a dark noise trace, and with the gain slider at 10dB. The UGF is 35kHz with a phase margin of 30deg. John is currently doing a more thorough inspection, and will detail his findings in a subentry.
Attachment 1: ISS.png
ISS.png
  121   Wed Nov 21 14:31:41 2007 robUpdatePSLFSS twiddle

I `tweaked' the FSS path today. Here's what I did:

1) Shut down the FSS autolocker

2) Turn off FSS servo

3) Assume the beam coming back from the AOM is double-first-order, and don't make any changes large enough to lose it.

4) Tweak the alignment of these components to maximize the incident power on the RC reflected diode:

a) PBS before AOM
b) AOM
c) curved mirror after the AOM

5) Translate the AOM such that the beam moves away from the PZT, then when it levels off (no more power gains with movement),
move it back just a little bit so there's a teensy drop in power. This should but the beam as close to the edge as possible,
but whether or not it's the best place is still to be determined.

6) Lock the FSS, and align the mirrors into the frequency reference cavity.

After all this, the RC transmitted power went from .57 to .73 -- probably not a big enough change to account for the missing loop
gain, but we'll know more once the loop gets measured (after Alberto stops hogging the Agilent network analyzer).

Other possible routes include a systematic check of the upstream path (e.g., the Pockels cell) and just increasing the pickoff fraction for the FSS.
  124   Tue Nov 27 15:45:08 2007 robConfigurationPSLFSS loop

It's unclear (to me, at least) what was the end result of the FSS path tweaking before Thanksgiving. Today I measured the open loop gain, and it was still around 100kHz, even with the gain sliders maxed out, but it looked really crappy with a sharp cutoff around the UGF. Then, on a lark, I pushed around the "Input Offset Adjust" slider, which sums an offset into the signal coming out of the mixer. By moving this slider to 7V, I got the UGF to 500kHz with 45 deg of phase. That would be fine, and we could go offset hunting, but the same thing happens if one puts in a large negative value! I don't really understand what's going on, but it seems like weirdness in the electronics. Unfortunately the web interface to the conlog is not running (presumably because the `new' linux1 doesn't have its apache server running) and my command line conlog efforts have been stymied. So, I don't know what the historical settings of this offset are, but zero is definitely not a good setting right now. Here's a snapshot:

FSS
UGF: 500kHz
CG : 24dB
FG : 19dB
input offset: 7V
Phase Adjust: 1.09V
Phase Button: 0
RF Amp Adjust: 7.38V

margins:
phase: 45 deg
gain: 8dB
Attachment 1: FSSsmall.jpg
FSSsmall.jpg
  125   Tue Nov 27 15:47:17 2007 robConfigurationIOOMC loop
After the FSS running pretty quick, I checked the MC loop. I used TPA 1&2.

MC loop
UGF: 70kHz
Input Gain: 29dB
Boost Level: 2
phase: 40 deg
Attachment 1: MCsmall.jpg
MCsmall.jpg
  126   Tue Nov 27 16:18:58 2007 robConfigurationIOOMC loop
Reduced the common gain to 22dB in the mcup script, so that the WFS would not blow the lock. The above measure of the OLG was done without the mcWFS running, so may be a low estimate as compared to when the alignment is perfect.
  134   Wed Nov 28 17:41:34 2007 robUpdatePSLFSS again
I investigated the FSS a bit more today. I looked at the signals coming out of the FSS frequency reference, and saw that both the LO and PC drive were distorted, non-symmetric waveforms. In addition, the LO path had a 3dB attenuator, meaning the mixer was starved. I placed mini-circuits SLP-30 filters in both paths, and now both are nice sine waves. I also took out the 3dB att. With this work, and the CG slider maxed out at 30, the FSS open loop gain (for real this time) goes up to ~250kHz. Still needs more investigation.
  139   Thu Nov 29 11:10:54 2007 robOmnistructureVACRGAlogger sleeping
Without the RGA controller responding, the RGAlogger script just hangs. Rather than fix it, I just put it to sleep by commenting out the line in op440m crontab file. Once we get it running again, we'll move the cronjob to op340m.
  141   Thu Nov 29 15:17:53 2007 robConfigurationPSLISS

I put some ISS beam on the diode on the PSL table. In the previous layout, this was the monitor diode (and it's labeled monitor) but I plugged it into the sensor jack anyways so we can run with the loop closed for now; we can just switch the cables later. The reason the beam was unclear is because someone popped up a flipper mirror which redirects the beam from the ISS into an OSA.

With the ISS gain slider at 15 dB the UGF is around 40kHz.

Why do we have such short cables for the ISS diodes?
  145   Fri Nov 30 11:44:57 2007 robConfigurationElectronicsETMX oplev
In the interests of getting the Xarm alignment script working again, I reset the local damping gains for the test masses to their previous known working values (1), then I noticed that the ETMX oplev was dead. Since the scripts use the oplev motion as a readback for the optic motion, this means the script was basically blindly swinging the optics around. Some monkeying around with swapping HeNe power supplies eventually led to the conclusion that the power strip is funky, since the laser works when plugged into another power strip. Even weirder, the HeNe and the power supply indicator light have some sort of XOR relationship going on. When one works, the other doesn't. Steve will sort out this confusion later; we're good for now.
  146   Fri Nov 30 13:46:50 2007 robConfigurationElectronicsETMX oplev dead again

Quote:
In the interests of getting the Xarm alignment script working again, I reset the local damping gains for the test masses to their previous known working values (1), then I noticed that the ETMX oplev was dead. Since the scripts use the oplev motion as a readback for the optic motion, this means the script was basically blindly swinging the optics around. Some monkeying around with swapping HeNe power supplies eventually led to the conclusion that the power strip is funky, since the laser works when plugged into another power strip. Even weirder, the HeNe and the power supply indicator light have some sort of XOR relationship going on. When one works, the other doesn't. Steve will sort out this confusion later; we're good for now.


Ech. The HeNe quit again. Let's replace it and see what happens.
  175   Thu Dec 6 18:11:15 2007 robHowToComputer Scripts / ProgramsMaking DMF monitors

I was able to use the matlab compiler to compile a version of the linetracker written by Rana, and run the compiled version on mafalda.

I believe I made the necessary edits to our mDV config file so that it should be easy for others to follow these steps:

1) Write the DMF routine you want, as a matlab function (not a script).

2) If it runs correctly in matlab, then from the matlab command line compile
it using the -m flag (i.e., mcc -m myfun.m). You should run the
compiler from the directory where you want the executable to end up (don't use the mDV/extra
directory so it doesn't get all cluttered).

3) prior to running the resulting executable (which should be called simply myfun),
prepend the directories
/cvs/cds/caltech/apps/linux/matlab/bin/glnx86
/cvs/cds/caltech/apps/linux/matlab/sys/os/glnx86/

to the LD_LIBRARY_PATH enviroment variable. These directories must be prepended as the
versions that already exist in /usr/lib don't work; I'm loathe to do this in the cshrc.40m
for fear of later conflicts, so it will need to be done in some sort of shell script which
calls the matlab executable.
  180   Fri Dec 7 14:14:48 2007 robMetaphysicsComputer Scripts / Programstdsread problems on Solaris

tdsread has developed a strange new illness, whereby it cannot read EPICS values from two subsystems at once (e.g., getting an LSC and SUS value simultaneously). I thought this might have something to with the fact that both losepics and iscepics are running on the same box,
but the same thing happens with IOO EPICS records, so that's not the culprit.

This is new behaviour, and it's only happening on the solaris machines. I suspect some ENV/cshrc juju has caused it, as the tdsread executable is the same one from April, and I don't think our EPICS infrastructure has changed otherwise. In the near term we can either try running the scripts on linux, or modify the IFO scripts to not do these types of calls.
  184   Mon Dec 10 13:54:26 2007 robHowToComputer Scripts / ProgramsDon't blame the Matlab compiler

For human error. We should be careful to only run the compiler outside the mDV directory (thus placing the _mcr outside of the range the addpath command in the mdv_config files). Or maybe there's a smarter solution...
  224   Thu Jan 3 12:38:49 2008 robBureaucracyTMISore throat

Quote:

I did not feel anything wrong yesterday, but unfortunately I have a very much sore throat today. I need to drink warm milk with honey and rinse my throat often today. So far I do not have other illness symptomes (no fever), so I hope that this small disease will not last for a long time, but I feel that it is better for me to cure my sore throat today at home (and probably it is safer for others in 40-m).

I took yesterday the book "Digital Signal Processing", so I have it for reading at home.

Hope to see you tomorrow.


I've added a new category--TMI--for entries along these lines.
  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.
  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.
  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
  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.
  263   Fri Jan 25 08:55:26 2008 robConfigurationGeneralChanges to Dataviewer channels (XARM)

As a general rule,


Quote:
clicking random blue buttons chaotically


is not a good problem solving technique. It is thus now explicitly discouraged as an option in the LIGO 40m Lab.
  265   Fri Jan 25 10:14:35 2008 robConfigurationSUSChanges to Dataviewer channels (XARM)

Quote:

2) BAD NEWS. While "clicking the appropriate blue button" on the DAQ MEDM screen,
namely CODAQ_DETAIL,adl screen, I obviously clicked some blue button that I should not have clicked,
and as a result the signal in Dataviewer from the channel "C1:SUS-ITMX_POS" has disappeared (it is now a straight line).


Description of what has happened and of my wrong actions:
I had two channels opened in Dataviewer simultaneously (both "C1:SUS-ETMX_POS" and "C1:SUS-ITMX_POS"),
and after clicking some blue button on CODAQ_DETAIL,adl screen, the signal from "C1:SUS-ITMX_POS" became
a straight line,
while signal from "C1:SUS_ETMX_POS" continued to be a random noise.

I was scared that I made worse for the channels and for Dataviewer, and I started clicking random blue buttons chaotically hoping that it will restore the signal from "C1:SUS-ITMX_POS". Random clicking on arbitrary blue buttons did not return the signal.

As the channel "C1:SUS-ETMX_POS" works normally, I will be measuring Q-factors of ETMX tonight,
but it is obvious that someone else (Rana, Robert,Steve?) needs to restore the correct settings for "C1:SUS-ITMX_POS".

Moreover, as I was clicking chaotically all the blue buttons on CODAQ_DETAIL,adl screen, someone else (Rana, Robert, Steve?) will need to check somehow that I did not destroy signals from some other channels.

I apologize for the negative consequences of my channel adding,

but Rana asked me in the very beginning in September to let others know if I spoil something, so that others would be aware of it and could fix the problem.


I eventually resolved the situation by restarting the c1susvme1 processor, which had somehow got confused by the clicking random blue buttons chaotically. The data acquisition should be working again.
  280   Mon Jan 28 15:11:38 2008 robHowToDMFrunning compiled matlab DMF tools

I compiled Rana's seisBLRMS monitor, and it's now running on mafalda. To start your own DMF tools, here is a procedure:

1) build your tool in mDV, get it working the way you'd like.
2) Make a new directory /cvs/cds/caltech/apps/DMF/compiled_matlab/{your_new_directory} and copy the *.m file there.
3) Make the *.m in your new directory into a function with no args (just add a function line at the top)
4) compile it (from within a fully mDV-configured matlab) with mcc -m -R -nojvm {yourfile}.m at the matlab command line.
5) add a line corresponding to your new tool to the script /cvs/cds/caltech/apps/DMF/scripts/start_all
6) Run the start_all script referenced in part (5).

NB: Steps (4) and (6) must be carried out on mafalda.
  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.
  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.
  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
  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.
  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
  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
  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.
  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.
  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.
  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
  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.  
  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.
  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.
  337   Fri Feb 22 16:47:54 2008 robUpdateElectronicsBaloney
Well I guess Rana didn't study too hard at Professor School, either. If he'd even bothered to actually read John's entry, he might have looked at the RF Out from the HP Analyzer. As it is, this experience so far has been like taking your car to a highly respected mechanic, telling him it's having acceleration problems, and then he takes a rag and wipes some dirt off the hood and then tells you "It's running fine. That'll be 500 bucks."

I make the current score:

Snarkiness: 2
Education:  0



I did RTFM, and it doesn't mention anything about crazy behaviour on the RF Output. So, I set up the analyzer to do a sweep from 500MHz to 1MHz, with output power of 0dBm, and plugged the output directly into the 300MHz scope with the input set to 50 Ohm impedance. The swept sine output looks totally normal from 500Mhz to 150MHz (measuring ~220mVrms below 300MHz -- 0dBm), where it abruptly transitions to a distorted waveform which the scope measures as having a frequency of ~25MHz and with 450mVrms (+6dBm). It then transitions again at some other part of the sweep to a cleaner-looking 25MHz waveform with ~1.2Vrms (+15dBm). See the attached Quicktime movie. The screeching in the background is the PSL door.

With this bizarre behaviour, it's actually possible that even someone who does everything carefully and correctly could break sensitive electronics with this machine. Let's get it fixed or get a new one.

Don't use the HP4195A anymore unless you want broken electronics.


Quote:
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
Attachment 1: bustedHP.mov
  343   Thu Feb 28 12:31:33 2008 robBureaucracyComputer Scripts / ProgramsMDV library does not work at "LINUX 2"

Quote:

While working on Thursday evening with Matlab scripts "dttfft2" and "get_data", I noticed that mDV library does not work at computer "LINUX 2" (the third computer in the control-room if you enter it from the restroom). There are multiple error messages if we try to run "hello_world", "dttfft2" or "get_data". In order to take data from accelerometers, I changed the computer - I was working from "LINUX 3" computer, the most right computer in the control room, but for the future someone should resolve the issue at "LINUX 2". I am not experienced enough to revive the correct work of mDV directory at "LINUX 2".

Andrey.


This turned out to be due to /frames not being mounted on linux2, as a result of a reboot. The issue is discussed in entry 270. I remounted the /frames, and added a line to mdv_config.m to check whether the frames are mounted.
  344   Thu Feb 28 13:04:59 2008 robUpdateVACrga logging working again

Quote:
The rga head and controller are running fine, but the data logging is not.


It should run tonight at 1:25 AM. To get the cron job to work properly on op340m, I had to make wrapper sh script which defines the perl library before calling the actual RGAlogger script.
  346   Thu Feb 28 19:37:41 2008 robConfigurationComputersmultiple cameras running and seisBLRMS

Quote:
1) Mafalda is now connected via an orange Cat5E ethernet cord to the gigabit ethernet switch in rack in the office space. It has been labeled at both ends with "mafalda".

2) Both the GC650M camera (from MIT) and the GC750M are working. I can run the sampleviewer code and get images simultaneously. Unforutnately, the fps on both cameras seems to drop roughly in half (not an exact measurement) when displaying both simultaneously at full resolution.

3)Discovered the Gigabit ethernet card in Mafalda doesn't support jumbo packets (packets of up to 9k bytes), which is what they recommend for optimum speed.

4)However, connecting the cameras through only gigabit switches to Mafalda did seem to increase the data rate anyways, roughly by a factor of 2. (Used to take about 80 seconds to get 1000 frames saved, now takes roughly 40 seconds).

5)Need to determine the bottleneck on the cameras. It may be the ethernet card, although its possible to connect multiple gigabit cards to single computer (depending on the number of PCI slots it has). Given the ethernet cards are cheap ($300 for 20) compared to even a single camera (~$800-1500), it might be worth while outfitting a computer with multiple.


I found the SampleViewer running and displaying images from the two cameras. This kept mafalda's network so busy that the seisBLRMS program fell behind by a half-hour from its nominal delay (so 45 minutes instead of 12), and was probably getting steadily further behind. I killed the SampleViewer display on linux2, and seisBLRMS is catching up.
  347   Thu Feb 28 19:49:21 2008 robUpdateElectronicsRF Monitor (StocMon)


Quote:

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.


I changed the names of these channels to the more appropriate (and informative, as they're coming from the RFAMPD):

C1:IOO-RFAMPD_33MHZ
C1:IOO-RFAMPD_133MHZ
C1:IOO-RFAMPD_166MHZ
C1:IOO-RFAMPD_199MHZ

I also added them in an aesthetically sound manner to the C1IOO_LockMC.adl screen and put them in trends. Along the way, I also lost whatever Alberto had done to make these monitors read zero when there's no light on the diode. It doesn't appear to be written down anywhere, and would have been lost with a reboot anyway. We'll need a more permanent & automatable solution for this.
  355   Tue Mar 4 10:08:21 2008 robUpdateComputersgreen lights unreliable when c0daqctrl down

So far I've tried powering off the framebuilder, power-cycling the RAID (it was showing an error message about bad IDE channel #4), and rebooting the LSC (just for fun). When I reset the LSC, its green light on the RFM_NETWORK screen did not turn red, making all these lights suspect. The iscepics40m process is what controls these red/green lights, so maybe it's gone wonky. It appears to be running however, on c1dcuepics, and it also seems to be functioning correctly in other ways (it's communicating correctly with the LSC).

Update: Alex and Jay came by. The solution was to reset the c0daqctrl processor, which apparently was not done in Rana's rebooting spree. Or maybe it needed to be done last.
  358   Tue Mar 4 23:22:32 2008 robDAQComputersc1susvme1&2 rebooted

I found that some channels from c1susvme1 and c1susvme2 were not being recording by the DAQ (and were not showing up in DV). I rebooted these processors, which fix the problem. If you see other cases of this (signal exactly zero, but not a testpoint problem), just reboot the corresponding processor.
ELOG V3.1.3-