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, Jenne]

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,

1. Former +24V Sorensen in the AUX OMC power rack (south of 1X2) has been reconfigured to +12V DC.
2. The voltage was routed to a bank of fusable terminal blocks on the NW corner of 1X1.
3. An unused cable running to the PSL table was hijacked for this purpose.
4. The ZHL-1010+ were installed on the upper shelf of the PSL table, the two gain blocks draw a total of ~600mA of current when powered.

Summary:

1. The ZHL-1010+ gain blocks acquired from MiniCircuits arrived sometime ago.
2. I packaged them in a box prepared  (Attachment #1).
3. Their performance was characterized by me (Attachment #2 and #3).

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).

Details:

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.

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).

[rana, ericq]

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.

Work Done:

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.

Calculations:

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.

[Paco, Yuta]

We realized that bandstop filters ("violin" filters) we implemented in 40m/17206 had pass band gain of -1dB.
gain(1,"dB") was added to all the filters (see Attachment #1 for gain adjusted violin filters for AS1).
We also realized that audio dither frequency we chose to generate BH55+audio dither error signal and to measure sensing matrix at ~280 Hz was too close to violin filters.
These will affect calibrations by upto ~60%.
For example, actuation gains should be actually

• LO1 = 3.14e-8 / f^2 m / cts * 3dB = 4.44e-8 / f^2 m / cts (3 violin filters)
• LO2 = 2.52e-8 / f^2 m / cts * 0dB = 2.52e-8 / f^2 m / cts (no violin filters)
• AS1 = 3.14e-8 / f^2 m / cts * 3dB = 4.44e-8 / f^2 m / cts (3 violin filters)
• AS4 = 2.38e-8 / f^2 m / cts * 4dB = 3.36e-8 / f^2 m / cts (3 violin filters+ bandstop at 96.7 Hz)

Next:
 - Redo actuator calibrations for LO1, LO2, AS1, AS4
 - Redo sensing matrix measurements with different audio dither frequencies for LO1 and AS1

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.

[Jenne, Rana]

* 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. 

HOWEVER,

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. 

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.

[Jordan, JC]

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.

Motivation:

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.

Results:

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

nameserver 127.0.0.1

so obviously it is useless to refer localhost (i.e. giada) as a nameserver.

I copied our usual resolv.conf to giada as following:

nameserver 192.168.113.104
nameserver 131.215.125.1
nameserver 8.8.8.8

search martian

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".

Case closed.

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.

• Since we're using a DC-coupled servo, the TF magnitude will go like f^k with k < 0 for low frequency.
• The UGF will be somewhere around 10 kHz to 1 MHz (most likely right around 100 kHz) as beyond 1 MHz, the gain of our servo is limited by the GBWP of the op-amps.
• We need around 3 or 4 orders of magnitude of gain in the 1-100 Hz range based on this, with gain > 10 for f < 10 kHz

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.

This week I've looked into finding an accurate sensitivity for the geophones in the STACIS. I found that when placing a geophone and accelerometer side by side, and using the sensitivity values I had from spec sheets, the readings were very different (see eLog 7054: http://nodus.ligo.caltech.edu:8080/40m/7054).

I cut the shunt resistor off one of the STACIS geos and found it to be 4000 Ohm, which is one of the standard values for this geophone model. When it is connected to the geophone the net resistance is 2000 Ohm (I took a more careful measurement, I took the geophone out). Then the internal coil resistance should be 4000 Ohm, if they are connected in parallel. However, the geophone spec sheet does not have a sensitivity value for this exact scenario, so I'll have to find a different way to determine the calibration (maybe by putting it next to a seismometer with a known sensitivity). So I know for sure that the sensitivity value I was originally using is wrong, because it assumed an internal coil resistance of 380 Ohm, but I have to check if the value I found by forcing the geophones to agree with the accelerometers (eLog 7054 --> 0.25 (m/s)/V) is correct.

I've also been looking again at the open loop gains of the STACIS (see eLog 7058: http://nodus.ligo.caltech.edu:8080/40m/7058). Attached is what TMC, which makes the STACIS, says it should look like (with a 4000 lb load on the STACIS). Today I am taking the open loop gains into higher frequencies to get a better comparison, but the plots look quite similar to what I have so far. So if it is an unstable open loop gain, then it's at least not new.

The attached file is a python notebook that you can use to get data. Minimal syntax.

Minute trend data seems not available using the NDS2 server. Its super slow using dataviewer from the control room.

Did some digging into the NDS2 config on megatron. It hasn't been updated in 2 years.

All of the stuff is run by the user 'nds2mgr'. The CronTab for this user was running all the channel name updates and server restarts at 3 AM each day; I've moved it to 5:05 AM. I don't know the password for this user, so I just did 'sudo su nds2mgr' to become him.

On megatron, in /home/nds2mgr/nds2-megatron/ there is a list of channels and configs. The file for the minute trend (C-M-ChanList.txt), hasn't been updated since Nov-2015. ???

We tried to acquire data from the seismometers and the mode cleaner using the Matlab function

datalist = NDS2_GetData({'C1:PEM-SEIS_GUR1_X_IN1_DQ'}, 996258376 , 10, CONFIG.nds.C)

and encountered the following error

Warning: daq_request_data failed
 
??? Error using ==> NDS2_GetData
Fatal Error getting channel data.

The same error was obtained with the following other channels

C1:PEM-SEIS_GUR2_X_IN1_DQ

C1:PEM-SEIS_STS_1_X_IN1_DQ

But we are able to get data from channel

C1:LSC-MC_OUT_DQ

for the same gps time.

We checked with Dataviewer that the data are saved (we viewed data of last 24h) for every channel.

I'm working on getting the input beam centered on the Yarm optics.  To do this, I measured the spot positions, move the tip tilts, realign the cavity, then measure the new spot positions.  While doing this, I am also moving the BS and Xarm optics to keep the Xarm aligned, so that I don't have to do hard beam-finding later.

Here is the plot of spot measurements today.  The last measurement was taken with no moving, or realigning, just several hours later after speaking with our Indian visitors.  I'm closer than I was, but there is more work to do.

[Reuben, Radhika]

Checked out the AUX PDH locking system at the XARM. Started by locking the AUX laser using the uPDH servo box and adjusting the test masses to maximize transmission (~0.6 achieved). There were some issues where the fundamental mode would be briefly visible and then lose lock. Higher order modes were also seen which could be removed by adjusting test masses. We also noticed the laser spot moving around a lot, as if the test masses were swaying. Finally after repeated tries we managed to lock and hold the laser to the cavity long enough to measure the open loop transfer function using the Moku:Go frequency response analyzer tool. Got an idea of the finicky and temperamental nature of the locking process.

Taking the transfer function data from the Moku:Go and using a Python script, found the UGF to be around 25.6 kHz and phase margin to be around 25.5 deg. My current goal is to keep reading up on control systems and related theory (I still feel like I lack understanding of the important principles needed), and parallelly making a small script that can take the transfer functions data and calculate some useful information (halfway done).

One issue I found with the script was that the Python control library was giving me a wrong value of Gain Margin (~0.26 where ~-5 was expected) while using the control.margin function. The other parameters phase margin and crossover frequencies agree with the data visually.

Kiwamu and I noticed that there is a ghost beam on the green beam going into the ETM. What we see is some interference fringes on the edge of the transmission of the green beam through the dichroic beam splitter (DCBS). If we look at the reflection from the dichroic beam splitter these are much more pronounced.

The spacing of the fringes (about 2 per 10mm) indicates an angle between the fields of around 0.1 mrad.

We were able to cause significant motion of the fringes by pushing on the knobs of the steering mirrors that steer the beam into the DCBS. A rough calculation of the derivative of optical path difference between the ghost and the primary beam as a function of input angle gives about 15 microns per mrad. What filtering the effect the arm cavity will have on the ghost beam is not immediately clear, but the numbers shouldn't be too difficult to determine.

The beam splitter (BS1-1064-33-2037-45S) that is currently being used has an antireflection coating on the second surface and a wedge of less than 5 arcmin; yet it leads to ghosting as shown in the figure attached (courtesy: Thorlabs). I'm also attaching its spec sheet I dug up on internet for future reference.

I came across pellicle beamsplitters, that are primarily used to eliminate ghost images. Pellicle beamsplitters have a few microns thick nitrocellulose layer and superimpose the secondary reflection on the first one. Thus the ghost image is eliminated. 

Should we go ahead and order them? (https://www.thorlabs.com/newgrouppage9.cfm?objectgroup_id=898

https://www.edmundoptics.eu/c/beamsplitters/622/#28438=28438_s%3AUGVsbGljbGU1&27614=27614_d%3A%5B46.18%20TO%2077.73%5D)

you have to use a BS with a larger wedge angle (5 arcmin ~ 1 mrad) so that the beams don't overlap on the camera

[Gautam, Kruthi]

This afternoon, Gautam helped me setup Giada to access the GigE installed for MC2. Unlike Paola, which was being used earlier, Giada has a better battery life and doesn't shutdown when the charger is unplugged. Gautam configured Giada to enable its wireless connection to Martian, just like Koji had configured Paola (https://nodus.ligo.caltech.edu:8081/40m/14672). We also rerouted  the ethernet cable we were using with the PoE adaptor from Netgear Switch in 1x2 to 1x6.

Turns out, focusing the GigE is actually a bit tricky. With pylon, everytime I change the exposure or the focus, I'm running into the error I had mentioned earlier in one of my elogs; so I tried using the python scripts to interact with the GigE. But whenever I try to change the focal plane distance by rotating the lens coupler, the ethernet cable connection becomes loose and the camera server needs to be relaunched every now and then. Also, everytime we want to change the distance between the lenses, the telescope needs to be dismantled and refocused again. I'll try to come up with a better telescope design for this.

Yesterday, I had focused the GigE using a low exposure time and small aperture of iris, to make sure that we are actually seeing a sharp image of the beam spot. I'm attaching a picture of the beam spot I had clicked while focusing it, unfortunately, I forgot to take a picture after I had focused it completely. I'm also attaching a picture of the final setup for future reference. 

Yesterday night, Rana asked me to lock the MC2. I figured that the PSL shutter was closed; I just opened it and was able to see the beam spot on the analog camera screen.

The GigE is focused now (judged by eye) and I have closed the lid. I'm attaching a picture of the MC2 beam spot, captured using GigE at an exposure time of 400µs.

What was the solution to resolving the flaky video streaming during the alignment process????

-> I think, the issue was with either the poor wireless network conection or the GigE-PoE ethernet cable.

I've started setting up the last new rackmount SuperMicro as a dedicated server for the GigE cameras. The new machine is currently sitting on the end of the electronics test bench. It is assigned the hostname c1cam at IP 192.168.113.116 on the martian network. I've installed Debian 10, which will be officially supported until July 2024.

I've added the /cvs/cds NFS mount and plan to house all the client/server code on this network disk. Any dependencies that must be built from source will be put on the network disk as well. Any dependencies that can be gotten through the package manager, however, will be installed locally but in an automated way using a reqs file.

We should ask Chub to reorder several more SuperMicro rackmount machines, SSD drives, and DRAM cards. Gautam has the list of parts from Johannes' last order.

This past week, I have building a sine wave rectifier and trying to write a simple program that displays a ccd image to familiarize myself with the code.  I also wrote a progress report in which I included the following images of the sine wave rectifier circuit as well as the optical chain including the phase-locked loop.  The hirose connector arrived so I can begin soldering the electronics together and testing the trigger box with the ccd.  I am waiting on the universal PDH box as well as another fiber coupler to begin setting up the optics.  In order to avoid the frustrations associated with sending a laser beam down a long pipe to an optical bench across the room, I will be transmitting laser 1 to the ccd by means of a fiber optic cable and dealing with the alternative new and exciting frustrations.

The plan for the optical setup has been corrected after it was realized that it would be impossible to isolate a 29.501 MHz frequency from a 29.499 MHz one because they are so close in value.  Instead, we decided to adopt the setup pictured below.  In this way, the low-pass filter should have no trouble isolating 29.501-29.5 MHz from 29.501 + 29.5 MHz.  Also, we decided to scrap the idea of sending Alberto's laser through a fiber optic cable after hearing rumors of extra lasers.  Since I shouldn't have to share a beam when the second laser comes in, I plan on setting up both lasers on the same optics bench.  I've been working on the software while waiting for supplies, but I should be able to start building the trigger box today (assuming the four-pair cable is delivered).

Today, I moved the router from on top of the PSL into the control room in order to perform dark field tests on the GC650 (which I also moved).  The GC750 along with the lens that was on it and the mount it was on has been lent to Ricardo's lab for the time being.  I successfully triggered the GC650 externally and I also characterized the average electronic noise.  For exposure times less than 1 microsecond, the average noise contribution appears to be a constant 15 on a 12-bit scale.

Lately, I have been able to externally trigger the camera using a signal generator passing through the op-amp circuit that I built.  The op-amp circuit stabilizes the jitter in the sine wave from the signal generator and rectifies the wave.  I wrote the calculations into the code allowing me to find the phase and amplitude from the images I take.  I still need to develop code that will plot these arrays of phase and amplitude.

The mysterious dark band at the top of the ccd images continues to defy explanation.  However, I have found that it only appears for short exposure times even when the lens is completly covered.  During the next couple of days, I will try to write a routine to correct for this structure in the dark field.

Koji recommended that we use the optical setup pictured below.  This configuration would require fewer optics and we would have to rely on slight misalignments between the carrier and reference beams to test the effectiveness of the phase camera instead of a wavefront-deforming lens.

This past week, I have mostly been debugging my software.  I have tried to use the fluorescent lights to test the camera, but I can't tell for sure if my code is finding the correct amplitude and phase or not.  I am currently using Mathematica to double check my calculations in solving for the phase and amplitude.

Also, I have taken dark field images using a lens with a closed shutter.  I have found that the dark band across the top of the images only appears after the camera heats up.  Also, there is an average electronic noise of 14 with a maximum of 40.  However, this electronic noise as well as any consistent ambient noise will be automatically corrected for in the calculations I'm using because I'm taking the differences between the CCD images to calculate relative phases and amplitudes.

I should be able to start setting up optics and performing better tests of my software this week.

This week, Joe and I have been setting up the laser and optics.  The mephisto laser is emitting a very ugly beam that we can hopefully remedy using an iris and a lens.  After scanning the beam width at a few different distances from the laser, I am currently trying to determine the appropriate lenses to use.

While aligning the optics, we tried to start up the CCD.  Although nothing should have changed since the last time I used it, the code claimed it could not find the camera.  All the right leds are lit up.  The only indication that something is awry is that the yellow led on the camera isn't blinking as it does when there is ethernet activity.  

The camera wasn't working because the router has no built-in dhcp server.  We had to manually start the server after rebooting the computer.