m * x = (x_G - x) * k + d(x_G - x) * b
x w0^2 + i*w*w0/Q
---- = -----------------------
x_G w0^2 + i*w*w0/Q - w^2
d (x - x_G) ( w0^2 + i*w*w0/Q ) . w^2 .
dt = ( ----------------------- - 1 ) * x_G = ----------------------- * x_G
( w0^2 + i*w*w0/Q - w^2 ) w0^2 + i*w*w0/Q - w^2
noise in m/s = -------------------
10 * 802(V/(m/s))
Symptoms: Belladonna could not (for a while) connect to the wireless network, since there was a driver problem for the wireless card. This (I believe) started when Yoichi was doing updates on it a while back.
The system: Belladonna is a Dell Inspirion E1505 laptop, with a Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card (rev 01)
Result: Belladonna now can talk to it's wireless card, and is connected to the Martian network. (MEDM and Dataviewer both work, so it must be on the network.)
What I did:
0. Find a linux forum with the following method: http://www.thelinuxpimp.com/main/index.php?name=News&file=article&sid=749
The person who wrote this has the exact same laptop, with the same wireless card.
1. Get a new(er) version of ndiswrapper, which "translates" the Windows Driver for the wireless card to Linux-ese. Belladonna previously was using ndiswrapper-1.37.
2. Put the ndiswrapper in /home/controls/Drivers, and installed it.
$ndiswrapper -i bcmwl5.inf 3. Get and put the Windows driver in /home/controls/Drivers/WiFi$wget http://ftp.us.dell.com/network/R140747.EXE
4. Unzip the driver
$unzip -a R140747.EXE
5. Make Fedora use ndiswrapper
6. Change some files to make everything work:
/etc/sysconfig/wpa_supplicant CHANGE FROM: DRIVERS="-Dndiswrapper" CHANGE TO: DRIVERS="-Dwext"
/etc/sysconfig/network-scripts/ifcfg-wlan0 CHANGE FROM: BOOTPROTO=none CHANGE TO: BOOTPROTO=dhcp
/etc/rc.d/init.d/wpa_supplicant CHANGE FROM: daemon $prog -c $conf $INTERFACES $DRIVERS -B CHANGE TO: daemon $prog -c$conf $INTERFACES $DRIVERS -B
6. Restart things
$service wpa_supplicant restart
$service network restart
7. Restart computer (since it wasn't working after 1-6, so give a restart a try)
8. Success!!! MEDM and Dataviewer work without any wired internet connection => wireless card is all good again!
Quick update on my wiener filtering status:
Joe has been helping me get on the GRID, so I now have a grid certificate, and accounts on most/all of the clusters.
Joe also helped me get menkar to get S5 data so that I can do wiener filtering to the back-data.
I've been running the wiener filtering algorithm, and right now, it doesn't do anything to improve the DARM_CTRL data. I am confident that this is because something is funky in the wiener filtering algorithm somewhere. The indicator of this is that the wiener filtering calculation takes the same amount of time (~95 seconds) to calculate a filter for 64 seconds of data as for 1 hour of data (both for N = 2000 taps).
For reference, attached are my plots for the wiener filtering result for (1) 64 seconds of S5 data, and for (2) 3600 seconds of S5 data.
These plots were made using H1:DARM_CTRL as the signal to minimize, with 4 seismometers as the witness channels (EX_SEISX, EY_SEISY, LVEA_SEISX, LVEA_SEISY)
I'm working on figuring out what's going on with the filtering algorithm, and why it does work for C1:MC_L minimization, but does not work for H1:DARM_CTRL minimization.
ITMX, ITMY, BS, SRM, PRM op levs were all recentered. ETM's looked okay enough to leave as-is.
[Rana, Jamie, Jenne]
SPOB DC hasn't been so good lately, so we installed a new PO DC PD on the PO table. We used a 30% reflecting beam splitter (BS1-1064-30-1025-someotherstuff). We didn't check with a power meter that it's a 30% BS, but it seems like that's about right. The beamsplitter is as close as we could get to the shutter immediately in front of the regular POB/SPOB PD's, since that's where the beam gets narrow. The new picked-off-pickoff beam goes to a Thorlabs 100A PD. We haven't yet checked for reflected beams off the PD, but there is a spare razor blade beam dump on the table which can be used for this purpose. The output of this PD goes to the LSC rack via a BNC cable. (This BNC cable was appropriated from it's previous "use" connecting a photodiode from the AP table to a bit of air just next to the LSC rack.) Our new cable is now connected where the old SPOB DC cable used to be, at the input of a crazy Pomona Box tee.
For reference, the new levels of POB DC and SPOB DC, as measured by their BNC DC out connections is ~4mV each. Since the beamsplitter is 70% transmissive, we used to be getting about 5.7mV on each PD.
The new photodiode puts out about 40mV, but it has an ND1.0 filter on, so if more gain is needed, we can take it off to get more volts.
When all things fail (netgpibdata.py is giving me weird data. When I plot the data it has saved from the 4395A, it's some wierd other universe's version of my transfer function. I don't really know what's up. I'm pretty sure I'm getting the 'correct' data, since each TF looks vaguely like it should, but with some crazy humps. I'll talk to Yoichi in the morning about it maybe.) (also, we're low on emergeny floppy discs), you can always take a picture of the Agilent 4395's screen, as shown below.
* Mode cleaner and PMC are both relocked after my shenanigans, and I'll try again in the morning (I assume locking is going on tonight) to get real TF's with real data, as opposed to the photo method.
Note to self: post the data of the TFs in the elog along with the plots, for posterity.
These TFs are of the Mode Cleaner servo board, exciting IN1 (or the 3.7MHz notch pomona box which is connected to IN1), and measuring at the SERVO out of the board.
One with the box, one without the box, and one of just the box for good measure.
netgpibdata.py is giving me weird data. When I plot the data it has saved from the 4395A, it's some wierd other universe's version of my transfer function. I don't really know what's up.
Yoichi, in all his infinite wisdom, reminded me that the netgpibdata script saves the data as the REAL and IMAGINARY parts, not the Mag and Phase. Brilliant. Using that nugget of information, here are the TFs that I measured earlier:
The last attachment is the .dat and .par files which contain the data and measurement parameters for the 3 TFs in the plots.
After many, many "it'll be there in 2 weeks" from the Guralp people, our seismometer is finally back!
I have it plugged into the Guralp breakout box's Channel 1xyz (so I have unplugged the other Guralp). Both of the Guralp's are currently sitting under the MC1/MC3 chamber.
Before we can have both Guralps up and running, I need to stuff the next 3 channels of the breakout box (back in the fall, I only had Caryn do 1x, 1y, 1z, and now I need 2x, 2y and 2z done with the fancy low-noise resistors), so all the gains match between the 2 sets of channels.
I'm leaving the new Guralp plugged in so we can see how it behaves for the next couple days, until I take out the breakout box for stuffing.
Old Guralp is hooked back up, the new one is sitting next to it, disconnected for now.
I noticed that the ISS Mean Value and CS Saturation were both RED and unhappy. (The alarms were going off, and they were both red on the MEDM screen). None of the MEDM settings seemed off kilter, so we went out to take a look at the PSL table.
Rob checked that light is indeed going to both of the ISS photodiodes (Morag and Siobhan). Next we checked that all the cables were good, and that the power to the ISS box was plugged in. In this process, Rob wiggled all the cables to check that they were plugged in. Just after doing this, the Mean Value and CS Sat were happy again. Rob thinks the current shunt connection might be bad, but we don't really know which one it was since all of the cables were jiggled between our checking the screens.
Right now, everything is happy again, but as with all bad-cabling-problems, we'll probably see this one again.
I don't know why in particular the connection decided to spaz out this afternoon...I don't think anyone opened the PSL table before Rob and I went to investigate. I was working on the PMC servo (checking the LO levels...to be posted in a couple minutes), but didn't have anything to do with the ISS. After I was done, I put everything back, and locked the PMC and the MC, and everything was good, until some time later when the ISS started flipping out.
I don't know who left the X arm locked, but I just ran the Align Full IFO script, so everything is good in case Yoichi/someone comes in to lock the IFO this weekend.
I have calibrated the PMC LO Mon (C1:PSL-PMC_LODET) on the PMC's EPICS screen, by inputting different RF LO levels into the LO input of the PMC servo board.
Since the RF output adjust slider on the PMC's Phase Shifter screen doesn't do a whole lot (see elog 1471), I used a combination of attenuators and the slider to achieve different LO levels. I measured the level of the attenuated RF out of the LO board using the 4395A in spectrum analyzer mode, with the units in dBm, with 50dB attenuation to make it stop complaining about being overloaded. For each row in the table I measured the RF level using the 4395, then plugged the cable back into the PMC servo board to get the EPICS screen's reading.
The last 2 columns of the table below are the 'settings' I used to get the given RF LO level.
When the new mixers that Steve ordered come in (tomorrow hopefully), I'll put in a Level 13 mixer in place of the current Level 23 mixer that we have. Also, Rana suggested increasing the gain on the op-amp which is read out as the LO Mon so that 13dBm looks like 1V. To do this, it looks like I'll need to increase the gain by ~80.
Following the method in Peter's Elog,
I edited c1psl.db to include the following:
I restarted c1psl (had to go hit the physical reset button since it didn't come back after telnet-ing and "reboot"ing) to make this take effect.
Next step is to tell the PMC screen to look at this _LOCALC rather than _LODET, and the screen will be calibrated into dBm.
Right now, the screen is as it always has been, because after relooking at the calibration, I no longer believe it. This calibration claimes -19dBm for an LOmon value of 0.1200, when I actually measured +16dBm for this LOmon value. So I've screwed something up in doing my MatLAB calibration. I'll fix it tomorrow, and put in the correct calibration before I change the PMC screen.
RefCav, PMC, MC are all back and locked after my shenanigans.
I edited c1psl.db to include the following:
As it turns out, I apparently can't tell X from Y when fitting a function in a rush. The real calibration stuff which is now in c1psl.db is:
I restarted c1psl (again, had to go hit the physical reset button since it didn't come back after a telnet-reboot) to have it take in the changes. The psl.db file that was in place before yesterday (before I touched it) is saved as psl.db.15Apr2009 just in case.
I edited the PMC EPICS screen to have the LO mon look at C1:PSL-PMC_LOCALC, which is the calibrated channel in dBm. I also stuck a little label on the screen saying what units it's in, because everyone likes to know what units they're looking at.
The new Level 13 mixer on the PMC servo board is installed (minicircuits SRA-3MH). Since the RF output of the LO board was ~16dBm, I put a 3dB attenuator between the LO board and the LO input on the servo board. Since the previous cable was *just* the right length, this required adding a tiny bit of cable. I found a very short cable, which worked out nicely, and didin't leave bunches of extra cable between the two boards. One of these days if I have time (i.e. if it is necessary), I'll make a new cable for this purpose, so that we don't have 2 cables daisy-chained.
A note on the Mixer-replacement: The mixer on the PMC servo board is soldered in a set of 8 through-holes, not stuck in a socket. So I had to desolder the old Level 23 Mixer (minicircuits RAY-3) which was a total pain. Unfortunately, in this process, I lifted one of the pads off the back side of the board. Once the old mixer was removed, it became clear that the pin for the pad I had lifted was shorted via a trace on the front side of the board to the pin directly across from it. So when installing the new mixer, I did my best to get some solder into the through-hole for the lifted-pad-pin, and then tied it using a jumper wire to the pin that it's shorted to on the front of the board. You can't see the trace that shorts the two pins because it's underneath the mixer, when the mixer is installed. (Sidenote: after talking with Rana, this should be okie-dokie, especially if these are ground pins).
The PMC and MC locked nice and happily after I replaced the board and turned all the HV supplies back on, so I call this a success!
I also measured the OLG of the PMC servo after today's adventures in mixer-land. I get a UGF of 1.4kHz, with 66 degrees of phase margin. The method for this is in elog 924.
I checked the phase slider setting of the PMC phase screen by putting 30kHz at 100mV into the Ext DC input of the servo board, and looking at the 30kHz peak output of the Mixer Out. I fiddled with the phase slider, and chose the value for which the 30kHz peak was maximized. The phase slider is now set to 5.0V.
To include the plots that I've been working on in some form other than on my computer, here they are:
First is the big surface plot of all the amplitude spectra, taken in 10min intervals on one month of S5 data. The times when the IFO is unlocked are represented by vertical black stripes (white was way too distracting). For the paper, I need to recreate this plot, with traces only at selected times (once or twice a week) so that it's not so overwhelmingly large. But it's pretty cool to look at as-is.
Second is the same information, encoded in a pseudo-BLRMS. (Pseudo on the RMS part - I don't ever actually take the RMS of the spectra, although perhaps I should). I've split the data from the surface plot into bands (The same set of bands that we use for the DMF stuff, since those seem like reasonable seismic bands), and integrated under the spectra for each band, at each time. i.e. one power spectra gives me 5 data points for the BLRMS - one in each band. This lets us see how good the filter is doing at different times.
At the lower frequencies, after ~25 days, the floor starts to pick up. So perhaps that's about the end of how long we can use a given Wiener filter for. Maybe we have to recalculate them about every 3 weeks. That wouldn't be tragic.
I don't really know what the crazy big peak in the 0.1-0.3Hz plot is (it's the big yellow blob in the surface plot). It is there for ~2 days, and it seems awfully symmetric about it's local peak. I have not yet correlated my peaks to high-seismic times in the H1 elog. Clearly that's on the immediate todo list.
Also perhaps on the todo list is to indicate in some way (analagous to the black stripes in the surface plot) times when the data in the band-limited plot is just extrapolated, connecting the dots between 2 valid data points.
A few other thoughts: The time chosen for the training of the filter for these plots is 6:40pm-7:40pm PDT on Sept 9, 2007 (which was a Sunday night). I need to try training the filter on a more seismically-active time, to see if that helps reduce the diurnal oscillations at high frequency. If that doesn't do it, then perhaps having a "weekday filter" and an "offpeak" filter would be a good idea. I'll have to investigate.
Even more plots for the Wiener filtering!
We have a set of spectrograms, which show (in color) the amplitude spectrum, at various times during a one month stretch of time, during S5. Each vertical data-'stripe' is 10min long.
We also have a set of band-limited plots, which take the spectra at each time, and integrate under it, for different frequency bands.
Each set of plots has the following 3 plots: The raw DARM spectrum, a ratio of residual/raw, and the residuals, normalized to the first one (on which the wiener filter was trained).
The residuals are the DARM spectrum, after subtracting the Wiener-filtered seismometer witness data.
From the ratio plots, it looks like the wiener filter is pretty much equally effective at the time on which the filter was trained, as one month later. Static filters may be okey-dokey for a long period of time with for the seismic stuff.
I measured the ETMY oplev beam size at a couple different distances away from the HeNe by taking out the steering mirror and letting the light propagate a ways. I put the steering mirror back, aligned the oplev, and was able to relock the Yarm, so I think it's all back as it has been the last couple of weeks.
Now I need t o do some geometry and ray-tracing matrices to decide what focal length lens to buy, then we'll have a shiny new ETMY oplev.
[ Jenne, Clara ]
We made new channels for the microphones which came in this week, by editing C1ADCU_PEM.ini (and making an appropriate backup before we modified it) then restarting the framebuilder and the frontend computer C0DCU1. The new channels are:
These are connected to channels 13 and 14 on the PEM ADCU board, just next to the GURALP seismometer channels.
Clara is testing the mics so the max output voltage can be limited to +-2V for the DAQ, then we'll hook them up to our new channels and listen to the IFO (and all the audio frequency noises around it).
I popped by the 40m, and was dismayed to find that all of the front end computers are red (only framebuilder, DAQcontroler, PEMdcu, and c1susvmw1 are green....all the rest are RED).
I keyed the crates, and did the telnet.....startup.cmd business on them, and on c1asc I also pushed the little reset button on the physical computer and tried the telnet....startup.cmd stuff again. Utter failure.
I have to pick someone up from the airport, but I'll be back in an hour or two to see what more I can do.
Before heading back to the 40m to check on the computer situation, I thought I'd check the web screenshots page that Kakeru worked on, and it looks like none of the screens have been updated since June 1st. I don't know what the story is on that one, or how to fix it, but it'd be handy if it were fixed.
Yet again, the DAQAWG flipped out for an unknowable reason. In order of restart activities listed on the Wiki, I keyed the crate and nothing really happened, then I hit the physical reset button and nothing happened, and then I did the 'telnet....vmeBusReset', and a couple minutes later, it was all good again.
While Clara was working on her Wiener filtering and optimizing the locations of the accelerometers, she discovered that MC_L and MC_L_256 are totally flatlined. I looked at them, and it looks like they've been dead since ~9:30pm-ish on Sunday night. Bootfest-type activities shall commence shortly.
Under Alberto's tutalage, I rebooted the whole vme set (iovme, sosvme, susvme1, susvme2), and after that MC_L was all good again.
ETMY oplev is currently a work in progress. The HeNe beam is hitting the photodiode, but the spot size there is pretty much the size of the entire QPD. Thus, the ETMY oplev isn't really useful right now. I'm re-figuring things out (note to self: close to the laser, you have to use Gaussian optics...regular ray tracing doesn't really work), and hopefully will have the oplev back under control by the time Alberto is finished realigning the IFO, so this doesn't keep anyone from doing any exciting locking work.