40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 327 of 335  Not logged in ELOG logo
ID Datedown Author Type Category Subject
  428   Fri Apr 18 19:46:08 2008 ranaUpdateASScheck adaptive
I restarted the adaptive code today using 'startass' and 'upass'.
I moved them into the scripts/ASS/ subdirectory.

Things seem OK. With a MU=0.03 and a TAU=0.00001, there is a still
a good factor of 10 reduction of the 3 Hz stack peak from the MC2
drive by doing FF into MC1.

I edited the ASS-TOP screen so that we could see such small numbers. I
also re-aligned the MC SUS to match the input beam (mainly MC3). The
cavity was locking on a TEM10 mode mostly -- we should look in the SUS
OSEM trends to see if MC3 has moved a lot in the last month or so.

Caryn Palatchi (a Caltech undergrad who just started working with us)
illustrated to me today that using even 1000 FIR taps is not very effective
for low frequency noise cancellation if you have a 2048 Hz sample rate. More
precisely, the asymptotic Wiener filter which our 'LMS' algorithm converges
to, can often amplify the noise at frequencies below f_sample/N_taps.

A less obvious thing that she also noticed is that there is almost no cancellation
of the 16.25 Hz bounce mode when using such a short filter. That's because that
mode is fairly high Q: the transfer function from the Z-ACC to the cavity signal
goes through the high-Q vertical suspension resonance; the FF signal we send back
goes through the low-Q horizontal pendulum response only. Therefore the filter
needs to be able to simulate ~100 cycles at 16.25 Hz in order to cancel that peak.

Duh.

The message here is: we need to find a computationally efficient way to do FIR filtering
or its not going to ever be cool enough to help us find the Crab.
Attachment 1: 0052_xray_thm45.jpg
0052_xray_thm45.jpg
  427   Fri Apr 18 16:48:13 2008 AndreyUpdatePEMRain collector of weather station

Today the rain collector of our weather station was cleaned. As a result, we checked that the rain indication on the weather monitor and on the MEDM screens is alive and working properly. I am adding some details about the roof sensors to the wiki-40 page about the weather station. See especially the link "More description of the roof sensors and their interaction with UNIX computers" from the main Weather Station page in wiki-40.

Pictures of the rain collector before (dirty, the opening is fully clogged with dust and dirt) and after (clean opening in the bottom of the bowl) the cleaning are attached.
Attachment 1: DSC_0520--before.JPG
DSC_0520--before.JPG
Attachment 2: DSC_0537--after.JPG
DSC_0537--after.JPG
  426   Fri Apr 18 16:27:04 2008 robUpdateSUSend station sus front-end bug fix

Quote:
installed and started new susEtmx.o and susEtmy.o to fix a problem with ETMY optical lever variables.


But where is the code?
  425   Fri Apr 18 16:02:58 2008 alexUpdateSUSend station sus front-end bug fix
installed and started new susEtmx.o and susEtmy.o to fix a problem with ETMY optical lever variables.
  424   Thu Apr 17 20:17:37 2008 AndreyUpdatePEMTwo issues with our weather station

I encountered two difficulties working with the "Weather Station".

(1) It turns out that there is no indication for "outside humidity" on the "weather monitor" (a small black box located on the north wall of the interferometer). I realized that "outside humidity" is absent in our system when I tried to see the Dataviewer trend and real-time value from the channel "C1: PEM-weather-outsideHumid". It shows impossible number 128%.

It follows from the "Davis" technical documentation that the outside sensor can be of two types: either "External Temperature Sensor" or "External Temperature/Humidity Sensor". I suspect (I do not know for sure) that we have the first type of sensor "external temperature only" and therefore we in principle cannot have information about outside humidity. I propose to Steve to climb to the roof on Friday to resolve this uncertainty looking at the sensor.

(2) I wanted to change the units of pressure from "Pascal" (force/area) to other units, "mbar" for example. For this purpose I need to edit the file "Weather.st" in the directory /cvs/cds/caltech/target/c1pem1 (this file is run on the VME processor "c1pem1"). Unfortunately, when I try to open the file with emacs, I get the message that the file exists but protected from modifications. I do not know how to unblock the file "Weather.st". I need some help with that.

I thought that switching-off the processor "c1pem1" could resolve the issue, so I switched-off the whole crate where the processor "c1pem1" is installed for about 5 minutes, turning the metallic key. As it did not make any difference for the accessibility of the file "Weather.st", I switched-on the crate after 5 minutes. There are other processors besides "c1pem1", so they were turned-off for several minutes earlier today.

Also, I created a new MEDM screen which has information about weather only, a smaller version of the "C0Checklist.adl" MEDM screen. Both screens are now located under the most top-left button "Checklist" of the main MEDM screen.
  423   Thu Apr 17 15:00:59 2008 steveUpdateVACvac controller computer to be replaced
Now that Rosalba is up and running someone should step forward to volunteer for this job.

Old desk top at the Vacuum Rack should be replaced by a functional less old computer so
the vacuum controller can count on an emergency situation. It's only has to be able to run medm
The existing one is dying.
  422   Wed Apr 16 21:11:12 2008 ranaSummaryDAQAA/AI Filters for the DAQ & FE systems
I used Foton to make up some new filters which will be used all over the project in order to downsample/upsample.

There will be 2 flavors:

  • The first one will be a downsampling filter for use in the DAQ system.
    Whenever you specify a sampling rate in the .ini files below the natural rate of the ADC,
    the data will be downsampled using this filter (called ULYAW_0 in the plot). This one was
    designed for flat bandpass and a 'good' bandstop but no care given to the phase shift.

  • The second one will be used in the FE systems to downsample the ADC signal which is often
    sampled at 64 kHz down to something manageable like 2k or 16k. This one was tweaked for
    getting less phase lag in the 'control' band (usually 3x or so below Nyquist).

Here is the associated filter file:
# SAMPLING ULYAW 16384
# DESIGN   ULYAW 0 zpk([0.512+i*1024;0.512-i*1024;2.048+i*2048;2.048-i*2048], \
#                      [515.838+i*403.653;515.838-i*403.653;318.182+i*623.506;318.182-i*623.506;59.2857+i*827.88; \
#                      59.2857-i*827.88],0.988553,"n")
# DESIGN   ULYAW 1 zpk([0.512513+i*1024;0.512513-i*1024;1.53754+i*2048;1.53754-i*2048], \
#                      [200+i*346.41;200-i*346.41;45+i*718.592;45-i*718.592],1,"n")
# DESIGN   ULYAW 2 zpk([0.768769+i*1024;0.768769-i*1024;1.53754+i*2048;1.53754-i*2048], \
#                      [194.913-i*331.349;194.913+i*331.349;53.1611+i*682.119;53.1611-i*682.119],1,"n")
###                                                                          ###
ULYAW    0 21 3      0      0 DAQAA         0.00091455950698073    -1.62010355523604     0.67259370084279    -1.84740554170818     0.99961738977942
                                                                   -1.72089534598832     0.78482029284220    -1.41321371411946     0.99858678588255
                                                                   -1.85800352005967     0.95626992044093     2.00000000000000     1.00000000000000
ULYAW    1 21 2      0      0 FEAA            0.018236566955641    -1.83622978049494     0.85804776530302    -1.84740518752455     0.99961700649533
                                                                   -1.89200532023258     0.96649324616546    -1.41346289594856     0.99893883979950
ULYAW    2 21 2      0      0 ELP             0.015203943102927    -1.84117829296043     0.86136943504058    -1.84722827171918     0.99942556512240
                                                                   -1.89339022414279     0.96048849609619    -1.41346289594856     0.99893883979950
Attachment 1: DAQ_filters_080416.pdf
DAQ_filters_080416.pdf
  421   Wed Apr 16 10:20:01 2008 AndreyUpdateComputersRosalba and linux3

Quote:
There is a new computer in the control room -- its called Rosalba,
in keeping with our naming convention. Its a quad-core machine that
Dmass found for cheap somewhere; we've installed the CentOS on it
that Alex recommended.

Its a 64-bit Linux and so that may cause some problems. Alex has done this
before and so we have some confidence that we can get our regular tools (DTT, Dataviewer)
to run on it.

I have made a new apps tree for all of our future 64-bit Linux machines. So far, there is
a 64-bit firefox and a 64-bit matlab in there. As we start using this machine some more, we
will be forced to install more 64-bit Linux stuff.

We also didn't have enough network cables to run to both linux3 and rosalba. Andrey has decided that we
should not ditch linux3 and so he will run another cable for it tomorrow.


The ethernet cable for linux3 was installed on Wednesday morning. Now linux3 has Internet connection again.
  420   Wed Apr 16 09:47:35 2008 AndreySummaryPEMWeather Station
The weather station is functional again.

The long ethernet Cat5 cable connecting 'WeatherLink' and processor 'c1pem1' was repaired yesterday, namely the RJ45 connector was replaced,
and information about weather conditions is now again continuously being transferred from the 'Weather Monitor' to the control UNIX computers. We can see this information in 'c0Checklist.adl' screen and in Dataviewer.

Below are the two sets of trends for the temperature, wind speed and direction, pressure and the amount of precipitation.

The upper set of trends ("Attachment 1") is "Full Data" in Dataviewer for the 3 hours from 6.30AM till 9.30AM this morning,
and the lower set of trends ("Attachment 2") is "Minute Trend" in Dataviewer for 15 hours from 6.30PM yesterday till 9.30AM this morning.

I also updated the wiki-40 page describing the Weather Station and added to there a description of the process of attaching the RJ45 connector to the end of ethernet Cat5 cable. To access the wiki-40 page about the "weather station" you should go from the main page to "PEM" section and click on "Weather Station".
Attachment 1: Weather-FullData_3hrs.png
Weather-FullData_3hrs.png
Attachment 2: Weather_Trend_15hrs.png
Weather_Trend_15hrs.png
  419   Tue Apr 15 18:44:25 2008 ranaConfigurationComputersRosalba
There is a new computer in the control room -- its called Rosalba,
in keeping with our naming convention. Its a quad-core machine that
Dmass found for cheap somewhere; we've installed the CentOS on it
that Alex recommended.

Its a 64-bit Linux and so that's going to cause some problems. Alex has done this
before and so we have some confidence that we can get our regular tools (DTT, Dataviewer)
to run on it.

I have made a new apps tree for all of our future 64-bit Linux machines. So far, there is
a 64-bit firefox and a 64-bit matlab in there. As we start using this machine some more, we
will be forced to install more 64-bit Linux stuff.

We also didn't have enough network cables to run to both linux3 and rosalba. Andrey has decided that we
should not ditch linux3 and so he will run another cable for it tomorrow.
  418   Tue Apr 8 09:08:54 2008 steveConfigurationPEMweather station disconnected
We can not leave cables in the walkways and go on vacation.
I disconnected the weather station from the DAQ
Every Tuesday is janitor day in the 40m.
We have to give him free space for doing a good job.

Burned toast award goes to Andrey.
Attachment 1: toast.jpg
toast.jpg
  417   Mon Apr 7 18:58:49 2008 steveUpdateGeneralreflectivity of SS304
The reflectivity of stainless steel 304 super polished # 8 was measured the same way as elog entry 409

The reflectivity: 74 +- 1 % from incident angle 10 to 80 degrees
Attachment 1: ss304s8refl.pdf
ss304s8refl.pdf ss304s8refl.pdf
  416   Mon Apr 7 16:42:56 2008 ranaUpdateComputerseLog intermittent
Phil Ehrens restarted Dziban again this morning. Looks like its still crashing each Monday around 8 AM.

Here is the latest suspect:

http://open.itworld.com/5040/reboot-unix-nlsunix-071225/page_1.html
  414   Fri Apr 4 16:54:06 2008 AndreySummaryEnvironmentWeather station is fully alive

After today's trip to the roof of our building the weather station seems to be completely resurrected!

We went to the roof together with Steve Vass, and we discovered that:

(1) Sensors of wind speed, wind direction and the bowl that measures the amount of precipitation do not have any visible defects, so there is no problem with all those sensors even after being outside for seven years.

(2) We discovered that there are cable junctions located on the roof, and those junctions were located close to the rim (edge) of the roof, before the cables go inside of 40-meter lab room. The taping in the place of the junction was not good due to the age, and the connections between the cables were disrupted (cable endings were out of the connectors). Therefore, no signal from the roof sensors could be transferred to the 'Weather Monitor'. It was not wise from the person who installed the weather station to leave the fragile cable connections outside, on the roof, because the length of the cables allowed to locate those three connectors inside of the building.

See the attached PDF-file with pictures.

(3) After the cables were plugged into the connectors, these cable junctions were gently pulled into the inside of the 40-meter interferometer room. These cable junctions should not be located outside of the building!

Immediately after all the above-mentioned steps, the reasonable indications of outside temperature, humidity, pressure, wind speed and direction appeared on the 'Weather Monitor'.

In order to see if there is any problem of communication between the 'Weather Monitor' and UNIX control computers through 'c1pem1', I rolled out two brand new black cat-5 ethernet cables on the floor of the interferometer room (they are on the floor temporarily, the ethernet cable will go from the floor into the ceiling cable tray eventually), connected the two cables together through freshly purchased from Caltech bookstore cable connectors, and thus connected the 'Weather Monitor' to the processor 'c1pem1'.

Result: Now we can see reasonable indications of outside temperature, pressure, amount of precipitation, wind speed and direction on the EPICS screen! Moreover, these indications are changing with time.

As a reminder for everyone: standard atmospheric pressure is about 101kPa, so the indications of pressure as 99900Pa is quite reasonable.

One thing is not clear for me yet: wind speed on the 'Weather Monitor' is fluctuating between 2 and 4 mph, while MEDM EPICS-screen values are fluctuation in the range between 0 and 3mph.

Many thanks to Steve Vass and Alexander Ivanov for their help.
Attachment 1: Work_on_the_Roof.pdf
Work_on_the_Roof.pdf Work_on_the_Roof.pdf Work_on_the_Roof.pdf Work_on_the_Roof.pdf
  413   Thu Apr 3 19:27:50 2008 AndreySummaryPhotosTour for prospective grad students
Last Friday (March 28), there was a tour of 40-meter lab for prospective graduate students.

Rana showed to the prospective students the interferometer. See pdf-attachment with pictures (two pictures of Rana with undergraduates (I took them) and two old pictures which I discovered on the memory card of Nikon d-40, it was not me who took those two last pictures).
Attachment 1: Rana_Lecturing.pdf
Rana_Lecturing.pdf Rana_Lecturing.pdf Rana_Lecturing.pdf Rana_Lecturing.pdf
  412   Thu Apr 3 18:46:04 2008 AndreyConfigurationComputers"Network switch board" and "c1pem1 crate" were touched

While working with the weather station, I did two things that potentially (with a very small probability) might influence the smooth work of other processors/computers.
I did the following on Wednesday, April 2nd, in times between 1PM and 3PM.

(1) I turned off for several seconds and returned into the initial position the switch-key on the rack with computer (processor) 'c1pem1' in order to reboot processor 'c1pem1'. The turning off/on of that key-switch was repeated several times.

(2) I pulled gently the whole "Network-Switch Board" towards me in order to replace an ethernet cat 5 cable going into the board form the processor 'c1pem1'. Some other connections of other ethernet cables might be flimsy, and then other people in 40-meter might have problems with computers other than 'c1pem1'. It should not happen, but in case of extraordinary behaviour of any other computer in our lab, people should check the connectors on the network-switch board. It is located near the middle of Y-arm. See picture.
Attachment 1: Computer_Rack.JPG
Computer_Rack.JPG
  410   Thu Apr 3 18:33:17 2008 AndreySummaryEnvironmentStatus of Weather Station

During the last two days some things related to weather station have been improved.

1) Startup file for the computer (processor) 'c1pem1' was changed so that now 'c1pem1' can be rebooted from "Linux1". Computer 'c1pem1' is responsible for communicating data between 'Weather Monitor' and control UNIX machines. Before April 1st it was impossible to reboot the computer 'c1pem1'. Now 'c1pem1' runs without difficulties.

2) It was determined that some ethernet cables of category "cat 5" were bad. I replaced one short cat 5 cable between 'c1pem1' and 'network-switch board' in the neighboring computer rack, and I still need to replace the internet ending of another long (~20 meters) cat 5 cable after Alex Ivanov will bring the tool for that.

3) 'Weather monitor' and 'WeatherLink' are temporarily moved away from their "nested" positions on the north wall, and they are now in the proximity of processor 'c1pem1'. Thus the signal about "Inside Temperature" goes into 'c1pem1' computer without any additional ethernet cables, and "inside temperature" is correctly displayed on the "Checklist" adl. MEDM screen on the control UNIX machines. The cable with a signal from the roof sensors (which might be dead due their 7-year age) is temporarily disconnected from the 'Weather Monitor'.

Result: 'Weather Monitor' and computer (processsor) 'c1pem1' are alive, they communicate reasonable "Inside Temperature" to the control UNIX-machines.

The fate of the outside sensors is currently unknown, I plan to go to the roof together with Mr. Steve Vass tomorrow and try to determine what should be done with them.

I am also writing (right now) a wiki-40 page which explains what is the "Weather Station" and what is its status.
  409   Wed Apr 2 15:03:51 2008 steveUpdateGeneralreflectivity of black glass
The reflectivity of black glass, shade 12 was supplied by Donald O'Shea
of Emerald Glass Inc., Westlake, OH 44145

The reflectivity of this glass was measured as shown

Old 1064 nm Crysta Laser with poor beam quality was the source.
Attachment 1: bg12refl.pdf
bg12refl.pdf
Attachment 2: bg12refsetup.pdf
bg12refsetup.pdf
  408   Mon Mar 31 14:14:16 2008 robUpdateComputersc1susvme2 status

Quote:
c1susvme2 is getting worse and worse. it won't run for more than ~45 minutes without fatally de-syncing. for now I've turned off c1iovme (which sends the MCL signal) to see if that's causing the problem. next I'll swap the boards for c1susvme1 and c1susvme2 to see if it's the cpu (or maybe the RFM card) itself, rather than the timing/pentek systems.


I swapped the processors for c1susvme1 and c1susvme2. So for now, to startup, you should ssh into c1susvme1 and run the startup.cmd for c1susvme2, and vice versa.
  407   Mon Mar 31 14:01:40 2008 jamieSummaryLSCSummary of DC readout PD non-linearity measurements
From March 21-26, I conducted some measurements of the response non-linearity of some mock-up DC readout photodetectors. The detectors are simple:
Vbias ---
        |
       PD
        |-------- output
     resistor
        |
       ---
        -
This is a description of the final measurement.

The laser current modulation input was given a 47Hz sine wave at 20mV. A constant small fraction of the beam was shown onto the reference detector, and a beam that was varied in DC power level was incident on the test detector. Spectra were taken from both detectors at the same time, 0.25Hz bandwidth, over 100 averages.

At each incident power level on the test detector, the Vpk in all multiples of the modulation frequency were measured (ie. V[i*w]). The difference between the 2f/1f ratio in the test and reference was then calculated, ie:
V_test[2*w]/V_test[1*w] - V_ref[2*w]/V_ref[1*w]
This is the solid black line in the plot ("t21-r21_v_power.png").

The response of a simulated non-linear detector was also calculated based on the Vpk measured at each harmonic in the reference detector, assuming that the reference detector had a purely linear response, ie:
V_nl[beta,2*w]/V_nl[beta,1*w] - V_l[2*w]/V_l[1*w]
these are the dashed colored lines in the plot ("t21-r21_v_power.png").

The result of the measurement seems to indicate that the non-linearity in the test detector is less than beta=-1.

The setup that was on the big optics table south of the laser, adjacent to the mode cleaner, is no longer needed.
Attachment 1: t21-r21_v_power.png
t21-r21_v_power.png
  406   Fri Mar 28 16:18:18 2008 robUpdateComputersc1susvme2 status
c1susvme2 is getting worse and worse. it won't run for more than ~45 minutes without fatally de-syncing. for now I've turned off c1iovme (which sends the MCL signal) to see if that's causing the problem. next I'll swap the boards for c1susvme1 and c1susvme2 to see if it's the cpu (or maybe the RFM card) itself, rather than the timing/pentek systems.
  405   Wed Mar 26 22:26:15 2008 JohnUpdateComputersc1susvme
I removed the fan and tweaked the timing cables to see if they were the source of our problems. I saw no effect. I'm leaving the fan off for the moment to see if that helps. It is on top of the filing cabinet next to my desk.
  404   Wed Mar 26 13:41:53 2008 AndreyHowToSUSModification of ''C1DRIFT_MONITOR''
I learned how to modify the drift-monitor in MEDM so that values on it change colors from green to yellow to red depending how much is the fluctuatioin (deviation) of the value from its mean nominal value.

In order to do this, I used the following eight commands:

tdswrite CHANNEL_NAME.HIHI VALUE
tdswrite CHANNEL_NAME.HIGH VALUE
tdswrite CHANNEL_NAME.LOW VALUE
tdswrite CHANNEL_NAME.LOLO VALUE
tdswrite CHANNEL_NAME.HHSV 2
tdswrite CHANNEL_NAME HSV 1
tdswrite CHANNEL_NAME LSV 1
tdswrite CHANNEL_NAME LLSV 2

where CHANNEL_MAME is the name of the channel the value of which is indicated on the MEDM screen C1DRIFT_MONITOR, for example
C1:SUS-MC1_SUSPOS_INMON, and VALUE is numerical value that I assigned to the channel parameters.

By now I modified nine mode-cleaner channels (POS, PITCH and YAW channels for MC1, MC2 and MC3) and 6 channels for ITMX and ITMY.

Note that as we have problems this week with computer C1SUSVM, namely ''c1susvme2'' is not working, indicators for MC2 in the drift-monitor do not change colors today although they should.

In order to judge which values should be established as reasonable deviations from the average nominal values, I was looking into Dataviewer trends for the channels that are in the drift-monitor.


In the future indicators for channels ETMX and ETMY, BS, PRM, SRM should be modified in complete analogy with what I did already for MC and for ITM. So, I have modified 3*5 = 15 channels, and 3*5 = 15 channels are left for the future.

Note that (as far as I understand) instead of commands "tdswrite" it is absolutely legitimate to use commands "ezcawrite".
  403   Tue Mar 25 16:34:47 2008 robUpdateComputersc1susvme2

Quote:

Quote:
c1susvme2 isn't behaving itself. It keeps getting out of sync and/or giving a red status light.

After going through the usual restart procedures a few times (unsuccessfully) we power cycled the c1susvme & c1sosvme crates. We think everything came back okay.

We still can't get the status and CRC (cyclic redundancy check) to return to normal on c1susvme2. If Alex is around tomorrow please ask him to take a look.


I rebooted it again this morning. The ASS machine is currently not running its process, for whatever reason (someone turn it off?). Let's leave it like this for a day and see how the c1susvme2 does. The other recent change is Steve's install of a cooling fan--maybe that's causing the problem.


Now c1susvme1 is joining the action. Since leaving the ASS off doesn't change anything, we can probably absolve it of blame. I now suspect the 4-pin LEMO cables going from the CLK DRIVER modules to the clock fanout modules. These cables are being squeezed/shaken by Steve's new fan setup, and may have been the culprit all along. John will do some testing to see if they are indeed the problem.
  402   Tue Mar 25 15:56:09 2008 JohnUpdateTreasureAssorted pictures
Some pictures scavenged from the D40.
Attachment 1: D40.pdf
D40.pdf D40.pdf
  401   Tue Mar 25 13:21:25 2008 AndreyUpdateComputersc1susvme2 is not behaving itself again
  400   Tue Mar 25 10:44:24 2008 robUpdateComputersc1susvme2

Quote:
c1susvme2 isn't behaving itself. It keeps getting out of sync and/or giving a red status light.

After going through the usual restart procedures a few times (unsuccessfully) we power cycled the c1susvme & c1sosvme crates. We think everything came back okay.

We still can't get the status and CRC (cyclic redundancy check) to return to normal on c1susvme2. If Alex is around tomorrow please ask him to take a look.


I rebooted it again this morning. The ASS machine is currently not running its process, for whatever reason (someone turn it off?). Let's leave it like this for a day and see how the c1susvme2 does. The other recent change is Steve's install of a cooling fan--maybe that's causing the problem.
  399   Mon Mar 24 20:15:03 2008 JohnSummaryComputersc1susvme2
c1susvme2 isn't behaving itself. It keeps getting out of sync and/or giving a red status light.

After going through the usual restart procedures a few times (unsuccessfully) we power cycled the c1susvme & c1sosvme crates. We think everything came back okay.

We still can't get the status and CRC (cyclic redundancy check) to return to normal on c1susvme2. If Alex is around tomorrow please ask him to take a look.
  398   Mon Mar 24 13:03:54 2008 robUpdateElectronicsHP4195A is back



Quote:
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).


The HP4195A is back from repair. At first, it exhibited exactly the same behaviour for which it was sent in for repair, and which is described above (pillage from entry 337). After speaking with the repair tech on the phone, who tried to imply that the digital scope was tricking us, I plugged the output into our HP8591E spectrum analyzer, just to have firm ammunition to combat the repair guy's looniness. This led to even weirder behaviour, like no output and overload signals on the inputs (with nothing connected). After turning the unit on and off several times, and firmly seating (and screwing in) the DB9 connectors in the back of the unit, it appears to be working properly. Except for a brief glitch as it passes through 150MHz, the swept sine signal now appears normal, both on the scope and in the spectrum analyzer.

Apparently the whole thing is due to a loose connection somewhere in the box, which wasn't actually fixed by the repair, but has at least been temporarily fixed by me stumbling around with a screwdriver and then pushing the power button a couple of times.
  397   Sun Mar 23 10:42:54 2008 ValeraSummaryElectronicsRFAM of the RF stabilization box is measured
I reconstructed Tobin's setup to measure the RFAM after the RF stabilization box in the 166 MHz modulation path.
The setup consisted of the splitter and the mixer followed by the RF low pass filter and the SR560 (gain x100).
The RF level into splitter was 20 dBm. The Mini-Circuits ZLW-3H (17 dBm LO) mixer was used. The LO was taken
straight out of the splitter and the RF path was attenuated by 11 dBm, The DC out of the mixer was 700 mV.
The noise floor was measured with the RF input of the mixer terminated on 50 Ohm. The 45 MHz measurement
in broad band setting looks better than the noise floor at high frequencies. I am not sure what was wrong with
one or both of those measurements. The 9 MHz measurements are above the noise floor.

The RFAM meets the AdvLIGO requirements in the detection band (f > 10 Hz).

The attached zipped files are:
SRS003 9 MHz DC-200 Hz
SRS004 9 MHz DC-26 kHz
SRS006 45 MHz DC-200 Hz
SRS005 45 MHz DC-26 kHz
SRS007 Noise floor DC-200 Hz
SRS008 Noise floor DC-26 kHz
Attachment 1: RFAM.zip
Attachment 2: amplitudenoise.pdf
amplitudenoise.pdf
  396   Sun Mar 23 00:56:42 2008 JohnUpdateLSCMore on 3f
We ended our last attempt at 3f locking concerned about the beam size on PD6. I investigated tonight. The beam was not obviously overfilling the diode and a quick tweak of the steering mirror revealed a decent plateaux. Nevertheless we decided to try a different approach to see if we found the same problems as before on a different diode.

This time our 3f diode was Refl 33. I put a splitter on the output of the diode at the LSC rack sending one half into the usual refl 33 board, the other into refl DD 199 (which is demodulating at 99Mhz).

I got as far as handing off PRC to the 3f signal in lock. More work needed.
  395   Sun Mar 23 00:43:08 2008 mevansHowToGeneralOnline Adaptive Filtering
I wrote a short document about the OAF running on the ASS. Since there is no BURT setup, I put a script in /cvs/cds/caltech/scripts to help with setting initial parameters: upass.
Attachment 1: OnlineAdaptiveFilter.pdf
OnlineAdaptiveFilter.pdf OnlineAdaptiveFilter.pdf OnlineAdaptiveFilter.pdf OnlineAdaptiveFilter.pdf OnlineAdaptiveFilter.pdf OnlineAdaptiveFilter.pdf
  394   Sat Mar 22 22:39:02 2008 mevansSummaryCDSDirect Form 2 filters are bad
Here I show a comparison between the filter algorithm currently used in LIGO (Direct Form II), and an alternative algorithm designed to reduce numerical noise. The input signal is

x = sin(2 * pi * t) + 1e-9 * sin(2 * pi * (fs / 4) * t);

where fs = 16384 is the sample rate. The filter is a 4th order notch at 1Hz (f_poles = f_zeros = 1Hz, Q_poles = 1, Q_zeros = 1e6). It is clear that the DF2 algorithm produces a noise floor that is, for this simple filter, 1e-11 / rtHz smaller than the input drive amplitude (see plots). That should probably be scary given how many second-order-sections we run our signals through. The low-noise form does a somewhat better job. The low-noise algorithm has the same memory and computational requirements as DF2, and our CDS guys have the code in hand. I suggest we start testing soon.

(The code is included below. You will need my Matlab library to run the top level test script.)
Attachment 1: low-noise_filtering.png
low-noise_filtering.png
Attachment 2: low-noise_zoom.png
low-noise_zoom.png
Attachment 3: FiltRT.zip
  392   Fri Mar 21 23:17:47 2008 ranaConfigurationDMFseisBLRMS restarted
I updated the seisBLRMS par file with the new channel names of the accelerometers and the seismometer and then
recompiled the code and restarted it according to Rob's elog entry. It went fine and the seisBLRMS is now back in
action
.
  391   Fri Mar 21 23:15:11 2008 ranaConfigurationPEMRanger SS-1: New Setup
The Ranger seismometer has been in a bad state. Its output had been sent into a SR560 without any termination.

The seismometer is, internally, just a mass on a flexure with a magnet and a pickup coil for readout.
The damping of the system depends on the resistor hooked up across the coil. With the SR560 this is
the 1 Meg input impedance of it and so the mass is undamped.

I installed a 4300 Ohm resistor in there which seems to nearly critically damp it. However, this will not
allow us to reach the ultimate quantum noise limited performance. We will have to analyze the thermal, voltage,
and current noise to get that.

I then also increased the gain from 10 to 100 on the SR560. This should now make the front end noise of the
seismometer/SR560 close to equal to the noise of the PEM ADC.
  390   Fri Mar 21 17:01:21 2008 ranaConfigurationDMFLocale change on Mafalda & seisBLRMS restart
Ever since we moved the accelerometers to be around the MC and changed their names, the seisBLRMS
has not been working. I tried to restart it today after fixing the channel names in the par file
but I ran into a PERL / UBUNTU bug.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_TIME = "en_US.ISO8859-1",
        LC_MONETARY = "en_US.ISO8859-1",
        LC_CTYPE = "en_US.ISO8859-1",
        LC_COLLATE = "en_US.ISO8859-1",
        LC_MESSAGES = "C",
        LC_NUMERIC = "en_US.ISO8859-1",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

I don't know how this crept up or when it started. There were a bunch of fixes on the Ubuntu
forums which didn't work.

In the end I just set the 'unset' environment variables via our cshrc.40m file and this seemed
to make ligotools/perl happy. Lets hope this lasts...I love Linux.
  389   Fri Mar 21 11:54:38 2008 robUpdateVACtp 2 failed

Quote:
Small turbo #2 is the forepump of the maglev.
It failed last night, shut down the maglev and interlock closed V1
Ifo pressure is 20 mTorr now. The Yarm was still locked at 8am this morning.
The PSL beam to MC was blocked just before the output periscope.
The psl mechanial shutter did not work from epic screen.


The PSL mechanical shutter actually did trip last night, greatly confusing me and Rana. Not realizing that the software vacuum interlock had tripped, we manually re-opened the shutter. I'll modify the relevant MEDM screens to indicate when the EPICS interlock trips.
  388   Fri Mar 21 09:02:03 2008 steveUpdateVACtp 2 failed
Small turbo #2 is the forepump of the maglev.
It failed last night, shut down the maglev and interlock closed V1
Ifo pressure is 20 mTorr now. The Yarm was still locked at 8am this morning.
The PSL beam to MC was blocked just before the output periscope.
The psl mechanial shutter did not work from epic screen.
  387   Thu Mar 20 17:45:36 2008 ranaSummaryASSAdaptive Filtering in the ASS system
Over the past couple weeks we (Matt, Alex, Rob, me) have worked on getting an adaptive filter
system working. We wanted to load this system into c1ass to use this processor. The dither alignment
system hasn't been employed here for awhile and so we have just used this box.

The signals are acquired in the PEM ADCU. Alex modified the code there to send the signals over to
the new system. We also get the SUS-LSC_OUT signals from each of the suspensions so that we can
try to minimize them.

The outputs of the adaptive filter go into the unused SUS-MCL inputs of all the suspensions (except
for MC2). In the current setup, we have 6 accelerometers and 1 seismometer around the MC to be used
to demonstrate the principle of the whole thing.

Much more documentation and description of everything is necessary. We'll try to get Matt, Rob, and Alex
to use the elog.
  386   Thu Mar 20 16:06:27 2008 robConfigurationLSCLSC code change

I changed the LSC code again. I noticed that when turning off the LSC (e.g., going from LA to OFF), the cpu time would jump from ~50 to ~80, and irrevocably de-sync all the SUS controllers. This was because turning off the LSC would suddenly zero the inputs to the decimation filters that send information to the ASS box, which for some reason greatly increases the computation time of the iir filter function call. I changed the code so that these inputs are never zeroed. The ASS receives inputs from the LSC all the time now.

I also noticed that the ASS machine was running in ~2400 usec. Yes, 2,400 microseconds. I don't know how long it's been doing that, but I restarted it. Immediately after restart, it ran at 1700 microseconds. After using the "RESET" field in the adaptOnline code, that dropped to ~100 usec. Now it's not doing any adaptive filtering, as I don't know what the good settings are and no-one has been elogging their IFO work the last few days.
  385   Thu Mar 20 15:28:20 2008 steveUpdateVACtp2 's drypump replaced
The fore pump of tp2 was replaced at fore line pressure 998m Torr
  384   Mon Mar 17 18:30:48 2008 mevansConfigurationPEMAdaptive Filtering
It seems that adaptive filtering can achieve results similar to those of the MISO FIR Wiener (entry 369). The adaptive code simulates real-time operation, but uses the same data used by Rana for the Wiener filter. I ran the adaptive filter over the data 100 times to ensure that it was well trained... maybe too well.
Attachment 1: mcacc_adaptive.png
mcacc_adaptive.png
  383   Sun Mar 16 17:03:32 2008 robConfigurationCDSASS code change

I've updated the ass.mdl file in the directory:

/cvs/cds/caltech/users/alex/cds/advLigo/src/epics/simLink/

to get us started in the adaptive PEM noise subtraction.

After several iterations of remote help from Alex, the code compiles and runs, receives signals from the LSC, PEM, and MC2, and communicates with the suspension controllers. I've also adapted the .par file from the code generator, but haven't got the testpoints working with the new ASS code. There are no MEDM screens yet, and Matt's adaptive filter code has not been installed (there's a matrix as a placeholder).

Putting in the adaptive code should be simple, building the MEDM screens tedious, and getting the testpoints working uncertain. I noticed that the new testpoint.par file starts at a different channel number than the previous (working) version, which is strange. I probably have a script somewhere to change all these numbers by a constant offset, but I don't know if that's the actual problem--maybe stuff just needs to be rebooted.

The code receives as input the first 24 channels from the PEM ADCU, the eight suspension control signals from the LSC, and the output of the MCL filter from MC2. It outputs to the MCL filter input of each suspension (except MC2).
  382   Fri Mar 14 16:56:03 2008 DmassBureaucracyComputersNew 40m control machine.
I priced out a new control machine from Dell and had Steve buy it.

GigE cards (jumbo packet capable) will be coming seperately.

Specs:
Quad core (2+GHz)
4 Gigs @ 800MHz RAM
24" LCD
low end video card (Nvidia 8300 - analog + digital output for dual head config)

No floppy drive on this one (yet?)
  381   Fri Mar 14 15:52:07 2008 robConfigurationLSCLSC code change

I've edited the LSC code to send different signals to the ASS box. Now, instead of the previously selected error signals deemed to be acceptable for the Alignment Sensing and Stabalization system, it sends the LSC control signals for each suspension to the ASS box (in its new incarnation as the Adaptive Susurration Subtraction system). These are the signals after the output matrix, and also after the LSC-[SUS] filter modules.
  380   Fri Mar 14 15:06:24 2008 robUpdateComputer Scripts / Programsrouting PEM -> ASS -> SUS_MCL

Quote:

on ASS RFM 1 has PEM signals at

float at 0x100000 has c0dcu1 first ICS110B chan 1
float at 0x100004 has chan 2
etc.

ASS sends to RFM 0

float at 0x100000 goes to PRM MCL
0x100004 to BS MCL
0x100008 to IMTX MCL
0x10000c to ITMY MCL
0x100010 to SRM MCL
0x100018 to MC1 MCL
0x10001c to MC3 MCL
0x100020 to ETMX MCL
0x100024 to ETMY MCL


You can differentiate between RFM 0 and RFM 1 in the simulink model by adding 0x4000000 to the offsets for RFM 1.
  379   Fri Mar 14 14:59:51 2008 josephbConfigurationCamerasComparison between GC650 (CCD) and GC750 (CMOS) looking at ETMX
Attached are images taken of ETMX while locked.

The first two are 300,000 microsecond exposure time, with approximately the same focusing/zoom. (The 750 is slightly more zoomed in than the 650 in these images). The second are 30,000 microsecond exposures. The la

The CMOS appears to be more sensitive to the 1064 nm reflected light (resulting in bright images for the same exposure time). This may make a difference in applications where images are desired to be taken quickly and repeatedly.

Both seem to be resolving individual specks on the optic reasonably well.

Next test is to place both camera on a Gaussian beam (in a couple different modes say 00, 11, and so forth), probably using the PMC.
Attachment 1: ETMX_z2_exp_300000_650.tiff
Attachment 2: ETMX_z2_exp_300000_750.tiff
Attachment 3: ETMX_z2_exp_30000_650.tiff
Attachment 4: ETMX_z2_exp_30000_750.tiff
  378   Fri Mar 14 12:06:29 2008 josephbConfigurationCamerasGC750 looking at ETMX while locked
The GC750 (CMOS) is currently looking at the front of ETMX. Unfortunately, its being routed through a 10Mbit connection (which I will be purchasing a replacement for today), so getting it to send images to Mafalda/Linux 2 or 3 isn't working well, but by using a local gigabit switch and a laptop I can get sufficient speed for full images with the sample viewer.

The attached image is from a full 752x480 reslution with 10,000 microsecond exposure with the X-arm locked. Although it looks like I still need to work on the focusing. Will be switching the GC750 with the GC 650 (CCD) later today and comparing the resulting images.
Attachment 1: ETMX_zoom_exp_10000_750.tiff
  377   Thu Mar 13 18:20:29 2008 JohnUpdateGeneralNew Focus 4003 EOM 29.489MHz
I measured the modulation index as a function of drive power using an OSA. Agrees well with spec of 0.2 rad/V.
  376   Thu Mar 13 13:15:09 2008 aivanovUpdateComputer Scripts / Programsnew sfotware intall, backup files
New:
op440m:40m>ls -alt /cvs/cds/caltech/target/c1susvme[12]/*.o
-rw-r--r-- 1 controls staff 57920 2008-03-13 13:11 /cvs/cds/caltech/target/c1susvme2/losLinux2.o
-rw-r--r-- 1 controls staff 57976 2008-03-13 13:11 /cvs/cds/caltech/target/c1susvme1/losLinux1.o
op440m:40m>ls -alt /cvs/cds/caltech/target/c1isce[xy]/*.o
-rw-r--r-- 1 controls staff 246861 2008-03-13 13:12 /cvs/cds/caltech/target/c1iscey/losEtmy.o
-rw-r--r-- 1 controls staff 246861 2008-03-13 13:12 /cvs/cds/caltech/target/c1iscex/losEtmx.o
op440m:40m>ls -alt /cvs/cds/caltech/target/c0dcu1/*.o
-rw-r--r-- 1 controls staff 63547 2008-03-12 14:57 /cvs/cds/caltech/target/c0dcu1/dcuDma.o


Backups:
op440m:40m>ls -alt /cvs/cds/caltech/target/c1susvme[12]/*.o.13mar08
-rw-r--r-- 1 controls staff 55960 2005-06-21 13:30 /cvs/cds/caltech/target/c1susvme2/losLinux2.o.13mar08
-rw-r--r-- 1 controls staff 55960 2005-06-21 13:30 /cvs/cds/caltech/target/c1susvme1/losLinux1.o.13mar08
op440m:40m>ls -alt /cvs/cds/caltech/target/c1isce[xy]/*.o.13mar08
-rw-r--r-- 1 controls staff 229793 2007-03-08 11:09 /cvs/cds/caltech/target/c1iscex/losEtmx.o.13mar08
-rw-r--r-- 1 controls staff 229793 2007-03-08 11:09 /cvs/cds/caltech/target/c1iscey/losEtmy.o.13mar08
op440m:40m>ls -alt /cvs/cds/caltech/target/c0dcu1/*.o.12mar08
-rw-r--r-- 1 controls staff 60810 2004-09-08 08:47 /cvs/cds/caltech/target/c0dcu1/dcuDma.o.12mar08
ELOG V3.1.3-