ID |
Date |
Author |
Type |
Category |
Subject |
234
|
Thu Jan 10 13:45:52 2008 |
Pkp | Update | Cameras | GLIBC 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 |
steve | Update | SUS | illuminator 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 |
pkp | Update | Cameras | GigE 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 ).
Once again any suggestions welcome. |
237
|
Mon Jan 14 14:41:09 2008 |
steve | Update | SUS | etmy 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 |
tobin | Update | Environment | lots of noise |
They're throwing concrete around at the construction site. |
240
|
Wed Jan 16 14:06:24 2008 |
rob | Update | LSC | monday'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 |
rob | Update | LSC | tuesday'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 |
rana | Update | SUS | ETMY 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 |
rob | Update | LSC | Wednesday'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 |
josephb | Update | Cameras | Working 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 |
Alberto | Update | Electronics | RF 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
|
|
Attachment 2: Chebyshevb.png
|
|
Attachment 3: Chebyshev2b.png
|
|
247
|
Thu Jan 17 20:50:55 2008 |
tobin | Update | General | fiber 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 |
Alberto | Update | Electronics | RF 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
|
|
249
|
Fri Jan 18 15:31:47 2008 |
rob | Update | LSC | Thursday'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 |
Andrey | Update | Computer Scripts / Programs | Matlab 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
|
|
252
|
Tue Jan 22 02:33:45 2008 |
rob | Update | LSC | DRMI 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 |
tobin | Update | ASC | ETMY oplev recentered |
The light wasn't even on the diode. |
254
|
Wed Jan 23 09:27:55 2008 |
steve | Update | | etmy sus damping restored |
Seismis event trips etmy |
Attachment 1: etmysus.jpg
|
|
255
|
Wed Jan 23 11:41:06 2008 |
steve | Update | PEM | sulfur 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 |
steve | Update | PEM | the 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 |
steve | Update | PEM | burned 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 |
Alberto | Update | Electronics | 40 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
|
|
270
|
Fri Jan 25 21:36:40 2008 |
rana | Update | CDS | mDV / 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 |
Andrey | Update | Computer Scripts / Programs | Overnight 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 |
John | Update | General | LSC-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 |
rana | Update | CDS | Seismic 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 |
rana | Update | DMF | seisBLRMS 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 |
rob | Update | DMF | seisBLRMS 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 |
Andrey | Update | SUS | New 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
|
|
Attachment 2: Accel-Seismic_10AM.pdf
|
|
287
|
Wed Jan 30 20:39:31 2008 |
rob | Update | DMF | seisBLRMS |
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 |
John | Update | Environment | Construction work |
The boys next door have some bigger noisier toys. |
Attachment 1: DSC_0433.JPG
|
|
291
|
Fri Feb 1 12:37:39 2008 |
rob | Update | DMF | seisBLRMS 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 |
rana | Update | PEM | Seism 4 day |
|
Attachment 1: Screenshot.png
|
|
299
|
Wed Feb 6 09:17:31 2008 |
steve | Update | PEM | IST building construction continoues |
The bulldosers at work |
Attachment 1: seismic8d.jpg
|
|
Attachment 2: seisioo.jpg
|
|
302
|
Fri Feb 8 17:09:52 2008 |
Max Jones | Update | Computers | Changes 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. |
308
|
Mon Feb 11 14:24:19 2008 |
steve | Update | PEM | more 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
|
|
313
|
Tue Feb 12 16:39:52 2008 |
rob | Update | Locking | report |
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 |
Alberto | Update | Electronics | Some 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 |
John | Update | LSC | Fibre 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 Jones | Update | Computers | Noise 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 |
rana | Update | Computers | Noise 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. |
320
|
Fri Feb 15 22:16:04 2008 |
Andrey | Update | Computers | MATLAB 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. |
321
|
Mon Feb 18 12:04:39 2008 |
Alberto | Update | Electronics | RF 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 |
steve | Update | VAC | rga 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 |
Andrey | Update | SUS | Earthquake 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 |
John | Update | PEM | More seismic in Baja California |
Steve spotted more activity from the same quake.
Reset watchdog on ETMY. |
325
|
Wed Feb 20 11:34:17 2008 |
steve | Update | PSL | laser head temp is up |
MOPA head temp is running at 20.3C now
Nomally it is at 18.5C |
Attachment 1: htempup.jpg
|
|
326
|
Wed Feb 20 16:24:37 2008 |
steve | Update | PSL | the 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
|
|
327
|
Thu Feb 21 09:56:26 2008 |
steve | Update | PSL | the 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
|
|
329
|
Thu Feb 21 19:55:46 2008 |
rana | Update | Electronics | 2 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 |
|