40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  ATF eLog, Page 33 of 56  Not logged in ELOG logo
ID Date Author Type Category Subject
  1192   Tue Dec 7 00:19:26 2010 ZachLaserGYROnoise budget-O-matic

 I have more-or-less finished a rough first draft of the automatic gyro noise budget MATLAB code. The rough architecture is:

  1. An M-file that obtains and saves the current gyro noise, by:
    1. Downloading a recent time series via NDS from the ATF frames
    2. Using pwelch to take the spectrum
    3. Saving the data and frequency vector as ASCII
  2. A "data" directory containing the above spectrum as well as ASCII spectra of all independently measurable noise contributions, such as:
    • PDH box output noises (V)
    • PD dark noises (V)
    • Displacement noise measurements for fundamental mechanical noise coupling estimates
    • Phase noise measurements
    • CCW and CW OLTFs
    • etc (this data library will be updated and amended as we go along)
  3. An M-file that calibrates all the data in (2), plots it along with (1), and generates a PDF. The current date and time are printed in the plot title. This file contains many adjustable parameters such as:
    • PDH box gain settings
    • AOM VCO deviation setting
    • Gyro signal -> ADC preamp gain
    • etc

In addition to this, there are two functions named "pdh1437" and "pdh2215" which contain analytical expressions for the two respective filters. They take as arguments 1) a frequency vector and 2) the appropriate box's gain setting and return a vector of the transfer function sampled at these frequencies. These are used wherever a spectrum needs to be multiplied or divided by the PDH gain.

The file in (2) takes the OLTF in each direction and divides by the correctly sampled PDH gain and actuator gain to obtain the optical response in V/Hz. This is used to calibrate voltage spectra into (rad/s)/rHz.

(1) is separate so that we can choose whether to pull the gyro noise from the frames or upload our own (e.g. an analog measurement), and there will be a single file that runs everything in one fell swoop.

Below is a sample output. In this case, I have used our analog measurement of the gyro noise from last week as I am still working out the kinks in the NDS method (for some reason, they don't come out quite the same). Obviously, this is still somewhat barebones and we will need to add in more noise sources as they come to us. The good thing is that---at long last---we will be able to simply press a button every time we want an up-to-date noise budget. If we make a change to the setup, it is simply a matter of dropping the new data into the "data" directory and re-running.

NoiseBudget.pdf

 

  1191   Mon Dec 6 16:31:15 2010 ZachLaserGYROCCW-CW noise spillover analysis

 Attached is a recent analysis of the "noise spillover" from the primary loop to the secondary (rotation sensing) loop. The plot shows the frequency noise as measured in 1) the primary error signal and 2) the secondary actuation signal. The idea here is that whatever noise is not removed by the primary loop (i.e. the error signal) should be attacked by the secondary loop. In the limit of an ideal secondary loop, the correctly calibrated signals should be exactly equal (that is, the rest of the noise is exactly cancelled by the secondary actuator).

The calibrations are:

  • AOM actuation: 6.103 x 10-4 V/ct * 1/42 (INMON gain) * 500,000 kHz/V (VCO gain)
  • CCW error signal: 6.103 x 10-4 V/ct * 1/50 (SR560 preamp gain) * (1 / 3 x 10-7 V/Hz) (CCW optical response)

CCW-CW_spillover_12_6_10.png

It appears as though the gyro noise is in fact dominated by residual common-mode noise above about 30 Hz. Below this, some other source contributes more strongly. The noise here is roughly 300x higher than the expected fundamental gyro noise from displacement, so this suggests that some other non-ideal condition is at fault.

  1190   Fri Dec 3 12:16:10 2010 AlastairComputingPurchasesThe router saga continues

I had word that the router shipped today.  Should be here Monday, or Tuesday at the latest.

 

Quote:

I finally got through to someone at (**insert name of offending company here**) to ask about our router order for the ATF.  It turns out that although it is now out of stock and discontinued they had not bothered to let us know.  So not only is the router used at the 40m not available, but the next model up in the range has also been discontinued.

I have therefore ordered this one instead as it appears to be the last wired router that linksys offer.  I guess we could have substituted a wireless one but I'm not sure that would have gained us anything.

The specification list on the linksys website is pretty vague:

Model: BEFSR41
Standards: IEEE 802.3, IEEE 802.3u, IEEE 802.1p
Ports: Four 10/100 RJ-45 Switched Ports
One 10/100 RJ-45 Port for Broadband Modem
Warranty: 1 year hardware limited warranty
Lifetime award-winning online support tools

I'm assuming it will allow all the port forwarding settings etc that we need.

 

  1189   Thu Dec 2 17:11:36 2010 FrankComputingPulserhardware & software updates

made the following changes to optimize the quantity and quality of data taken:

  • reduced camera image size to region of interest by using a special camera function where you only read a defined area of the camera chip. Image size is now 640x480 showing only the photodiode.
  • added white LED to get some slight illumination in order to see where the chip actually is on the picture. White LED can be turned on/off via individual hardware channel (dev1/port1/line3)
  • had some timing issues showing part of the pulse in some of the pictures. changed code to avoid that.
  • added cylindrical lens to compensate for angle of red laser beam hitting the target
  • added control for pixel clock, exposure time, hardware gain, area of interest etc.
  • changed JPEG compression level to minimum compression (value 1000)
  • reduced resolution for dark noise spectrum to reduce measurement time. Now total cycle time is about 15min for 200 pulses and all data taken. Pictures are taken after every single pulse.
  • increased step size for i/v-curve to 20mV. Taking now 1005 points from 100mV (forward bias) to -20V (reverse bias).
  • Taking independent measurements at -10mV and 10mV to calculate shunt impedance.

 

  1188   Thu Dec 2 16:03:01 2010 FrankComputingDAQexternal framebuilder acces to fb0 fixed

people complained about not be able to access fb0 from outside the lab, but fb1 was working.
I turned out the the default gateway on fb0 was set to 10.0.0.1 instead of 10.0.1.1.

fixed that and now everything is fine...

  1187   Thu Dec 2 15:48:05 2010 AlastairComputingPurchasesThe router saga continues

I finally got through to someone at (**insert name of offending company here**) to ask about our router order for the ATF.  It turns out that although it is now out of stock and discontinued they had not bothered to let us know.  So not only is the router used at the 40m not available, but the next model up in the range has also been discontinued.

I have therefore ordered this one instead as it appears to be the last wired router that linksys offer.  I guess we could have substituted a wireless one but I'm not sure that would have gained us anything.

The specification list on the linksys website is pretty vague:

Model: BEFSR41
Standards: IEEE 802.3, IEEE 802.3u, IEEE 802.1p
Ports: Four 10/100 RJ-45 Switched Ports
One 10/100 RJ-45 Port for Broadband Modem
Warranty: 1 year hardware limited warranty
Lifetime award-winning online support tools

I'm assuming it will allow all the port forwarding settings etc that we need.

  1186   Wed Dec 1 13:34:04 2010 ZachLaserGYROcurrent gyro noise budget

 Attached is a current gyro noise budget. It has not yet been fully automated, but Koji wanted to have something to look at this afternoon so I made this one by hand. One very nice thing to note here is that the current gyro sensitivity is clearly limited by the dark noise of the PDA255 REFL diodes above ~20 Hz, which we suspected but until now haven't substantiated.

A couple notes:

  • The PDA255 dark noise was only plotted as it affects the primary loop, as the second loop appears to have ~5x higher optical gain [V/Hz]
  • Shot noise and demod noise do not currently appear as the current REFL noise is dominated by the PDA255 dark noise, as shown here.

gyro_nb_12_1_10.png

  1185   Wed Dec 1 02:01:34 2010 FrankComputingPulserCamera problems on IBM computer

spent hours now to figure out why the camera image taken contains only black data when using my program and example programs but working fine with the camera manager utility and everything working fine on two other computers.No error occurs, nothing, just no data.

But now i got it !: the pixel-clock is too high for that computer and is higher by default than using the camera manager software which obviously must reduce the pixel-clock when getting started. After debugging the shit i started adding all options and playing with it, like frame rate etc - nothing helped. But reducing the pixel-clock from 25MHz to 10MHz and suddenly real data is available from the data . So probably the USB or the computer is too slow (it's USB2.0, the camera complains about being connected to something slower). That's my only explanation.

  1184   Tue Nov 30 19:03:21 2010 FrankComputingDAQfb0 working again - fsck forced

after having issues with a non-working frontend yesterday we rebooted fb0 (using a clean software shutdown and reboot) to bring it back up in a clean state without zombi processes or so.
While booting it was bitching about file system errors which the system couldn't fix on it's own automatically and requested mandatory manual repair.
So i started a manual fsck for sdc1 and Zach was answering all the questions "should we fix whatever is broken" with yes. It finished the check 5min ago and i rebooted the machine again.
Now everything is running, including frontend code and framebuilder.

  1183   Tue Nov 30 12:59:16 2010 FrankComputingPulserswitched computers for pulsing experiment

Since the other computer stops working on a regular basis i finally installed and tested all software on the old IBM notebook we had in the lab. Installed Labview 2009 and the Vision package (30-day trial licenses) on that computer  and tested everything. Seems to work fine so far. I went away from the compiled executables as i'm still changing little things from time to time which means that i have to make a new compilation every time. Now having the full development version installed i can modify the code on the exact same computer whenever i want.

  1182   Tue Nov 30 11:03:55 2010 AlastairThings to BuyGYROvacuum gauge for gyro system

 I realised that I had not bought a vacuum gauge for the gyro system.  The simplest solution seemed to be to use a wide-range gauge so we don't need to worry about damaging the gauge if the pressure creeps up too high.  I've ordered a combination gauge from Kurt Lesker that gives atmosphere down to 1e-9 Torr with an analogue output so we can hook it up to a DAQ channel.

  1181   Mon Nov 29 22:01:29 2010 AlastairComputingDAQissues

Quote:

 The NDS server has been inaccessible from the outside for some time. I checked the port forwarding settings and they look correct, so this might have something to do with the router. Alastair ordered it some time ago so perhaps it is in.

In trying to troubleshoot this issue, I noticed that---when accessing the data with DV from within the network---I couldn't look at data from more than a few minutes ago. While I was on the diagnostics MEDM screen, I noticed that the FB indicators flashed red every few minutes and then went back to normal. This is just about the right timescale to explain why only very recent data is viewable.

In trying to troubleshoot this issue, I unacquired some channels (in case the DAQ rate was too high, which I don't think it was) and tried restarting daqd in the usual way. Then all hell broke loose, and the process wouldn't stay running for more than about a minute, during which the indicator was red all for except a few brief green flashes (with errors).

I enlisted Frank's help. We tried restarting the front end and then the diagnostic indicated no sync signal. Finally, we decided to reboot fb0 to see if that helped. While booting, it found an error and forced a disk check, which is probably still running now.

I will try to get it running again in the morning, and then see if I can get the new router swapped in and get NDS visible.

 I've not seen the new router in yet.  I have emailed Gina to ask her to look into the status of this order.  The techmart info says that it was ordered on 9th Nov, and it was in stock when I ordered it.

  1180   Mon Nov 29 20:29:57 2010 ZachComputingDAQissues

 The NDS server has been inaccessible from the outside for some time. I checked the port forwarding settings and they look correct, so this might have something to do with the router. Alastair ordered it some time ago so perhaps it is in.

In trying to troubleshoot this issue, I noticed that---when accessing the data with DV from within the network---I couldn't look at data from more than a few minutes ago. While I was on the diagnostics MEDM screen, I noticed that the FB indicators flashed red every few minutes and then went back to normal. This is just about the right timescale to explain why only very recent data is viewable.

In trying to troubleshoot this issue, I unacquired some channels (in case the DAQ rate was too high, which I don't think it was) and tried restarting daqd in the usual way. Then all hell broke loose, and the process wouldn't stay running for more than about a minute, during which the indicator was red all for except a few brief green flashes (with errors).

I enlisted Frank's help. We tried restarting the front end and then the diagnostic indicated no sync signal. Finally, we decided to reboot fb0 to see if that helped. While booting, it found an error and forced a disk check, which is probably still running now.

I will try to get it running again in the morning, and then see if I can get the new router swapped in and get NDS visible.

  1179   Mon Nov 29 19:42:23 2010 AlastairElectronicsGYROphotodiode plans

 Here is the plan for our generic PD board.  It is designed to be used in three different readout configurations:

1) Transimpedance amplifier

2) Resonant PD (using capacitance of the photodiode in resonant circuit)

3) Resonant notch readout.

IC4 is the main RF readout.  The inputs have jumpers to allow it to be connected in either inverting or non-inverting configuration.  The output of this goes either directly to the output of the box (for transimpedance readout) or can go to IC5 which will be an RF amplifier (probably from this company).

IC3 gives DC readout (except for transimpedance design) using a transimpedance setup to connect L1 to ground.  At very high frequencies we bypass this using a capacitor to ground.

The diode is biased through a resistor giving a second DC readout option.  IC1 reads out the voltage across this resistor differentially.  Frank suggested using the setup with IC2 to keep the voltage at the photodiode constant (otherwise when the photocurrent changes, the voltage drop across the resistor will also change causing a change in diode bias).

Attachment 1: photodiode_diagram.pdf
photodiode_diagram.pdf
  1178   Fri Nov 26 19:43:34 2010 KojiLaserGYROGyro OLTFs and current noise spectrum

It seems that the gyro noise level looks much better than that in entry 1150. Can you overlay the improvement of the gyro signal?

Note that your latest gyro signal is not valid above 1kHz considering you only have OLG of less than 10 above 1kHz.
(i.e. error in the noise level estimation is more than 10% above 1kHz unless you conpensate the effect of the control.)

- I wonder how I can obtain 0.67 (rad/s)/V from this formula... (In other word, I like to know the freq stability measured by the VCO.)

- How do we characterize / reduce the low frequency noise? Does going to vacuum really improve this noise? What is expected?

- Where is the VCO phase noise level now?

- We definitely need to have better PHD circuit. Probably we can use the box but should replace the board.

- We should start to look at the beat signal.

Quote:

500 kHz/V (VCO gain) x (c * 3.15 m) / (4 * 0.62 m2) ~ 0.67 (rad/s)/V

 

  1177   Fri Nov 26 13:00:20 2010 ZachLaserGYROGyro OLTFs and current noise spectrum

 Here is a plot of the CCW and CW loop OLTFs as measured on Wednesday afternoon. They both have a UGF around 12 kHz with a phase margin of 20 degrees for the CW loop and a lousy ~7 degrees for the CCW loop

oltfs_11_23_10.png

Here is the current noise plot as measured in the AOM feedback signal. The level is about the same as before. The calibration is

500 kHz/V (VCO gain) x (c * 3.15 m) / (4 * 0.62 m2) ~ 0.67 (rad/s)/V

gnoise_11_23_10.png

Now that I have current OLTF models I can continue with the list here

  1176   Wed Nov 24 23:57:13 2010 FrankMiscPulserimproved setup finished

Added another channel using a small transistor to turn the red laser on and off.  Will keep the shutter open when taking pictures even the 1064nm light causes some strange pattern on the diode chip. Should be OK as we are only interested in changes of whatever initial pattern we get. Turning off the 1064nm light would require to close the shutter every time i take a picture. So far i'm planning on taking a picture after every pulse, which would mean 50k-100k of shutter cycles per pulse energy setting. That's way beyond the expected lifetime of the shutter.

I've also added a cylindrical lens to compensate for the large elliptical beam coming from the large angle at which i hit the surface if the diode. No i have a round spot illuminating the active area.

Will do some first measurements with the new setup over the holiday/weekend.

  1175   Tue Nov 23 23:36:12 2010 FrankMiscPulseradded digital camera readout

added the readout for the USB CMOS camera watching the scatter from the photodiode surface.

Right now i think i will take a picture after every single pulse even if the amount of data will be very high.
Pictures will be individually saved in a slightly compressed JPEG to not delete much of the valuable information about the changing surface.

If i don't safe them i can't really handle the amount of data (1.3MB per picture, usually 1000 pulses per cycle, so far about 50 cycles, so 65GB of data).
Each picture will also be a frame of a movie. So there will be a movie and hundreds/thousands of individual pictures per cycle.

The photodiode is illuminated by the extra red laser diode. Everything is working so far except that i have to add another switch to turn the red laser on/off before/after pulsing cycle (where i'm taking the pictures) to do all the other measurements.

  1174   Tue Nov 23 11:55:04 2010 ZachLaserGYRObackscatter problem

 Yesterday was fun...

I started from where I left off, trying to direct the AOM-passed beam to the cavity and get the TEM00 through, but then I noticed that the PBS for the AOM isolation setup was transmitting a fair amount of light, so I had to realign it to minimize this (the setup is that the S light from the CCW/CW separating PBS goes to a second PBS and then into the AOM, hits a QWP twice on the double-pass and then emerges as P and passes through the second PBS again and to the rest of the experiment).

I then had to completely realign the AOM again, which I did and got ~50% double-pass efficiency again, but then I noticed the same ~2 MHz oscillation in the primary REFL PD signal again when i was trying to lock the cavity and sweep the other direction. This time, however, it could not make it go away by increasing the power (using the HWP at the experiment input) as I could before. I thought perhaps it was the PD, so I switched it out for the other PDA255 we had for the CW REFL, but it saw the same effect. I turned off all the RF oscillators and connected the PD supplies to several different power strips to try and eliminate any ground loops (also, the PDs are on insulating posts).

I then noticed that adjusting the drive current and, sometimes, the temperature of the NPRO made the effect go away or at least stop for a short while. I disconnected the slow and fast actuation signals and meddled with it a bit by hand with the knob, but couldn't see anything obvious except that with a low enough drive current (~half the usual value) it stopped oscillating. The shape of the junk also changed depending on the current and temperature.

I enlisted Frank's help, and we systematically went through the experiment, placing diodes at pickoff spots and adjusting optics one-at-a-time until we found the source. We traced it back all the way to the initial high-extinction PBS at the input to the experiment. We noticed that changing the ratio of admitted and rejected light caused the effect everywhere downstream, so we thought it might have something to do with scattered light. In the end, this appears to have been the case, as PBS had some strange ghost beam reflecting inside and clipping on the custom mount. We think that when the power was high enough this would reflect back into the laser and interfere, causing the oscillation.

We made the effect pretty much go away by moving the thing slightly so that the ghost beam wasn't clipping anymore, but Frank thinks that we might want to replace it anyway since it shouldn't produce a ghost beam by design. I am going to inspect it now and then realign everything. One day I'll get back to the loop measurements.

  1173   Sun Nov 21 16:24:06 2010 ZachLaserGYROrealignment, etc

I did the EOM sweep measurement. It looks like we are fine above ~30 MHz, but the junk at low frequencies could explain why we had excess RFAM at, say, 18 MHz. The plot and a diagram of the experimental setup are below.

EOM_TF.pngEOM_sweep_setup.png

The source level was the maximum 15 dBm, the frequency range was 1-100 MHz (linear) over 801 pts (maximum) with 30 averages. The RFAM amplitude is now back below about -80 dBm for the standard DC PD voltage of 100 mV we have been using. Note: the strange ~2 MHz oscillation for low incident power remains...

I also reconfigured the AOM double-pass setup, realigning the polarizing optics and extracting the double-first-order beam. I was able to get ~50% efficiency (~125 mW out / 250 mW in), or a single-pass efficiency of ~71%. Tomorrow I will direct this beam into the cavity and maximize transmission, then continue with the loop measurements.

 

Quote:

Remember that you still have to check the crystal for resonances. Sweep the EOM and look at the CCW PD with the cavity blocked internally. The mechanical Q of the crystal can be ~1000s, so it needs to be a fairly fine sweep.

If there are resonances close to the 33 MHz, you'll have to tune it off a little bit. And where's the sketch for the Pomona matching circuit?

 

 

  1172   Sat Nov 20 15:02:05 2010 ranaLaserGYROrealignment, etc

Remember that you still have to check the crystal for resonances. Sweep the EOM and look at the CCW PD with the cavity blocked internally. The mechanical Q of the crystal can be ~1000s, so it needs to be a fairly fine sweep.

If there are resonances close to the 33 MHz, you'll have to tune it off a little bit. And where's the sketch for the Pomona matching circuit?

 

  1171   Fri Nov 19 20:09:57 2010 ZachLaserGYROrealignment, etc

 I have realigned the primary beam from scratch; the spots are now centered fairly exquisitely on each of the cavity mirrors, as well as on all of the pre-cavity optics downstream of the input optics that Koji adjusted on Wednesday. I also aligned CW/CCW splitting PBS better.

I had somewhat of a difficult time getting everything to lock again very stably, but it appears to stay locked indefinitely now. Some notes:

  • Regarding the RFAM, I wanted to verify that it was still minimal after I got things working again. I reduced the experiment input power to the point where the DC level on the REFL PD was ~100 mV, as in Koji's post. The RFAM had increased from -85 dBm to about -75 dBm, but this was still the minimum level achievable by rotating the HWP before the EOM. Though it has gotten worse slightly, the large RFAM swings we were seeing before appear to have gone, and the cavity stays locked, so it looks like Koji fixed it. The DC error offset on lock is ~20 mV in INPUT_MON, and so it's < 1 mV in the actual error signal.
    • A somewhat more troubling issue is that, for some reason, the DC signal from the PD appears to oscillate at ~2 MHz for incident power levels corresponding to lower than a few hundred mV. At 100 mV, there is a peak-to-peak swing of almost 50 mV. This exists with and without the LO on.
  • I had trouble keeping the loop under control at low frequency, so I increased the gain on the MEDM filter module for the thermal loop from 0.05 to 0.1, which it accepted without becoming unstable.
  • I was still seeing some weird effects wherein the TRANS DC level on lock would hop up and then lose lock, or generally switch between levels. I thought this might have to do with some sideband coupling, so I increased the modulation frequency back to the original value of 33 MHz, which is fine now that we are using fast diodes again.

Next up:

  1. Realign the AOM and extract the 1st-order double-passed beam
  2. Direct this to the cavity and maximize TEM00 coupling
  3. Reinstall second faraday isolator and reconfigure CW REFL readout

(side note: we still need a modematching telescope for the CW beam)

After this, I can go back to the other list I made concerning loop measurements and beyond..

  1170   Thu Nov 18 09:27:18 2010 KojiLaserGYRORFAM & Sprious RF coupling
  • Checked the alignment of the beam at the input optics
  • Checked the RF leakage to the PD.
  • It turned out the isolation transformer and the cable at the function generator caused the main leakage source.
  • By removing them the leakage was improved 20~30dB.
  • At the end of the experiment the RFAM level (RF leakage + RFAM) was -85dBm for the beam of ~100mVDC
  • The alignment of the interferometer is now totally screwed up.

 1. Alignment check of the IO

The original angle reads of the wave plates were 316deg and 38.0deg for the QWP and HWP, respectively.
The beam power before the EOM was 284mW.

  • FIrst, the wave plates after the laser were adjusted so as to minimize the PBS transmission.
  • The PBS was also aligned to minimize the transmission.
  • With the angle setting of 318.2deg and 78.3deg, the power of 48uW reached the EOM.
     
  • Rotated the HWP to maximize the PBS transmission.

At the last state, with the angle of 318.2deg and 33.7deg, the power of 284mW reached the EOM.

  • Beam alignment to the EOM was checked. It was OK, but the slight touch of the alignment was made.

After the adjustment the power after the EOM was 274mW. The transmission efficiency of 96.5% sounds pretty fine.

2. RF leakage investigation

  • The primary cavity RF PD was aligned to the beam. I temporarily removed the attenuation mirror. The DC output (with 50ohm) was 90.9mV
  • I tried to minimize the 18MHz RFAM by tuning the HWP for the EOM.
  • I minimized the RFAM but I noticed that the amount of the RF is comparable with and without the beam
     
  • The leakage RF power at 18MHz was ~70dBm. This corresponds to the RIN of 10-3. It was there even without the beam on the PD.
     
  • I tracked down the cause of the leakage and found that the leakage power was reduced when the cable between the isolation transformer and the coupler is replaced to the SMA cable.
  • Another discovery was that the leakage decreased when the isolation transformer is removed.
  • See the attached photo 1.

  • The overall improvement was 20-30dB (seen in the attachment 2) although the peak height is continuouwly changing.
     
  • It is always difficult to understand how the RF leakage is improved: The isolation transformer isolate the grounding of the RF source and the others. The line is somehow grounded at various places. Maybe at the EOM or/and the LO ports? They may have not low impedance to the reference ground of our system and cause fluctuation of the voltage level on the table, the aluminum frame of the table, or the power line. Then they couples to the PD???
  • I imagine that we previously cancelled the RF leakage by putting an artificial RFAM by the EOM. But both the amount of the leakage and the RFAM was always changing. They may have caused the locking problem.

3. RFAM adjustment

  • Now I went back to the HWP before the EOM. The HWP was adjusted to minimize the RFAM peak (forgot to record the angle!).
    Also Yaw alignment of the EOM was slightly adjusted to minimize this peak further.
  • The resulting RF leakage of -85dBm was recorded. Shown in the attachment 3. This corresponds to the RIN of 2x10-4.

4. Power supply AC path

  • I noticed that one of the AC tap is obtained the power from the ceiling while another one is taking the power from the wall.
    (Attachment 4)
    Is this what you really want? I am afraid of having big ground loop.
     
  • Suggestion:
    • Get some isolation transformers for the AC / define the grounding point of the experiment.
    • Also ground the optical table and the Al frame.

 

Attachment 1: cabling.jpg
cabling.jpg
Attachment 2: reduction.jpg
reduction.jpg
Attachment 3: IMG_3714.jpg
IMG_3714.jpg
Attachment 4: IMG_3715.jpg
IMG_3715.jpg
  1169   Mon Nov 15 23:03:39 2010 ZachLaserGYRORFAM

On Friday evening, I acquired the primary error signal into the ADC with the cavity obstructed so that it would not resonate. I tuned the HWP before the EOM so that the error signal was centered about zero. I wanted to see if the RFAM was truly oscillating in amplitude or just monotonically increasing to some level after I had minimized it. Here is a short (5-hour) time series beginning right around then. The following 48 hours looked essentially the same, with a slight variation in the oscillation period and peak-to-peak level.

err_drift.png 

Today, I tried to get a quantitative handle on the RFAM level, but I was sidetracked by the weird behavior. I once again tried to minimize the circular light getting through the input optics by iteratively adjusting the initial QWP and the HWP immediately after it and minimizing the P light getting through the PBS. I was able to obtain a maximum contrast of 55.5 uW to 159 mW over the full range of the HWP for the optimal QWP setting, so that only ~0.03% of the light remained circularly polarized.

Then, I adjusted the HWP just down the line (immediately before the EOM) to center the far-from-resonance error signal about zero. I observed the same drift as before. I then put my hand on the metal case of the EOM and the drift increased rapidly, indicating that the time dependence of the RFAM is likely due to thermal coupling.

I verified that the beam was not clipping on either end of the EOM (there was some scatter from the edges of the beam, but the spot was centered on the aperture). I tried changing the alignment slightly to see if the drift lessened, but this failed.

I then tried swapping out the HWP for another---no dice. Then, I swapped the EOM for another broadband ThorLabs modulator of the same model. This seemed to work for a few minutes, as the drift appeared less pronounced, but it worsened quickly. It also responded the same way to the "grab the damn thing" test.

An interesting observation: the HWP orientation that minimizes the RFAM when looking at the signal from the PD on the RF analyzer IS NOT the same one that centers the error signal DC level at zero (in fact, the cavity will not lock at this setting). Conversely, when the error signal is centered at zero by setting the HWP, the PD signal shows strong RFAM (~40 dBm above noise level). This is baffling.

As my frustration was maturing, I caught the following sight (several of them, actually, but this was the only one I froze in time) on the scope:

TEK00000.PNG

Green is TRANS_DC, yellow REFL DC, blue ERR_INMON (note the offset), and purple the actuation signal to the PZT. The cavity has been locked for quite some time, but the slow loop is not engaged. As the length of the cavity slowly drifts, the feedback signal hops discretely from one level to another. This particular one is about a 3.5-volt step, corresponding to about 14 MHz. I am no expert, but this looks to me like some sort of mode hopping. There is not (and has never been) a dedicated faraday isolator at the experiment input, so I think it is quite possible that back-reflections are getting back into the laser head. From what I understand, mode hopping is uncommon in a short NPRO, and I'm not sure how this would affect the output polarization of the laser, but it seems suspicious. By the time I gave up, the circular light contrast had decreased by a factor of more than 4 (i.e. the minimum achievable power with the same QWP orientation was > 200 uW).

 

 

 

  1168   Sat Nov 13 11:37:03 2010 ZachElectronicsGYROchannels acquired

That's just a measure of the total rate at which data is getting acquired. I'm not sure of the units, but for comparison, we were above 1000 before we reconfigured everything (including the channels that Dmass was using).

Come to think of it, "LASER_PZ_ACT_EXC" is not really the channel we want for transfer functions (at least not of the fast loop) because this excitation will go to the temperature control. I have connected the gyro TEST out #1 to the PZT SWEEP input of the primary PDH box, so this is the channel that we should use. I will switch them.

Quote:

Quote:

I acquired the necessary channels for the gyro. They are:

  • AOM_ACT_OUT (32k)
  • LASER_PZ_ACT_IN1 (32k) - CCW fast feedback
  • LASER_PZ_ACT_OUT (256) - CCW slow feedback
  • CW_ERR_OUT (32k)
  • CCW_ERR_OUT (32k)
  • DC_TRANS_OUT (256)
  • LASER_PZ_ACT_EXC (32k) - excitation channel for TFs

We will need to add the TEST input and output channels as we need them, as well as the REFL DCs when that information is available.

Current DAQ rate = 919

 What does this DAQ rate=919 thing mean?  Is it not running at 32k?

 

  1167   Fri Nov 12 23:12:18 2010 AlastairElectronicsGYROchannels acquired

Quote:

I acquired the necessary channels for the gyro. They are:

  • AOM_ACT_OUT (32k)
  • LASER_PZ_ACT_IN1 (32k) - CCW fast feedback
  • LASER_PZ_ACT_OUT (256) - CCW slow feedback
  • CW_ERR_OUT (32k)
  • CCW_ERR_OUT (32k)
  • DC_TRANS_OUT (256)
  • LASER_PZ_ACT_EXC (32k) - excitation channel for TFs

We will need to add the TEST input and output channels as we need them, as well as the REFL DCs when that information is available.

Current DAQ rate = 919

 What does this DAQ rate=919 thing mean?  Is it not running at 32k?

  1166   Fri Nov 12 17:56:48 2010 ZachElectronicsGYROchannels acquired

I acquired the necessary channels for the gyro. They are:

  • AOM_ACT_OUT (32k)
  • LASER_PZ_ACT_IN1 (32k) - CCW fast feedback
  • LASER_PZ_ACT_OUT (256) - CCW slow feedback
  • CW_ERR_OUT (32k)
  • CCW_ERR_OUT (32k)
  • DC_TRANS_OUT (256)
  • LASER_PZ_ACT_EXC (32k) - excitation channel for TFs

We will need to add the TEST input and output channels as we need them, as well as the REFL DCs when that information is available.

Current DAQ rate = 919

  1165   Fri Nov 12 12:56:47 2010 ZachLaserGYROtime-varying RFAM

 This morning, I started fresh with this error signal offset issue. I put a beam block in the cavity so that it would not resonate and tried the following things:

  • First, I just tried to null the offset by adjusting the angle of the HWP before the EOM (as I did yesterday).
    • I observed a drift in the error signal at roughly 1 mV per 2-3 minutes. This doesn't seem like much, but it is fatal to the lock loop.
  • Then I adjusted the input QWP to ensure that the beam was linearly polarized on the way in (by iteratively adjusting it and the HWP following it to make the power on one port of the PBS go to zero).
    • The drift was still there after re-nulling the error signal
  • Finally, I decided to analyze the beam coming out of the EOM by circumventing most of the experiment.
    • I removed the HWP following the EOM and installed two steering mirrors to direct the beam to the dedicated steering mirror of the REFL CCW PD (PDA225)
    • I then adjusted the power to a reasonable level and plugged the signal from the PD into the RF analyzer
    • Since pure PM should not show up in the spectrum (the carrier beats with the two sidebands cancel each other out), while AM does, I purified the modulation by eliminating the peak at fmod = 18 MHz
    • Within 5 minutes or so, the peak had grown out of the noise floor by ~20 dBm (noise floor = -98 dBm, peak height = -80 dBm)

Therefore, it appears that there is some (strong) time dependence to the amount of RFAM we get out of the EOM. It's not clear to me why this wasn't an issue before we put in the new PDs, but I guess several things have changed in the past week or two. The experimental setup is below.

RFAM_setup.jpg

  1164   Thu Nov 11 23:53:12 2010 ZachLaserGYROTO DO

 This is a list of what needs to be done next.

  1. Understand and fix error signal offset problem
  2. New OLTFs
  3. Obtain new cavity responses (in V/Hz) with PDA255s using (2) and known actuation/PDH gains
  4. Characterize notch filter to extend loop characterization and electronics noise influence beyond 10 kHz
  5. Produce current noise budget (including new electronics noise info) and gyro noise spectrum, update SVN
  6. PDA255 characterization
    1. Measure noise directly (RF analyzer)
    2. Compare with spec and expected noise from circuit
  7. Modify PDH box(es)
    1. Reduce gain range in order to increase gyro optical power and utilize maximum optical gain without instability
    2. Replace OP27s with faster op amps to improve UGF phase margin
  8. Repeat (2-5)

In parallel:

  • Finalize CDS setup and procedures
  • Write MATLAB code to automate gyro spectrum generation (make it plot this along with current NB)
  • Investigate servo noise level
    • Is it too high to benefit from better RFPDs? If so, make sure that custom design is not (actually, do that either way...)
  • Altium: RFPDs and custom servos
  • Fancy stuff:
    • Remote/automatic BOOST/slow loop control
    • Autolock script
  1163   Thu Nov 11 23:15:14 2010 ZachLaserGYROupdate

 [Zach, Koji]

Yesterday, we replaced the CW REFL PD with the second PDA225. We noticed that turning it on made the output rail so we did some debugging and found that the switch was broken. Koji did some magic and got it working again. We also changed the CCW REFL setup so that we could point the beam at the PD better (before, we didn't have room for a full mount between the faraday isolator and the gyro enclosure, so we had fixed up a lens mount to do the job and had to use the focusing lens and PD height to center the beam).

The InGaAs diodes have a much better response to 1064 nm so---even with the maximum screening from a Y1S-45---we had to reduce the input power to the experiment in order not to cause the loop to oscillate. (This was, of course, after we turned the gain of the PDH box all the way down to "0.0". We should modify the PDH box to have lower gain so that we can turn up the optical power without the loop becoming unstable).

We hooked everything up and got the gyro fully operational again, with both directions locking well. The measured primary loop had a UGF of ~12 kHz with a puny phase margin of ~8 deg. The thought here is that we should swap out the slow OP27s in the PDH box for faster op amps  (in the short term) and eventually design our own servo.

We also noticed that there was a significant DC offset in the primary error signal. We guessed that this was from RFAM from the EOM, so we adjusted the orientation of the HWP before it to minimize it.

We hooked the following signals up to CDS:

ADC:

  • Both error signals
  • Both feedback signals
  • TRANS DC
  • Primary PDH box TP2 (for OLTF measurements)

DAC:

  • TEMP control out (this has been there, of course)
  • PZT SWEEP out

Today, I came in to find that the gyro was not locked. When I got it locking again, I noticed that the PZT drive was sitting close to the rail and the slow loop was doing nothing about it. I played around with the slow loop filter and got it into a reasonably stable configuration (pole @ DC, zero @ 0.1 Hz to cancel the internal pole of the PZT).

As I changed settings in the slow loop, I noticed that the cavity was having a hard time locking again. I realized that the error signal offset had returned, and a slight rotation of the HWP brought the cavity back into a lockable state. I decided to remove all other variables by sweeping the PZT directly (as opposed to through the PDH box) and looking at the error signal directly (as opposed to through INMON). I then rotated the HWP to minimize the error signal offset, retuned the phase shift to maximize the response, and then adjusted the input power to make it as high as possible without an oscillation.

Things seemed to be working, but then the same error offset issue came back. I am not sure what it is, but it needs to be investigated thoroughly. This is the plan for tomorrow morning.

 

 

 

  1162   Thu Nov 11 01:37:35 2010 FrankMiscPulserdiode blasting setup changed - added CCD camera

added a ccd camera and a macro lens to monitor changes in surface scatter. I'm using a 670nm diode laser module for illumination.
Due to the added ccd camera i had to change the way i make the whole setup dark in order to be able to measure the dark current and dark noise.
Using a black trash bin to cover the entire setup. Drilled and tapped a 1" hole in on side where i attached the beam tubes which connect to the shutter.
Have to work on the cable feedthroughs and replace the netbook with the IBM notebook. Installed all software today but didn't have time to test it.

Here first pictures of the new setup: red: diagnostic beam, blue: 1064nm beam.
Everything has to fit between the area between the black baseplates on the table (top, left & right of the picture) minus ~0.5" for the trash bin.

 setup.jpg

covered setup with shutter attached to the right. Trash bin has adhesive-backed foam on bottom (window insulation) as cushion to seal against the table

100_1147.JPG

first sample picture taken from monitor showing scattered light from diode active area taken in the dark with some additional white led light to see the diode structure

100_1140.JPG

  1161   Wed Nov 10 18:49:01 2010 ranaLaserGYROPDA255 noise

 You ought to measure the PDA255 noise with the RF analyzer and compare it to the spec and the thermal noise you expect from such a diode.

Is the demodulator noise of the PDH box good enough for our purposes? i.e. will we reap the benefit of a good PD or not?

  1160   Wed Nov 10 11:28:34 2010 ZachLaserGYROPDA255 noise

 Below is a plot of some noise measurements on the PDA255 with which we have replaced the old PDA10A as the primary REFL diode. The traces are:

  1. PD connected, shutter closed (dark noise)
  2. PD connected, 367 uW power incident, no EOM
  3. PD connected, 367 uW power incident, EOM on
  4. Noise with 50-ohm terminator in place of PD (demod noise only)

I realized that last time I did this I simply turned off the oscillator to take the no-EOM data. This is wrong because it also turns off the LO to the mixer, so the PD signal is not getting mixed down. This time, I physically disconnected the EOM to take this trace.

PDA255.png

The plot is not very illuminating, except in that it shows that the noise in the demodulation setup is dominated by the dark noise of the PD. As seen in a previous post, the dark PD noise level is above but comparable to the input noise of the PDH box above ~1Hz. Below this---in our frequency band of highest interest---the PDH input noise dominates at the moment. The same linked plot shows that the theoretical noise estimate for the PDH input is substantially lower than the measured noise at low frequencies, so the PDs will certainly limit us if we get it to this level.

It goes without saying that both the final PDs and the final servo should contribute much less noise than these do.

  1159   Wed Nov 10 01:52:22 2010 AlastairComputingComputingWiki is down...

Quote:

Quote:

Seems fine, now...

Quote:

 The ATF wiki is down.  So is the 40m one.  The elogs are still running and I can ssh into Nodus which is where the ATF wiki now lives.  I'm having a bit more of a look at this now.

 

That is strange.  I had also forgotten that the 40m wiki isn't hosted at Caltech.  I still can't get access to either of them.

 

I suspect that the problem is actually at this end.  I tried another computer and a desktop with a wired connection and neither worked.  It's strange though because I would have assumed that although it's weird port number on the wiki's server, I would still be using a normal port number at this end since I'm accessing it through a browser (or is this not the way it works?).

  1158   Wed Nov 10 01:46:53 2010 AlastairComputingComputingWiki is down...

Quote:

Seems fine, now...

Quote:

 The ATF wiki is down.  So is the 40m one.  The elogs are still running and I can ssh into Nodus which is where the ATF wiki now lives.  I'm having a bit more of a look at this now.

 

That is strange.  I had also forgotten that the 40m wiki isn't hosted at Caltech.  I still can't get access to either of them.

 

  1157   Wed Nov 10 01:21:49 2010 KojiComputingComputingWiki is down...

Seems fine, now...

Quote:

 The ATF wiki is down.  So is the 40m one.  The elogs are still running and I can ssh into Nodus which is where the ATF wiki now lives.  I'm having a bit more of a look at this now.

 

  1156   Wed Nov 10 01:15:34 2010 AlastairComputingComputingWiki is down...

 The ATF wiki is down.  So is the 40m one.  The elogs are still running and I can ssh into Nodus which is where the ATF wiki now lives.  I'm having a bit more of a look at this now.

  1155   Tue Nov 9 12:57:30 2010 ZachElectronicsGYROPrimary PDH box noise assessment

 Below is a comparison of the measured input-referred noise of PDH box #1437 with the estimated noise from LISO. It appears that the measured noise is substantially higher below around a kHz. The only thing not included in the model (besides shielding capacitors, etc.) is the AD8336 variable gain stage, but unless this is a limiting noise source it should not contribute to the input-referred noise. The LISO model output is provided below, as well.

1437_noise_assessment.pngScreen_shot_2010-11-09_at_12.42.38_PM.png

  1154   Tue Nov 9 02:18:36 2010 alastairComputingComputingrouter ordered

 I've ordered the new router.  Joe tells us that the 40m router is a Linksys BEFSX41  , however this model doesn't seem to be available anywhere (unless you count secondhand ones on amazon....) even on the linksys website.  Instead I have ordered the next one up in the range which appears from the specs to be the same router but with 8ports.  It is a BEFSR41.  Should be with us in approx 2-3days as it was in stock.

  1153   Tue Nov 9 01:38:50 2010 ZachLaserGYROTektronix VCO / NPRO PZT actuation calibration

 [Zach, Koji]

Last week, we did some work towards calibrating the actuation gains of the VCO and NPRO PZT, which was documented in Koji's elog posts. This post summarizes the method.

First, a sine wave with a nominal amplitude of 10 mVpp @ 1 kHz was injected into the PZT sweep of the primary PDH box, and the peaks in the primary error and feedback signals were recorded, as well as that in the secondary error signal (which was being held in the linear response region by the main servo):

  • Primary error: 685.2410 uVrms
  • Primary feedback: 98.7438 uVrms
  • Secondary error: 64.9701 uVrms

Note that the error signals were being read out at INMON, so they are multiplied up by ~42.

Next, the same drive signal was connected to the Tektronix VCO external FM input, with a nominal deviation setting of 100 kHz/V and a carrier frequency of 47.5 MHz (as usual). The output was then connected to the RF analyzer to study its frequency structure and determine the modulation depth.

The structure of an FM signal in frequency space consists of a carrier and a series of sidebands at integer numbers of the modulation frequency from the carrier, whose powers are determined by the bessel expansion. I.e., the nth sideband will be at a frequency fc + n*fmod with a power Pn = ( Jn(Γ)/J0(Γ) )2 * Pc, where Γ = Δf / fmod is the modulation depth and 2*Δf is the peak-to-peak amplitude of the frequency modulation.

The powers of the sidebands were measured (in dBm) and divided by the carrier power, and this array of values was fit to the appropriate array of bessel function ratios to obtain a modulation index and therefore an FM amplitude. Below are two plots, one for the 1-kHz excitation mentioned above and another for the same test done with a 100-Hz excitation with the same amplitude, which is more impressive and used more points.

FM_fit_1k.pngFM_fit_100.png

The inferred peak-to-peak FM deviation was thus ~993 * 2 = 1986 Hz. Since the FG displays the voltage for a 50-ohm load, this value is reasonable as the external FM input has an impedance of 10kohm. So, 0.01 mVpp (*2 for display error) * 10K/(10K + 50) * 100 kHz/V ~ 1990 Hzpp.

This signal was put into the AOM and elicited a peak of 247.258 Vrms in the secondary loop error signal. Since the AOM is double passed, the true optical deviation was 2 * 1986 = 3972 Hzpp. This implies that, when it was put into the PZT sweep input, the same injection caused a deviation

(64.9701 uVrms / 247.258 uVrms) * 3972 Hzpp = 1043 Hzpp.

Using the signal strength in the PZT feedback path from above, we can infer a PZT actuation gain of

GPZT = 1043 Hzpp / (98.7438 uVrms * 2*sqrt(2)) = 3.734 MHz/V

  1152   Mon Nov 8 22:37:33 2010 ranaComputingComputingfb0/fb1 user ID and group ID changed to controls=1001

 Frank and I had to play some games with openmotif/grace/medm to get things going again. Basically, the EPEL repo should be added to all of the linux machines using rpm.

Then, we must install grace from the EPEL and this will also install the correct 64 bit openmotif which is used by MEDM (Motif Editor and Display Manager). As of now, dataviewer

and DTT and MEDM are working on most machines.

Attachment 1: Untitled.png
Untitled.png
  1151   Mon Nov 8 17:26:38 2010 ranaComputingComputingfb0/fb1 user ID and group ID changed to controls=1001

I changed over the user/group ownership of the /frames subdirectories to controls for both fb0 and fb1. Lets see if this is correct.

I also updated the firmware on the linsys router, turned off uPnP, and also turned off DHCP (as a test). I've been noticing that what happens

lately is that the connection to the outside world just goes away sometimes and then comes back after a few minutes. This along with

the fact that our bandwidth to our own LIGO network is only 600 kB/s makes me think that the issue is on Larry's side of the table.

  1150   Mon Nov 8 17:18:14 2010 ZachLaserGYROelectronic noise contributions

 Below is a plot of one particular gyro signal channel along with various electronics noise contributions to the gyro signal in general. The traces are:

  1. The secondary error signal with the secondary loop open (but the primary closed, so that the error signal is kept within the linear regime). This gives a linear output proportional to the measured frequency mismatch between the two cavity directions, and is thus a form of gyro signal. Typically, we would lock the second loop and read this out at the feedback point, but it is useful to do this way as an intermediate measure when trying to characterize the loops.
  2. Noise at the INMON of the primary box with the laser off, divided by 42 to obtain the level at the true servo input.
  3. Same as (2), but for the secondary loop.
  4. Noise at the INMON of the primary box with a 50-ohm terminator in place of the PD (i.e. noise in the demod electronics).
  5. Output noise of the primary PDH box with the input terminated, divided by the estimated analytical transfer function of the box with G = 0.5 (as when the noise spectrum was measured).

All of these signals were then divided by the cavity response in [V/Hz]---which are all the same except for in (3)---and then multiplied by (lambda P / 4A) to obtain spectra in units of (rad/s)/rHz. The input-referred noise of PDH 2 is not shown, but given the same output level would result in roughly 10x the noise contribution to the gyro signal due to the roughly 10x lower optical response of the cavity in the secondary direction.

e-noise_contribs.png

  1149   Mon Nov 8 13:42:06 2010 FrankMiscPulserincreased pulse energy again

now 300mJ (20W and 15ms). Beam diameter still 1mm.

I keep increasing the pulse duration until i see first damage of this already heavily used diode to see where the damage threshold is, then use go back a little bit an use a new, unused diode to see if i can measure changes in parameters.

  1148   Mon Nov 8 11:42:03 2010 FrankComputingPulserNetbook frozen again

after ~1.5 the netbook stopped working again. Will switch to the old IBM notebook tomorrow. Jan is using it right now as a backup computer.

  1147   Mon Nov 8 00:21:43 2010 ZachLaserGYROPrimary loop unsuppressed frequency noise

Below is a comparison of the "unsuppressed" primary loop frequency noise with the free-running NPRO noise taken from Rana's thesis (p.80). The primary error signal was multiplied by the OLTF to obtain the unsuppressed voltage noise at the servo input, and this was then divided by the cavity response quoted in the previous elog post to obtain the unsuppressed noise in Hz. The plot shows that the gyro cavity displacement noise is ~10-100x higher than the free-running laser noise up to a few kHz.

unsup_freq_noise.png

  1146   Mon Nov 8 00:15:21 2010 ZachLaserGYROprimary loop self-consistency check

 By using the measured NPRO PZT actuation gain of ~4 MHz/V, along with an analytical model of the PDH box and primary OLTF, I estimated a cavity response of roughly 5.6 x 10-8 V/Hz. Using this, I calibrated both the primary error signal and feedback signal into units of frequency to see that they were consistent. The calibrations are

  • Feedback signal: multiply by the PZT actuation gain in [Hz/V] and divide by the OLTF (to get the suppressed noise)
  • Error signal: divide by the cavity response in [V/Hz]

The plot below demonstrates that they are self-consistent. Note that this is only done up to 10 kHz because I have not made an analytical model of the notch filter yet.

fnoise_self-check.png

 

  1145   Sun Nov 7 21:47:10 2010 ranaComputingComputingfb0/fb1 user ID and group ID changed to controls=1001

As is the standard mandated by CDS, I have converted the UID for controls to 1001 and the groupID of the controls group to 1001 and made the user controls be a member of the controls group only.

I had done this on ws1/ws2 before and there were naturally inconsistencies with it and fb1. I have just now done it fb1 and then fixed up many files by doing:

chgrp -R controls *; chown -R controls *

in /cvs/cds/caltech/ and in /opt/

There will certainly be short term negative consequences of this action, but its better we do it sooner than later. I'll have to get some Seifert consultation to finish fixing fb0.

  1144   Sun Nov 7 15:13:29 2010 FrankComputingPulsernetbook frozen

netbook was frozen the second time this weekend. Software installations didn't change since a week (since i'm using it for the pulsing experiment).
We have seen this before when using it for the wincam or the particle counter, but very rarely.
Now it happend twice within 24h, once after ~23000 pulses, second time after ~6000 (3h of operation after reboot)

Will restart the measurements...

  1143   Sat Nov 6 23:48:02 2010 ranaComputingComputingws1 is back, almost

The network interface for ws1 was failing to work for some reason. I tried the usual Linux forums for advice but most of it was useless.

Finally one of them suggested that there was a warm power up v. cold power up issue with the Realtek 8169 Network card chipset.

So I turned off the machine and then reformatted the disk and did a fresh install. The network is now working (allowing this elog access).

But then...I realized that (someone) gave me a 32-bit install DVD and so I'm now wiping it and starting over.

ELOG V3.1.3-