I disconnected the yellow GPIB box from the backside of HP3563A (classic analyzer),
and connected it to AG4395A (network analyzer), which is the official place for it.
I've just stolen a GPIB controller, an yellow small box, from the spectrum analyzer HP8591E.
The controller is going to be used for driving the old spectrum analyzer HP3563A for a while.
Gopal and I will be developing and testing a GPIB program code for HP3563A via the controller.
Once after we get a new GPIB controller, it will be back to the original place, i.e. HP8591E.
--- GPIB controller ----
I really don't understand why my programs that I used to use to get data from the HP Spectrum Analyzer and the Marconi frequency generator don't work anymore.
I spent hours trying to debug the code but I can't sort the problem out.
The main problem seem to be with the function recv from the socket library. Somehow it can't anymore get any data from the instruments. The thing I can't understand, though, is that if called directly from the python terminal it works fine!
In particular the problem is with the following lines in my code:
tmp = netSock.recv(1024)
Tried a lot of tickering but it didn't work.
I attach the two scripts I've been using. One (sweepfrequencyPRC.py) calls the other (HP4395PRC.py).
They worked egregiously for weeks in the past. Don't know what happened since then.
## sweepfrequency.py [-f filename] [-i ip_address] [-a startFreq] [-z endFreq] [-s stepFreq] [-m numAvg]
## This script sweeps the frequency of a Marconi local oscillator, within the range
## delimited by startFreq and endFreq, with a step set by stepFreq. An arbitary
## signal is monitored on a HP8590 spectrum analyzer and the scripts records the
## amplitude of the spectrum at the frequency injected by the Marconi at the moment.
## The GPIB address of the Marconi is assumed to be 17, that of the HP Spectrum Analyzer to be 18
## Alberto Stochino, October 2008
# This function provides the measuremeent of the peak amplitude on the spectrum analyzer
# HP8590 analyzer while sweeping the excitation frequency on the function generator.
# Alberto Stochino 2008
from optparse import OptionParser
from socket import *
tmp = netSock.recv(1024)
This morning Joe looked at my code and made me notice that for some reason the query to the Spectrum Analyzer made by netSock.recv(1024) contained two answers. It was like the buffer contained the answer two different queries.
After some experiment I found that basically the GPIB interface wasn't switching from the "auto 1" to the "auto 0" mode as it should. I rewrote part of the code and that seemed have solved the problem.
Still don't understand why it used to work in the past and then it stopped.
GPIB<->WIFI on Agilent Network Analyzer 4395A was broken.
The connection was fixed by replacing and configuring the LINKSYS bridge.
Kiwamu and I have identified that the LINKSYS bridge was guilty.
I knew that we had another one in the bathroom, I configured it.
HOW TO CONFIGURE IT
The new unit works fine.
I checked the malfunctioning unit and the configuration was the same as the others.
The bad one detected the existence of 40MARS during the configuration, but it does not establish
the connection in the actual use. I am afraid that something is broken or some setting is lost
during the power supply shutdown.
Visual inspection of rooftop GPS antennae:
The 2 GPS antennas are located on the north west corner of CES roof. Their condition looks well weathered. I'd be surprised if they work.
The BNC connector of the 1553 head is inside of the conduit so it is more likely to have a better connection than the other one.
I have not had a chance to look into the "GPS Time Server" unit.
The setting when we found it was "GPS", which seems logical enough. However, when we switched it to "UTC" the time as shown on the front panel was correct, now with "UTC" vertically to the right of the time, and fb1 was then showing the correct GPS time.
From Keith Thorne:
Soooo, "UTC" is the correct mode for the GPS receiver.
The GPS receiver (EndRun Technologies box in 1Y5? (rack closest to door)) seems to not coming back up properly after the reboot. The front pannel says that it's "LKD", but the "sync" LED is flashing instead of solid, and the time of year displayed on the front panel is showing day 6. The fb1 symmetricom driver and VME timing module are still both seeing day 299, though. So something may definitely be screwy with the GPS receiver.
I called https://www.endruntechnologies.com/pdf/USM3014-0000-000.pdf and they said it's very likely just needs a software update. They will email Jamie the details.
I got the email from them. There was apparently a bug that manifested on February 14 2016. I'll try to software update today.
I have no idea what happened to the GPS timing on fb1, but it seems like the issue was coincident with the power glitch on Monday.
As was noted by Koji above, the GPS time kernel interface was off by a year, which was causing the frame builder to write out files with the wrong names. fb1 was using DAQD components from the advligorts 3.3 release, which used the old "symmetricom" kernel module for the GPS time. This old module was also known to have issues with time offsets. This issue is remniscent of previous timing issues with the DAQ on fb1.
I noted that a newer version of the advligorts, version 3.4, was available on debian jessie, the system running on fb1. advligorts 3.4 includes a newer version of the GPS time module, renamed gpstime. I checked with Jonathan Hanks that the interfaces did not change between 3.3 and 3.4, and 3.4 was mostly a bug fix and packaging release, so I decided to upgrade the DAQ to get the new components. I therefore did the following
updated the archive info in /etc/apt/sources.list.d/cdssoft.list, and added the "jessie-restricted" archive which includes the mx packages: https://git.ligo.org/cds-packaging/docs/-/wikis/home
removed the symmetricom module from the kernel
sudo rmmod symmetricom
upgraded the advligorts-daqd components (NOTE I did not upgrade the rest of the system, although there are outstanding security upgrades needed):
sudo apt install advligorts-daqd advligorts-daqd-dc-mx
loaded the new gpstime module and checked that the GPS time was correct:
sudo modprobe gpstime
restarted all the daqd processes
sudo systemctl restart daqd_*
Everything came up fine at that point, and I checked that the correct frames were being written out.
I did the cabling for monitoring DC transmission of the green beam from the end table.
The two PDs are called GREEN TRX and GREEN TRY, and the channel names are C1:GCV-GREEN_TRX and C1:GCV-GREEN_TRY.
The two signal from the PDs go to the ADC_0 card of the c1ioo computer.
Now, C1:GCV-GREEN_TRX/Y are actually connected to the respective PDs, but green beams are not hitting on the PD. We need two pickoff mirrors.
The Y arm green transmission has been measuring in counts all along. I modified the gain in the ALS-TRY filter module to normalise the transmission.
Transmission has been normalised with GTRY = 1 corresponding to 600 counts.
Meh. 600 counts is too weak. You should fix the electronics so that the maximized green laser transmission gives more like ~10000 counts.
Last night we noticed an excess in the GUR1Z seis BLRMS on the StripTool. It was in the 0.1 - 0.3 Hz band. The rumor in the control room was that "this kind of noise has been showing up at night recently".
AS it turns out, this was not some environmental noise around the 40m at night, but instead its some internal servo oscillation in the GUR1 Z channel. In the Guralp seismometers, each channel is a different mechanical sensor (unlike the STS or T240), so when a single channel gets noisy it doesn't always implicate the others.
My guess is that the oscillation came from the Z channel needing to be recentered. I power cycled the interface box just now. The oscillation had already gone away, but I thought this might reduce the excess noise. Maybe it did, but the effect is tiny. You can see in the oscillation reference that the low frequency noise is high, but in the new trace its still kind of high. Needs to be re-centered correctly with the paddle. Or add a centering button to the interface box.
Evan brought the Guralp handheld readout paddle and cables back from the ATF (Zach is using GUR2 and one of the T240s for gyro stuff this week), and we recentered the GUR1 masses. N/S and Vert were okay (within 0.1 V), but E/W was at -0.5 V, so we set it at zero. We then plugged the Guralp back in, and turned on the readout box.
There isn't much of a change on the BLRMS on the wall, so it's possible that we weren't actually having any trouble anyway.
Yaakov and I investigated the GUR 2 problem. It turns out that the ADC channels that GUR 2 was plugged into, ADC channels 6 through 8 (on the actual ADC they are C7 through C9), did not correspond to the channels labelled "GUR 2" in the PEM, ADC channels 3 through 5. We modified them so that GUR 2 is now plugged into ADC channels 3 through 5 (on the ADC it's +1).
Before we discovered that this was the problem, we attempted to take the cover off of GUR 1 to check the gains, and discovered a stripped Allen screw on the side by the "Vertical" pot, which we removed.
Now the GUR 2 readout looks good, and we will give it more time to settle down before we take data.
Jordan will write up the detailed elog but in summary,
I will install these at the next opportunity, so that we can get rid of the many attenuators in this path (the main difficulty will be sourcing the required +12V DC for operation, we only have +15V available near the PSL table).
The measurements are consistent with the specifications, and there is no evidence of compression at any of the power levels we expect to supply to this box (<0dBm).
These "gain blocks" were acquired for the purpose of amplifying the IR ALS beat signals before transmission to the LSC rack for demodulation. The existing ZHL-3A amplifiers have a little too much gain, since our revamp to use IR light to generate the ALS beat.
Attachment #4: Setups used to measure transfer functions and noise.
For the transfer function measurement, I chose to send the output of the amplifier to a coupler, and measured the coupled port (output port of the coupler was terminated with 50 ohms). This was to avoid saturating the input of the AG4395. The "THRU" calibration feature of the AG4395 was used to remove the effect of cabling, coupler etc, so that the measurement is a true reflection of the transfer function of OUT/IN of this box. Yet, there are some periodic ripples present in the measured gain, though the size of these ripples is smaller than the spec-ed gain flatness of <0.6dB.
For the noise measurement, the plots I've presented in Attachment #3 are scaled by a factor of sqrt(2) since the noise of the ZFL-500-HLN+ and the ZHL-1010+ are nearly identical according to the specification. Note that the output noise measured was divided by the (measured) gain of the ZFL-500-HLN+ and the ZFL-1010+ to get the input referred noise. The trace labelled "Measurement noise floor" was measured with the input to the ZFL-500-HLN+ terminated with 50ohms, while for the other two traces, the inputs of the ZHL-1010+ were terminated with 50ohms.
Raw data in Attachment #5.
We spent time trying to relieve the Yend green PDH of it troubles.
We realized that the mixer in the PDH setup (mini circuits ZAD-8+), wants 7dBm of LO to properly function. However, we use one function generators output, through a splitter, to give signals to the laser PZT and the mixer LO.
We don't want 7dBm of power hitting the laser PZT, though. The summing node that adds the servo output to the sideband signal was supposedly designed to do some of this attenuation. Rana measured that 10Vpp out of the function generator resulted in 20mVpp on the fast input to the NPRO, after the summing node. Hence, the 0.09V setting was only resulting in something like 0.2mV hitting the PZT. The PZT has something like 30 rad/V PM response, meaning we only had ~0.006 rad of modulation.
Now, the function generator is set to 2 Vpp, meaning 4 mVpp hitting the PZT, meaning ~0.12 radians of modulation. The mixer is now getting +7dBm on its LO, and the PDH traces look much cleaner. However, the PDH error signal is now something like 100mVpp, which is much bigger than the PDH board is designed for, so there is now a 10dB attenuator between the reflection PD DC block and the RF input to the mixer.
Here are screenshots of the Inmon channel (which has a gain of ~20) showing a sweep through some PDH signal, and the error signal while in green lock. Huge 60Hz harmonics are still observed.
Regarding these 60Hz issues, we need to make sure that we remove all situations where long BNCs are chained together with barrel connectors, or Ts are touching other ones. We also should glue or affix the pomona summing box to the shelf, so that its not just laying on the floor.
The concrete next step is to go fiddle with things, and see if we can get the 60Hz noise to go away, then measure the PDH loop and noises again. Hopefully, this should make the ALS much more reliable.
I found that the barrel of one the BNC to BNC connectors used for getting the output of the PDH servo box to the laser controller was touching the ETMY chamber. When I held it away, all of the 60Hz harmonics disappeared from the mixer output spectrum; this was pretty repeatable. This inspired me to replace the refl PD and PZT signal cables (which were 2 and 3 cables stitched together, respectively) with 20' long BNCs. I also cleaned up a lot of the routing of signal and power cables in the little rack, and moved the big T->DC Block->Attenuator combo off of the panel mount, because I didn't like how it was wiggling. It and the summing pomona box are sitting on top of the PDH box and function generator, instead of hanging freely.
All of the 60Hz harmonics were banished afterwards, and the green locked happily.
This required me touching the Y end table, to remove the old cable and its cable ties, and putting the new one in. I don't think I did anything immediately apparently bad; the green and IR transmissions both are within nominal ranges.
I haven't had luck measuring the CLG yet, which I wanted to do to get and set the UGF before measuring the noises. However, here is a scope trace of the in-lock error signal, which compares quite favorably to the trace posted in the previous post; the scope indicates that the signal has 1/3 of the RMS that it did before I replaced the cables.
I hope to measure up the current status after I get back from dinner.
Yesterday I measured the spectra and OLTF of the Y-Arm green PDH, after the LO touch-up and 60Hz hunt from last week. I also went to lower frequencies with the SR785, but forgot to take some of the background spectra down there, so I don't have the full breakdown plots yet. Nevertheless, here is the improvement in the PDH error signal:
I also measured the OLTF (SR785 injection at the error signal, Auto level ref 5mV at channel 2, 10mV/s source ramping, 50mV max output)
As you can see, we have tons of phase margin. Flipping the local boost switch had no visible effect on the OLTF; we should change it to something that puts this surplus of phase to good use, and squash the error signal even more. Putting an integrator at 5kHz should still leave about 45 degrees phase margin at 10k. I've started making a LISO model of the PDH board from the DCC drawing, and then I'll inspect the boards individually to make sure I catch the homegrown modifications.
Data, and code used to generate the plots is attached.
Finally, the 0.1s sampling rate of the frequency counter(FC) has been achieved. For this I had to :
Send in byte codes to set a particular range of the frequency counter.
I was digging in to find how exactly the circuit inside the frequency counter works and how the processor inside is able to read and write bytes through a HID-USB interface. I found out that the 'AutoRange' setting (which I have been using so far) has an independent multiplexing circuit which consumes some time(that varies with the drift in frequencies) and thus, the the processor waits for some specific time for this process and cannot reach the minimum 0.1 s sampling time. To mitigate this issue, I set the range bytes to the appropriate range of frequencies so that I can bypass the MUX delay. Here is the list of Range and frequencies for the FC:
Range 1: 1 - 40 MHz
Range 2: 40 - 190 MHz
Range 3: 190 - 1400 MHz
Range 4 : 1400 - 6000 MHz
I then took measurements for sampling time of 0.1 s at carrier frequencies of 5 MHz and 25 MHz from SRS DS345 and plotted the improvised gain plots(attached) to those in my previous elog(10070) with the same procedure mentioned before.
To do Next:
Plot the gain plots for higher carrier frequencies till range 3 using Marconi Function generator.
Write the data from FC into C1: ALS-Y_SLOW_SERVO1_OFFSET EPICS channel.
The attached are the gain plots at carrier frequencies of 100 MHz, 500 MHz and 1 GHz measured using IFR 2023B (Marconi).
The goal is to characterize the Mini-Circuits RF FC (Model UFC-6000) by plotting Gain Plots.
The sampling rate of the UFC-6000 RF FC is 1s (should look into making the sampling time smaller). So to satisfy Nyquist criterion, the maximum modulation frequency is 0.5 Hz beyond which aliasing effects are seen.
The measurements taken (mentioned in my previous elog) are used to plot Gain vs Modulation frequency for carrier frequencies of 5 MHz and 25 MHz.
A modulated signal can be represented as X(t)= A*sin (Fc*t+D*sin(Fm*t+phase1)) where Fc and Fm are carrier and modulation frequencies respectively and D is the modulation depth.
This signal Y(t) is input to the FC and the output frequencies of the FC are recorded.
Let the output of the FC is Y(t)= A'*sin(Fc*t+D'*sin(Fm'*t+phase2));
Gain = D'/D;
phase = phase2 - phase1;
D' is calculated by subtracting the carrier frequency from the output frequency and calculating the amplitude of the resulting fitted sine wave.
The phase can be calculated if the phase of the input is known(which will be done next).
Plotting the Bode plots would give response of the FC to modulation.
The plots generated will be used to estimate:
1) Transfer Function of FC to be known to build an FOL-PID loop.
2) Quantization noise from Power Spectral Density(PSD) vs Hz.
To Do Next:
1)Calculate the phase difference to complete the Bode plot. This would require interfacing of the ADC on raspberry pi.
2)Estimate the quantization noise from the digital output.
Here's the game plan for things that we need to do to get this IFO locked up.
Red is for things that should be done today, or tomorrow if they don't get finished today (eg. laser mode hopping temperature check). Orange is for things that will become red once the current red things are gone (eg. inferring the POP QPD gouy phase, and moving it to minimized PRM information). Green is for things that we'd like to do, but aren't high priority (eg. X green mode matching). Blue is for things that we should remember, but not plan on working on soon (eg. putting PZTs on the Yend table for green).
TODAY so far:
Q already did the tweak up of the PSL SHG crystal alignment. HE SHOULD ELOG ABOUT THIS. What was the final power of green that you got? Do we have any record of a previous measurement to compare to?
Q helped me install PDA55s on each of the lasers (I did the ends, he did the PSL) so that we could do the mode hop temperature check. For the Yend, I took the leakage transmission through the first Y1 steering mirror after the laser. This beam was dumped, so I replaced the dump with a PDA55. For the Xend, the equivalent mirrors are too close to the edge of the table, so I put in a spare Y1, and reflect most of the light to a beam dump. The leakage transmission then goes to a PDA55. Note that for both of these cases, no alignment of main laser path mirrors was touched, so we should just be able to remove them when we're through. For the PSL, I believe that Q took the rejected light from one of the PBSes before the PMC. He mentioned that he bumped something, so had to realign the beam into the PMC, but that he was able to get the transmission back up to 0.802, when we were seeing it in the mid 0.7's for the last several days.
The end temporary PDs are using the TRX / TRY cables, so we will be looking at the C1:LSC-TR[x,y] channels for the power of the end lasers. The PSL's temporary PD is connected to the PMC REFL cable. For the end PDs, since I had filter banks available, I shuttered the end lasers and removed the dark offset. I then changed the gains to 1, so the values are in raw counts. The usual transmission normalization gains are noted in one of the control room notebooks.
I did a slow ezcastep and ramped the temperature of all 3 lasers over about an hour. I'll write a separate elog about how that went.
* Decided that earlier mode hop scan won't give us the information that we were hoping for. We need to think about where we can actually see the frequency change. Can we use the IR beatnote that we will soon have to do this? We'd only be able to scan one laser temp at a time, but that's okay. Leave, say, the PSL temperature alone, and scan one of the end laser temps. Using the PSL as the reference, we will be able to see if the frequency of the end laser goes crazy and jumpy as we pass through a certain temp. Then, repeat while holding the end laser constant and scan the PSL. Thoughts?
* Meditated on PSL oplev servo, but I need to make a Matlab script that can evaluate different loops according to a cost function based on elog 9690.
* Aligned IFO to IR, then greens to arms (got back to 0.9 for GTRY, but only about 0.5 for GTRX, with the PSL green shutter closed). Then aligned green beams on the PSL table, since the PSL green pointing had changed a bit from Q's crystal alignment tweak-up earlier today. Beatnotes are nice and big (see elog 10381 - The Yarm is the larger beatnote, and the Xarm is the smaller one.)
* Was not able to lock ALS comm/diff and hold long enough to get both arms to IR resonance. Also, saw that TRY's RIN was more than 50%(!!!). We took a look, and there seems to be much more low frequency noise than there was when the spectrum in the control room was taken for the multicolor metrology paper:
* Tried to balance the ALS comm/diff input matrix, with not a lot of success. First of all, it looks like the Xarm has overall about 10 times more noise! We were exciting MC2 in position (~88 Hz, about 130 counts I think), and then looking at DARM_IN1 for the peak. When DARM_IN1 was just one of the 2 ALS error signals (i.e. one matrix element set to zero), versus when both matrix elements were set to 1, we saw a factor of only about 3 in reduction of the peak height. We were hoping to have better cancellation of this pure CARM signal in the DARM channel. The Xarm green PDH loses lock every ~5 or 10 minutes, and when we relock it, this cancellation seems different, so we want to try again tomorrow when the ALS is locked on comm / diff, rather than just the free running ALS that we have now. Although, if the balance of the input matrix changes lock-to-lock, we may need to consider redoing the green PSL table layout so we get a pure DARM beatnote signal like they have at the sites.
* We want to change how the watch script for ALS works, although this is a low-priority task. Rather than looking at the control signal, we should maybe look at the sum of all the coil outputs, multiplied by a pendulum TF, and use that as a rough displacement sensor. We want to be careful of pushing too hard at low frequencies, but we want to allow higher frequency actuation without having the watch script shut things down.
* Also, I should put on the to-do list the revamp of the ALS find IR resonance script.
As Jenne mentioned, I did this.
Specifically, I first tweaked the mirror pointing the IR into the SGH in pitch and yaw to maximize the green power, and then adjusted the little set screws on the side of the SHG to maximize further. Power after the harmonic separator was of order 150uW. On the Y Green BBPD, I got ~48uW, instead of the 40uW Rana, Jenne, and myself saw the other night.
now that I look through old ELOGs, I find some posts by Kiwamu saying the power should be around 650uW, and that he was able to get 640uW out. So: I should do this again, systematically, more carefully, etc., etc. (Linked ELOG also states that optimum SHG temperature is alignment dependent...)
Jamie has arranged for phase map measurements this afternoon, so I will take the 6 dichroic LaserOptik optics over to Downs at 1:15 this afternoon.
Team Jamie+Nic will lead the effort to clamp down dog clamps as placement markers for all 4 in-vac passive TTs, and then pull all 4 TTs out of the chambers. They plus Den will move the TTs to the Cleanroom, and will start to install the new pitch alignment hardware.
When I return with the optics, we will install them in the TTs and re-balance them. Then we can put them back in the chambers and get back to work on alignment.
After we re-install the TTs, we will need to check the leveling of all 3 corner tables, just to be sure.
The game plan graffle file is now in the 40m dropbox, so anyone can edit it. Please just make sure to keep the date in the top right corner accurate.
Slightly updated Game Plan. Mostly, Q is continuing to check out the Xend PDH box saturation, and I am thinking on what our requirements are for ALS, and thus for the green PDH boxes.
After the second of the two recent power outages, the outlet powering Chiara's external drive for local backups didn't come back. The modification to the backup script I made correctly identified that the drive wasn't mounted, and happily logged its absence and didn't try to stuff the internal drive with a copy of itself. However, I hadn't checked the logs to see if the backups were proceeding until today... maybe I should set up an email alert for these, too.
I plugged the external drive into a live outlet, and mounted the 40mBackup drive with: sudo udisks --mount /dev/sdc1, which is a helpful command that puts the drive at /media/40mBackup as it should be, based on the drive label.
sudo udisks --mount /dev/sdc1
The /cvs/cds backup is now proceeding, to make up for lost time.
There was a rogue, undocumented, gateway process running on NODUS since ~4 PM. This guy was broadcasting channels back into the Martian and causing lockups in the IOO controls. I did a kill -9 on its process.
Someone will pay for this.
It was brought to attention during yesterday's meeting that the pressures in the vacuum system were not equivalent althought the valve were open. So this morning, Jordan and I reviewed the pressure gauges P3 and P4. We attempted to recalibrate, but the gauges were unresponsive. Following this, we proceeded to connect new gauges on the outside to test for a calibration. The two gauges successfully calibrated at atmosperic pressure. We then proceeded to remove the old gauges and install the new ones.
I’m working on a code to determine the Gaussianity of a PSD.
It can be difficult to distinguish between GW events and non-Gaussian noise, especially in burst searches. By characterizing noise Gaussianity, we can better recognize noise patterns and distinguish between GW events and noise.
What I did:
I analyzed an hour of S5 L1 data. First, I plotted a timeseries, just to see what I was working with. Then, I produced a PSD (technically, an ASD) for the timeseries using Welch’s method in Python.
I split the data segment into smaller time-chunks and then produced a PSD for each chunk. All PSDs were superimposed in one plot. Here’s a plot for 201 time-chunks of equal length:
For a specific frequency, I can view the spread in PSD value through the production of a histogram.
I’ve made histograms displaying varying PSD values for the 201 PSD plot at 100 Hz, 500 Hz, and 1kHz.
For Gaussian noise, an exponential decay plot is expected. I will continue this analysis by following the statistical method in Ando et al. 2003 to calculate specific values indicative of the Gaussianity of various distributions. I’ll then look at different periods of time in the S5 L1 data to find periods of time suggesting non-Gaussian behavior.
I've continued to work on my Gaussianity tests for S5 L1 data.
Following the statistical measure in Ando et al. (2003), I've calculated the Laguerre coefficient, c2, for all frequencies present in my S5 L1 PSD as a metric of Gaussianity. When c2 is zero, the distribution is Gaussian. A positive c2 corresponds to glitchy noise, while a negative c2 suggests stationary noise.
Below is a plot displaying variation in c2 for this PSD:
By observing the c2 value and histogram of distribution of various PSD values at a given frequency, we can elucidate statistical differences in the Gaussian nature of noise at that frequency which are unclear in the standard PSD.
For magnet strength measurement: There is a gaussmeter in the flukes' drawer (2nd from the top). It turns on and reacts to a whiteboard magnet.
Kruthi noticed that she could not login to rossa from giada.
I checked /etc/resolv.conf and it was
so obviously it is useless to refer localhost (i.e. giada) as a nameserver.
I copied our usual resolv.conf to giada as following:
Giada's ssh known_host had unupdated entry for rossa, so I had to clean it up, but after that we can connect to rossa from giada just by "ssh rossa".
Updated the FILTER.adl file to have the yellow button moved up, and replaced the symbol in the upper right with a white A with black background. I made a backup of the filter file called FILTER_BAK.adl. These are located in /opt/rtcds/caltech/c1/core/advLigoRTS/src/epics/util.
I also modified the Makefile in /opt/rtcds/caltech/c1/core/advLigoRTS/ to make the startc1SYS scripts it makes take in an argument. If you type in:
sudo startc1SYS 1
it automatically writes 1 to the BURT RESTORE channel so you don't have to open the GDS_TP screen and by hand put a 1 in the box before the model times out.
The scripts also points to the correct burtwb and burtrb files so it should stop complaining about not finding them when running the scripts, and actually puts a time stamped burt snapshot in the /tmp directory when the kill or start scripts are run. The Makefile was also backed up to Makefile_bak.
While attempting to develop a somewhat accurate noise budget for the 40m, I reasoned that while the shape of the transfer function for the ISS is important, the degree to which we can 'tune' it to a particular experiment/application is limited.
Beyond that, we're sort of limited by the desired high and low frequency behavior as well as the general principle that more electronics = more noise so we probably don't want more than 3 or 4 filter stages, if that. Additionally, the ISS can be over-engineered so that it suppresses the laser noise to levels well below other fundamental noise sources over the important regime ~10 - 10^3 Hz without particular regard to a noise budget.
The design I propose is very similar to a previous design, with a few adjustments. It consists of 3 filter stages that easily be modified to increase gain for higher frequencies if it is known/determined that the laser being stabilized has a lot of high frequency noise.
Stage 1: Basic LP Filter + Establish UGF (each stage 'turning on' will not change the UGF), Stage 2: Integrator with zero @ 10 kHz, Stage 3: Optional extra gain if necessary
With the full TF given by,
As usual we consider the noise caused by the servo itself. Noise analysis in LISO is done with a 1 V input excitation.
This servo should function sufficiently for the 40m.
Tonight I looked at the signal from a geophone and accelerometer side by side, in order to see if they show the same ground motion and if the sensitivity factor I am using to convert from V to m/s is right. This is plotted below, along with the current estimates for accelerometer and geophone noise:
From this it is pretty clear that at least one of the sensitivity factors (V/m/s) I am using is wrong (the noise levels are much lower than the ground motion, so they can't account for the difference). I suspect it is the geophone one, because Wilcoxon provided these sensitivities for each individual accelerometer, but I was just using the number I found in online specs for the geophones.
The reason the online value is wrong is probably because of the value of the shunt resistor, a resistor that just goes across the top of the geophone (its purpose is to provide damping, by Lenz's Law). The specs assume a value of 380 Ohm, but I measured the one in the STACIS to be about 1.85 kOhm.
Assuming the accelerometer signal is correct, I multiplied the geophone signal by different factors to try to get an idea of what the true calibration factor is, and found that a value of 0.25 (m/s)/V gives decent agreement at higher frequencies (below 10 Hz the sensitivity drops off, according to the online specs). This is shown below:
Above, the geophone noise was recalculated with the new sensitivity and assuming that both geophones in the noise measurement had the same sensitivity. I took the transfer function of two geophones side by side to see if their gains were dramatically different; this plot is shown below. The coherence is only good for a small band, but looking at that band the gain is approximately unity, implying very roughly that the sensitivity of each is approximately the same. The lack of coherence is strange, and I'm not sure what the cause is. Even using the shaker near the geophones only improved the coherence slightly.