ID |
Date |
Author |
Type |
Category |
Subject |
2473
|
Mon Jan 4 17:21:30 2010 |
Jenne | Configuration | IOO | Elusive Mode Matching Solution found! | I think I have finally found a Mode Matching solution for our new Input Mode Matching Telescope! And after looking at the layout diagram with Koji and Raffaele, it seems like all of the optics will fit into the chambers / onto the tables (not true as of last week).
3. RoCMMT1 is -5m
RoCMMT2 is 8m,
with the MMTs 1.89m apart.
This is a 1.6x telescope.
MMT2 is 2.2641m from the PRM
MMT1 is 2m from MC3.
The Condition Number for this optical chain is 89219047.5781.
This layout is very similar to the one that Koji posted on the wiki yesterday: Upgrade09/Optical Layout. The difference is that I want to move MMT1 ~20cm closer to the MC13 table, so just on the other side of the main red beam that goes directly to PRM. There is plenty of space there, so it should be all good. The tricky bit is that the flat steering mirrors fit into things now while they are piezos, but they will be trickier to fit if we make them into Tip Tilts. But I have full faith in Koji's amazing optical table layout skills, that he can make it happen.
Unless there are major objections, I think this is the MMT that we're going to go with. (So speak now or forever hold your peace.) The angle between tilt and translation isn't quite what we'd like it to be (at ~18deg), but it's not too terrible. And we still have 99.5% overlap which is very important. |
Attachment 1: Awesome_MM_Solution.png
|
|
2474
|
Mon Jan 4 17:26:01 2010 |
Mott | Update | General | T & R plots for Y1 and Y1S mirrors | The most up-to-date T and R plots for the Y1 and Y1S mirrors, as well as a T measurement for the ETM, can be found on:
http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/Optics/RTmeasurement
|
2475
|
Tue Jan 5 01:31:09 2010 |
Jenne | Update | WienerFiltering | New Wiener Filters installed in PEM IIR matrix on OAF screen | Using the techniques employed at LLO, and then by Rana here at the 40m a few weeks ago, Wiener filters have been installed on the inputs of all of the PEM IIR channels which are hooked up to the 110B PEM ADCU. Some slight modifications have taken place to the code, and it's all been checked in to the 40m svn.
I have installed the filters into: All 6 Wilcoxon accelerometers, the Ranger seismometer, and one of the Guralps (GUR1). The other Guralp is currently connected through the ASS/OAF machine's ADC, so it's not used in this test. The filters are all labeled "Wiener", and are FM1 in the C1:ASS-TOP_PEMIIR_## filter banks.
The first figure below is the output of the Wiener Filter calculation program. It shows the uncorrected MC_L (black) and the corrected MC_L (red), using the optimal wiener filter. This is as good as we should be able to do with these sensors in these positions.
The second figure is a DTT shot of me trying out the nifty new filters. They seem to maybe do a teensy bit on the microseism, but otherwise it's a bit unremarkable. Hopefully I'll get better subtraction during the day, when the base level for MC_L is higher. Here, Black is uncorrected MC_L, Red is the corrected MC_L, Blue is the actuation channel, and green is an example seismometer channel to illustrate the ground motion at the time.
For posterity, since it's not all in one elog that I can find, the order of operations to install a Wiener Feed Forward filter is as follows:
1. (When you can borrow the IFO) Take a very careful TF of the plant, between your actuation point and your error signal readout. At the 40m, this means between C1:ASS-TOP_SUS_MC1_EXC and C1:IOO-MC_L, since we actuate by pushing on the MC1 coils. At the sites / future 40m, this would be between the HEPI (or STACIS) and the error signal. The limit of how good your Feed Forward can do will depend heavily on how good this TF is. Coherence should be above ~0.95 for all points. Export this data from DTT as a .txt file, using units "Complex (abs/rad)".
2. Run fitMC12MCL.m (or equivalent wrapper file) to fit the transfer function you just took with some Poles and Zeros. Make sure to edit the wrapper file with your new .txt file's name so you're getting a fresh TF (if you've just taken one).
3. (Again, when you can borrow the IFO) Run getMCdata.m (or equivalent) to fetch witness channel data and error signal data. At the 40m, this usually means C1:IOO-MC_L, and witness sensors which are around the MC chambers. This data should be taken at a time when the cavity is locked, but pretty much on it's own. (i.e. probably shouldn't have Common Mode feedback on the MC - so the MC should be locked, but not the full IFO, for example.)
4. Run c1winoiir.m (the main program here, which contains some of these notes). This will take in the TF data you've fit, and the witness channel data you have, and calculate the optimal combination of Wiener filters for your witness channels. It pre-filters your witness data by your TF, then calculates the Wiener filter. The resulting FIR filters are saved in a file.
5. Run firfit.m This will take the FIR Wiener filters you've just created, and convert them conveniently to IIR filters, in a format to be copied directly into Foton. For each witness channel, you'll get the IIR filter in 2 formats: the first is for copying into the Foton .txt file (ex ASS.txt), and the second is for copying into the Foton gui, in the "Command" box on the filter design screen. The "o" at the end of the copy-able filter indicates to Foton that it is a Z-Plane Online filter. Copy filters appropriately (there should be a line preceding each set of SOS filter formats to indicate which channel this Wiener filter is for...these channel names are extracted from your getMCdata.m)
6. Save your Foton file, and update your Coefficients in MEDM. Enable your outputs to actuators, and watch magic happen!
On the To-Do list:
Check the transfer of signal btwn PEMIIR matrix and the 9x1 'matrix' that sends the signals to the SUS inputs. In the SimuLink, the input to the 9x1 matrix is a bundle of 8 numbers (the 8 outputs of the PEMIIR matrix), but it looks like it only pays attention to the first one. Need to figure out how to make it realize that it's a bundle, not a single number.
Also, the OAF up / down scripts don't seem to be working on any of the control room computers. This needs to be checked in to / fixed (but not tonight....) |
Attachment 1: MCwino-FFtest_4Jan10_sameFiltersAsinEPICS.png
|
|
Attachment 2: OAF-FF_test_4Jan10.png
|
|
2476
|
Tue Jan 5 09:18:38 2010 |
Alberto | Omnistructure | Electronics | Universal PDH Box Stored in the RF Cabinet | FYI: I stored the Universal PDH boxes in the RF cabiner in the Y arm. |
2477
|
Tue Jan 5 10:26:32 2010 |
Alberto, Steve | Omnistructure | Environment | Added new wall cable-racks | we hung two new WALL cable racks. One is on the pillar next to the Sp table, the other is next to the PSL computer rack.
To do that we had to drill holes in the wall since the simple screws weren't strong enough to keep them up.
One of the racks, the yellow, is dedicated to 4-pin lemos and other thick cables.
 
|
2478
|
Tue Jan 5 11:00:04 2010 |
rana | Omnistructure | Environment | Added new wall cable-racks |
Quote: |
we hung two new WALL cable racks. One is on the pillar next to the Sp table, the other is next to the PSL computer rack.
|
awesome - I have ordered 5 blue racks so that we can hang power cables. The fat BLUE ones are for fat cables and the orange ones for the coax cables. |
2479
|
Tue Jan 5 13:23:45 2010 |
Alberto | Omnistructure | Environment | turning page | In the lab there are lots of old posters with outdated autocad drawings, or printouts with schematics of old electronics hanging on the walls.
Can we get rid of those and start giving the lab a fresh and modern look? |
2480
|
Tue Jan 5 17:32:59 2010 |
Jenne | Update | WienerFiltering | New Wiener Filters installed in PEM IIR matrix on OAF screen | EDIT 6 Jan 2010: Shouldn't have done this. My bad. The AA32 is on the other PEM matrix because the Adaptive code runs at 64Hz, so there's downsampling, calculating, and upsampling which goes on. The Feed Forward path all runs at 2kHz, the regular rate of the ASS/OAF machine. All of these filters are turned off (although I haven't deleted them from Foton). Since we're focusing on low frequency stuff and trying to get that to do some subtraction, we're not worrying about the junk at higher frequencies just yet.
I have put AA32 filters into the PEMIIR matrix's input filter banks (ie, C1:ASS-TOP_PEMIIR_##), to match the ones that are in the same places in the regular PEM matrix on the OAF screen.
I redid the uncorrected vs. corrected MC_L DTT printout, shown below. You can see that there's less junk at higher frequencies in the Blue (actuation channel) trace, which is good. |
Attachment 1: OAF-FF_test_5Jan10.png
|
|
2481
|
Wed Jan 6 03:44:41 2010 |
Koji | Configuration | IOO | Elusive Mode Matching Solution found! | I am in the way to get a reasonable optical layout.
Please calculate the final results with the following conditions.
"Result" =
- mode overlapping with astigmatism
- alignment matrix (m/rad, rad/rad) for Pitch and Yaw
- alignment orthogonality
- sensitivity of the mode overlapping to the perturbations
* histgram
* individual scan of the optic positions
Optics chain: MC3 - SM1(flat) - MMT1(f=-5m) - MMT2(f=+8m) - SM2(flat) - PRM
Incident angles: SM1 24deg, MMT1 3deg, MMT2 1deg, SM2 44.5deg
Distances:
MC3 HR - SM1: 884mm
SM1 - MMT1: 1058.2mm
MMT1 - MMT2: 1890mm
MMT2 - SM2: 2007.9mm
SM2 - PRM HR: 495.6mm
It has ~200mm deviation from the solution. I can move only MMT1 for final optimization.
Give us the numbers if it can improve the performance.
Note that this move changes SM1-MMT1 and MMT1-MMT2 simultaneously.
Quote: |
I think I have finally found a Mode Matching solution for our new Input Mode Matching Telescope! And after looking at the layout diagram with Koji and Raffaele, it seems like all of the optics will fit into the chambers / onto the tables (not true as of last week).
3. RoCMMT1 is -5m
RoCMMT2 is 8m,
with the MMTs 1.89m apart.
This is a 1.6x telescope.
MMT2 is 2.2641m from the PRM
MMT1 is 2m from MC3.
The Condition Number for this optical chain is 89219047.5781.
This layout is very similar to the one that Koji posted on the wiki yesterday: Upgrade09/Optical Layout. The difference is that I want to move MMT1 ~20cm closer to the MC13 table, so just on the other side of the main red beam that goes directly to PRM. There is plenty of space there, so it should be all good. The tricky bit is that the flat steering mirrors fit into things now while they are piezos, but they will be trickier to fit if we make them into Tip Tilts. But I have full faith in Koji's amazing optical table layout skills, that he can make it happen.
Unless there are major objections, I think this is the MMT that we're going to go with. (So speak now or forever hold your peace.) The angle between tilt and translation isn't quite what we'd like it to be (at ~18deg), but it's not too terrible. And we still have 99.5% overlap which is very important.
|
|
2482
|
Wed Jan 6 16:48:52 2010 |
steve | Bureaucracy | SAFETY | copied NPRO key | We lost our key to the Lightwave 125/6-OPN-PS The key shop just made one look a like that works. |
Attachment 1: nprokey.JPG
|
|
2483
|
Thu Jan 7 14:08:46 2010 |
Jenne | Update | Computers | We haven't had a bootfest yet this week.....so today's the day | All the DAQ screens are bright red. Thumbs down to that. |
2484
|
Thu Jan 7 14:55:36 2010 |
Jenne | Update | Computers | We haven't had a bootfest yet this week.....so today's the day |
Quote: |
All the DAQ screens are bright red. Thumbs down to that.
|
All better now. |
2485
|
Fri Jan 8 10:03:04 2010 |
Alberto | Omnistructure | LSC | SPOB shutter was closed | This morning I found that there was no light on the SPOB PD. I went looking at the photodetector and I found that the shutter in front of it was closed.
I switched the shutter driver from n.c. to n.o. which had the effect of opening it.
I guess we inadvertently closed the shutter with Rana when last week we were tinkering with the ITMY camera. |
2486
|
Fri Jan 8 10:38:35 2010 |
josephb, koji | Update | Computers | RFM and Megatron | Last night, we installed the VMI 5565 RFM card into Megatron. After turning off the watchdogs for the ETMY optic, we disconnected the RFM fiber, and connected it to megatron, then powered it up.
We modified the RCG code to have 3 rfmio blocks, which were reading 0x11a1c0 (ascPit), 0x11a1c4 (ascYaw), and 0x11a1c8 (lscPos). These were connected to the approriate filter module inputs, and we also added grounds to the front of the rfmio blocks (we looked at the ass code which was setup that way, so we just did the same thing). When we started it however, it didn't read properly. If we turned off the input and set and offset, it calculated the output of the filter module correctly, (i.e. just the offset value), but as soon as we turned on the input, it was set to 0, no matter the offset value, which indicated it was reading something correctly.
After this test, the RFM fibers were reconnected to c1iscey, we rebooted c1iscey, and we confirmed that the system was working properly again. We turned the watch dogs back on for ETMY.
|
2487
|
Fri Jan 8 11:43:22 2010 |
josephb, alex | Update | Computers | RFM and Megatron | Alex came over with a short RFM cable this morning. We used it to connect the rfm card in c1iscey to the rfm card megatron
Alex renamed startup.cmd in /cvs/cds/caltech/target/c1iscey/ to startup.cmd.sav, so it doesn't come up automatically. At the end we moved it back.
Alex used the vxworks command d to look at memory locations on c1iscey. Such as d 0xf0000000, which is the start of the rfm code location. So to look at 0x11a1c8 (lscPos) in the rfm memory, he typed "d 0xf011a1c8". After doing some poking around, we look at the raw tst front end code (in /home/controls/cds/advLigo/src/fe/tst), and realized it was trying to read doubles. The old rts code uses floats, so the code was reading incorrectly.
As a quick fix, we changed the code to floats for that part. They looked like:
etmy_lsc = filterModuleD(dsp_ptr,dspCoeff,ETMY_LSC,cdsPciModules.pci_rfm[0]? *(\
(double *)(((void *)cdsPciModules.pci_rfm[0]) + 0x11a1c8)) : 0.0,0);
And we simply changed the double to float in each case. In addition we changed the RCG scripts locally as well (if we do a update at some point, it'll get overwritten). The file we updated was /home/controls/cds/advLigo/src/epics/util/lib/RfmIO.pm
Line 57 and Line 84 were changed, with double replaced with float.
return "cdsPciModules.pci_rfm[0]? *((float *)(((void *)cdsPciModules.pci
_rfm[$card_num]) + $rfmAddressString)) : 0.0";
. " *((float *)(((char *)cdsPciModules.pci_rfm[$card_nu
m]) + $rfmAddressString)) = $::fromExp[0];\n"
This fixed our ability to read the RFM card, which now can read the LSC POS channel, for example.
Unfortunately, when we were putting everything the way it was with RFM fibers and so forth, the c1iscey started to get garbage (all the RFM memory locations were reading ffff). We eventually removed the VME board, removed the RFM card, looked at it, put the RFM card back in a different slot on the board, and returned c1iscey to the rack. After this it started working properly. Its possible in all the plugging and unplugging that the card somehow had become loose.
The next step is to add all the channels that need to be read into the .mdl file, as well as testing and adding the channel which need to be written.
|
2488
|
Fri Jan 8 15:40:14 2010 |
josephb, alex | Update | Computers | RFM and RCG | Alex added a new module to the RCG, for generating RFMIO using floats. This has been commited to CVS. |
2489
|
Fri Jan 8 18:20:12 2010 |
steve | Metaphysics | Treasure | Rob now can concentrate on his thesis | We are celebrating Rob's promotion to thesis poetry. These pictures were taken on December 9, 2009
Rob has finished all his measurements in the lab and is officially well prepared to graduate.
 
|
2490
|
Fri Jan 8 20:13:49 2010 |
Alberto, JoB | Configuration | Computers | The 40m Kaiser Permanent Reboot Marathon | This morning after Alex and Jo's tinkering with Megatron the RFM network crashed and it brought down also some computers. The effect was that it was not possible to lock the mode cleaner anymore.
A few computers crashed and things didn't come back to their origianl state.
After an endless day of rebooting and fixing problems with the single front ends (in particular with c1susvme1), eventually the mode cleaner got locked again.
Among my weapons I also used the Nuclear Option (TM).
Maybe I'll include more details in a future elog entry.
Anyway, in the end I burtrestored everything to Jan 8 2009 at 9:00.

|
2491
|
Sat Jan 9 09:47:03 2010 |
Alberto | Update | LSC | Problems trying to lock the arms | This morning I've been having problems in trying to lock the X arm.
The X arm's filter FM6 in the LSC screen starts blinking as it was halfloaded. Then the transmitted power drops from 1 to ~0.5 and eventually the arm loses lock.
To me it looked like a computer related issue. So I decide to reboot C1ISCEX by powercycling it.
That doesn't seem to have solved the problem. The X arm can get locked but TRX slowly moves between 0.2 and 1. |
2492
|
Sat Jan 9 11:07:30 2010 |
Alberto | Update | LSC | Problems trying to lock the arms |
Quote: |
This morning I've been having problems in trying to lock the X arm.
The X arm's filter FM6 in the LSC screen starts blinking as it was halfloaded. Then the transmitted power drops from 1 to ~0.5 and eventually the arm loses lock.
To me it looked like a computer related issue. So I decide to reboot C1ISCEX by powercycling it.
That doesn't seem to have solved the problem. The X arm can get locked but TRX slowly moves between 0.2 and 1.
|
The X arm is now locked with TRX stable at ~1.
I think earlier on today I was having problems with running the alignment scripts from op540. Now I'm controlling the IFO from Rosalba and I can easily and stably lock all degrees of freedom.
I needed the X arm to be locked to align the auxiliary beam of the AbsL experiment to the IFO. To further stabilize TRX I increased the loop gain from 1 to 1.5.
Now the auxiliary beam is well aligned to the IFO and the beat is going through the PRC. I'm finally ready to scan the recycling cavity.
I also changed the gain of the PRC loop from -0.1 to -0.5. |
2493
|
Sat Jan 9 15:02:01 2010 |
Alberto | Update | ABSL | PRC scanning | I scanned the PRC in the frequency range of 30-60 MHz, untill the PLL lost lock. But everything is working fine.
The PRC remained lock for all time, with SPOB at ~1000.
I'm leaving the lab now, planning to come back tomorrow.
I turned the flipping mirrors down and closed the mechanical shutter of the auxiliary NPRO. |
2494
|
Sun Jan 10 13:32:09 2010 |
Haixing | Update | SUS | transfer function measurement of the quadrant maglev circuit | I have assembled the circuit and the control box for the quadrant magnetic levitation yesterday. The final setup is shown
in the figure below:
 
Due to my carelessness, I I connected the wrong ends of the power supply. I damaged 4 op-amp and one voltage
regulator during this assembly. This stupid mistake spent me several hours to fix, and I got a bitter lesson;-(
Afterwards, I replaced those op-amps and reconnected the power supply . Kiwamu helped me and we measured
the transfer function of this circuit. The transfer function agrees with the specification in the schematics which
has a integrator below 1 Hz and a differentiator from 5 to 20 Hz. The bode plot for the measured transfer function
is the following:


Today I tested the photodetector parts and found that there is a mysterious oscillation. Whenever I connect the
photodector input A of the circuit (as indicated in the figure below),

the output of the op-amp has a 500k Hz oscillation shown up in the oscilloscope.This happens even A is disconnected from
the photodetector and connected to an open end wire. I don't know how to eliminate it, and its amplitude is so large (peak to
peak is around 2.5 V) which completely dominates the photodetector output. Does anybody has some ideas? Thanks.

|
2495
|
Sun Jan 10 15:47:26 2010 |
Koji | Update | SUS | transfer function measurement of the quadrant maglev circuit | 1. Why do all of the BNCs have no GND connection? Each should have the individual cables to the ground. Each signal line and the corresponding ground line should be twisted together.
2. This looks the (usual) oscillation of the V-I conversion stage but I can't tell anything as I don't have the circuit diagram of the whole circuit.
3. In a certain case, putting some capacitance at the feedback may help. Read P.11 of the data sheet of LT1125. Try to put some capacitors from 20pF to some larger one whether it changes the situation or not. I suppose the bandwidth of your sensor can be ~1kHz. So putting a capacitance less than 10nF still has no effect to the servo. |
2496
|
Sun Jan 10 16:05:51 2010 |
Alberto | Omnistructure | Environment | Lab Thermostats Temperature Lowered by 1 deg F | Rana noticed that recently the temperature inside the lab has been a little bit too high. That might be causing some 'unease' to the computers with the result of making them crash more often.
Today I lowered the temperature of the three thermostats that we have inside the lab by one degree:
Y arm thermostat: from 71 to 70 F
X arm thermostat: from 70 to 69 F
Aisle thermostat: from 72 to 71 F.
For the next hours I'll be paying attention to the temperature inside the lab to make sure that it doesn't go out of control and that the environment gets too cold. |
2497
|
Sun Jan 10 16:50:34 2010 |
Haixing | Update | SUS | transfer function measurement of the quadrant maglev circuit |
Quote: |
1. Why do all of the BNCs have no GND connection? Each should have the individual cables to the ground. Each signal line and the corresponding ground line should be twisted together.
2. This looks the (usual) oscillation of the V-I conversion stage but I can't tell anything as I don't have the circuit diagram of the whole circuit.
3. In a certain case, putting some capacitance at the feedback may help. Read P.11 of the data sheet of LT1125. Try to put some capacitors from 20pF to some larger one whether it changes the situation or not. I suppose the bandwidth of your sensor can be ~1kHz. So putting a capacitance less than 10nF still has no effect to the servo.
|
1. They are all connected to the box which has a single connection to the board ground. If I connect each of them to the ground, there would be many small loops
of ground. Of course, I should have replaced all the connectors such that the they are disconnected to the box as point out by Robert.
2. The oscillation disappears after I add 5 nF capacitor in parallel to the existing resistor. Thank you very much for pointing this out. |
2498
|
Sun Jan 10 17:15:25 2010 |
Koji | Update | SUS | transfer function measurement of the quadrant maglev circuit | 1. Yes. That is the bad. You should eventually replace the BNCs to the isolated ones.
2. OK. I like to emphasize again that everyone works on electronics should read data sheets more carefully and seriously because they have many important practical instructions to exploit full performance of the components.
Quote: |
Quote: |
1. Why do all of the BNCs have no GND connection? Each should have the individual cables to the ground. Each signal line and the corresponding ground line should be twisted together.
2. This looks the (usual) oscillation of the V-I conversion stage but I can't tell anything as I don't have the circuit diagram of the whole circuit.
3. In a certain case, putting some capacitance at the feedback may help. Read P.11 of the data sheet of LT1125. Try to put some capacitors from 20pF to some larger one whether it changes the situation or not. I suppose the bandwidth of your sensor can be ~1kHz. So putting a capacitance less than 10nF still has no effect to the servo.
|
1. They are all connected to the box which has a single connection to the board ground. If I connect each of them to the ground, there would be many small loops
of ground. Of course, I should have replaced all the connectors such that the they are disconnected to the box as point out by Robert.
2. The oscillation disappears after I add 5 nF capacitor in parallel to the existing resistor. Thank you very much for pointing this out.
|
|
2499
|
Sun Jan 10 23:22:56 2010 |
Jenne | Summary | General | Scattering Measurements of 35W Beam Dumps | On Friday, Rana and I measured the scatter coming from the 35W beam dumps.
(These are the ones with big aluminum heat sinks on the back that kind of look like little robots with 2 legs...inside the horn is a piece of polished silicon at Brewster's Angle.)
SETUP:
For the measurement, we used the Scatterometer setup at the 40m on the small optical table near MC2.
We used a frequency of 1743 Hz for the Chopper, and this was also used as the reference frequency for the SR830 Lock-In Amplifier.
The settings on the Lock-In were as follows:
Input A
24dB/octave
AC coupled
Floating input
"Low Noise"
Time Constant = 1sec
'Scope reading Output A, Output A set to 'Display', and A's display set to "R" (as in magnitude).
Sensitivity changed throughout the experiment, so that's quoted for each measurement.
MEASUREMENTS:
White Paper Calibration - white paper placed just in front of Beam Dump. Sensitivity = 500microVolts. Reading on 'scope = 7V
Laser Shuttered. Sensitivity = 500microVolts. 'scope reading = 9mV.
Black Glass at Beam Dump location. Sensitivity = 500microVolts. Reading on 'scope = 142mV. (DON'T touch the glass....measure the same setup with different sensitivity)
Black Glass at Beam Dump location (Not Touched since prev. measurement). Sensitivity = 10microVolts. Reading on 'scope = 6.8V
Laser Shuttered. Sensitivity = 10microVolts. 'scope Reading = 14mV +/- 10mV (lots of fluctuation).
Black Glass Wedge Dump at Beam Dump location. Sensitivity = 10microVolts. 'scope = 100mV.
Beam Dump with original shiny front plate. Sensitivity = 10microVolts. 'scope railing at 11V
Beam Dump with front plate removed. Sensitivity = 10microVolts. 'scope reading = 770mV
Beam Dump, no front plate, but horn's opening surrounded by 2 pieces of Black Glass (one per side ~1cm opening), BG is NOT flush with the opening...it's at an angle relative to where the front plate was. Sensitivity = 10microV. 'scope = 160mV +/- 20mV.
Beam Dump, no front plate, only 1 piece of Black Glass. Sensitivity = 10microV. 'scope reading = 260mV.
Beam Dump, no front plate, 2 pieces of Black Glass, normal incidence (the BG is flush with where the front plate would have been). Sensitivity = 10microV. 'Scope reading = ~600mV
CALIBRATION:
Using our calibration numbers (Black Glass measured at 2 different sensitivities, not touching the setup between the measurements), we can find the calibration between our 2 different sets of measurements (at 500microV and 10microV), to compare our Beam Dump with regular white paper.
BG at 500uV was 142mV. BG at 10uV was 6.8V. 6.8V/0.142V = 47.9
So the white paper, which was measured at 500uV sensitivity, would have been (7V * 47.9) = 335 V in 10uV sensitivity units.
This is compared to the BG wedge dump at 10uV sensitivity of 100mV, and the Beam Dump reading of 770mV, and the Beam Dump with-black-glass-at-the-opening reading of 160mV.
So our Silicon/Steel horn dump is ~8x worse than a Black Glass wedge and (335 / 0.77) = 435x better than white paper.
We used regular white paper as a calibration because it has a Lambertian reflectance. For some general idea of how to do these kinds of scatter measurements, you can look at this MZ doc.
Assuming that our white paper had a BRDF of (1/pi)/steradian, we can estimate some numbers for our setup:
Sensitivity (signal with the laser shuttered) = (0.02 / 335 / pi) = 2 x 10^-5 / sr. This is ~3x worse than the best black glass surfaces.
Our wedge = (0.1 / 335 / pi) = 1 x 10^-4 / sr. Needs a wipe.
Our Silicon-Steel Horn = (0.75 / 335 / pi) = 7 x 10^-4 / steradian.
Our measurements were all made at a small angle since we are interested in scatter back along the incoming beam. We were using a 1" lens to collect the scatter onto a PDA55. The distance from the beam to the center of the lens was ~2" and the detector's lens was ~20" from the front of the horn. So that's an incident angle of ~3 deg.
CONCLUSIONS:
* It seems that any front plate other than Black Glass is probably worse than just having no front plate at all.
* If we put in a front plate, it shouldn't be normal to the incident beam. Black Glass at normal incidence was almost at the same level as having no front plate. So if we're going to bother with a front plate, it should be about 30deg or 40deg from where the original front plate was.
* No front plate on the Dump is about 7x a Black Glass wedge dump.
* The silicon looks like it might have some dust on it (as well as the rest of the inside of the horn). We should clean everything. (Maybe with deionized nitrogen?)
* We should remeasure the Beam Dump using polished steel at a small (30-40deg) angle as the front plate.
ATTACHMENTS:
* Photos taken with the Olympus camera, which has its IR blocker removed.
* In the photo you can see that we have a lot of reflection off of the horn on the side opposite from the silicon.
* The 2nd picture is of the scatterometer setup. |
Attachment 1: P1090014_copy.JPG
|
|
Attachment 2: ScatterometerSetup.png
|
|
2500
|
Mon Jan 11 09:18:44 2010 |
Alberto | Update | General | Measurement running | I'm working on the AbsL experiment. A measurement which involved the PRC locked is running at the moment.
Please make sure of not interfering with the interferometer until it is done. Thank you. |
2501
|
Mon Jan 11 10:01:06 2010 |
Alberto | Omnistructure | Environment | Lab Thermostats Temperature Lowered by 1 deg F |
Quote: |
Rana noticed that recently the temperature inside the lab has been a little bit too high. That might be causing some 'unease' to the computers with the result of making them crash more often.
Today I lowered the temperature of the three thermostats that we have inside the lab by one degree:
Y arm thermostat: from 71 to 70 F
X arm thermostat: from 70 to 69 F
Aisle thermostat: from 72 to 71 F.
For the next hours I'll be paying attention to the temperature inside the lab to make sure that it doesn't go out of control and that the environment gets too cold.
|
Today the lab is perceptibly cooler.
The temperature around the corner is 73 F. |
2502
|
Mon Jan 11 11:06:53 2010 |
Alberto | Update | ABSL | Measurement running |
Quote: |
I'm working on the AbsL experiment. A measurement which involved the PRC locked is running at the moment.
Please make sure of not interfering with the interferometer until it is done. Thank you.
|
I'm done for the moement.
I realized that I need to take into account somehow the DC power from the photodiode. By now the measurement of the transmitted beat's power is affected by the total power circulating inside of the PRC and thus it depends on the cavity alignment.
I closed the laser shutter and turned down the flipping mirrors.
I'm planning to restart measuring by 2.30pm today. Till then the interferometer is available. |
2503
|
Mon Jan 11 14:16:59 2010 |
Jenne | Update | PEM | Gur2 cables reconnected to the PEM ADCU | So that we can use both Guralps for Adaptive stuff, and so that I can look at the differential ground motion spectra, I've reconnected the Guralp Seismometers to the PEM ADCU, instead of where they've been sitting for a while connected to the ASS ADC. I redid the ASS.mdl file, so that the PEM and PEMIIR matricies know where to look for the Gur2 data. I followed the 'make ass' procedure in the wiki. The spectra of the Gur1 and Gur2 seismometers look pretty much the same, so everything should be all good.
There's a problem with DataViewer though: After selecting signals to plot, whenever I hit the "Start" button for the realtime plots, DataViewer closes abruptly.
When I open dataviewer in terminal, I get the following output:
allegra:~>dataviewer
Warning: communication protocol revision mismatch: expected 11.3, received 11.4
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: communication protocol revision mismatch: expected 11.3, received 11.4
msgget: No space left on device
allegra:~>framer4 msgget:msqid: No space left on device
Does anyone have any inspiration for why this is, or what the story is? I have GR class, but I'll try to follow up later this afternoon. |
2504
|
Mon Jan 11 16:59:14 2010 |
Alberto | Update | ABSL | Interferometer Busy | I'm currently running a measurement on the PRC.
Please don't interfere with the IFO until it is done. Talk with Alberto if you've been intending to work inside the lab.
Thank you. |
2505
|
Mon Jan 11 19:36:13 2010 |
Alberto | Update | ABSL | Measurement running | Leaving for dinner. Back in ~1hr.
I left a measurement running. Please don't interfere with it till I'm back. Thanks. |
2506
|
Mon Jan 11 21:49:17 2010 |
Jenne | Update | ABSL | Measurement running |
Quote: |
Leaving for dinner. Back in ~1hr.
I left a measurement running. Please don't interfere with it till I'm back. Thanks.
|
Per Alberto's instructions, I have closed the shutter on his laser so that the Adaptive Team can play with the Mode Cleaner. |
2507
|
Tue Jan 12 09:14:52 2010 |
steve | Summary | General | Scattering Measurements of 35W Beam Dumps |
What was the power level, polarization and beam size at beam trap? |
2508
|
Tue Jan 12 09:37:05 2010 |
Alberto | Update | ABSL | IFO available | I finished measuring the AbsL for this morning. The IFO is again available.
Please don't mess up with the interferometer though. I'll be back in a couple of ours |
2509
|
Tue Jan 12 11:34:26 2010 |
josephb | Update | PEM | Allegra dataviewer |
Quote: |
So that we can use both Guralps for Adaptive stuff, and so that I can look at the differential ground motion spectra, I've reconnected the Guralp Seismometers to the PEM ADCU, instead of where they've been sitting for a while connected to the ASS ADC. I redid the ASS.mdl file, so that the PEM and PEMIIR matricies know where to look for the Gur2 data. I followed the 'make ass' procedure in the wiki. The spectra of the Gur1 and Gur2 seismometers look pretty much the same, so everything should be all good.
There's a problem with DataViewer though: After selecting signals to plot, whenever I hit the "Start" button for the realtime plots, DataViewer closes abruptly.
When I open dataviewer in terminal, I get the following output:
allegra:~>dataviewer
Warning: communication protocol revision mismatch: expected 11.3, received 11.4
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: communication protocol revision mismatch: expected 11.3, received 11.4
msgget: No space left on device
allegra:~>framer4 msgget:msqid: No space left on device
Does anyone have any inspiration for why this is, or what the story is? I have GR class, but I'll try to follow up later this afternoon.
|
This problem seems to be restricted to allegra. Dataviewer works fine on Rosalba and op440m, as well as using ssh -X into rosalba to run dataviewer remotely. DTT seems to work fine on allegra. The disk usage seems no where near full on allegra. Without knowing which "device" its refering to (although it must be a device local to allegra), I'm not sure what to look at now.
I'm going to do a reboot of allegra and see if that helps.
Update: The reboot seems to have fixed the issue.
|
2510
|
Tue Jan 12 13:24:50 2010 |
Haixing | Update | SUS | Quadrant Magnetic Levitation | I have tried to make the quadrant magnetic levitation work but unfortunately I did not succeed. During the experiment, I have made
the following changes to the circuit and setup:
(1) I added small resistors (6K) in parallel to R11, R23, R35 and R47 (indicated in the following schematics) to increase
the control bandwidth from 20 Hz to 80 Hz.

(2) I changed RLED1, RLED2, RLED3, RLED4 from 2.2K to 1.5K in the LED driver such that the current of the
LED increases and in turn the displacement sensitivity increases.
(3) I changed R51 and R51 (in the differencing block for PD1 and PD2) from 5K to 1 K. Correspondingly,
I increased R52 and R54 from 5K to 50K. This changes increase the gain in the differential control by a
factor of 50, which compensates the gain loss after increasing the control bandwidth.
(4) The trim pots in the coil drive block have the following values: 100K for pot1 and pot4, 1K fro pot 2 and pot3.
To increase the gain, I replaced R17, R30, R31, R41 by 102 Om resistors (we run out of 100 Om chip resistors.)
(5) I wrapped the OSEM flags by plastic tubes to block the light from the LED more efficiently. This also removed
the changes of the photocurrent in the photodetector when the levitated plate moves horizontally.
Possible issues that cause the setup not working at the moment:
(1) The feedback gain could be probably still not enough. During the experiment, I can't feel any force changes when the
flags crossing the zero point. The error signals and control signal has the right sign.
(2) The levitated weight may be not enough and the working point is below the extremum of the DC attracting force.
This could give rise to a large negative spring which requires unreasonable feedback gain to compensate.
(3) The DC attracting force between the magnets are differing each other too much (mismatch) and can't
be compensated by the coil driving force.
(4) The control bandwidth may be still not large enough. Initially my design was 100 Hz, but I forgot to divide
the angular frequency by 2pi and the resulting circuit has a bandwidth of 20 Hz. Later I increase it up to 80 Hz
by changing the resistors as mentioned before.
(5) The polarization of the coil could have a wrong sign. I have checked with Gauss meter, but still the absence
of zero-point crossing force change makes me worry about this.
For continuation of this work, I will finish writing my document and summarize all the results and outline what
needs to be done in the future. If everything goes well, I will be back in June and can spend more time on this
experiment. I can also work with the summer students together on this project. |
2511
|
Tue Jan 12 14:28:01 2010 |
steve | Summary | Environment | lab temp of 7 years |
Quote: |
Quote: |
Rana noticed that recently the temperature inside the lab has been a little bit too high. That might be causing some 'unease' to the computers with the result of making them crash more often.
Today I lowered the temperature of the three thermostats that we have inside the lab by one degree:
Y arm thermostat: from 71 to 70 F
X arm thermostat: from 70 to 69 F
Aisle thermostat: from 72 to 71 F.
For the next hours I'll be paying attention to the temperature inside the lab to make sure that it doesn't go out of control and that the environment gets too cold.
|
Today the lab is perceptibly cooler.
The temperature around the corner is 73 F.
|
|
Attachment 1: labtemp7y.png
|
|
2512
|
Wed Jan 13 12:01:06 2010 |
Alberto | Update | Computers | c1dcuepics, c1lsc rebooted this morning | Since last night the alignemtn scripts couldn't work.
c1lsc wasn't working properly because attempts to lock the X arm would try to control ETMY and attempts of locking the Y arm, wouldn't actuate any optics.
Also, another sign of a malfunctioning c1lsc was that one of the LSC filter modules, FM6, couldn't get loaded properly. It looked like only half loaded on the LSC MEDM screen.
On the other hand, plotting the trend of the last month, c1lsc's CPU didn't look more loaded that usual.
Rebooting and restarting C1lsc wasn't enough and I also had to reboot c1dcuepics a couple of times beforse getting things back to work. |
2513
|
Wed Jan 13 12:03:00 2010 |
Alberto | Update | ABSL | Measurement now running. Please be careful | At the moment I'm running a measurement on the PRC and I'm planning to leave it going for the time we'll be at the 40m meeting.
Please be careful in the lab. Thank you. |
2514
|
Thu Jan 14 11:44:06 2010 |
josephb | Summary | Computers | Memory locations for TST model for ITMY | The main communications data structure is RFM_FE_COMMS, from the rts/src/include/iscNetDsc40m.h file. The following comments regard sub-structures inside it. I'm looking at all the files in /rts/src/fe/40m to determine how the structures are used, or if they seem to be unnecessary.
The dsccompad structure is used in the lscextra.c file. I am assuming I don't need to add anything fo the model for these. They cover from 0x00000040 to 0x00001000.
FE_COMMS_DATA is used twice, once for dataESX (0x00001000 to 0x00002000), and once for dataESY (0x00002000 to 0x00003000).
Inside FE_COMMS_DATA we have:
status and cycle which look to be initialized then never changed (although they are compared to).
ascETMoutput[P,Y], ascQPDinput are all set to 0 then never used.
qpdGain is used, and set by asc40m, but not read by anything. It is offset 114, so in dataESX its 4210 (0x00001072), and in dataESY its (0x00002072)
All the other parts of this substructure seem to be unused.
daqTest, dgsSet, low1megpad,mscomms seem unused.
dscPad is referenced, but doesn't seem to be set.
pCoilDriver is a structure of type ALL_CD_INFO, inside a union called suscomms, inside FE_COMMS_Data, and is used. In this structure, we have:
extData[16], an array of DSC_CD_PPY structures, which is used. Inside extData we have for each optic (ETMY has an offset of 9 inside the extData array):
Pos is set in sos40m.c via the line pRfm->suscomms.pCoilDriver.extData[jj].Pos = dsp[jj].data[FLT_SUSPos].filterInput; Elsewhere, Pos seems to be set to 1.0
Similarly, Pit and Yaw are set in sos40m, except with FLT_SUSPitch and FLT_SUSYaw, and being set elsewhere to 1.1, 1.2. However, these are never applied to the ETMX and ETMY optics (it goes through offests 0 through 7 inclusive).
Side is set 1.3 or 1.0 only, not used.
ascPit , ascYaw, lscPos are read by the losLinux.c code, and is updated by the sos40m.c code. For ETMY, their respective addresses are: 0x11a1c0, 0x11a1c4, 0x11a1c8.
lscTpNum, lscExNum, seem to be initialized, and read by the losLinux.c, and set by sos40m.c.
modeSwitch is read, but looks to be used for turning dewhitening on and off. Similarly dewhiteSW1R is read and used.
This ends the DSC_CD_PPY structure.
lscCycle, which is used, although it seems to be an internal check.
dum is unused.
losOpLev is a substructure that is mostly unused. Inside losOpLev, opPerror, opYerror, opYout seem to be unused, and opPout only seems ever to be set to 0.
Thats the end of ALL_CD_INFO and pCoilDriver.
After we have itmepics, itmfmdata, itmcoeffs, rmbsepics,...etymyepics, etmyfmdata,etmycoeffs which I don't see in use.
We have substructure asc inside mcasc, with epics, filt, and coeff char arrays. These seem to be asc and iowfsDrv specific.
lscIpc, lscepics, and lscla seems lsc specific,
The there is lscdiag struct, which contains v struct, which includes cpuClock, vmeReset, nSpob, nPtrx, nPtry don't seem to be used by the losLinux.c.
The lscfilt structure contains the FILT_MOD dspVME, which seems to be used only by lsc40m.
The lsccoeff structure contrains the VME_COEF pRfmCoeff, which again seems to only interact in the lsc code.
Then we have aciscpad, ascisc, ascipc, ascinfo, and mscepics which do not seem to be used.
ascepics and asccoeff are used in asc.c, but does not seem to be referenced elsewhere.
hepiepics , hepidsp, hepicoeff, hepists do not appear to be used.
|
2515
|
Fri Jan 15 11:21:05 2010 |
josephb | Update | Computers | Megatron and tst model for ETMY | The tst model wasn't compiling this morning due to some incorrect lines in the RfmIOfloat.pm file located in /home/controls/cds/advLIgo/src/epics/util/lib file on megatron.
The error was "Undefined subroutine &CDS::RfmIOfloat::partType called at lib/Parser2.pm line 354, <IN> line 3363."
I changed RfmIO to RfmIOfloat on lines 1 and 6.
Basically the first 6 lines are now
package CDS::RfmIOfloat;
use Exporter;
@ISA = ('Exporter');
sub partType {
return RfmIOfloat;
}
The tst now compiles. At the moment, I believe we should be able to switch megatron in for ETMY and attempt to lock the arm. The whitening/dewhitening filters are still not automatically synced in software and hardware, but I don't think that should prevent locking. |
2516
|
Fri Jan 15 12:04:26 2010 |
Sanjit, mevans | Update | Adaptive Filtering | Canceling noise again! |
OAF is successfully canceling noise again, thanks to Matt!
Here is a plot showing more than a factor of 10 noise reduction around 3Hz (similar to what we saw in the simulations)
The changes that has made it work are:
- use of RANGER channel (with ACC_MC1_X and/or ACC_MC2_X)
- mu = 0.01, tau = 1.0e-6, ntaps = 2000, nDown = 16
- nDelay = 5 and nDelay = 7 both work (may not be so sensitive on delay at low frequencies)
- Main changes: filter bank on the PEM channels (ASS_TOP_PEM_## filters: 0.1:0, 1:, Notch24, AA32)
- Added the AI800 filter for upsampling in MC1 (should not matter)
Matt suggested playing with the emphasis (EMPH) filters to cancel noise in different frequency bands.
|
Attachment 1: OAF_15JAN2010.png
|
|
2517
|
Fri Jan 15 18:53:05 2010 |
josephb,peter,koji | Update | Computers | Attempted locking with Megatron replacing ETMY front end | This afternoon we attempted to lock the interferometer using Megatron insteady of the usual ETMY front end.
We attempted it once, found the alignment seemed particularly bad, then realized we had forgotten to add the QPDs. In the process of adding the QPDs to the tst.mdl file, we realized I (Joe) should have been looking at the iscNetDsc.h file, not the iscNetDs40m.h file for the RFM memory structure. The only major difference was the memory location of where the qpd information gets passed.
We added QPDs to the tst.mdl file, writing to the RFM network with the QPD pitch, yaw and sum values.
We also added normalization to the oplev, by dividing the OL pitch and yaw values by the OL sum value in the tst.mdl file.
The lscPos, ascPit, ascYaw were working properly, although we did have to poke at the ascPit and ascYaw values once before they started reading properly at Megatron (they started at -1e20). We think the RFM card may have started in an odd state, and without something causing the ascPit and ascYaw values to change, it never updated.
At the end of the day, the interferometer was locked for a few seconds. There is are still some issues to be worked on, but its progress.
Koji returned everything back to normal operations after the test. |
2518
|
Sun Jan 17 05:22:42 2010 |
rana | Configuration | Computers | ELOG script change | With Dave Barker's help, I changed the elog startup script. Instead of running as a Daemon with the -D option,
it now runs in the background with the unix "&". I think that the stdout and stderr are now redirected to a log file called elog.log.
We can 'tail -f' this file to see what its up to and debug any future crashing. |
2519
|
Sun Jan 17 19:18:55 2010 |
Alberto | Update | Computers | Boot fest to restart the computer and c1iscey not responding. | Thi afternoon I found that the RFM network in trouble. The frontends sync counters had railed to 16384 counts and some of the computers were not responding. I went for a bootfest, but before I rebooted c1dcu epics. I did it twice. Eventually it worked and I could get the frontends back to green.
Although trying to burtrestore to snapshots taken at any time after last wednesday till today would make the RFM crash again. Weird.
Also, c1iscey seems in a coma and doesn't want to come back. Power cycling it didn't work. I don't know how to be more persuasive with it. |
2520
|
Mon Jan 18 09:44:36 2010 |
Alberto, Bob | Omnistructure | Environment | No rain water infiltrations so far | It has rained continuously for the last 24 hours. Bob walked through the lab looking for possible water infiltrations. The floor looked dry: no puddles or leaks anywhere so far. |
2521
|
Mon Jan 18 18:34:01 2010 |
Alberto | Update | ABSL | Measurement in progress | I started a long measurement of the PRC's transmissivity. I'm leaving the lab and I'm going to be back at about 8 tonight. Please do not disturb the interferometer. it is important that the MC and the PRC stay locked all the time. |
2522
|
Mon Jan 18 20:58:40 2010 |
Alberto | Update | ABSL | Measurement in progress |
Quote: |
I started a long measurement of the PRC's transmissivity. I'm leaving the lab and I'm going to be back at about 8 tonight. Please do not disturb the interferometer. it is important that the MC and the PRC stay locked all the time.
|
That measurement is finished. I'm now going to start another one that will take another hour or so. I'm leaving it running for the night. If you want to work on the IFO, it should be definitely done by 11pm. |
|