Having no luck doing things remotely, we went into the ITMX chamber and roughly aligned the IR beam. Using the little sliding alignment target, we moved the BS to get the IR beam centered on ITMX, then moved ITMX to get good michelson fringes with ITMY. Using an IR card, found the retroflection and moved ETMX to make it overlap with the beam transmitted through the ITM. With the PRM flashing, X-arm cavity flashes could be seen. So, at that point, both the y-arm and x-arm were flashing low order modes.
This morning I poked around with the green layout a bit. I found that the iris immediately preceding the viewport was clipping the ingoing green beam too much, opening it up allowed for better coupling to the arm. I also tweaked the positions of the mode matching lenses and did some alignment, and have since been able to achieve GTRX values of around 0.5.
I also removed the 20db attenuator after the mixer, and turned the servo gain way down and was able to lock easily. I then adjusted the gain while measuring the CLG, and set it where the maximum gain peaking was 6dB, which worked out to be a UGF of around 8kHz. On the input monitor, the PDH horn-to-horn voltage going into the VGA is 2.44V, which shouldn't saturate the G=4 preamp stage of the AD8336, which seems ok.
The ALS sensitivity is now approaching the good nominal state:
There remains some things to be done, including comprehensive dumping of all beams at the end table (especially the reflections off of the viewport) and the new filters to replace the current post-mixer LPF, but things look pretty good.
First, I disabled front end starts on boot up, and brought c1sus up. I rebuilt the models for the c1sus computer so they had a new specific_cpu numbers, making the assumption that 0-1 were one real core, 2-3 were another, etc.
Then I ran the startc1SYS scripts one by one to bring up the models. Upon just loading the c1x02 on "core 2" (the IOP), I saw it fluctuate from about 5 to 12. After bringing up c1sus on "core 3", I saw the IOP settle down to about 7 consistently. Prior to hyper-threading it was generally 5.
Unfortunately, the c1sus model was between 60 and 70 microseconds, and was producing error messages a few times a second
[ 1052.876368] c1sus: cycle 14432 time 65; adcWait 0; write1 0; write2 0; longest write2 0
[ 1052.936698] c1sus: cycle 15421 time 74; adcWait 0; write1 0; write2 0; longest write2 0
Bringing up the rest of the models (c1mcs on 4, c1rfm on 5, and c1pem on 6), saw c1mcs occasionally jumping above the 60 microsecond line, perhaps once a minute. It was generally hovering around 45 microseconds. Prior to hyper-threading it was around 25-28 microseconds.
c1rfm was rock solid at 38, which it was prior to hyper-threading. This is most likely due to the fact it has almost no calculation and only RFM reads slowing it down.
c1pem continued to use negligible time, 3 microseconds out of its 480.
I tried moving c1sus to core 8 from core 3, which seemed to bring it to the 58 to 65 microsecond range, with long cycles every few seconds.
I built 5 dummy models (dua on 7, dub on 9, duc on 10, dud on 11, due on 1) to ensure that each virtual core had a model on it, to see if it helped with stabilizing things. The models were basically copies of the c1pem model.
Interestingly, c1mcs seemed to get somewhat better and only taking to 30-32 microseconds, although still not as good as its pre-hyper-threading 25-28. Over the course of several minutes it was no longer having a long cycle.
c1sus got worse again, and was running long cycles 4-5 times a second.
At this point, without surgery on which models are controlling which optics (i.e. splitting the c1sus model up) I am not able to have hyper-threading on and have things working. I am proceeding to revert the control models and c1sus computer to the hyper-threading state.
I am working on IMC electronics. IMC is misaligned until further notice.
First, the easy story: SRM got it's guiderod & standoff glued on this evening. It will be ready for magnets (assuming everything is sorted out....see below) as early as tomorrow. We can also begin to glue PRM guiderods as early as tomorrow.
The magnet story is not as short.....
Problem: ITMX and ITMY's side magnets are not glued in the correct places along the z-axis of the optic (z-axis as in beam propagation direction).
ITMX (as reported the other day) has the side magnet placement off by ~2mm. ITMX side was glued using the magnet fixture from MIT and the teflon pads that Kiwamu and I improvised.
It was determined that the improvised teflon pads were too thin (maybe about 1m thick), so I took those out, and replaced them with the teflon pads stolen from the 40m's magnet gluing fixture. (The teflon pad from the MIT fixture and the ones from the MIT fixture are the same within my measuring ability using a flat surface and feeling for a step between them. I haven't yet measured with calipers the MIT pad thickness). The pads from the 40m fixture, which were used in the MIT fixture to glue ITMY side last night were measured to be ~1.7mm thick.
Today when Koji hung ITMY, he discovered that the side magnet is off by ~1mm. This improvement is consistent with the switching of the teflon pads to the ones from the 40m fixture.
We compared the 40m fixture with the one from MIT, and it looks like the distance from the edge of where the optic should sit to the center of the hole for the side magnet is different by ~1.1mm. This explains the remaining ~1mm that ITMY is off by.
We should put the teflon pads back into the 40m fixture, and only use that one from now on, unless we find an easy way to make thicker teflon pads for the fixture we received from MIT. (The pads that are in there are about the maximum thickness that will fit). I'm going to use my thickness measurements of SRM (taken in the process of gluing the guiderods) to see what thickness of pads / what fixture we want to actually use, but I'm sure that the fixture we found in the 40m is correct. We can't use this fixture however, until we get some clean 1/4-28 screws. I've emailed Steve and Bob, so hopefully they'll have something for us by ~lunchtime tomorrow.
The ITMX side magnet is so far off in the Z-direction that we'll have to remove it and reglue it in the correct position in order for the shadow sensor to do anything. For ITMY, we'll check it out tomorrow, whether the magnet is in the LED beam at all or not. If it's not blocking the LED beam enough, we'll have to remove and reglue it too.
Why someone made 2 almost identical fixtures, with a 1mm height difference and different threads for the set screws, I don't know. But I don't think whoever that person was can be my friend this week.
[ericq, Lydia, Teng]
Brief summary of this afternoon's activities:
Addendum: I had a suspicion that the alignment had moved so much, we were missing the TRX PDs. I misaligned the Y arm, and used AS110 as a proxy for X arm power, as we've done in the past for this kind of thing. Indeed, I could maximize the signal and lock a TM00 mode. Both the high gain PD and QPD in the TRX path are totally dark. This needs realignment on the end table.
Rana suspicious. We had arms locked before pumpdown with beams on Transmon PDs. If they're off now, must be beams are far off on the mirrors. Try A2L to estimate spot positions before walkin the beams too far.
The misalignment wasn't as bad as I had intially feared; the spot was indeed pretty high on ETMX at first. Both transmon QPDs did need a reasonable amount of steering to center once the dither had centered the beam spots on the optics.
Arms, PRMI and DRMI have all been locked and dither aligned. All oplevs and transmon QPDs have been centered. All AS and REFL photodiodes have been centered.
Green TM00 modes are seen in each arm; I'll do ALS recovery tomorrow.
Here is a list of suggested improvements to the summary pages. Let me know if there's something you'd like for me to add to this list!
- CDS Tab
We want to monitor the status of the digital control system.
Title: EPICS DAQ Status
I wonder we can plot the binary numbers as statuses of the data acquisition for the realtime codes.
We want to use the status indicators. Like this:
Title: IOP Fast Channel DAQ Status
These have two bits each. How can we handle it?
If we need to shrink it to a single bit take "AND" of them.
C1:FEC-40_FB_NET_STATUS (legend: c1x04, if a legend placable)
C1:FEC-20_FB_NET_STATUS (legend: c1x02)
C1:FEC-33_FB_NET_STATUS (legend: c1x03)
C1:FEC-19_FB_NET_STATUS (legend: c1x01)
C1:FEC-46_FB_NET_STATUS (legend: c1x05)
Title C1LSC CPU Meters
C1:FEC-40_CPU_METER (legend: c1x04)
C1:FEC-42_CPU_METER (legend: c1lsc)
C1:FEC-48_CPU_METER (legend: c1ass)
C1:FEC-22_CPU_METER (legend: c1oaf)
C1:FEC-50_CPU_METER (legend: c1cal)
The range is from 0 to 75 except for c1oaf that could go to 500.
Can we plot c1oaf with the value being devided by 8? (Then the legend should be c1oaf /8)
Title C1SUS CPU Meters
C1:FEC-20_CPU_METER (legend: c1x02)
C1:FEC-21_CPU_METER (legend: c1sus)
C1:FEC-36_CPU_METER (legend: c1mcs)
C1:FEC-38_CPU_METER (legend: c1rfm)
C1:FEC-39_CPU_METER (legend: c1pem)
The range is be from 0 to 75 except for c1pem that could go to 500.
Can we plot c1pem with the value being devided by 8? (Then the legend should be c1pem /8)
Title C1IOO CPU Meters
C1:FEC-33_CPU_METER (legend: c1x03)
C1:FEC-34_CPU_METER (legend: c1ioo)
C1:FEC-28_CPU_METER (legend: c1als)
The range is be from 0 to 75.
Title C1ISCEX CPU Meters
C1:FEC-19_CPU_METER (legend: c1x01)
C1:FEC-45_CPU_METER (legend: c1scx)
C1:FEC-44_CPU_METER (legend: c1asx)
The range is be from 0 to 75.
Title C1ISCEY CPU Meters
C1:FEC-46_CPU_METER (legend: c1x05)
C1:FEC-47_CPU_METER (legend: c1scy)
C1:FEC-91_CPU_METER (legend: c1tst)
The range is be from 0 to 75.
We want a duty ratio plot for the IMC. C1:IOO-MC_TRANS_SUM >1e4 is the good period.
Duty ratio plot looks like the right plot of the following link
OL_PIT_INMON and OL_YAW_INMON are good for the slow drift monitor.
But their sampling rate is too slow for the PSDs.
Can you use
For the PSDs? They are 2kHz sampling DQ channels. You would be able to plot
it up to ~1kHz. In fact, we want to monitor the PSD from 100mHz to 1kHz.
How can you set up the resolution (=FFT length)?
LSC / ASC / ALS tabs
Let's make new tabs LSC, ASC, and ALS
We should have a plot for
It's OK to use the minute trend for now.
You can check the range using dataviewer.
C1:SUS_MC1_ASCPIT_OUT16 (legend: IMC WFS)
C1:ASS-XARM_ITM_YAW_OSC_CLKGAIN (legend: XARM ASS)
C1:ASS-YARM_ITM_YAW_OSC_CLKGAIN (legend: YARM ASS)
C1:ASX-XARM_M1_PIT_OSC_CLKGAIN (legend: XARM Green ASS)
as the status indicators. There is no YARM Green ASS yet.
Title: ALS Green transmission
We want a time series of
Title: ALS Green beatnote
Another time series
Title: Frequency monitor
We have frequency counter outputs, but I have to talk to Eric to know the channel names
Hours of struggle and still no data
I tried to measure the AR reflectivity and the loss due to flipping of G&H mirrors
With almost no wedge angle, separating the AR reflected beam from the HR reflected beam seems to need more tricks.
The separation between the 2 reflected rays is expected 0.8mm. After using a lens along the incident beam, this distance was still not enough to be separable by an iris.
The first trick: I could find a prism and tried to refract the beams at the edge of the prism...but the edges weren't that sharp to separate the beams (Infact I thought an axicon would do the job better..but I think we don't have any of those).
Next from the bag of tricks: I installed a camera to see if the spots can actually be resolved.
The camera image shows the 2 sets of focal spots; bright set to the left corresponding to HR reflected beam and the other from the AR surface. I expect the ghost images to arise from the 15 arcsec wedge of the mirror. I tried to mask one of the sets using a razor blade to see if I can separate them and get some data using a PD. But, it so turns out that even the blade edge is not sharp enough to separate them.
If there are any more intelligent ideas...go ahead and suggest!
How about to measure the AR reflectivity at larger (but small) angles the extrapolate the function to smaller angle,
or estimate an upper limit?
The spot separation is
D = 2 d Tan(\phi) Cos(\theta), where \phi = ArcSin(Sin(\theta) * n)
D = 2 d Tan(\phi) Cos(\theta), where \phi = ArcSin(Sin(\theta) / n) (<== correction by Manasa's entry)
\theta is the angle of incidence. For a small \theta, D is propotional to \theta.
So If you double the incident angle, the beam separation will be doubled,
while the reflectivity is an even function of the incident angle (i.e. the lowest order is quadratic).
I am not sure until how much larger angle you can use the quadratic function rather than a quartic function.
But thinking about the difficulty you have, it might be worth to try.
n1Sin(\theta1) = n2 Sin(\theta2)
So it should be
\phi = ArcSin(Sin(\theta) / n
I did check the reflected images for larger angles of incidence, about 20 deg and visibly (on the IR card) I did not see much change in the separation. But I will check it with the camera again to confirm on that.
Use the trick I suggested:
Focus the beam so that the beam size at the detector is smaller than the beam separation. Use math to calculate the beam size and choose the lens size and position. You should be able to achieve a waist size of < 0.1 mm for the reflected beam.
I adjusted the focal length of the focusing lens and reduced the beam size enough to mask with the razor blade edge while looking at the camera and then making measurements using PD.
I am still not satisfied with this data because the R of the HR surface measured after flipping seems totally unbelievable (at around 0.45).
G&H AR reflectivity
11 ppm @4 deg
19.8 ppm @6 deg
20 ppm @ 8 deg
30 ppm @ 20 deg
Gooch & Housego optics order specification from 03-13-2010
Side 1: HR Reflectivity >99.99 % at 1064 nm for 0-45 degrees for S & P polarization
Side 2: AR coat R <0.15
The HR coating scans uploaded to 40mwiki / Aux optics today
We measured the wedge angle of the G&H and LaserOptik mirrors at the OMC lab using an autocollimator and rotation stage.
The wedge angles:
G&H : 18 arc seconds (rough measurement)
LaserOptik : 1.887 deg
Steve sent 4 of our 1" diameter G&H HR mirrors to Josh Smith at Fullerton for scatter testing. Attached photo is our total stock before sending.
I upgraded the GDS and ROOT installations in /ligo/apps/ubuntu12 the control room workstations:
My cursory tests indicate that they seem to be working:
Now that the control room environment has become somewhat uniform at Ubuntu 12, I modified the /ligo/cdscfg/workstationrc.sh file to source the ubuntu12 configuration:
controls@nodus|apps > cat /ligo/cdscfg/workstationrc.sh
# CDS WORKSTATION ENVIRONMENT
This should make all the newer versions available everywhere on login.
I've noticed that we're experiencing this bug which was previously seen at LHO. We cannot enter 10 digit GPS times into the time fields for DTT due to a limit in TLGEntry.cc, which Jim Batch fixed in September of last year. Seems like we're running an old version of the GDS tools.
I checked the Lidax tool (which you can get from the GDS Mainmenu). It does, in fact, allow 10 digit entries.
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.