We've provided acoustic excitation using speakers on the AS table and saw that PSD of YARM feedback signal increased in the frequency range 50 - 100 Hz. Meanwhile, XARM feedback signal did not change. Moreover, YARM noise is much higher at these frequencies compared to XARM.

The problem was with YARM oplev servos. Both ITMY and ETMY produced noise to YARM length. ITMY oplev signal had a huge resonance at 55 Hz. We measured coherence with accelerometers, it was 0.8. It turned out that one of the mirror mounts was not fixed in the oplev path. When we fixed it, noise has gone.

Note: speakers were on AS table but mirror mounts could steel feel it on ITMY table.

Then we had a look on ETMY table. We saw a mirror on suspiciously long mirror mount that was used in the ETMY oplev path. We slightly kicked long mount with a small screwdriver and YARM control signal went up with resonance at 100 Hz.

 c1ass was really useful today when we slowly aligned PZT and servo kept arms aligned to the input beam. I think it is possible to automate phase and matrix measurements. DRMI servo will be very useful.

Today I tried to investigate the mode in PRCL and MICH. I locked them but power build-up was only 27. The beam on the POP camera looked like interference of 00 mode and a long strip of fringes. (I wanted to make videocaptures but script is not working - the problem is that it is looking for /usr/lib/*.so.4 libraries but they were updated to *.so.5, I made a few links .so.4 -> .so.5 but this kept going for many libraries, so this should be fixed in a better way). 

We looked at PRM and BS faces and they had the same shape - interference of a circle with a strip. There were also a lot of bright spots all over the frames. Loops were closed and circle was not moving. Strip was oscillating at ~1Hz and also its position significantly changed with alignment. Looking at PRM face camera we made a conclusion that the length of the strip is ~5 cm and width ~1cm. Interesting that strip has plenty of power - approximately 10 times of transmitted beam when cavity is not locked. As a result POYDC was oscillating at the same frequency as a strip.

 This looks like a good performance tuning for these. It would be good if you can codify this procedure in the wiki so that even unexperienced people can tune up the system after reboots or vacuum work.

Is it possible to have some python scripts automatically measure and set the phases and matrices? If so, can we also run them iteratively so that after the second run we can confirm that they have converged? Then the script can output a short report of numbers telling us how well the system is now tuned.

I suppose that there is also a similar system possible to align the arms in a continuous way; i.e. low level drives and very low bandwidth. Also something fast / slow for the the DRMI.

Today I've set c1ass model to improve alignment of X and Y arms. I've added all measured parameters to ASS scripts. I've also added a script to c1ass.adl that downloads calculated OFFSETs to corresponding ASC filter banks and blocks outputs. It should be called after alignment convergence.

XARM phase rotation and sensing matrix

Output gains were (-0.5, 0.5, -0.25, -0.25). XARM Gain was set to 0.5.

YARM phase rotation and sensing matrix

Output gains were (-0.25, 0.25, 0.7, -0.7). YARM Gain was set to 0.8.

I have started making the circuit to measure the transimpedance for the photodiode PDA10CF using Jenne's laser. I will continue it tomorrow.

The NDS2 protocol is not for non-DQ, but the NDS2 client is capable of talking both the NDS1 and NDS2 protocols.

fb:8088 is an NDS1 server, so the client is talking NDS1 to fb.  It should therefore be capable of getting online data.

It doesn't seem to be seeing the online channels, though, so I'll work with Leo to figure out what's going on there.

The old mex functions, which like I said are now available, aren't capable of getting online data.

  Don't try to re-invent the mic mount: just copy the LIGO mic mount for the first version.

NDS2 is not designed for non DQ channels - it gets data from the frames, not through NDS1.

For getting the non-DQ stuff, I would just continue using our NDS1 compatible NDS mex files (this is what is used in mDV).

I wanted to center beams on the XARM cavity mirrors using c1ass model. I've run XARM setup script and then turned dithering on. Cavity went out of lock because calculated offsets were incorrect.

I was using TRX only and calculated rotation phases for ITM and ETM pitch and yaw. For this I've added a low pass filter into Q-quadrature bank and made DC value at the output to be zero by adjusting the phase. I've put gains (+1 or -1)  in the I quadrature such that output was positive.

Then I've set the sensing matrix to identity as I decided to deal with separate loops. Of coarse, they are mixed by the cavity, but at least in the control system they are distinguished. Old matrix summed error signals in one degree of freedom from both mirrors. This makes more sense but still not precise because coils are not ideally diagonalized.

Then I've adjusted gains for control loop for every degree of freedom. I've ended up with (0.1; 0.1; 0.1; -0.1). I did not use large gains as I wanted slow convergence because of the demodulation low-pass filter time response constant of 20 sec. Coupling (I quadrature) was reduced from (0.9, 0.3, 2.4, 1.2) to zeros (0-0.1) in ~5 minutes, TRX increased from 0.73 to 0.90.

There is one thing that I do not understand yet. I think controllers should minimize angle -> length coupling that is proportional to I-quadrature if phase is correct. But phase depends on alignment and when the feedback loops are on, phase drifts. I could see it during my measurement. But I did not find any script that smoothly tunes phase such that coupling is all in I-quadrature. I guess this is not hard to set a gradient descent algorithm that minimizes DC value of Q-quadrature. Or how this is usually done?

 In order to see the acoustic coupling on arm signals, I set 6 microphones and the speaker on the AP table. The microphones are not seismically isolated for now.
I have a signal generator under the AP table.

When I played the 43 Hz triangular wave sound, I could see some coherence between POY error signal and microphones even though there is no peak in POY.

To Do:

• Try to subtract the acoustic signal and see with which microphone the acoustic signal can be subtracted best. But how can I find whether the signal is subtracted or not? Is coherence information enough?
• Make circuits for microphones to come to 40m.
• Make suspension systems for microphones. One idea is that the microphones should be suspended from bridges which is to be put around at the top of the tables since there is no space for stacks for each microphones.
• Prepare a new ADC.
• Perform the same measurements at the other tables, such as POX and POY.

 I've tried new nds2 Java interface in Matlab. Using findChannels method of the connection class I see only slow, DQ and trend channels. I could even download data online using iterate method. When it will be possible to do the same with fast non-DQ channels?

>> conn = nds2.connection('fb', 8088);
>> conn.iterate({'C1:LSC-XARM_OUT'})
??? Java exception occurred:
java.lang.RuntimeException: No such channel.
    at nds2.nds2JNI.connection_iterate__SWIG_0(Native Method)
    at nds2.connection.iterate(connection.java:91)

 The connectors can be plugged into the BOSEMs if we loosen the two screws which hold down the mini-D connector and the flex circuit.  Tighten the screws after the connector is pluged in.

I've installed the new nds2 packages on the control room machines.

These new packages include some new and improved interfaces for python, matlab, and octave that were not previously available. See the documentation in:

  /usr/share/doc/nds2-client-doc/html/index.html

for details on how to use them.  They all work something like:

  conn = nds2.connection('fb', 8088)
  chans = conn.findChannels()
  buffers = conn.fetch(t1, t2, {c1,...})
  data = buffers(1).getData()

NOTE: the new interface for python is distinct from the one provided by pynds.  The old pynds interface should continue to work, though.

To use the new matlab interface, you have to first issue the following command:

   javaaddpath('/usr/lib/java')

I'll try to figure out a way to have that included automatically.

The old Matlab mex functions (NDS*_GetData, NDS*_GetChannel, etc.) are now provided by a new and improved package.  Those should now work "out of the box".

Please leave here what was the instruction by Bran and Suresh so that the other people can redo it sometime later!

BS chamber seemed to be kicked again around 10:00 am today.

I moved PZT mainly in YAW and locked both arms. I adjusted the beam to be almost on the center of both ETM by sights.

 Using instructions from Bram and Suresh, I was able to plug in connectors to BOSEMs. Today I've tested electronics, everything works good. Jamie made an medm screen and channels for TTs. Sliders for pitch and yaw go from -100 to 100 counts. Calibration to angle is 1e-5 rad / count.

TTs are in the clean room waiting for installation.

In order to have less unknown, you can calibrate the PMC PZT separately. Lock the PMC and take a transfer function from either the NPRO PZT input or the FSS AOM VCO input to the PMC control signal. The VCO is better, since the calibration should be much better known, but I am not sure what the current setup of the 40m PSL is, so I don't know if the FSS is normally locked.

Since you know the NPRO PZT or VCO actuation coefficients, you can assume the PMC loop (where the OL gain is high enough) is correcting for the frequency fluctuations. So, simply multiply the known coefficient by the transfer function to get the PMC PZT gain.

Then, you can re-do your PMC PZT sweep measurement and be confident of the calibration. The FSR must be right, so you can get the finesse with confidence.

PRM oplev gains set to zero from PIT 0.15 and YAW -0.3 and damping restored

CALIFORNIA INSTITUTE OF TECHNOLOGY

                 FACILITIES MANAGEMENT

**PLEASE POST**

Building:         Campus

Date:             Thursday October 04,2012

This morning at 2:17 a.m. much of the City of Pasadena including our Campus experienced a electric power sag of short duration, approximately 1/10 of a second. The cause was a fault on one of Pasadena’s 17KV circuits. Some sensitive equipment have been impacted.

Contact:          Mike Anchondo x-4999

  If you can't find the PMC sidebands in the transmission, its because the SNR is too small.

It may be a better idea to look at the PMC error signal, since the DC signal there is suppressed by the demodulation.

In order to calibrate MC_F signal, I need to know the calibration value from thorlab's PZT driver to laser frequency.
The calibration value should be ~ 15MHz/V (the PZT driver has 15 gain, and the laser has the calibration value of ~ 1MHz/V according to the laser spec sheet), but I want to confirm it.
This can be measured by sweeping the input voltage of the PZT driver and see the transmission signal from unlocked PMC.
 

1. Response of PMC transmission when the signal is inputted to laser PZT

I inputted 0.2 Hz triangular wave with 5Vamp and 2.5V offset into the PZT driver and see the transmission signal from PMC. After the PZT driver and before the laser, there is an analog low pass filter but its cut off frequency is 1 Hz so I did not take it into consideration. 
(TEK00000.CSV, TEK00001.CSV in the zip file)

I could not the side-band resonances. I guess it was because the generated signal is not big enough (but still the maximum range of the signal generator.)
Therefore, in order to calibrate the input voltage to the frequency, I need to know finesse or FWHM frequency.
 

2. Responce of PMC transmission when the voltage of PZT on the PMC is swept

In order to measure the finesse and FWHM frequency, I also swept the PMC PZT voltage with the DC offset slider at the FSS.adl and tried to measure the finesse of PMC. (reference: elog #904)
(PMC-PZTcal_121203.xml in the zip file)

The result of fitting:

V_FSR (the PZT voltage difference between the 2 resonances) ~ 63 +/- 7 V (= 731MHz (given))
V_FWHM (the PZT voltage to sweep FWHM) ~  0.32 +/- 0.04 V (~ 3.7 MHz)
Finesse ~ 200 +/- 30

However, this finesse value is much smaller than the value on the Wiki, 800. (Manasa showed me.)
V_FSR is comparable to the result Rana got at the referenced elog. But I am not sure about the V_FWHM because it is hard to figure out how large the PZT voltage changed from the template file (PMC-PZTcal.xml).
Are those mode wrong? But if so, where is the correct mode resonances? I think they should be visible...
 

3. Calibration value 

When I know the FWHM frequency, I can calibrate the input on the PZT driver into laser frequency.

The results are:

if I take the finesse of 800 and FSR of 731 MHz (the values on the Wiki): ~5.0 MHz/V
if I take the finesse of 200 and FSR of 731 MHz (the measured value): ~20.0 MHz/V

Actually, the measured value is closer to the value calculated from the spec sheet.

Hmm... Does anyone find falses in my measurement?
If not, the finesse can be 4 times smaller than the value which was 5 years ago?

 BT EM172 microphones  are ordered.

 I'm taking full responsibility for this action and I told them after lunch Friday.

HOW NOT TO:

The BS isolation stack  supported by two beam tubes and they can pivot around the pivot point.

 This week I've got all TT stuff baked and today was testing eddy current damping and electronics.

In the beginning everything was good: ring magnets fit mirror holder holes and their interaction with actuation magnets is strong enough to keep damping magnets in the wholes. I've put the frame horizontally and kicked it, magnets were still in the whole. Brackets also fit to the TT frame.  

I've tested eddy current dumping during ring down measurements, it was strong enough.

Then I started to test electronics. I've provided signal to TT1 channels and could see it in the clean room. But then things went terrible. I just could not connect TT cables to OSEMS, there is not enough space in the OSEM for the connector to plug in.

Connector should be machines to be more narrow. There is actually no reason for a connector to have this shape. I think it was designed to fit perfectly the OSEM frame but turned out to be ~0.5 mm wider then it should be.

I have updated the wiki with the layout of the out-of-vac optical tables: Updated optical tables

I used the new camera to take pictures.

Lesson learnt after the update:

To use the new canon to take better pictures of optics tables; set the camera to manual mode; no flash and iso at around 800 or higher if you can hold the camera still for that long. The autofocus works beautifully...so you will not need any minor tweaking of lens to take pictures. 

 Whoever was working around the BS chamber at 11 AM on Friday should admit it now and take the punishment.

For those of you who like to do work on the interferometer without reporting it in the elog because you think that what you did doesn't affect anything, this is your example of how our time can be wasted by such laziness.

Today at 11:13 AM the stack of invacuum BS table was kicked and IFO misaligned. We adjusted PZT2 voltage by ~20 V in yaw such that IPPOS was restored. Then we could lock arms.

 Adaptive filtering was applied to MC and X,Y arms at the same time. I used a very aggressive (8 order) butterworth filter at 6 Hz as an AI filter for MC not to inject noise to ARMS as was done before

Mu for MC was 0.2, downsample = 16, delay = 1. I was able to subtract 1 Hz. Stack subraction is not that good as for arms but this is because I used only one seismometer for MC that is under the BS. I might install accelerometers under MC2.

EDIT, JCD, 18Feb2013:  Den remembers using mu for the arms in the range of 0.01 to 0.1, although using 0.1 will give extra noise.  He said he usually starts with something small, then ramps it up to 0.04, and after it has converged brings it back down to 0.01.

 3 of the 4 remote controlled illuminators at the vertex are installed and can now be turned on via sitemap. There are a total of 15 controls for "Illum", but only the 3 labeled with MC, BS-PRM and ITMY-SRM are functional.

 I actuate on ETMY for YARM and ETMX for XARM. For now I did adaptive filtering for both arms at the same time. I used the same parameters for xarm as for yarm.

I've notched 16 Hz resonance because it has high Q and I need to think more how to subtract it using FIR filter or apply IIR.

I'll try MC stabilazation method.

This is how to post PDF:

From DTT, print the plot as a postscript file.

Then use ps2pdf to make a archival PDF version (the flag is the key!). Example:

ps2pdf -dPDFX /home/controls/Desktop/darm.ps

This is interesting. I suppose you are acting on the ETMY.
Can you construct the compensation filter with actuation on the MC length?
Also can you see how the X arm is stabilized?

This may stabilize or even unstabilize the MC length, but we don't care as the MC locking is easy.

If we can help to reduce the arm motion with the MCL feedforward trained with an arm sometime before,
this means the lock acquisition will become easier. And this may still be compatible with the ALS.

Why did you notched out the 16Hz peak? It is the dominant component for the RMS and we want to eliminate it.

Aluminum foil replaced by sheet metal on Enclosure and AP table.

Clean cabinet S15 doors were left open. You have to lock it up!

I've applied FIR adaptive filter to YARM control. Feedback signal of the closed loop was used as adaptive filter error signal and OAF OUT -> IN transfer function I assumed to be flat because of the loop high gain at low frequencies. At 100 Hz deviation was 5 dB so I've ignored it.

I've added a filter bank YARM_OAF to C1LSC model to account for downsampling from 16 kHz to 2 kHz and put low-pass filter inside.

I've used GUR 1&2 XYZ channels as witnesses. Bandpass filters 0.4-10 Hz we applied to each of them. Error signal was filters using the same bandpass filter and 16 Hz 40 dB Q=10 notch filter. As an AI filter I used 32 Hz butterworth 4 order low-pass filter. Consequently, AI, bandpass and notch filters were added to adaptive path of witness signals.

I've used an FIR filter with 4000 taps, downsampling = 16, delay = 1, tau = 0, mu = 0.01 - 0.1. Convergence time was ~3 mins.

 First of all, STS-2 is in the end of X arm, GUR2 is under BS, GUR1 is in the end of Y arm.

BLRMS were small because we applied calibration from counts to um/s two times. In the past we had calibration in the RMS BP filter bank (vel2vel = FM2). Now we have calibration in the seismometer input filter bank so we can save calibrated _OUT channels.

[Den, Ayaka]

We found that seismometer was working and the calibration in the filter banks should have been wrong.
We turned off the all FM2 filter in RMS filter banks.

We also installed STS seismometer. It is under the BS. Now we have spectrum of three seismometers.

RA: the above plot is kind of unreadable and useless. Please replace with something legible and put in some words about why there is a wrong filter, what exactly it is, etc., etc. etc. And why would you leave in a filter which is not supposed to be on? We might as well leave a few secretly broken chairs in the control room...

 The problem was caused by low reflectivity of the mirror that splits MC reflected beam into two: first goes to trash, second - to WFS. Power before the mirror was 100mW, reflected beam that goes to WFS was 0.3mW. Using dataviewer we learnt that the beam intensity was ~5 times more in the past.

This happened because the mirror position was adjusted a few days ago. Its reflection depends on the angle of incidence and amount of light to WFS was significantly reduced. We could either increase the angle of incidence or use two mirrors with high reflectivity instead of this with high transmission.

We've chosen the second variant not to confuse anyone in future with non-45 degrees angles. We are now using one mirror with reflectivity 98% to direct most power to the trash while other 2% are directed using the second mirror to WFS path. We now have 0.7 mW on WFS1 and 1.3 mW on WFS2.

Then we adjusted WFS 

• blocked the beam and run scripts/MC/WFS/WFS_FilterBank_offsets to calculate offsets in the WFS servo
• aligned MC and centered beams on WFS 1 and 2
• provided excitation to MC1 at 5 Hz (400 counts) and adjusted I&Q phase rotation
• adjusted the gain and changed it in MC autolocker (reduced from 0.25 to 0.15 as we now have more power of WFS as before)

We were able to close the loops. The phase margin is too low though, we need to improve feedback filters.

 I have been searching for the way we can subtract signal better since I could see the acoustic coupling signal remains in the target signal even though there are no coherence between them.

I changed the training time which is used to decide wiener filter.
I have total 10 minutes data, and the wiener filter was decided using the whole data before.

(Right: the performance with the data when the triangular sound was created. Left: the performance with the data when the gaussian sound was created.)

I found that the acoustic signal can be fully subtracted above 40 Hz when the training time is short. This means the transfer functions between the acoustic signals and MCF signal change.
However, if the wiener filter is decided with short-time training, the performances at lower frequencies get worse. This is because wiener filter do not have enough low-frequency information.

So, I would like to find the way to combine the short-time training merit and long-time training merit. It should be useful to subtract the broad-band coupling noise.

The attached plots display RMS noise from various accelerometers and seismometers over the past 90 days. One can see how after the reinstallation of the seismometers in November, RMS from the GUR1Z and GUR1X channels decreases by a factor of about 100 from data in August. Additionally, the RMS over the course of the last 90 days has notably decreased in all instruments. In many cases, the RMS is only the result of inherent electronics noise, rather than from a signal.

An error this evening on rossa: dataviewer not working due to some font errors:

controls@rossa:~ 0$ dataviewer
Connecting.... done
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning:
    Name: FilterText
    Class: XmTextField
    Character '\52' not supported in font.  Discarded.

Warning:
    Name: FilterText
    Class: XmTextField
    Character '\56' not supported in font.  Discarded.

Warning:
    Name: FilterText
    Class: XmTextField
    Character '\170' not supported in font.  Discarded.

Warning:

etc.............

Koji and I figured out what the problem is.  Apparently firefox 17.0 (specifically it's user-agent string) breaks fckeditor, which is the javascript toolbox the elog uses for the wysiwyg text editor.  See https://support.mozilla.org/en-US/questions/942438.

The suspect line was in elog/fckeditor/editor/js/fckeditorcode_gecko.js.  I hacked it up so that it stopped whatever crappy conditional user agent crap it was doing.  It seems to be working now.

Edit by Koji: In order to make this change work, I needed to clear the cache of firefox from Tool/Clear Recent History menu.

 I ve tested another bandpass filter today with similar set-up. This time I took the data with corrected reference level. To set this reference-level the filter was disconnected and the cable was connected "thru" according to the instructions provided in the manual of AG4395A at http://cp.literature.agilent.com/litweb/pdf/04395-90040.pdf, page 3-10. The transfer functions are as follows 

Spare optics from the AP table were moved to glass cabinet in the east arm. I'm not sure this is the right place. We'll see what everybody thinks.

There were two UNMARKED optics. Shame on you! No pencil marks on the optics either. These optics were shipped to the FBI for finger tip analysis.

Jeff is still working on the filter banks.

 It took 15 days to reach 1e-5 Torr

The RGA was turned on yesterday. The rga scan plotting was not working. Den wrote a Python script to log and plot because the Mathlab had trouble receiving data from our old c0raga.

It turned out that the Joe's log&plot system was working today. Thanks Den and Joe.

Here is the first rga scan.

 Done.  The beam is also going vaguely in the direction of POP110, but I can't see the beam, so it's tricky. 

Order of operations:

1. Find POP on the table, place iris so I wouldn't forget.  Find beam by putting big IR card where I think beam should be, look at IR card with IR viewer.

2. Move and re-clamp 2" lens so beam is on center of lens.

3. Move and re-clamp 1st (2") mirror so that beam is on center of mirror. 

4. Remove BS-33% so that all the beam goes to POP55, steer that 1st mirror so beam is on POP55's little mirror.  Align little mirror so beam is centered on POP55 (as seen by looking at PD with viewer, finding "edges" of PD, going back to center).

5. Put BS-33% back in place.  The reflected portion of this beam is not possible to see using card+viewer technique.

6. Remove BS-50% that reflects half of this beam to POP110.  Find beam reflected from BS-33% by waving POP camera around.  Steer BS-33 until beam goes back in the direction that the camera used to be mounted.  Adjust camera mount and BS-33 so that beam is on camera.

7. Put BS-50% back in place.  Steer it around with voltmeter on PD to see if beam ever hits PD.  Unsuccessful. Give up, since we have POP55, and POP camera.

8. Make a youtube video: POP, AS, REFL, ITMXF (all on Quad3) - PRMI coarsely aligned, no IFO parts locked.  MICH was locked earlier, but not during video time.

 Last Thursday, I put the speaker and my laptop in the PSL table, and make triangular wave sound with the basic frequency of 40Hz, and Gaussian distributed sound.
(I create the sounds from my laptop using the software 'NHC Tone Generator' because I could not find the connector from BNC to speaker plug.)
And I measured the acoustic coupling in MCF signal. The all the 6 microphones were set in PSL table around PMC and PSL output optics. 

The performance of the offline noise cancellation with wiener filter is below.
(The target signal is MCF and the witness signals are 6 microphones.)

• With Gaussian sound (Sorry for wrong labeling 'XARM' and no calibration)
  
• With 40Hz Triangular sound (Sorry for no calibration again)
  

I can see some effects on MCF due to the sound on PSL table. Though I can subtract some acoustic signal and there are no coherence between MCF signal and mic signals, still some acoustic noise remains.
This is maybe because of some non-linearity effects or maybe because we have other effective places for acoustic coupling measurement. More investigations are needed.

Also, I compared the wiener filter and the transfer function from microphones signal to MCF signal. They should be the same ideally.

(Left: Wiener filter, Right: Transfer function estimated by the spectrum. They are measured when the Gaussian sound is on.)

These are different especially lower frequencies than 50 Hz. The wiener filter is bigger at lower frequencies. I guess this adds extra noise on the MCF signal. (see the 1st figure.)
The wiener filter can be improved by filterings. But if so, I want to know how can we determine the filters. It is interesting if we have some algorithms to determine the filters and taps and so on.
The more investigations are also needed.

I grabbed the a plot of the iLIGO PSL frequency noise spectrum from the Rana manifesto:

Rana's contention is that this spectrum (red trace) is roughly the same as for our NPRO.

From the jenne/mevans/pepper/rana paper Active noise cancellation in a suspended interferometer I pulled a plot of the calibrated MC_L noise spectrum:

The green line on this plot is a rough estimate of where the above laser frequency noise would fall on this plot.  The conversion is:

    L / f  =  10 m / 2.8e14 Hz = 3.5e-14 m/Hz

which at 10 Hz is roughly 1.5e-11 m.  This puts the crossover somewhere between 1 and 10 Hz.

 After some system updates this evening, firefox can no longer handle the html input encoding for the elog.  I'm not sure what happened.  You can still use the "ELCode" or "plain" input encodings, but "HTML" won't work.  The problem seems to be firefox 17.  ottavia and rosalba were upgraded, while rossa and pianosa have not yet been.

I've installed chromium-browser (debranded chrome) on all the machines as a backup.  Hopefully the problem will clear itself up with the next update.  In the mean time I'll try to figure out what happened.

To use chromium: Appliations -> Internet -> Chromium