40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 269 of 337  Not logged in ELOG logo
ID Date Author Type Category Subject
  3450   Fri Aug 20 16:41:43 2010 AlbertoUpdateElectronicsFrequency Generation Box Assembly Completed

I finished assembling the frequency generation unit for the upgrade. I tested it through to check that the power levels are as expected at the various connection (see attached png, showing in black the design power values, and in red the measured ones).

Because of some modifications made on the design along the construction, I have to recalculate the SNR along the lines.

I can now start to measure phase noise and distortion harmonics.

A document with a description of the design and the results of the characterization measurements will be available in the end.

 

Attachment 1: RFplan_6_measured_powers.png
RFplan_6_measured_powers.png
Attachment 2: DSC_2409.JPG
DSC_2409.JPG
Attachment 3: DSC_2413.JPG
DSC_2413.JPG
Attachment 4: DSC_2414.JPG
DSC_2414.JPG
Attachment 5: DSC_2415.JPG
DSC_2415.JPG
Attachment 6: DSC_2417.JPG
DSC_2417.JPG
Attachment 7: DSC_2419.JPG
DSC_2419.JPG
  3449   Fri Aug 20 16:17:35 2010 steveUpdatePEMPEM-count channels are not working

C1: PEM-count channels are dead since August 12, 2010

  3448   Fri Aug 20 15:49:14 2010 steveUpdatePEMgrouting is done

The preparation for pouring concrete is continuing. The grout forms were removed. Half inch ribbed steel bars were epoxied into our 4" thick floor.

The concrete holding sides- forms are cut to size. They will be installed on Monday morning and pouring concrete should follow.

We can be planning for cleaning up on Tuesday

 

Atm1, epoxy used bars

Atm2, south west tripod feet grouted

Atm3, ribbed bars are getting ready

Attachment 1: P1060699.JPG
P1060699.JPG
Attachment 2: P1060700.JPG
P1060700.JPG
Attachment 3: P1060704.JPG
P1060704.JPG
  3447   Fri Aug 20 15:22:09 2010 JenneUpdateSUSTTs done!!!

[Yoichi, Jenne]

Hooray!!! The Tip Tilts are completely done!  The only things remaining are (1) Install 4 TTs in chambers sometime in September and (2) do shake tests / take TFs of the spare.

Today we balanced and characterized #'s 1 and 5.  All 5 TTs are waiting happily on the flow bench in the cleanroom for installation.

  3446   Fri Aug 20 13:09:53 2010 josephbUpdateelogRebooted elog

I had to restart the elog again.

At this point, I'm going to try to get one of the GC guys to install gdb on nodus, and run the elog in the debugger, that way when it crashes the next time, I have some error output I can send back to the developer and ask why its crashing there.

  3445   Thu Aug 19 21:56:02 2010 ZachUpdateelogrestarted

 script

  3444   Thu Aug 19 16:03:59 2010 steveUpdatePEMgrouting of PSL tripod legs

The 10' x 6' optical table is seating on 6 tripods. Each tripod leg has 3 feet. They are supported by jack screws against copper plates on the concrete floor.                            These set screws allowed us to set the height,  level and distribute the load of the table.

To lock this position of the table grouting is used around the jack screws and between the concrete floor and the tripod feet.

Once the grout set the load will be carried by the hole feet  of 4" x 3.25" x3 = 39 sq inches per tripod leg

 

These ~4" thick grouted islands of 8-9" OD will be covered by 4" concrete. The area between the legs will be filled with 8" thick concrete.

http://www.fivestarproducts.com/techinfo/GroutHandbook.pdf

 

Atm1, http://www.fivestarproducts.com/cementgrouts/specsheets/grout_ss.pdf

         Cement based grout, early height change 0 - 4%, hardened height change 0 - 0.3%

Atm2-3,  pouring grout

Atm4,  south west leg is done

 

Tomorrow: setting up ribbed bars, building frame to hold concrete and pour concrete

Attachment 1: P1060687.JPG
P1060687.JPG
Attachment 2: P1060681.JPG
P1060681.JPG
Attachment 3: P1060686.JPG
P1060686.JPG
Attachment 4: P1060696.JPG
P1060696.JPG
  3443   Thu Aug 19 12:06:07 2010 AlastairUpdateComputersATF wiki

Quote:

The ATF wiki page doesn't seem to be working any more.  Does anyone know where this is held so we can try to get it back online?  Thanks

 I phoned Phil Ehrens and found out that all these wikis have been moved to a new wiki site

The ATF wiki can now be found here

I have updated the link from the 40m wiki to reflect this

  3442   Thu Aug 19 11:38:48 2010 AlastairUpdateComputersATF wiki

The ATF wiki page doesn't seem to be working any more.  Does anyone know where this is held so we can try to get it back online?  Thanks

  3441   Thu Aug 19 09:52:51 2010 AlastairUpdateComputersElog down

 I restarted it using start-elog-nodus and this worked out fine - even though I did it from Pete's on my phone ;-)

  3440   Thu Aug 19 09:51:43 2010 josephbUpdateelogelog dead again

I found the elog dead again this morning, and the script didn't kill again. I modified the script to use the following line instead of "pkill elogd":

kill `ps -ef | grep elogd | grep -v grep | grep -v start-elog-nodus | awk '{print $2}'`

Hopefully the script will be a bit more robust in the future.

Quote:

Quote:

The elog was so dead this time that the restart script didn't work.  I followed the restart-by-hand instructions instead, with success.

 Just for added interest, I tried a different method when the restart script broke.  The "start-elog-nodus" script has a line "kill elogd".  This seems not to be actually killing anything anymore, which means the elog can't restart.  So this time I went for "kill <pid number>", and then ran the startup script.  This worked.  So it's the "kill elogd" which isn't working reliably.

 

  3439   Thu Aug 19 01:49:14 2010 JenneUpdateelogelog dead again

Quote:

The elog was so dead this time that the restart script didn't work.  I followed the restart-by-hand instructions instead, with success.

 Just for added interest, I tried a different method when the restart script broke.  The "start-elog-nodus" script has a line "kill elogd".  This seems not to be actually killing anything anymore, which means the elog can't restart.  So this time I went for "kill <pid number>", and then ran the startup script.  This worked.  So it's the "kill elogd" which isn't working reliably.

  3438   Wed Aug 18 20:54:23 2010 rana, yoichiConfigurationEnvironmentChiller's chiller turned off

WE programmed the MOPA chiller's AC unit to turn off at 6PM each day and automatically turn on at 7 AM each morning. Its now very quiet in the control room at night.

Next, we'll leave it off during the day and see if it makes Steve go crazy or not.

  3437   Wed Aug 18 19:19:38 2010 JenneUpdateSUSFinal 2 TTs suspended!

[Jenne, Yoichi]

The final 2 Tip Tilts (#1 and #5) have been suspended.  We have designated #5 the spare.  It looks like there might be a teensy bit of dust on the AR surface of the optic in #5, right near the edge of the coating.  Not a critical issue if this one is the spare, although we should see if we can blow it off with the Nitrogen.  Both #1 and #5's optics were suspended using the thicker wire, 0.0036" diameter.  This leaves 4/5 TTs with this thick wire, and 1 of the 5 has the thin wire.

To do still: Balance both #1 and #5, and then measure the modes of each.  Then we'll be ready to install them into the chambers, and we'll reserve #5 for shake table TFs for some later date.

 

  3436   Wed Aug 18 19:14:59 2010 JenneUpdateelogelog dead again

The elog was so dead this time that the restart script didn't work.  I followed the restart-by-hand instructions instead, with success.

  3435   Wed Aug 18 16:42:14 2010 steveUpdatePEMPSL optical table legs load balanced

 

 Rana, Koji, Alberto and Steve, Tuesday afternoon

 

Atm3, Part of the tunnel under the table was filled with quick drying concrete this morning  to give solid support for tripod legs.

          PVC tube 6 " ID with TEE will able us to connect AP table, PSL table and Control room if needed

Atm4, Table height set to equal AP at  ~32.75 " on copper plates using 5/8-11 x 4.5" set screw-bolt in tripod foot

           Rough leveling was done by 4 individual levels at the four corners with 9" long Stanley cast aluminum levels.

          Load balancing of the total weight  ~ 3000 lbs over  6 legs x3 = ~170 lbs on each jack screw with Snap-On torque wrench at 140 lbs/ft

Atm1, Three crew members at work. Prof. Rana's calibrated right hand was used at jack screws where insufficient space was available for socket head wrench.

Atm2, Table is ready for no shrink grouting now.

         

 

 

 

 

Attachment 1: P1060671.JPG
P1060671.JPG
Attachment 2: P1060674.JPG
P1060674.JPG
Attachment 3: P1060670.JPG
P1060670.JPG
Attachment 4: P1060676.JPG
P1060676.JPG
  3434   Wed Aug 18 12:24:58 2010 josephb,kiwamuUpdateCDSshmem issue

Apparently its possible to have working models get into a bad state in regards to shared memory, which prevents the model from working after killing it and restarting it.  We found that by shutting all the models down, and then killing and restarting the setup_shmem process, it allowed models to function properly again.

The symptom was getting stuck at the burt restore step, according the log files (/opt/rtcds/caltech/c1/target/c1SYS/logs/log.txt).

  3433   Wed Aug 18 12:02:29 2010 AlastairConfigurationComputerselog had crashed again...

...I restarted it.

  3432   Wed Aug 18 11:40:59 2010 josephb,kiwamu,yoichiUpdateCDSEnd station working with latest RCG code

We were able to get the latest SVN checkout (revision 2009), working with the c1x00 (IOP) and c1vgl models at the new X end on the c1iscex machine.

We were unable to get it working yesterday, and as far as we can tell, the only significant change was a reboot of the c1sus machine.  Before the reboot, it did not look like there were any conflicting models running on the c1sus machine, but apparently something was preventing the models on c1iscex from running properly.

Other simulated plant models still need to have their shared memory location blocks updated to the new type.

Now that we have proved we still can get the end model running, we are moving onto the c1sus machine.

  3431   Tue Aug 17 23:59:46 2010 KatharineUpdateelogMaglev update

Katharine, Sharmila

Update: 
We haven't been posting in the elog regularly, for which we are very sorry.  We have been taking notes in our log books, but we ought to have posted here as well.  We apologize and now present an overview of what we've been up to.

Some time ago, we created a Simulink model to predict the response of our system, but for the model to be useful we needed to include approximately correct gains for each block in the diagram, including the magnet force and coil force gradients and OSEM "gain." We also needed to better quantify the 1x1 levitation.


Adjusting the potentiometers:

The circuit which converts current to voltage in the Quadrant maglev control has a variable resistor. This is useful as it gives us a way to zero the current when the levitated object is in the equilibrium position. It was done as follows. The output voltage from the circuit converting current to voltage is fed into the oscilloscope. The voltage values for zero and complete blockage of the LED is noted(say 2V). We adjust the resistor to make the voltage output to be V when the flag completey bolcks the LED. This gives a zero current when the flag is in the equilibrium position.

OSEM Calibration:

The OSEM works by blocking the light that goes into the photodetector from the LED by a flag. To simulate the model we had on simulink, we needed to find what the gain of the OSEM was. The gain of the OSEM is the current it gives per unit displaccement of the flag. To determine this we attached a micrometer to the OSEM flag. The micrometer was long eneough to push the flag to completey block the OSEM. We connected the output of the PD test point (which was the voltage after the photodiode current was converted into voltage) to the oscilloscope. We noted down the voltage difference in the oscilloscope with a fixed reference for different positons of the flag. From the oscilloscope output, we were able to get the PD current. We then selected a linear region of the plot of PD current vs flag position(which is usually in the middle) to fit the graph with a straight line. The slope gives the OSEM gain.

Magnet strength
    We need to know about the relative strengths of our magnets (levitated and fixed in the coil) in order to do magnet matching.  We used a Gaussmeter to measure the field from each coil magnet at  ~2 mm away from the center (the probe was fixed to an aluminum block, so that the tip had the same vertical separation for each of the four fixed plate magnets).  We labeled each of the four magnets and calculated the field at this distance to be 0.206 kG, 0.210 kG, 0.212 kG, and 0.206 kG,  respectively, for coils 1-4.  However, each measurement had a rather large uncertainty of 0.01 kG, because the field strength varied a lot with position on the magnet, and the measurements were limited by how well we could align the probe tip with the center.

Fixed Plate Magnets - magnetic field (kG)           
meas't    1        2        3        4
1       0.205    0.213    0.209    0.204
2       0.211    0.219    0.223    0.207
3       0.199    0.205    0.211    0.201
4       0.207    0.203    0.206    0.213
average 0.206    0.210    0.212    0.206
stdev   0.005    0.007    0.007    0.005

    We also planned to take the same measurements for the coil magnets.  We noted that the magnetic field varied a lot depending on the probe's location, but not in the way we would expect.  At the edges of the magnet, the field was much stronger (~2 kG) than at the center (~0.5 kG).  We initially thought this might have to do with how we were holding the probe -- for instance, if we measured the force towards the edge by moving the tip all the way across the center of the magnet, there might be some kind of integration effect which does not accurately represent the field.   However, we measured the field at the edge with the probe across the magnet and also with the probe, so this is clearly not the case.

    We also noticed that the cylindrical magnet we used for single-magnet levitation was not attracted to the coil magnets in the way we expected.    Though the cylindrical magnet was oriented so that it was strongly attracted to the coil magnet, it was attracted more to the edges than the center, so that it seemed to be repelled by the centers of the coil magnets.  Though this follows somewhat from the Gaussmeter readings, it is not the behavior we would expect when considering the coil magnets as magnetic dipoles.

Attempting single-magnet levitation for each coil:
    We attempted to levitate single magnets using all four OSEM/coil combinations.   We assembled the magnets and OSEMs using Haixing's mount, and, adjusting the height of the OSEM plate, attempted to levitate the single magnet with a flag with which we were previously successful.   This was completely unsuccessful using all of the coil magnets (and when we tried to levitate using the south magnets, we flipped the cylindrical magnet's orientation).
    Since we had already achieved this levitation, this seemed particularly wrong.  We disassembled the fixed OSEM plate in Haixing's mount and built a cursory OSEM mount, similar to the one we had used for levitation before, and did not fix it in place.  After a little experimenting with the height and position of the OSEM, we were able to achieve levitation with coils 1 and 4.
    We noted the levitation magnet separation (~4.5 mm) and the height of the OSEMs at which levitation was achieved (147 +/- 1 mm for coil 1, 146 +/- 1 mm for coil 4).  Then, we reassembled Haixing's OSEM plate and tried to levitate the cylindrical magnet at coil 1 and coil 4, respectively, adjusting the OSEM plate so that the height of the OSEM of interest was the same as when we achieved single-magnet levitation.  This was unsuccessful, which leads us to believe that there is some alignment issue between the fixed coil magnets and the OSEMs in the mount,  possibly due to the unusual field from the fixed coil magnets.
    We also were completely unable to levitate using coils 2 and 3.  Coils 1 and 4 have identical circuit paths, whereas 2 and 3 differ slightly.  With more time, we need to investigate this further.

Force-distance measurements
    We also measured the repulsive force between the cylindrical magnet and the coil magnets as a function of separation.  We fixed each of the coil magnets, individually, on a stack of sticky notes on a precision balance (the stack of sticky notes was to prevent the coil magnet from interacting with the digital balance) and zeroed the balance.  We then fixed the cylindrical magnet (oriented so that it would be repelled by the coil magnet) to a teflon rod, and mounted the rod so that we could slide it up and down a long cylindrical post.  Noting the position of the rod and cylindrical magnet, we were able to measure the repulsive force as a function of separation (see Excel graph).
    However, because the magnetic field varied so much with position on the coil magnet, there is a lot of uncertainty associated with these measurements.    We tried to keep the cylindrical magnet in the same horizontal position, but it was impossible to keep the exact position while sliding the mounted teflon rod up and down the posts.    In spite of this, we fit the linear region of this graph, near the equilibrium separation of the magnets, for a very approximate measurement of the magnetic field force gradient. The slope gives the force per unit distance of the magnet.

Coil-force measurement
    We measured the force by changing the current through the coil of wire, using a very similar setup as described above.  Since we are concerned with the magnetic force as a function of current, not separation, we fixed the teflon rod so that the cylindrical magnet and coil magnet were separated by ~4.5 mm, the approximate levitation separation of the two magnets.   We then completely blocked the OSEM with the flag, creating a maximum PD current, and measured the coil current using an oscilloscope when the LED was fully blocked and the current when we removed the flag.  At the same time, we measured the repulsive force by looking at the precision balance.
    Unfortunately, we had difficulty taking further readings, because our circuit starting behaving oddly (described below).  Otherwise, we would repeat this process by blocking the OSEM LED by various amount and measuring the change in coil current, and the corresponding reading on the precision balance.   However, the force should be linearly dependent on coil current, and we ought to know one other point: when there is no current in the coil, there should be no magnetic force from the coil to the magnet.  Using this information, we can determine the slope of magnetic force by coil current, but it's not very reliable as we have only one real data point.
    One additional aspect makes this reading questionable.  When we switched on the power supply, the reading on the precision balance changed, before we had blocked the OSEM LED at all. Since no light was blocked, theoretically no photocurrent should be coming from the PD and there should not be a coil current from the feedback, so the force should not be changing. We are not sure why this is.

Recent Circuit Behavior
    Some noise in the circuit appears to be hugely amplified when the gains of each coil are high, resulting in a high frequency signal of a few hundred kHz.  When the gains are all sufficiently high, this noise can saturate the coil current so that when PD current changes, there is no visible change in coil current.
    On Saturday, we noticed some odd behavior from the circuit.  We hooked up the oscilloscope so we could see both PD current and coil current, and were very surprised that the PD current signal was oscillating and continually changing even when no flag was inside the OSEM.   This was also affecting the coil current as well.  We thought this might be due to some component burning out in our circuit, or RC coupling somewhere, but we did not get a chance to pinpoint the origin of this problem.

Modeling
Initially we had attempted to model the force-distance treating the two cylindrical magnets as dipoles, and finding the attraction/repulsions between the four distinct poles.  However, the resulting equation did not have a maximum, which is what we got in our measured values, so it seems this is not the best approach.  We would like to try the current loop approximation.

Attachment 1: repulsiveforce.png
repulsiveforce.png
Attachment 2: OSEMcalibration.png
OSEMcalibration.png
Attachment 3: OSEMslopes.png
OSEMslopes.png
  3430   Tue Aug 17 14:09:15 2010 steveUpdatePEMPSL optical table schedule

Tuesday, 17 August : fill tunnel, set table height, level table and balance load

Wednesday : grout tripod legs and leave it alone

Thursday : built  guide-form for concrete

Friday :  pour concrete

Monday, 23 August : remove guide forms and clean up

  3429   Tue Aug 17 09:06:08 2010 AlbertoUpdateelogelog was down

I just restarted the elog after I found it down a few minutes ago.

  3428   Tue Aug 17 02:07:11 2010 YoichiUpdateCDSDACs have correct number of channels

Quote:

- DACs 

  None of them are working although the computer can recognize that all three DAC cards are mounted.

  I think something in the IOP file and the model file may be wrong because this symptom looks similar to that of C1ISCEX we tested two weeks before ( see this entry ) 

  I have to fix it anyhow because the DACs are very necessary part for this damping test.

 Since we had a similar trouble with the DAC at CLIO, I checked if this problem comes from the same origin.

The origin of the problem we had was that although the board was sold as 16 channel DAC, the firmware was set to use only 8ch.

To see if this problem exist in the DAC boards of c1sus, I added the following code to the /cvs/cds/caltech/cds/advLigoRTS/src/fe/map.c

printk("DAC ASSC = 0x%x\n",dacPtr[devNum]->ASSC);

in the definition of mapDac() function.

This code prints the information of the ASSC (Assembly Configuration) register of the PMC66-16AO16 board as a kernel message at the start up time of the realtime code. You can check the message with dmesg command.

After the modification, I recompiled the c1sus and installed it.

make c1sus; make install-c1sus

After starting c1sus, I checked the dmesg. Then found that the ASSC register was set to 0x130006. To decipher this magic number, you have to consult with the manual of the DAC, which is available online.

http://www.generalstandards.com/view-products.php?product=pmc66-16ao16

The manual says the 17th and 18th bits of this number set the number of channels. Those bits are 11 for 0x130006. According to the manual, 11 means 16 channels are present. So it seems that the ASSC register is correctly set. In the case of CLIO, the ASSC register was 0x110003, meaning only 8 channels are present.

Unfortunately, the ASSC register was not the cause of the problem, but at least this possibility was checked.

  3427   Mon Aug 16 23:39:29 2010 YoichiUpdateSUSMore TT characterization

Quote:

Things we noticed:  Koji and I had been concerned the last time we were looking at TT#2 because the frequency got lower and the Q seemed to get higher when we added the damping to the vertical blades.  Yoichi and I did not find that to be true today.  We did notice, however, that the EQ stop screws with the viton had been placed in the holes closer to the clamping point, whereas with TT #4 the screws had been placed in the holes farther from the clamping point.  We moved the screws on TT #2 to the outer holes, and noticed that the frequency increased slightly, and the Q significantly decreased.  We then followed this outer-hole philosophy when installing screws in TT #3.

The inner and outer screw holes of the EQ stop Jenne is talking about are shown in the photo below.

EQStopScrewHoles.jpg

  3426   Mon Aug 16 23:13:25 2010 ZachUpdateeloge to the log

 Zach

  • I get so many freebies it's ridiculous
  3425   Mon Aug 16 19:12:18 2010 JenneUpdateSUSMore TT characterization

[Jenne, Yoichi]

We characterized Tip Tilts numbers 2 & 3 today.  Recall #4 is the one which Koji and I measured some time ago, and #s 1 & 5 have yet to be suspended (that's on the to-do list for tomorrow).

When we began looking at #3 (the one which had been in the BS chamber for a few days, but was removed for characterization) we found that the pitch pointing was way off.  The beam was way too low after reflection.  So we adjusted that (and got it right on the first try....a miracle!).  This does however make me pretty concerned about our in-chamber pointing.  Are we destroying our pointing during travel between the cleanroom and the chambers?  Is there anything we can do about it? Pointing doesn't seem to be lost when we move them around on the tables in the cleanroom, ie we can pick up a TT, move it, leave it for a while, move it back to the oplev, and the pointing still seems okay.  But the TT which was sent to the chambers came back with bad pointing. I'm sure this is related to the hysteresis we see in the pointing if we poke the top of the mirror holder versus the bottom when exciting pitch motion.

For both #2 and #3, we measured the frequency and Q of Pitch, Yaw, Pos, Side, Vert motion.  For the Vert motion, we measured both without and with EQ stops as dampers.  For the other modes, all were measured with the ECD backplane in place.  Pitch and Yaw were measured with reflection off of the mirror surface onto the PD, while Pos, Side and Vert were measured using the wire clamp on the mirror holder to obscure the beam as a shadow sensor.

TT #2

Pitch: Overdamped, no freq measured, Q < 1/2

Yaw: freq ~1.8Hz, Q between 2-7

Pos: freq ~1.75Hz, Q too low to measure, but above critically damped

Side: freq ~ 1.8Hz, Q~5

Vert no dampers: freq ~20Hz, Q~36

Vert with dampers on outer screws: freq~24Hz, Q~8,

TT #3

Pitch: no freq measured.  Q~1/2?  Upon being excited in Pitch, the beam started down way below the photodiode, came up a little past its DC place, and went back down a tiny bit.  So not quite overdamped.

Yaw: freq ~1.96Hz, Q very low

Pos: freq ~1.72Hz, Q~3

Side: freq ~1.85Hz, Q~6

Vert no dampers: freq ~20Hz, Q~75

Vert with dampers on outer screws: freq ~20Hz, Q~34  (Frequency stayed constant....we did several measurements both with and without the dampers...but the half life time changed significantly)

 

Things we noticed:  Koji and I had been concerned the last time we were looking at TT#2 because the frequency got lower and the Q seemed to get higher when we added the damping to the vertical blades.  Yoichi and I did not find that to be true today.  We did notice, however, that the EQ stop screws with the viton had been placed in the holes closer to the clamping point, whereas with TT #4 the screws had been placed in the holes farther from the clamping point.  We moved the screws on TT #2 to the outer holes, and noticed that the frequency increased slightly, and the Q significantly decreased.  We then followed this outer-hole philosophy when installing screws in TT #3.

To Do List: We need to suspend the ECDs and the Optics for the remaining two Tip Tilts, and to characterize them.  We also (probably farther-future) need to take transfer functions using a shaker / shake table with our spare Tip Tilt.  After all the TTs are suspended and have their modes measured, we will be ready for installation into the chamber during the next vent.

 

  3424   Mon Aug 16 13:33:06 2010 ZachFrogsPhotosHere's the 40m team

 One day I'll get to be part of the krew

  3423   Fri Aug 13 20:58:20 2010 JennaSummaryElectronicsRubidium clock phase noise measurement

 Here's an overview of the rubidium measurement:

rubidium_diagram.png

HPIM3871.JPG

 

HPIM3880.JPG

 We have two SRS FS275 Rubidium clocks which are locked together using the built-in PLL through the 1pps input/output. The default time constant for this locking is 18.2 hours because it's designed to be locked to a GPS. We changed this time constant to .57 hours (as decribed in this elog entry) to get the clocks to more reliably lock to each other. We then mix the 10MHz outputs together using a 7dbm mixer (see elog here and picture below)

HPIM3872.JPG

 

The signal then goes through an AC-coupled SR560 with a gain of 100 and LPF at 10kHz, and is then fed into the DAQ. In the first picture below you can make out what all the lights are labeled, and in the second you can see what lights are on. I couldn't get a picture that did both in one, sadly.

HPIM3878.JPG

HPIM3876.JPG

  3422   Fri Aug 13 18:32:48 2010 steveUpdatePEM new legs attached to optical table

Koji, Rana and Steve

 

The floor preparation continued today. The really messy part of drilling and jack-hammering the concrete were done in controlled manner.

Particle counts peaked at 106K of 0.3 micron and 13 K of 1.0 micron particles/ cfmin at the top of SP table.

Legs were installed with the help of Koji and strongman Rana. Professor Rana was very useful lifting the 85 lbs legs. 

 

Atm1, Drilling holes for ribbed bar reinforcement of concrete

Atm2, Koji and Rana are playing hide and seek while installing legs

Atm3-4, 6 Rigid tripod legs attached by 6x3 of 1/4-20x 7/8 screws. The top plates of the legs were torqued to 108 ft/lbs by Rana

Attachment 1: P1060612.JPG
P1060612.JPG
Attachment 2: P1060626.JPG
P1060626.JPG
Attachment 3: P1060631.JPG
P1060631.JPG
Attachment 4: P1060636.JPG
P1060636.JPG
  3421   Fri Aug 13 15:29:35 2010 AidanFrogsPhotosHere's the 40m team
Attachment 1: 40m_team.JPG
40m_team.JPG
  3420   Fri Aug 13 13:11:30 2010 DmassUpdateelogrestarted

Quote:

Quote:

 script

 More of the same. 

Who is putting weird figures into the elog?!?!  I haven't checked lately, but this is what usually crashes the elog.  It's been happening a lot lately, and it might be the .pdf's. 

Let's play a new game.  We'll call this game "Everyone only use .png files for the next week" Ready? GO!

Do we know what causes the crashes for definite? Let's give the whole knowledge gathering a shot. Surfs welcome to post. Please follow the format and keep it brief. P.S. if the elog stops responding or hangs while you're trying to edit a post or write a post, you may have crashed it.

Person

  • Crashes

Dmass

  • I have crashed the elog with downsized jpegs (~300-900kB).
  • I see jpegs on the front page of the 40m (which seem to have not crashed it?)
  • I have posted pdf's with and without png thumbnails (associated automatically via the Mac program preview) without problem.

 

Edit this post to add your own experience using the above format

  3419   Fri Aug 13 09:41:00 2010 nancyOmnistructureComputersCharger for dell laptop

 I have taken the charger for the dark gray dell laptop from its station, and have labelled the information there too.

Will keep it back tonight.

  3418   Fri Aug 13 01:53:12 2010 GopalUpdateOptic StacksGravity Implementation Confirmed

Time Domain Analysis on a Driven, Damped Simple Pendulum has produced a method for implementing gravity.

COMSOL made this simple task a cryptic one: the following methods had previously failed:

  • Previous Frequency Domain testing lead to unwanted oscillations of all loads.
  • Prescribed accelerations at first seemed to create a constant gravity, but instead incorrectly constrained net acceleration to the inputted amount

Methodology:

1) An (approximately) impulse displacement was applied in the horizontal direction. The pendulum bob's displacement was observed for varying pendulum lengths.

2) The drive and response displacements vs. time were FFT'd to produce transfer functions.

3) The fundamental frequencies were inverted, squared, and plotted against frequency.

4) Since the graph is linear with an R^2 of over 0.99, it is reasonable to assume that gravity is properly acting as a restoration force.

Pendulum_Length.png

Attachment 1: Pendulum_Length.png
Pendulum_Length.png
Attachment 2: Pendulum_Length.png
Pendulum_Length.png
  3417   Thu Aug 12 23:49:04 2010 nancyUpdateEnvironmentLaser chiller temp raised

Since the laser is off, Jenne and I rasied the chiller-chiller (small AC in the Control Room) set point temperature to 73 degree F (from 68F) to save people from shivering.

  3416   Thu Aug 12 23:41:48 2010 JenneUpdateelogrestarted

Quote:

 script

 More of the same. 

Who is putting weird figures into the elog?!?!  I haven't checked lately, but this is what usually crashes the elog.  It's been happening a lot lately, and it might be the .pdf's. 

Let's play a new game.  We'll call this game "Everyone only use .png files for the next week" Ready? GO!

  3415   Thu Aug 12 23:17:54 2010 ZachUpdateelogrestarted

 script

  3414   Thu Aug 12 18:30:08 2010 kiwamuUpdateCDSRe: current status

Yes.  

The medm screen C1SUS_GDS_TP.adl showed some numbers which correspond to that I wrote  on the outputs.

But I still could not get any physical voltage coming from the DACs.

Quote:

 When you write outputs on DAC_0 or DAC_1 is the C1SUS GDS TP screen showing anything? 

  3413   Thu Aug 12 17:28:28 2010 RazibUpdatePhase CameraSideband power measurement (updated)

Quote:

This sounds very relieving although this could be a lower bound of the number.
Why didn't you use the output on the PD which just give us the direct observation of your so-called SCR.

Quote:

So the SCR is calculated by the ratio of the FFT'd DC and the 5 Hz signal. Using the CCD, I obtained the SCR to be 0.075 ± 0.01. Previously, we expected our SCR to be 0.09 as in the previous e-log entry. 

 

 The SCR was at first measured using the output of the PD. That was exactly from where we got our 0.09 (previous elog entry). The second measurement was from the CCD.

  3412   Thu Aug 12 17:10:07 2010 KojiUpdatePhase CameraSideband power measurement (updated)

This sounds very relieving although this could be a lower bound of the number.
Why didn't you use the output on the PD which just give us the direct observation of your so-called SCR.

Ed: I meant time series of the PD output

Quote:

So the SCR is calculated by the ratio of the FFT'd DC and the 5 Hz signal. Using the CCD, I obtained the SCR to be 0.075 ± 0.01. Previously, we expected our SCR to be 0.09 as in the previous e-log entry. 

 

  3411   Thu Aug 12 16:52:02 2010 RazibUpdatePhase CameraSideband power measurement (updated)

I made some measurement of the SCR (signal to contrast ratio) from the signal from the EOM and the AOM.

The recipe for that was:

1. Trigger the camera at 20 Hz (from function generator).

2. Take a series of 20 images.

3. Do FFT to take out the DC component.

4. Extract the beat signal out of the FFT'd data.

5. Block the EOM.

6. Take another set of images of the AOM beam.

7. Take more(!) images, but this time of the background (blocking both EOM and AOM).

 

So the SCR is calculated by the ratio of the FFT'd DC and the 5 Hz signal. Using the CCD, I obtained the SCR to be 0.075 ± 0.01. Previously, we expected our SCR to be 0.09 as in the previous e-log entry.

The plot for that is:

SCR.jpg

 After measuring the SCR, I also measured the amplitude of the sideband and made an amplitude profile of the 40 MHz sideband.

The amplitude measurement is done as follows:

We know that the our 5 Hz signal consists of,

Sig = A_r * A_sb    where A_r = amplitude of the reference beam, A_sb= amplitude of the sideband

So, A_sb = Sig / A_r .

But,  A_r = sqrt ( P_AOM - Background),

Thus  A_sb = Sig / sqrt( P_AOM - Background) .

So the amplitude profile is done by taking the 5 Hz beat signal and dividing by the square root of the AOM beam minus the background light.

The plots looks like this:

DC_sig_sideband_profile.jpg

The solo sideband profile looks like this:

sideband_profile.jpg

Next we plan to trigger the camera with a 1 KHz signal and take snaps at n* T/4 (where n=0,1,2,3) of the period of the beat signal. So the plan is to trigger the camera at the point where the red dots appear in following cartoon.

sine_trig.jpg

Some more details of this setup will be posted later.

  

Quote:
 

 

Attachment 4: sine_trig.jpg
sine_trig.jpg
  3410   Thu Aug 12 16:18:46 2010 steveUpdateEnvironmenttiles and adhesive removed

Quote:

I powered down 1Y1 and 1Y2 instrument racks of MC and RF-systems this morning.

Both racks, SP table, clean tools-parts boxes and MC2 area are also covered with plastics.

Bertin Bros. Construction, Inc is working on the floor preparation. Their head man is Robby Bertin, cell 626. 831.2264

Today's job:

remove tiles, clean off tile glue, drill for ribbed  steel bars, rough clean- surface for good bounding. paint floor with bounding agent

Tiles and adhesive removed. There were no dust storms created. Solvent paint- removal made the hole IFO -lab smell like the paint shop.

The south door is open with a fan blowing air inside. The north-west door is open through control room to outside to let air rinse the drying

paint-removal. Koji is  taking lunch break while test riding our new PSL table legs.

Attachment 1: P1060604.JPG
P1060604.JPG
Attachment 2: P1060606.JPG
P1060606.JPG
Attachment 3: P1060603.JPG
P1060603.JPG
Attachment 4: P1060610.JPG
P1060610.JPG
Attachment 5: DSC_2388.JPG
DSC_2388.JPG
  3409   Thu Aug 12 16:18:00 2010 JennaUpdateElectronicsRb clocks overnight

I took a look at the data from the middle of the night to see if it was significantly quieter than the data from the day, but it doesn't seem to be. The plot shows data from yesterday around 12:30pm and from this morning around 2am. It's a bit quieter at low frequencies, but not by much.

Attachment 1: rbcomp.pdf
rbcomp.pdf
  3408   Thu Aug 12 14:01:53 2010 josephbUpdateCDScurrent status

First, awesome progress.

Second, the Binary Output parts do in fact need to be added to the c1sus model.  They don't need to appear in the IOP though.  (They are somehow automatically taken care of by the IOP code). 

It looks like in the 2004 revision in SVN, the cdsCDO32 part (located in the CDS_PARTS.mdl/IO_PARTS) was broken.  I fixed it and updated the svn with it, so a svn update should pull the corrected version.

I'm not sure whats wrong with the DAQs.  I'll try to take a closer look at the model file tonight and see if I can make suggestions.  When you write outputs on DAC_0 or DAC_1 is the C1SUS GDS TP screen showing anything?

  3407   Thu Aug 12 11:59:31 2010 kiwamuHowToCDSset up ntp daemom

(sad story)

When I was working on a new front end machine c1sus, I found that make command didn't run and gave the following message.

      "make:warning:clock skew detected.Your build may be incomplete"

This was caused by a clock difference between the nfs (nodus) and the terminal machine (c1sus).

I had to set up ntp daemon to synchronize them. Here is a procedure to set up it

 


(how to)

- log in to a front end machine

              ssh c1sus

- enable the ntp daemon

              sudo ntsysv

- configure the ntpd

              vi (emacs)  /etc/ntp.conf

- below is the contents I wrote on ntp.conf

             server 192.168.113.200  minpoll 4 maxpoll 4 iburst

      driftfile /var/lib/ntp/drift

 - let the daemon run
            sudo service ntpd start
- check it if it's running
             ntpq -p
  3406   Thu Aug 12 11:39:27 2010 ZachUpdateelogelog restarted

with script

  3405   Thu Aug 12 11:19:04 2010 kiwamuUpdateCDScurrent status

Current status of the new CDS test (summaries can be found on the wiki)

- Cables 

  All the necessary cables are in our hands, such as SCSIs, 37 pin D-sub and 3 pin power cables.

  With a big help from Jenne and Koji, we made 37 pin F/M cables and 3 pin power cables on the last Tuesday.

  Now all the cables are connected to the machines except for the 3 pin power cables.

  To install the power cables I will switch off Sorensens at new 1X5  for a minute.

 

- Suspension model file 

  The model file named C1SUS was made and I succeeded in compiling and building it. So it is ready for the test.

  But some medm screens look like not correctly complied.

  For example the channel names which are listed on C1SUS_MONITOR_ADC0.adl aren't correctly assigned.

 

- ADCs 

 All the ADC channels are working. Also the channel assignments are correct.

 I checked all the ADC channels if it was working while I ran the front end realtime code C1SUS.

 By injecting a signal from a function generator directly to the SCSIs, I could clearly see the numbers hopping on medm screens.

 

- DACs 

  None of them are working although the computer can recognize that all three DAC cards are mounted.

  I think something in the IOP file and the model file may be wrong because this symptom looks similar to that of C1ISCEX we tested two weeks before ( see this entry ) 

  I have to fix it anyhow because the DACs are very necessary part for this damping test.

 

- Binary Outputs

  They didn't work at all. Even the computer didn't recognize the binary output cards.

  I think I should put some magical components on the model files.

 

- Conversion of the filter coefficients 

  The conversion of the filter coefficients has been doen yesterday.

  It looks running well because I can load and unload these filters on medm screens.

  I manually copied the filter coefficients from the current suspension filter file to that of new filter file.

 The current file can be found under /cvs/cds/caltech/chans/,  and the new one is under /cvs/cds/rtcds/caltech/c1/chans


Suspended works

   - Binary Outputs

   - simlink realtime model with the new CDS PARTS ( see the notice from Joe )

 

To be done

   - let DACs work

   - damping tests

 

  3404   Thu Aug 12 10:56:31 2010 steveUpdateEnvironment dusty floor work in progres

I powered down 1Y1 and 1Y2 instrument racks of MC and RF-systems this morning.

Both racks, SP table, clean tools-parts boxes and MC2 area are also covered with plastics.

Bertin Bros. Construction, Inc is working on the floor preparation. Their head man is Robby Bertin, cell 626. 831.2264

Today's job:

remove tiles, clean off tile glue, drill for ribbed  steel bars, rough clean- surface for good bounding. paint floor with bounding agent

  3403   Wed Aug 11 16:56:00 2010 KojiSummaryEnvironmentCovering of the IFO

Katharine, Sharmila, Gopal, Kiwamu, Jenne, Aidan, Steve, and Koji

A guy from the carpenter shop has done the drilling work in the morning.

In the afternoon we wrapped the central part of the interferometer with plastic sheets in order to avoid the dusts from the tile ripping that will happen tomorrow.

Attachment 1: IMG_2732.jpg
IMG_2732.jpg
  3402   Wed Aug 11 16:38:02 2010 JennaUpdateElectronicsRubidium clock phase noise

Quote:

The units of this plot are rad/rt(Hz). I've no idea why it just says magnitude.

 This is a known thing (at least to me and Rana), so it's not just you.  When you put in some points like your PD Spec, the units disappear, and I've never figured out how to get them back while keeping the points.  Thanks for putting the units in your entry though.  If anyone else does know how to get the units to 'stick' where they're supposed to be, that would be helpful. 

  3401   Wed Aug 11 16:13:59 2010 JennaUpdateelogelog restarted

The elog crashed, so we restarted it again.

ELOG V3.1.3-