40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 90 of 346  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  13744   Tue Apr 10 14:28:44 2018 gautamUpdateIOOFurther debugging

I am working on IMC electronics. IMC is misaligned until further notice.

  2654   Thu Mar 4 02:25:14 2010 JenneUpdateCOCFurther details on the magnet story, and SRM guiderod glued

[Koji, Jenne]

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. 

  12507   Mon Sep 19 22:03:10 2016 ericqUpdateGeneralFurther recovery progress

[ericq, Lydia, Teng]

Brief summary of this afternoon's activities:

  • PMC alignment adjusted (Transmission of 0.74)
  • IMC locked, hand aligned. Tranmission slightly over 15k. Measured spot positions to be all under 2mm.
  • Set DC offsets of MC2 Trans + WFS1 + WFS2 (WFS2 DC offsets had wandered so much that DC "centered" left some quadrants almost totally dark)
  • Set demod offsets of WFS1+WFS2
    • Note to self: WFS script area is a mess. I can never remember which scripts are the right ones to run. I should clean this up
  • WFS loops activated, tested. All clear.
  • Locked Yarm, dither aligned. Transmission 0.8
  • Moved BS to center ITMY reflection on AS camera
  • Misaligned ETMY, aligned PRM to make a flashing PRY AS beam. REFL camera spot confirmed to be on the screen, which is nice
  • Wandered ITMX around until its AS spot was found. ITMX OSEMs not too far from their half max. (todo: update with numbers)
  • Wandered SRM around until full DRMI flashes seen
  • Centered all vertex oplevs
  • Made a brief attempt at locking X arm, could only get some crazy high order mode to lock. BS and ITMX alignments have changed substantially from the in-air locks, so probably need to adjust ETMX much more.

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.

  12508   Tue Sep 20 10:45:06 2016 ranaUpdateGeneralFurther recovery progress

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.

  12510   Wed Sep 21 01:08:02 2016 ericqUpdateGeneralFurther recovery progress

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. 

  11414   Tue Jul 14 17:14:23 2015 EveSummarySummary PagesFuture summary pages improvements

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!

  • A lot of plots are missing axis labels and titles, and I often don't know what to call these labels. I could use some help with this.
  • Check the weather and vacuum tabs to make sure that we're getting the expected output. Set the axis labels accordingly. 
  • Investigate past periods of missing data on DataViewer to see if the problem was with the data requisition process, the summary page production process, or something else.
  • Based on trends in data over the past three months, set axis ranges accordingly to encapsulate the full data range.
  • Create a CDS tab to store statistics of our digital systems. We will use the CDS signals to determine when the digital system is running and when the minute trend is missing. This will allow us to exclude irrelevant parts of the data.
  • Provide duty ratio statistics for the IMC.
  • Set triggers for certain plots. For example, for channels C1:LSC-XARM OUT DQ and page 4 LIGO-T1500123–v1 C1:LSC-YARM OUT DQ to be plotted in the Arm LSC Control signals figures, C1:LSCTRX OUT DQ and C1:LSC-TRY OUT DQ must be higher than 0.5, thus acting as triggers.
  • Include some flag or other marking indicating when data is not being represented at a certain time for specific plots.
  • Maybe include some cool features like interactive plots.
  11437   Wed Jul 22 22:06:42 2015 EveSummarySummary PagesFuture summary pages improvements

- CDS Tab

We want to monitor the status of the digital control system.

1st plot
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:
https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20150722/plots/H1-MULTI_A8CE50_SEGMENTS-1121558417-86400.png

channels:
C1:DAQ-DC0_C1X04_STATUS
C1:DAQ-DC0_C1LSC_STATUS
C1:DAQ-DC0_C1ASS_STATUS
C1:DAQ-DC0_C1OAF_STATUS
C1:DAQ-DC0_C1CAL_STATUS

C1:DAQ-DC0_C1X02_STATUS
C1:DAQ-DC0_C1SUS_STATUS
C1:DAQ-DC0_C1MCS_STATUS
C1:DAQ-DC0_C1RFM_STATUS
C1:DAQ-DC0_C1PEM_STATUS

C1:DAQ-DC0_C1X03_STATUS
C1:DAQ-DC0_C1IOO_STATUS
C1:DAQ-DC0_C1ALS_STATUS

C1:DAQ-DC0_C1X01_STATUS
C1:DAQ-DC0_C1SCX_STATUS
C1:DAQ-DC0_C1ASX_STATUS

C1:DAQ-DC0_C1X05_STATUS
C1:DAQ-DC0_C1SCY_STATUS
C1:DAQ-DC0_C1TST_STATUS

1st plot
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)

3rd plot
Title C1LSC CPU Meters
channels:
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)

4th plot
Title C1SUS CPU Meters
channels:
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)

5th plot
Title C1IOO CPU Meters
channels:
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.

6th plot
Title C1ISCEX CPU Meters
channels:
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.

7th plot
Title C1ISCEY CPU Meters
channels:
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.

=====================

IOO

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
https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20150722/lock/segments/

=====================

SUS: OPLEV

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
C1:SUS-ETM_OPLEV_PERROR
C1:SUS-ETM_OPLEV_YERROR
etc...
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

LSC:

We should have a plot for
C1:LSC-TRX_OUT_DQ
C1:LSC-TRY_OUT_DQ
C1:LSC-POPDC_OUT_DQ
It's OK to use the minute trend for now.
You can check the range using dataviewer.

ASC:

Let's use
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.

ALS:

Title: ALS Green transmission
We want a time series of
ALS-TRX_OUT16
ALS-TRY_OUT16

Title: ALS Green beatnote
Another time series
ALS-BEATX_FINE_Q_MON
ALS-BEATY_FINE_Q_MON

Title: Frequency monitor
We have frequency counter outputs, but I have to talk to Eric to know the channel names

  8045   Fri Feb 8 21:14:52 2013 ManasaUpdateOpticsG&H - AR Reflectivity

 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.

pr2.png

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! 

 

27_1044419003.bmp

  8046   Fri Feb 8 22:49:31 2013 KojiUpdateOpticsG&H - AR Reflectivity

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.

  8047   Fri Feb 8 23:04:40 2013 ManasaUpdateOpticsG&H - AR Reflectivity

Quote:

D = 2 d Tan(\phi) Cos(\theta), where \phi = ArcSin(Sin(\theta) * n)

\theta is the angle of incidence. For a small \theta, D is propotional to \theta.

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.

  8051   Sat Feb 9 19:34:34 2013 ranaUpdateOpticsG&H - AR Reflectivity

 

 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.

  8063   Mon Feb 11 19:55:47 2013 ManasaUpdateOpticsG&H - AR Reflectivity

 

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

R percentage

11 ppm @4 deg
19.8 ppm @6 deg
20 ppm @ 8 deg
30 ppm @ 20 deg

  8075   Wed Feb 13 09:28:56 2013 SteveUpdateOpticsG&H - HR plots

 

 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

  8018   Wed Feb 6 20:19:52 2013 ManasaUpdateOpticsG&H and LaserOptik mirrors

[Koji, Manasa]

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

  12102   Mon May 2 17:06:58 2016 ranaSummaryCOCG&H optics to Fullerton/HWS for anneal testing

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.

Attachment 1: 20160427_182305.jpg
20160427_182305.jpg
  530   Wed Jun 11 15:30:55 2008 josephbConfigurationCamerasGC1280
The trial use GC1280 has arrived. This is a higher resolution CMOS camera (similar to the GC750). Other than higher resolution, it has a piece of glass covering and protecting the sensor as opposed to a plastic piece as used in the GC750. This may explain the reduced sensitivity to 1064nm light that the camera seems to exhibit. For example, the image averages presented here required a 60,000 microsecond exposure time, compared to 1000-3000 microseconds for similar images from the GC750. This is an inexact comparison, and the actual sensitivity difference will be determined once we have identical beams on both cameras.

The attached pdfs (same image, different angles of view) are from 200 averaged images looking at 1064nm laser light scattering from a piece of paper. The important thing to note is there doesn't seem to be any definite structure, as was seen in the GC750 scatter images.

One possibility is that too much power is reaching the CMOS detector, penetrating, and then reflecting back to the back side of the detector. Lower power and higher exposure times may avoid this problem, and the glass of the GC1280 is simply cutting down on the amount passing through.

This theory will be tested either this evening or tomorrow morning, by reducing the power on the GC750 to the point at which it needs to be exposed for 60,000 microseconds to get a decent image.

The other possibility is that the GC750 was damaged at some point by too much incident power, although its unclear what kind of failure mode would generate the images we have seen recently from the GC750.
Attachment 1: GC1280_60000E_scatter_2d.pdf
GC1280_60000E_scatter_2d.pdf
Attachment 2: GC1280_60000E_scatter_3d.pdf
GC1280_60000E_scatter_3d.pdf
  649   Tue Jul 8 21:46:38 2008 YoichiConfigurationPSLGC650M moved to the PMC transmission
I moved a GC650M, which was monitoring the light coming out of the PSL, to the transmission port of the PMC to see the transmitted mode shape.
It will stay there unless someone find other use of it.

Just FYI, you can see the picture from the control computers by the following procedure:

ssh -X mafalda
cd /cvs/cds/caltech/target/Prosilica/40mCode
./SampleViewer

Chose 02-2210A-06223 and click on the Live View icon.
  521   Thu Jun 5 13:35:23 2008 josephbConfigurationCamerasGC750 looking at 1064nm scattered light
I've taken 200 images of the GC750 (CMOS) camera while holding it by hand up to a beam card (also held by hand) in the path of ~5mW of beam power. I then averaged the images to produce the fourth attached plot.

Rob has pointed out the image looks a lot like PCB traces. So perhaps we're seeing the electronics behind the CMOS sensor?

I repeated the same experiment with HeNe laser light (again scattered off a card). These show none of the detailed structure (just what looks to be a large reflection from the card moving around depending on how steady my hand was). These are the first 3 attached plots. So only 1064nm light so far sees these features.

As a possible solution, I did a quick and dirty calibration by dividing a previous PSL output beam by the 1064 average scatter light values. These produce the last attached pdf (with multiple images). The original uncalibrated image is on top, while the very simply calibrated image is on the bottom of each plot.

It seems as the effect may be power dependent (which could still be calibrated properly, but would take a bit more effort than simply dividing), as determined by looking at the edges of the calibrated plot.
Attachment 1: GC750_HeNe_scatter_avg.pdf
GC750_HeNe_scatter_avg.pdf
Attachment 2: GC750_HeNe_scatter_avg2.pdf
GC750_HeNe_scatter_avg2.pdf
Attachment 3: GC750_HeNe_scatter_avg3.pdf
GC750_HeNe_scatter_avg3.pdf
Attachment 4: GC750_scatter_avg.pdf
GC750_scatter_avg.pdf
Attachment 5: GC750_nitrogen_white.pdf
GC750_nitrogen_white.pdf GC750_nitrogen_white.pdf GC750_nitrogen_white.pdf GC750_nitrogen_white.pdf GC750_nitrogen_white.pdf GC750_nitrogen_white.pdf GC750_nitrogen_white.pdf
  378   Fri Mar 14 12:06:29 2008 josephbConfigurationCamerasGC750 looking at ETMX while locked
The GC750 (CMOS) is currently looking at the front of ETMX. Unfortunately, its being routed through a 10Mbit connection (which I will be purchasing a replacement for today), so getting it to send images to Mafalda/Linux 2 or 3 isn't working well, but by using a local gigabit switch and a laptop I can get sufficient speed for full images with the sample viewer.

The attached image is from a full 752x480 reslution with 10,000 microsecond exposure with the X-arm locked. Although it looks like I still need to work on the focusing. Will be switching the GC750 with the GC 650 (CCD) later today and comparing the resulting images.
Attachment 1: ETMX_zoom_exp_10000_750.tiff
  558   Tue Jun 24 17:12:10 2008 josephb, EricConfigurationCamerasGC750 setup, 1X4 Hub connected, ETMX images
The GC750 camera has been setup to look at ETMX. In addition, the new 1X4 rack mounted switch (131.215.113.200) has been connected via new cat6 cable to the control room hub (131.215.113.1?), thanks to Eric. The camera is now plugged into 1X4 rack switch and now has a gigabit connection to the control room computers as well as Mafalda (131.215.113.23).

By using ssh -X mafalda or ssh -X 131.215.113.23, then typing:

target
cd Prosilica/bin-pc/x86/
./Sampleviewer

A viewer will be brought up. By clicking on the 3rd icon from the left (looks like an eye) will bring up a live view.

Closing the view, and then cd ../../40mCode, and then running ./Snap --help will tell you how to use a simple code for taking .tiff images as well as setting things such as exposure length and size of image (in pixels) to send.

When the interferometer was set to an X-arm only configuration, we took two series of 200 images each, with two different exposure lengths.

Attached are three pdf images. The first is just a black and white single image, the second is an average of 100 images, and the third is the standard deviation of the 100 images.
Attachment 1: GC750_ETMX_E30000_single.pdf
GC750_ETMX_E30000_single.pdf
Attachment 2: GC750_ETMX_E30000_avg.pdf
GC750_ETMX_E30000_avg.pdf
Attachment 3: GC750_ETMX_E30000_std.pdf
GC750_ETMX_E30000_std.pdf
  10854   Mon Jan 5 20:17:26 2015 jamieConfigurationCDSGDS upgraded to 2.16.14

I upgraded the GDS and ROOT installations in /ligo/apps/ubuntu12 the control room workstations:

  • GDS 2.16.14
  • ROOT 5.34.18 (dependency of GDS)

My cursory tests indicate that they seem to be working:

2015-01-05-200025_1694x996_scrot.png

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
source /ligo/apps/ligoapps-user-env.sh
source /ligo/apps/ubuntu12/ligoapps-user-env.sh
source /opt/rtcds/rtcds-user-env.sh
controls@nodus|apps > 

This should make all the newer versions available everywhere on login.

  7238   Tue Aug 21 00:02:05 2012 ranaSummaryComputer Scripts / ProgramsGDS/DTT bug: 10 digit GPS times not accepted

 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.

  13   Thu Oct 25 00:01:21 2007 ranaSoftware InstallationCDSGEO DV => LIGO DV
Martin Hewitson of GEO600 fame has modified the cool GEO DV
to work with the LIGO NDS system with some NDS advice from Rolf (who's over in Germany this week).

I've moved it onto the 40m CDS system and installed it on the AdhikariLab computer named 'django'. It worked immediately.

I modified the main .m file to include the 40m's NDS server. When you run it you have to include the path to the NDS
client written by Ben Johnson.

The attached is a screenshot of it working on a Mac; it looks as cool on Linux.

Its installed in /cvs/cds/caltech/apps/ligoDV/. In matlab you navigate to that directory and then
type addpath('/cvs/cds/caltech/apps/linux/UNIX_NDS_Client_beta2/') to add the NDS client.
On the Solaris machines, type type addpath('/cvs/cds/caltech/apps/solaris9/UNIX_NDS_Client_beta2/') instead.

Then type ligoDV to start it up. Then click away and have fun.

In the example I've selected
C1:PEM-BS_ACC_EAST_Z
and plotted its specgram.

Big grin
Attachment 1: Picture_1.png
Picture_1.png
  144   Fri Nov 30 11:22:22 2007 ajwSummaryCDSGEO DV => LIGO DV

Quote:
Martin Hewitson of GEO600 fame has modified the cool GEO DV
to work with the LIGO NDS system with some NDS advice from Rolf (who's over in Germany this week).

I've moved it onto the 40m CDS system and installed it on the AdhikariLab computer named 'django'. It worked immediately.

I modified the main .m file to include the 40m's NDS server. When you run it you have to include the path to the NDS
client written by Ben Johnson.

The attached is a screenshot of it working on a Mac; it looks as cool on Linux.

Its installed in /cvs/cds/caltech/apps/ligoDV/. In matlab you navigate to that directory and then
type addpath('/cvs/cds/caltech/apps/linux/UNIX_NDS_Client_beta2/') to add the NDS client.
On the Solaris machines, type type addpath('/cvs/cds/caltech/apps/solaris9/UNIX_NDS_Client_beta2/') instead.

Then type ligoDV to start it up. Then click away and have fun.

In the example I've selected
C1:PEM-BS_ACC_EAST_Z
and plotted its specgram.

Big grin


Download and installation instructions, as well as a few examples for use
can be found here (typical lsc username and password):

https://www.gravity.phy.syr.edu/dokuwiki/doku.php?id=ligodv:home
https://www.gravity.phy.syr.edu/dokuwiki/doku.php?id=ligodv:downloading_the_ligodv_software
  234   Thu Jan 10 13:45:52 2008 PkpUpdateCamerasGLIBC Error
So, I have tried to compile the camera files which are in /cvs/cds/caltech/target/Prosilica/examples for the past 2 days now and have been unable to get rid of the following error. (specifically ListCameras.cpp, as it doesnt have any other libraries required, which unnecessarily complicates things)

../../bin-pc/x86/libPvAPI.so: undefined reference to `__stack_chk_fail@GLIBC_2.4'
collect2: ld returned 1 exit status
make: *** [sample] Error 1

I used to get this error on mafalda too, but I had fixed it by installing the latest version of the glibc libraries. Inspite of doing so on linux2, the error still persists. I suspect it had something to do with it being a FC3 machine. My own laptop, which also runs Ubuntu works fine too. The problem with these Ubuntu machines is that they dont let me set the packet sizes to 9 kb which is required by the camera. Linux2 does.

If anyone has any idea how to resolve this issue, please let me know.

Thanks
Pinkesh.
  158   Mon Dec 3 16:24:47 2007 tobinHowToComputersGNU screen
GNU screen is a utility that can be quite handy for managing long-running psuedo-interactive terminal programs on remote machines. In particular, I think it might be useful in developing and testing "Matlab DMT" tools on Mafalda.
  142   Thu Nov 29 18:10:13 2007 AlbertoHowToComputer Scripts / ProgramsGPIB Scripts
I've spent a lot of time trying to configurate the GPIB-USB interface for the HP4195. After installing 1) the Agilent libraries, 2) the drivers, 3) the matlab Instrument Toolbox, 4) Jamie script, 5) Alice's script the computer can see the HP but still they can't 'talk' to each other.
I give up. I asked Alice Wang how she managed to get data. I'm not sure she used the GPIB interace. Rob said she might have used the old fashion floppy disks that we can't read anymore here.
I would really appreciate any suggestion by anyone who happened to have the same problems.
  143   Thu Nov 29 19:35:14 2007 ranaHowToComputer Scripts / ProgramsGPIB Scripts

Quote:
I've spent a lot of time trying to configurate the GPIB-USB interface for the HP4195. After installing 1) the Agilent libraries, 2) the drivers, 3) the matlab Instrument Toolbox, 4) Jamie script, 5) Alice's script the computer can see the HP but still they can't 'talk' to each other.
I give up. I asked Alice Wang how she managed to get data. I'm not sure she used the GPIB interace. Rob said she might have used the old fashion floppy disks that we can't read anymore here.
I would really appreciate any suggestion by anyone who happened to have the same problems.


Alice and Jamie used the USB-GPIB interface. You should just try using the black laptop which already has this capability or ask Jamie Rollins
who actually knows something.
  3969   Mon Nov 22 20:01:56 2010 kiwamuConfigurationComputersGPIB box : took it out from HP3563A and connect it to AG4395A

 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.

  3120   Fri Jun 25 12:09:27 2010 kiwamuUpdateComputersGPIB controller of HP8591E

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

name: teofila

address: 131.215.113.106

  1479   Mon Apr 13 18:57:03 2009 AlbertoFrogsComputersGPIB/ETH Interface Troubles

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:

netSock.send("mkpk;mka?\n")
netSock.send("++read eoi\n")
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.

Attachment 1: sweepfrequencyPRC.py
## 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
... 53 more lines ...
Attachment 2: HP8590PRC.py
# 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

import re
import sys
import math
from optparse import OptionParser
from socket import *
... 70 more lines ...
  1481   Tue Apr 14 12:10:11 2009 AlbertoFrogsComputersGPIB/ETH Interface Troubles

Quote:

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:

netSock.send("mkpk;mka?\n")
netSock.send("++read eoi\n")
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.

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.

  5994   Thu Nov 24 02:23:43 2011 KojiSummaryGeneralGPIB<->WIFI

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

  • You need a host with 192.168.1.*.
  • Connect the host and the LINKSYS directly
  • Open http://192.168.1.226/
  • Select 40MARS and infrastructure mode
  • Register it in the MAC filter of the 40MARS (see wiki and use your head)

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.

  1070   Wed Oct 22 20:50:30 2008 AlbertoOmnistructureComputersGPS
Today I measured the GPS clock frequency at the output of CLOCK_MON in a board on the same crate where the c1iool0 computer is located. The monitor was connected with a BNC cable to the 10MHz reference input of the frequency counter on top of that rack, where it was used to check the 166MHz coming from one of the Marconi.

The frequency was supposed to be 10MHz but I actually measured 8 MHz. I tracked down the GPS input cable to the board and it turned out to come from one of the 1Y7 rack. Here it was connected to a board with a display that was showing corrupted digits, plus some leds on the front panel were red.

I'm not sure the GPS reference is working properly.
  1133   Thu Nov 13 15:50:44 2008 AlbertoConfigurationGeneralGPS 10MHz clock
The schematic of the 1Y7 rack that Alan pointed out (see attachment) don't represent anymore the actual rack.
First, with Yoichi we found that the GPS receiver for the 10 MHz is in a different position,
on the other side of the VME computer. It seems to output 1 kHz, which also appears in some modulated way.
This signal is then passed to a board on 1Y7 that seems make just copies of the signal. One of these goes
to an other board in 1Y6 that looks like a GPS receiver but has actually no GPs antenna input. Here it is
not connected to anything, but on its same crate is a the awg computer, so it might be providing the clock
to that by the crate.

We also checked the clock monitor output on the boards in the PSL that provides for the clock to the Penteks
and it seems that these are actually getting 4MHz.
Attachment 1: rackstuff.pdf
rackstuff.pdf rackstuff.pdf rackstuff.pdf rackstuff.pdf
  12182   Wed Jun 15 10:19:10 2016 SteveConfigurationCDSGPS antennas... debugging

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.

Attachment 1: GPStimeServer.jpg
GPStimeServer.jpg
Attachment 2: GPSsn.jpg
GPSsn.jpg
Attachment 3: GPSantennas.jpg
GPSantennas.jpg
Attachment 4: GPSantHead.jpg
GPSantHead.jpg
Attachment 5: GPSantHead2.jpg
GPSantHead2.jpg
Attachment 6: GPSantCabels.jpg
GPSantCabels.jpg
  13211   Tue Aug 15 16:32:42 2017 Jamie, GautumUpdateCDSGPS receiver apparently set to correct mode as "UTC"
Quote:

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:

In the GPS receiver, you are trying to match the IRIG-B output format that is created by the aLIGO IRIG-B Fanout.  Since we have to prep the aLIGO IRIG-B Fanout every time there is a leap second coming, I would suspect that we are sending UTC to the IRIG-B receivers.  Thus, the GPS receiver needs to be set to that mode.

Soooo, "UTC" is the correct mode for the GPS receiver.

  12167   Fri Jun 10 12:21:54 2016 jamieConfigurationCDSGPS receiver not resetting properly

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.

  12200   Mon Jun 20 11:11:20 2016 SteveConfigurationCDSGPS receiver not resetting properly

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.

Quote:

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.

 

  12201   Mon Jun 20 11:19:41 2016 jamieConfigurationCDSGPS receiver not resetting properly
Quote:

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.

http://endruntechnologies.com/pdf/FSB160218.pdf
http://endruntechnologies.com/upgradetemplx.htm

  16299   Wed Aug 25 18:20:21 2021 JamieUpdateCDSGPS time on fb1 fixed, dadq writing correct frames again

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.

  6725   Thu May 31 01:36:17 2012 yutaUpdateGreen LockingGREEN_TRX/GREEN_TRY PDs

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.

  9055   Thu Aug 22 21:16:47 2013 ManasaUpdateGreen LockingGTRY normalized

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. 

  9056   Thu Aug 22 22:05:36 2013 ranaUpdateGreen LockingGTRY normalized

Meh. 600 counts is too weak.  You should fix the electronics so that the maximized green laser transmission gives more like ~10000 counts.

  9675   Tue Feb 25 23:38:05 2014 rana, jenneUpdatePEMGUR1 Z channel excess noise: oscillating Z channel

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.

Attachment 1: gur1z.pdf
gur1z.pdf
  8567   Mon May 13 23:05:51 2013 JenneUpdatePEMGUR1 masses recentered

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

  6973   Fri Jul 13 13:02:52 2012 Masha, YaakovUpdatePEMGUR2 Fixed

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.

 

  15153   Fri Jan 24 17:14:01 2020 gautamUpdateALSGain blocks installed

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.
Quote:
 

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

  15130   Fri Jan 17 18:02:21 2020 gautamUpdateALSGain blocks packaged and characterized

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

Attachment 1: photos.pdf
photos.pdf
Attachment 2: gain.pdf
gain.pdf
Attachment 3: noise.pdf
noise.pdf
Attachment 4: measSchem.pdf
measSchem.pdf
Attachment 5: zhl1010Data.zip
  10418   Thu Aug 21 02:42:17 2014 rana, ericqConfigurationGreen LockingGain changes on Green Y PDH

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

TEK00002.PNGTEK00003.PNG

 


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. 

ELOG V3.1.3-