ID |
Date |
Author |
Type |
Category |
Subject |
217
|
Thu Dec 27 18:18:56 2007 |
rana | Update | Computers | Update 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 |
pkp | Update | General | Another 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 |
steve | Update | SUS | etmy 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
|
|
221
|
Thu Jan 3 09:12:59 2008 |
steve | Update | PSL | MZ 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
|
|
Attachment 2: mz40d.jpg
|
|
222
|
Thu Jan 3 09:55:11 2008 |
steve | Update | SUS | etmy sus damping restored |
ETMY watch dog was lost at midnight |
Attachment 1: etmy12h.jpg
|
|
225
|
Fri Jan 4 08:42:03 2008 |
steve | Update | SUS | etmy 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
|
|
Attachment 2: etmy120s.jpg
|
|
Attachment 3: etmysenV.jpg
|
|
226
|
Mon Jan 7 09:01:39 2008 |
steve | Update | SUS | BS sus damping restored |
The BS sus damping was lost at 8am Sunday morning. |
Attachment 1: bssdl.jpg
|
|
227
|
Tue Jan 8 15:20:17 2008 |
Pkp | Update | Cameras | GigE 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 |
fricke | Update | Computers | ethernet 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 |
Go | Update | Treasure | Money in lab |
Go's Desk. |
Attachment 1: DSC_0370.JPG
|
|
232
|
Thu Jan 10 10:38:02 2008 |
steve | Update | SUS | etmy 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 |
steve | Update | SUS | why did the BS move? |
|
Attachment 1: bshopped.jpg
|
|
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
|
|