40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 154 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  11020   Fri Feb 13 03:28:34 2015 ranaUpdateLSCNew Locking Paradigm - Loop-gebra

Not so fast!

In the drawing, the FF path should actually be summed in after the Phase Tracker (i.e. after S_ALS). This means that the slow response of the phase tracker needs to be taken into account in the FF cancellation filter. i.e. D = -A_REFL * P_ALS * S_ALS. Since the Phase Tracker is a 1/f loop with a 1 kHz UGF, at 100 Hz, we can only get a cancellation factor of ~10.

So, tonight we added a 666:55 boost filter into the phase tracker filter bank. I think this might even make the ALS locking loops less laggy. The boost is made to give us better tracking below ~200 Hz where we want better phase performance in the ALS and more cancellation of the ALS-Fool. If it seems to work out well we can keep it. If it makes ALS more buggy, we can just shut it off.

Its time to take this loop cartoon into OmniGraffle.

  11001   Wed Feb 11 04:08:53 2015 JenneUpdateLSCNew Locking Paradigm?

[Rana, Jenne]

While meditating over what to do about the fact that we can't seem to hold PRMI lock while reducing the CARM offset, we have started to nucleate a different idea for locking

We aren't sure if perhaps there is some obvious flaw (other than it may be tricky to implement) that we're not thinking about, so we invite comments.  I'll make a cartoon and post it tomorrow, but the idea goes like this.....

Can we use ALS to hold both CARM and DARM by actuating on the ETMs, and sit at (nominally) zero offset for all degrees of freedom?  PRMI would need to be stably held with 3f signals throughout this process. 

1) Once we're close to zero offset, we should see some PDH signal in REFL11.  With appropriate triggering (REFLDC goes low, and REFL11I crosses zero), catch the zero crossing of REFL11I, and feed it back to MC2. We may want to use REFL11 normalized by the sum of the arm transmissions to some power (1, 0.5, or somewhere in between may maximize the linear range even more, according to Kiwamu).  The idea (very similar to the philosophy of CESAR) is that we're using ALS to start the stabilization, so that we can catch the REFL11 zero crossing. 

2) Now, the problem with doing the above is that actuating on the mode cleaner length will change the laser frequency.  But, we know how much we are actuating, so we can feed forward the control signal from the REFL11 carm loop to the ALS carm loop.  The goal is to change the laser frequency to lock it to the arms, without affecting the ALS lock.  This is the part where we assume we might be sleepy, and missing out on some obvious reason why this won't work.

3) Once we have CARM doubly locked (ALS pushing on ETMs, REFL11 pushing on MC/laser frequency), we can turn off the ALS system. Once we have the linear REFL11 error signal, we know that we have enough digital gain and bandwidth to hold CARM locked, and we should be able to eek out a slightly higher UGF since there won't be as many digital hops for the error signal to transverse. 

4) The next step is to turn on the high bandwidth common mode servo.  If ALS is still on at this point, it will get drowned out by the high gain CM servo, so it will be effectively off. 

5) Somewhere in here we need to transition DARM to AS55Q.  Probably that can happen after we've turned on the digital REFL11 path, but it can also probably wait until after the CM board is on.

The potential show-stoppers:

Are we double counting frequency cancellation or something somewhere?  Is it actually possible to change the laser frequency without affecting the ALS system?

Can we hold PRMI lock on 3f even at zero CARM offset?  Anecdotally from a few trials in the last hour or so, it seems like coming in from negative carm offset is more successful - we get to slightly higher arm powers before the PRMI loses lock.  We should check if we think this will work in principle and we're just saturating something somewhere, or if 3f can't hold us to zero carm offset no matter what.

A note on technique:  We should be able to get the transfer function between MC2 actuation and ALS frequency by either a direct measurement, or Wiener filtering.  We need this in order to get the frequency subtraction to work in the correct units.

  14412   Tue Jan 22 20:45:21 2019 gautamUpdateVACNew N2 setup

The N2 ran out this weekend (again no reminder email, but I haven't found the time to setup the Python mailer yet). So all the valves Steve and I had opened, closed (rightly so, that's what the interlocks are supposed to do). Chub will post an elog about the new N2 valve setup in the Drill-press room, but we now have sufficient line pressure in the N2 line again. So Chub and I re-opened the valves to keep pumping on the RGA.

  14026   Wed Jun 27 19:37:16 2018 KojiConfigurationComputersNew NAT router installed

[Larry, Koji]

We replaced the NAT router between martian and the campus net. We have the administrative web page available for the NAT router, but it is accessible from inside (=martian) as expected.

We changed the IP address registration of nodus for the internet so that the packets to nodus is directed to the NAT router. Then the NAT router forwards the packets to actual nodus only for the allowed ports. Because of this change of the IP we had a few confusions. First of all, martian net, which relies on chiara for DNS resolution. The 40m wifi router seemed to have internal DNS cache and required to reboot to make the IP change effective.

The WAN side cable of nodus was removed.

We needed to run "sudo rndc flush" to force chiara's bind9 to refresh the cache. We also needed to restart httpd ("sudo systemctl restart httpd") on nodus to make the port 8081 work properly. 

So far, ssh (22), web services (30889), and elog (8081, 8080) were tested. We also need to test megatron NDS port forwarding and rsync for nodus, too.

Finally I turned off the firewall rules of shorewall on nodus as it is no longer necessary.

More details are found on the wiki page. https://wiki-40m.ligo.caltech.edu/FirewallSetting

  3781   Tue Oct 26 00:45:08 2010 ranaUpdatePSLNew NPRO Diagnostic Wiring

Untitled.png

I copy section 6.2 into here to share with you all what the diagnostic capabilities of the new NPRO are. Its not a lot.

We'll need to record a sample of the NPRO output beam on a regular photodiode in order to get a real power monitor. My plan is to use a regular 25-pin Dsub and run it fron the NPRO controller over to the PSL rack and hijack the old MOPA monitoring channels (3113 and 3123 ADCs).

  3679   Fri Oct 8 12:29:21 2010 KevinUpdateComputersNew Netgear Switch

I removed some old equipment from the rack outside the control room and stacked them next to the filing cabinets in the control room. I also mounted the new Netgear switch in the rack.

  3724   Thu Oct 14 22:26:38 2010 KojiUpdateComputersNew Netgear Switch

The network cables for the Martian network were moved to the new Netgear switch from the old one which had the broken fan.
The martian machines look happy so far.

Above the new switch we have the GC network switch. The two fans of it were also broken. The fans were replaced.

They are now quiet and I am quite satisfied.

Quote:

I removed some old equipment from the rack outside the control room and stacked them next to the filing cabinets in the control room. I also mounted the new Netgear switch in the rack.

 

  1033   Wed Oct 8 12:35:56 2008 josephbConfigurationComputersNew Network diagram for the 40m
Attached is a pdf of the new network diagram for the 40m after having removed all of the old hubs.
  10410   Tue Aug 19 21:40:44 2014 AndresUpdateIMCNew Optical Setup for the IMC

IMC Calculation and Setup

I have been working in the calculation for improving the Gouy Phase separation between the WFSs. I tried different possible setup, but the three big constrains in choosing a good optical table setup are to have a Waist size that range from 1mm-2mm, the Gouy Phase  between the WFSs have to be greater than 75 degrees and there has to be a steering mirror before each WFS. I will be showing the best calculation because that calculation complies with Rana request of having both WFSs facing west and having the shortest beam path. I approximate the distances by measuring with a tape the distance where the current optics are located and by looking at the picture that I took I approximated the distance where the lenses will be placed. I'm using a la mode for calculating the gouy phase different. I attached a picture of the current optical table setup that we have. Using a la mode, I found that the current gouy phase that we have is 49.6750 degrees.

Now, for the new setup, a run a la mode and found a Gouy phase of 89.3728 degrees. I have to create a two independent beam path: one for the WFS1 and another one for WFS2. The reason for this is that a la mode place everything in one dimension so and since the WFS1 will have a divergence lens in order to increase the waist size, and since that lens should not be interacting with the waist size in the WFS2. We need two beam path for each WFS.  A la mode give us the following solution:

For the beam path of the WFS1

    label                z (m)           type             parameters        
    -----                  -----              ----             ----------        
    MC1                   0              flat mirror          none:           
    MC3                   0.1753     flat mirror          none:           
    MC2                   13.4587   curved mirror    ROC: 17.8700 (m)     
    Lens1                 29.3705   lens                  focalLength: 1.0201 (m)
    BS2                    29.9475   flat mirror          none:           
    First Mirror         30.0237   flat mirror          none:           
    Lens3                30.2000    lens                  focalLength: -0.100 (m)
    WFS1                30.4809    flat mirror         none: 

For the beam path of the WFS2

    label                   z (m)             type             parameters        
    -----                    -----                 ----             ----------        
    MC1                    0               flat mirror          none:           
    MC3                    0.1753      flat mirror          none:           
    MC2                    13.4587    curved mirror    ROC: 17.8700 (m)     
    Lens1                  29.3705    lens                   focalLength: 1.0201 (m)
    BS2                     29.9475    flat mirror          none:           
    Second Mirror    30.2650     flat mirror          none:           
    Lens2                 30.4809     lens                  focalLength: -0.075 (m)
    Third Mirror        30.5698     flat mirror          none:           
    WFS2                30.6968      flat mirror          none:  

I attached bellow how the new setup should look like in the second picture and also I include and attachment of the a la mode code.

 I used Mist to be able to see the read out that we get in the WFSs that take the Mode Cleaner Reflection and the QPD that take the transmitted from MC2. In the following, plots I'm misaligned the each mirrors: MC1, MC2 and MC3. The misalignment are in Yaw and Pitch. I'm dividing the WFSs reading by the total power reflect power, and I'm dividing the QPD for the MC2 transmission by the total transmitted power. In my Mist model, I have a laser of 1W and my EOM is modulated at 30MHz instead of 29.5MHz and the modulation depth was calculating by measuring the applied voltage using and Spectrum analyzer. I using Kiwamu measurement of modulation depth efficiency vs the applied voltage, https://dcc.ligo.org/DocDB/0010/G1000297/001/G1000297-v1.pdf,  I got a modulation depth of 0.6 mrad. I put this modulation depth and I got the following plots: The fourth and fifth attachment are for the current optical setup that we have. The sixth and seventh attachment is for the new optical setup. The eighth attachment is showing the mode cleaner cavity resonating. The last attachment contains the plots of WFS1 vs WFS2, MC2_QPD vs WFS1, MC2_QPD vs WFS3 for each mirror misaligned. The last two attachment are the MIST code for the calculation.

We have all the lenses that we need. I checked it last Friday and if everything is good we will be ready to do the new upgrade this coming Friday. For increasing the power, I check and we have different BS so we can just switch from the current setup the BS. Can you let me know if this setup look good or if I need to chance the setup? I would really love to do this upgrade before I leave.

 

 

 

 

 

 

  5330   Wed Aug 31 16:18:25 2011 JenneUpdateGeneralNew Optics Drawers

[Kiwamu, Manuel, Jenne]

The new optics storage drawers have been populated with optics.  Each drawer is labelled.  Harsh punishments will be inflicted on anyone found disobeying the new scheme.

  14202   Thu Sep 20 11:29:04 2018 gautamUpdateCDSNew PCIe fiber housed

[steve, yuki, gautam]

The plastic tubing/housing for the fiber arrived a couple of days ago. We routed ~40m of fiber through roughly that length of the tubing this morning, using some custom implements Steve sourced. To make sure we didn't damage the fiber during this process, I'm now testing the vertex models with the plastic tubing just routed casually (= illegally) along the floor from 1X4 to 1Y3 (NOTE THAT THE WIKI PAGE DIAGRAM IS OUT OF DATE AND NEEDS TO BE UPDATED), and have plugged in the new fiber to the expansion chassis and the c1lsc front end machine. But I'm seeing a DC error (0x4000), which is indicative of some sort of timing error (Attachment #1) **. Needs more investigation...

Pictures + more procedural details + proper routing of the protected fiber along cable trays after lunch. If this doesn't help the stability problem, we are out of ideas again, so fingers crossed...

** In the past, I have been able to fix the 0x4000 error by manually rebooting fb (simply restarting the daqd processes on fb using sudo systemctl restart daqd_* doesn't seem to fix the problem). Sure enough, seems to have done the job this time as well (Attachment #2). So my initial impression is that the new fiber is functioning alright yes.

Quote:

The PCIe fiber replacement is a more involved project (Steve is acquiring some protective tubing to route it from the FE in 1X6 to the expansion chassis in 1Y3)

  14203   Thu Sep 20 16:19:04 2018 gautamUpdateCDSNew PCIe fiber install postponed to tomorrow

[steve, gautam]

This didn't go as smoothly as planned. While there were no issues with the new fiber over the ~3 hours that I left it plugged in, I didn't realize the fiber has distinct ends for the "HOST" and "TARGET" (-5 points to me I guess). So while we had plugged in the ends correctly (by accident) for the pre-lunch test, while routing the fiber on the overhead cable tray, we switched the ends (because the "HOST" end of the cable is close to the reel and we felt it would be easier to do the routing the other way. 

Anyway, we will fix this tomorrow. For now, the old fiber was re-connected, and the models are running. IMC is locked.

Quote:

Pictures + more procedural details + proper routing of the protected fiber along cable trays after lunch. If this doesn't help the stability problem, we are out of ideas again, so fingers crossed...

  14206   Fri Sep 21 16:46:38 2018 gautamUpdateCDSNew PCIe fiber installed and routed

[steve, koji, gautam]

We took another pass at this today, and it seems to have worked - see Attachment #1. I'm leaving CDS in this configuration so that we can investigate stability. IMC could be locked. However, due to the vacuum slow machine having failed, we are going to leave the PSL shutter closed over the weekend.

  1705   Fri Jun 26 18:00:36 2009 JenneUpdatePEMNew PEM channels for the fancy-pants new microphones

[ Jenne, Clara ]

We made new channels for the microphones which came in this week, by editing C1ADCU_PEM.ini (and making an appropriate backup before we modified it) then restarting the framebuilder and the frontend computer C0DCU1.  The new channels are:

C1:PEM-AUDIO_MIC1

C1:PEM-AUDIO_MIC2

These are connected to channels 13 and 14 on the PEM ADCU board, just next to the GURALP seismometer channels.

 

Clara is testing the mics so the max output voltage can be limited to +-2V for the DAQ, then we'll hook them up to our new channels and listen to the IFO (and all the audio frequency noises around it).

  4452   Mon Mar 28 21:12:14 2011 JenneUpdatePSLNew PMC Base Riser Design

I (think) I have finished the new PMC base riser.  The eDrawing of it (so you can view it on any computer) has been uploaded to the PMC wiki page.

I also attach it here, for comments.

  4453   Mon Mar 28 22:56:14 2011 ranaUpdatePSLNew PMC Base Riser Design

Its going to need some kind of way to locate the PMC on the top. In the previous design, we had the 3 balls to decouple the body from the base. That design was flawed due to the roughness of the holes in the PMC body.

Also probably need some kind of relief on the bottom. Its possible that it would be OK like this, but I am unsure if the shop can maintain the flatness we want over the whole length and/or the flatness of any given (OLD) optical table over ~8". Its probably not a good idea to have to torque this (aluminum?) to make it conform to the optical table's shape.

  4454   Mon Mar 28 23:51:54 2011 JenneUpdatePSLNew PMC Base Riser Design

Quote:

Its going to need some kind of way to locate the PMC on the top. In the previous design, we had the 3 balls to decouple the body from the base. That design was flawed due to the roughness of the holes in the PMC body.

 Hmmm, so, this was just meant to be a riser that goes underneath the old PMC mount, to raise it from 3" beam height to 4" beam height.  I will make another one that is a complete mount, designed for 4" beam height.  Please hold........... .......... ....... ..... ... .

  1423   Tue Mar 24 19:55:24 2009 JenneUpdateLSCNew PO DC

[Rana, Jamie, Jenne]

SPOB DC hasn't been so good lately, so we installed a new PO DC PD on the PO table.  We used a 30% reflecting beam splitter (BS1-1064-30-1025-someotherstuff).  We didn't check with a power meter that it's a 30% BS, but it seems like that's about right.  The beamsplitter is as close as we could get to the shutter immediately in front of the regular POB/SPOB PD's, since that's where the beam gets narrow.   The new picked-off-pickoff beam goes to a Thorlabs 100A PD.  We haven't yet checked for reflected beams off the PD,  but there is a spare razor blade beam dump on the table which can be used for this purpose.  The output of this PD goes to the LSC rack via a BNC cable.  (This BNC cable was appropriated from it's previous "use" connecting a photodiode from the AP table to a bit of air just next to the LSC rack.)  Our new cable is now connected where the old SPOB DC cable used to be, at the input of a crazy Pomona Box tee.

For reference, the new levels of POB DC and SPOB DC, as measured by their BNC DC out connections is ~4mV each.  Since the beamsplitter is 70% transmissive, we used to be getting about 5.7mV on each PD.

The new photodiode puts out about 40mV, but it has an ND1.0 filter on, so if more gain is needed, we can take it off to get more volts.

 

  1424   Tue Mar 24 23:23:05 2009 ranaUpdateLSCNew PO DC
We also found that the SPOB RF cable was going through a splitter before going into the SPOB demod board. The other
input of the splitter was open (not terminated). Using 50m Ohm devices without terminated inputs is illegal. It
makes there be standing waves in the cables and makes the RF phase very dependent on cable lengths. We took away
the splitter and ran the cable straight. So expect some change in the SPOB gain and phase plus some shame.
  8658   Thu May 30 17:18:58 2013 JenneUpdateASCNew POP path

I have placed the G&H mirrors and the Y1 as pictured in my proposed layout in elog 8649.  The distance between the 2" lens and the PDs has increased, so the focus point is all wrong.  I have measured the distances between optics on the table, and will pick new lenses and finish the POP layout later today or tomorrow.

For now, here are the powers measured using the Ophir power meter:

----------------------

PRM-ITMY lock, POPDC was ~190 counts

5.29 uW after Y1 weird angle.  Can't see beam before then to measure

5.27 uW before BS50
3.5 uW before razor PD
3.00 uW before 110PD

 ------------------------

After installing G&H mirrors, replacing BS-98 with Y1:

4.94 uW before y1 (after G&H's)
4.92 uW after y1
2.66 uW before razor PD
1.61 uW before 110PD

  8663   Sat Jun 1 14:14:56 2013 JenneUpdateASCNew POP path

I have a lens solution for the new POP QPD, plotted below.  To get the beam size, I started with the waist at the ITM, so the out of vacuum table starts around 6 meters on this plot.  Also, "PD" is the QPD, but the position marked on the plot is the maximum distance from the 2nd lens.  In reality, I will place it a few cm after the lens.  Once I've got that laid out, I'll move the 110PD (and its lens) and the camera around so that they are in good spots relative to the beam size.

 POP_QPD_lensSolution.png

Here is a photo of the way I left the table last Thursday.  The notations in orange indicate what I need to do to make the actual table match my lens solution.

 POX_table_30May2013progress.pdf

 

  8707   Fri Jun 14 03:10:40 2013 JenneUpdateASCNew POP path - PDs in place, need cabling

I have placed the lenses and the PDs in their new positions on the POP path.  As Koji had pointed out to me in reply to elog 8663, what really matters to get the beam size I want on the QPD is the distance between the lenses, and not so much the absolute position of the lenses (since the Rayleigh range of the POP beam coming out of the vacuum is so long), so I left the 2" lens in place, and made the distance between the Y1 and the QPD's lens 35 cm. 

I didn't move the camera very much, mostly just enough to get the beam centered on the TV.  I need to check where this is in terms of the beam shape, to see where I should move it to, so that I'm getting useful beam motion information by looking at the camera. 

The steering mirror for the POP110 PD is still between the camera and the steering mirror for the QPD, there's just much less space between those 3 elements than there was previously.  I put the POP110 PD's lens and the PD itself in such a way that the PD is at the focus.

The PD which used to be the ASC razor blade PD has been put back in the cabinet.  The cable that was plugged into it was being used for POPDC.  I will need to switch things back so that POPDC is once again coming from the POP110 PD.  Also, I need to bring over the power supply for the QPD, and lay some cables between the supply/readout box and the IOO chassis (where Jamie has freed up some channels for me).

Also, while I was on the POX table, I was reminded that we need to deal with the ITMX oplev situation, which Gautam detailed in elog 8684.  I will ask Steve to take care of it when he's back from vacation.

  8710   Fri Jun 14 17:54:11 2013 JenneUpdateASCNew POP path - cabling work

Quote:

... I need to ... lay some cables between the supply/readout box and the IOO chassis (where Jamie has freed up some channels for me).

 I have made 3 dongles that go from 2-pin lemo to BNC so that I can connect the 3 QPD signals (X, Y, Sum) to the IOO ADC (Pentek Generic board in 1Y2, which also has the MC channels). 

The interface board with the 2-pin lemo connectors doesn't have anything in the DCC for the document number (D020432), so I asked BAbbott, and he said: "After a bit of searching, I found that on psage 2 of D020006-A-pdf ( https://dcc.ligo.org/LIGO-D020006-x0 ), Pin 1 of each LEMO connector is the + leg, and pin 2 is the - leg.  This means that you should connect the center conductor of the BNC (if you don't have any 2-wire twisted-pair cables around) should be connected to pin 1 of the LEMO, and the outer conductor should be connected to Pin 2.  According to http://il.rsdelivers.com/product/lemo/epg0b302hln/2-way-size-0b-pcb-mount-socket-10a/1305621.aspx Pin one is the top one on the right-angled LEMO."  According to page 50 of the lemo data sheet, pin1 is the one with the mark next to it, when you are looking at the solderable end.


  8728   Wed Jun 19 22:02:03 2013 JenneUpdateASCNew POP path - ready to try

I put the POPDC cable back to the DC output of the bias tee that is the first thing at the LSC rack that the POP110 PD sees.  So, now we should be back to the old nominal PRCL locking, with the addition of the new QPD.

I'm going to give it a whirl.....

  11721   Wed Oct 28 17:06:30 2015 ericqUpdateASCNew PRC Angular FF filters installed

I've installed new filters for the T240 -> PRM static online angular feedforward that were trained after some of the recent changes to the signal chain of the relevant signals (i.e. the counts->velocity calibration that Rana did for the seismometers, and fixing the improper dewhitening of the POP QPD channels used as the Wiener target.)

Quickly trying them out now shows about the same level of performance as the previous ones, but the real performance I care about is during after-hours locking-time, so I'll take more measurements tonight to be posted here. 

  9773   Tue Apr 1 22:03:44 2014 KojiSummaryASCNew PRM ASC is running

[Koji Jenne]

New PRM ASC was implemented. [to be cnt'd]

  9777   Wed Apr 2 19:50:12 2014 KojiSummaryASCNew PRM ASC is running

As the designed ASC filters in this entry had too little phase margins (~10deg), I had to compromise the servo design.

The design was modified and tested again. This will be reported by a following entry.

Incidentally, I have adjusted the demodulation phases of REFL33/55/165 for PRMIsb so that the PRCL is eliminated from the Q signals.

REFL33    125.5 deg -> +136.5 deg
REFL55      45.0 deg -> +  25.0 deg
REFL165   -79.5 deg -> +  44.5 deg

This change of the demod phase for REFL165 was a bit surprising.
I did not check the sign, so it could be -135.5 deg. But still this is a bit change.

  9779   Wed Apr 2 23:08:51 2014 KojiSummaryASCNew PRM ASC is running

The new PRM ASC design


Pitch
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000

FM5: (boost)
zero: f: 0.5Hz q: 1  /  4Hz, q: 2 / f: 1Hz, q: 3
pole: f: 2Hz q: 3  / f: 2.7Hz, q: 2  / f: 1Hz, q: 15

FM9: (HF Roll-off)
pole: f: 40Hz q: 1/Sqrt(2) (2nd order butterworth)

Servo gain: -0.023

Yaw
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000

FM5: (boost)
zero: f: 0.5Hz q: 1  /  4Hz, q: 2 / f: 1.5Hz, q: 10
pole: f: 1.02Hz q: 10  / f: 3Hz, q: 5  / f: 2Hz, q: 6

FM9: (HF Roll-off)
pole: f: 40Hz q: 1/sqrt(2)
 
Servo gain: -0.027


The loop gains were adjusted to have the UGFs of 10Hz. The measured openloop transfer functions were compared with the model.
The transfer functions for yaw are well matched. However, the pitch ones don't. It seems that the pitch loop has extra low pass
which I can't locate. The possibility is the analog electronics of the pitch loop.


The effect of the control between 0.3Hz to 3Hz are well represented by the model. The attachment 2 shows the free running
angle fluctuation, the ones with the control engaged, and the estimated spectra. Indeed, the estimated spectra well represent
the measured angular spectra.

  2308   Fri Nov 20 13:54:45 2009 AlbertoOmnistructureEnvironmentNew Paper and Cardboard Recycling Bins Introduced to the 40m

The 40m produces a large amount of paper and cardboard waste. It would be worth it if we disposed those kind of garbages for recycling.

I set up two new garbage bins in the lab: one in the control rooms that adds up to the can/bottle recycling bin, and one other one in the office area, next to the printer for general paper disposal.

People in the lab are strongly invited to make use of the two new garbage bins and recycle their paper and cardboard waste.

Boxes can be larger than the garbage bin, so I'd recommend people to crash them before throwing them into the bin.

DSC_1030.JPG

DSC_1031.JPG

  4064   Thu Dec 16 10:52:42 2010 josephbUpdateCamerasNew PoE digital cameras

We have two new Basler acA640-100gm cameras.  These are power over ethernet (PoE) and very tiny.

  16772   Tue Apr 12 09:05:21 2022 JordanUpdateVACNew Pressure Gauge Install/Pump Spool Vent

Today, Tega and I would like to vent the pump spool an dinstall the new FRG-400 Agilent Pressure Gauges (per elog 15703). The attached picture shows the volume needed to be vented highlighted in red, and the gauges that need to be replaced/removed (purple dot next to the name).

The vent plan is as follows:

Open RV2

Open VM3

Open V7

Open V4

Shut down TP2

Install new gauges

Will add to post with updates post vent.

  16773   Wed Apr 13 12:50:07 2022 TegaUpdateVACNew Pressure Gauge Install/Pump Spool Vent

[Jordan, JC, Tega]

We have installed all the FRGs and updated the VAC medm screens to display their sensor readings. The replacement map is CC# -> FRG#, where # in [1..4] and PRP1 -> FRG5. We now need to clean up the C1VAC python code so that it is not overloaded with non-function gauges (CC1,CC2,CC3,CC4,PRP1). Also, need to remove the connection cables for the old replaced gauges.

  10186   Fri Jul 11 17:49:12 2014 NichinUpdateElectronicsNew Prologix GPIB-Ethernet controller

I have configured a NEW Prologix GPIB-Ethernet controller to use with HP8591E Spectrum analyzer that sits right next to the control room computers.

Static IP: 192.168.113.109

Mask: 255.255.255.0

Gateway: 192.168.113.2

I have no clue how to give it a name like "something.martian" and to update the martian host table (Somebody please help!!)

 

  10190   Sun Jul 13 11:37:36 2014 JamieUpdateElectronicsNew Prologix GPIB-Ethernet controller

Quote:

I have configured a NEW Prologix GPIB-Ethernet controller to use with HP8591E Spectrum analyzer that sits right next to the control room computers.

Static IP: 192.168.113.109

Mask: 255.255.255.0

Gateway: 192.168.113.2

I have no clue how to give it a name like "something.martian" and to update the martian host table (Somebody please help!!) 

The instructions for adding a name to the martian DNS table are in the wiki page that I pointed you to:

https://wiki-40m.ligo.caltech.edu/Martian_Host_Table

  10192   Mon Jul 14 12:49:07 2014 NichinUpdateElectronicsNew Prologix GPIB-Ethernet controller

Quote:

Quote:

I have configured a NEW Prologix GPIB-Ethernet controller to use with HP8591E Spectrum analyzer that sits right next to the control room computers.

Static IP: 192.168.113.109

Mask: 255.255.255.0

Gateway: 192.168.113.2

I have no clue how to give it a name like "something.martian" and to update the martian host table (Somebody please help!!) 

The instructions for adding a name to the martian DNS table are in the wiki page that I pointed you to:

https://wiki-40m.ligo.caltech.edu/Martian_Host_Table

The instructions at https://wiki-40m.ligo.caltech.edu/Martian_Host_Table   are outdated!

The name server configuration is currently at /etc/bind/zones/martian.db [ source: elog:10067 ]

 

Anyway, I need superuser access to edit the files, which I don't have. Even if I did know the password, I don't think it's a good idea for me to be messing around. So any of the 40m folks please update the martian table to include:

santuzza.martian  192.168.113.109

 

  2989   Wed May 26 10:58:29 2010 josephbUpdateCDSNew RCG checkout for use with all machines plus some issues

Now that we have multiple machines we'd like to run the new front end code on, I'm finding it annoying to have to constantly copy files back and forth to have the latest models on different machines.  So I've come to the conclusion that Rana was right all along, and I should working somewhere in /cvs/cds/caltech which gets mounted by everyone. 

However, this leads to the svn problem: I.e. I need recent code checked out from the RCG repository, but our current /cvs/cds/caltech/cds/advLigo directory is covered by the 40m SVN.  So for the moment, I've checked out the advLigoRTS from https://redoubt.ligo-wa.caltech.edu/svn/advLigoRTS/trunk into /cvs/cds/caltech/cds/advLigoRTS.  This directory will be kept as up to date as I can keep it, both by running svn update to get Alex/Rolf's changes and on my end by keeping the new and updated models.  It will remain linked the RCG repository and not the 40m repository.  At some point a better solution is needed, but its the best I can come up with for now.

Also, because we are starting to compile on different machines sometimes, you may run into a problem where a code won't run on a different machine.  This can be fixed by commenting out some lines in the startup script.  Go to the /cvs/cds/caltech/scripts directory.  Then edit the associated startSYS file by commenting out the lines that look like:

if [ `hostname` != megatron ]; then
echo Cannot run `basename $0` on `hostname` computer
exit 1
fi

Unfortunately, this gets reverted each time "make SYS" and "make install-SYS" gets run.

The other issue this leads to is that some machines don't have as many CPUs available as others.  For example our new thin 1U machines have only 4 dual cores (8 CPUs total).  This means the specific_cpu setting of any of the codes cannot be higher than 7 (cores being numbered 0 through 7).  Core 0 is reserved for the real time kernel, and Core 1 will be used on all machines for the IO processor. This leaves only cores 2 through 7 available for models to use which include LSC, LSP, SUS, SUP, SPY, SCY, SPX, SCX, OMC, OMP, OAF, OAP?, IOC, IOP.  Since there are more than 6 models, duplication in final production code of specific_cpus will be necessary.  Codes which are all running on Megatron at one point will have to be rebuilt with new specific_cpu values when run on the actual final machine.

  2882   Wed May 5 16:32:39 2010 AlbertoUpdate40m UpgradingNew REFL55 PD, 11MHz rejection

Here's the (calibrated) transimpedance of the new REFL55 PD.

T(55.3) / T_(11.06) = 93 dB

2010-05-05_REFL55_CalibratedOpticalResponse0-60MHz.png

  11403   Mon Jul 13 14:08:10 2015 ericqUpdateElectronicsNew RF amps, housed

I made a little box for the new RF amplifiers we'll be using for the green beatnotes, to keep things tidy on the PSL table. They are both Minicircuits model ZHL-3A-S.

I took TFs of their response with the agilient analyzer (calibrating out the cables, splitters, etc.) Powered at +24V, we get a solid ~27dB of gain up to around 200MHz, which is fine for our needs. The phase profile is mostly a 6-7 nsec delay, which is negligible for ALS. Data files are attached. 

Koji looked at me like I was crazy for using a BNC connector for the DC power. I haven't yet been able to find panel mount banana connectors, but when I do, I'll replace it. 


Banana'd:

  10867   Wed Jan 7 12:15:17 2015 manasaUpdateGeneralNew RF cables

I was working around the PSL table this morning.

1. I have fibers running from the Y end and the PSL table to the Optical Fiber Module for Frequency Offset Locking. 

Y+PSL out power is ~200uW. From the transimpedance and responsivity specs of the RFPD (ThorLabs FPD310), we expect ~100uW or -10dBm RF power. I have not hooked up the RF output to a spectrum analyser to confirm this as yet.

2. Also, Steve and I ran RF cables (LMR-195A) from the PSL table to the FC module on the IOO rack.

 

  4636   Thu May 5 13:13:32 2011 JenneUpdateLSCNew RFPD screens are in

Joe helped me compile the lsc simulink model, and now we have R&D phase rotation.

Right now, we have to do our own math, and figure out what relative phase to put in.  Soonly, I'll figure out how to do subtraction, and we can put in the measured value.

 

More details when I'm not running around like crazy...

--------------------------------------------------------------------------------------------

Okie dokie.  Last night I had modified the c1lsc.mdl to accommodate the R & D phase rotation.  I also made pretty new screens.  This morning however, the adventures began.....

Under Joe's supervision, I ran "make c1lsc".  The error that came up was something about things not being connected.  Joe assures me that this is a temporary problem, that Rolf is already working on.  The reason is that right now the LSC model is "flat", i.e. it doesn't have a bunch of sub-boxes and sub-screens in the simulink model.  Somehow this causes badness.  Joe stuck all the guts of the LSC model into a sub-model.  He then enabled "top_names", which makes the channels use the name of the sub-model, not the sub-model AND the main model (so since the sub-model is called LSC, our channels are just C1:LSC-OTHER_STUFF, rather than C1:LSC-LSC_OTHER_STUFF).  This fixed things so that the compiling worked (when we did "make c1lsc").  The one other thing that we changed was to delete all of the little "Outs" that were attached to EPICS readouts.  These are unneccessary and don't go anywhere, and when we made the sub-model, they made a bunch of empty outputs (unconnected outs on the main simulink model).  So, after doing that, we were able to compile, and do "make install-c1lsc", and all was good in the world.  Mostly.

Joe then noticed that I was using the CDS part "cdsPhase", which only takes one phase input.  I wanted "cdswfsPhase", which actually does the R&D phase rotation that we want.  Perhaps Alex/Rolf/whoever should change the name of that CDS part.  We switched all of the cdsPhase blocks to be cdswfsPhase, and recompiled.  All was still good in the world.  Mostly.

The last thing that was funny was that when I wanted to execute the medm screens, they would still look at the old _IQ_MTRX_1_1 and _IQ_MTRX_2_1 values, rather than the newly defined _PHASE_R and _PHASE_D channels, even though while editing the medm screen, it looked like it was pointing to the right place.  Anyhow, I opened the text file version of the C1LSC_PDX.adl, and changed the channel names to the _R and _D versions by hand.  I don't know if we edit the screens and run generate_screens.py again, if we'll have to re-edit the .adl text files.

After fixing this, all really was good in the world. 

Perhaps though, this making a subsystem business broke the filters somehow?  Foton is looking at the wrong text file now?  Something?  The filters are all still there, they just got moved down a level.  Joe said that he and Rolf are on it, and he should be able to put the LSC model back to being "flat" in the next few days.

  16807   Sun Apr 24 13:17:08 2022 TommyUpdateElectronicsNew RFSoC2x2 Overlay

We recieved an overlay from Chris Stoughton which he used for a ZCU11 board. The overlay is supposed to be compatible with the RFSoC 2x2 and help enable the Multi-Tile Synchronization (MTS) we need. He also provides a .py with the necessary low level connection to the board and its memory along with a few sample notebooks.

Progress So Far:

  • The overlay loads properly and in reasonable time. 
  • We can set the mixer and dac frequencies. However, it is unclear what event_src Chris wanted for the adc mixers. It seems that he was using event_src_immediate (possibly unintenionally) which is not an available adc mixer setting in our board. Instead, we set the event source to "Tile" and will later determine if this is an issue.
  • We then go to get data from the buffer. There are two functions called: capture and transfer. These are called on the pynq DMA. Capture runs fine but we get stuck during the transfer at dma.revchannel.wait(). This issue has not been resolved.
  7018   Tue Jul 24 12:06:41 2012 MashaUpdatePEMNew RMS channels, New C1PEM Overview

As Jenne suggested last night, I changed the C1PEM overview in Epics. Previously, the C1PEM_OVERVIEW.adl screen had two separate visualizations, one for LP and one for BP for each channel. I changed the format so that there is only one frame per RMS channel, showing all of the input and output as before, but continuously, to demonstrate the actual RMS process.

First, the input is bandpass filtered, then multiplied by itself (squared), then lowpass filtered, and then square rooted to yield the final output. I have kept the previous files, but have applied this new format to all of the RMS ACC*, GUR1, GUR2, and STS1 channels. 

As Rana suggested yesterday, I made channels for 0.01 - 0.03 Hz and 0.03 - 0.1 Hz, and created filters for them, which I will work on some more now.

  15729   Thu Dec 10 17:12:43 2020 JonUpdate New SMA cables on order

As requested, I placed an order for an assortment of new RF cables: SMA male-male, RG405.

  • x3 12"
  • x3 24"
  • x2 48"

They're expected to arrive mid next week.

  15739   Sat Dec 19 00:25:20 2020 JonUpdate New SMA cables on order

I re-ordered the below cables, this time going with flexible, double-shielded RG316-DS. Jordan will pick up and return the RG-405 cables after the holidays.

Quote:

As requested, I placed an order for an assortment of new RF cables: SMA male-male, RG405.

  • x3 12"
  • x3 24"
  • x2 48"
  15740   Sat Dec 19 02:42:56 2020 KojiUpdate New SMA cables on order

Our favorite (flexible) RF cable is Belden's 1671J (Jacketed solder-soaked coax cable). It is compatible RG405. I'm not sure if there is off-the-shelf SMA cables with 1671J.

 

  15322   Fri May 8 14:27:25 2020 HangUpdateBHDNew SRC gouy phase

[Jon, Hang]

After updating the 40 m finesse file to incorporate the new SRC length (and the removal of SR2), we find that the current SRM radius curvature is fine. Thus a replacement of SRM is NOT required

Basically, the new one-way SRC gouy phase is 11.1 deg according to Finesse, which is very close to the previous value of 10.8 deg. Thus the transmode spacing should be essentially the same. 

In the first attached plot is the mode content calculated with Finesse. Here we have first offset DARM by 1m deg and misaligned the SRM by 10 urad. From the top to bottom we show the amplitude of the carrier fields, f1, and f2 sidebands, respectively. The red vertical line is the nominal operating point (thanks Koji for pointing out that we do signal recycling instead of extraction now). No direct co-resonance for the low-order TEM modes. (Note that the HOMs appeared to also have peaks at \phi_srm = 0. This is just because the 00 mode is resonant and thus the seed for the HOMs is greater. )

We can also consider a clean case without mode interactions in the second plot. Indeed we don't see co-resonances of high order modes. 

  2820   Tue Apr 20 18:02:22 2010 JenneUpdateCOCNew SRM and PRM Hung

[Jenne, Steve]

We removed the old SRM and PRM from their cages, and are temporarily storing them in the rings which we use to hold the optics while baking.  Steve will work on a way to store them more permanently.

We then hung the new SRM (SRMU03) and new PRM (SRMU04) in the cages.  We were careful not to break the wires, so the heights will not have changed from the old heights.

The optics have not been balanced yet.  That will hopefully happen later this week.

  3155   Thu Jul 1 17:05:36 2010 josephb, kiwamu, steveUpdateCDSNew SUS Chassis in rack

Thanks to Steve's work on some L brackets, and Kiwamu's lifting help, we now have a new SUS IO chassis in the new 1X4 rack (formerly the 1Y4 rack), just below the new SUS and LSC computers.  I have decided to call the sus machine, c1sus, and give it IP address 192.168.113.85.  We also put in a host interface adapter, OSS-HIB2-PE1x4-1x4 Re-driver HIB, which connects the computer to the IO chassis.

The IP was added to the linux1 name server.  However, the computer itself has not been configured yet.  I'm hoping to come in for an hour or two tomorrow and get the computer hooked up to a monitor and keyboard and get its network connection working, mount /cvs/cds and get some basic RCG code running.

We also ran ethernet cables for the SUS machine to the router in 1X6 (formerly 1Y6) as well as a cable for megatron from 1X3 (formerly 1Y3) to the router, in anticipation of that move next week.

During the day, I realized we needed 2 more ADCs, one of which I got from Jay immediately.  This is for two 110Bs and 4 Pentek ADCs.  However, there's a 3rd 110B connected to c0dcu1 which goes to a BNC patch panel.  Original Jay thought we would merge that into 4 pin lemo style into the 2nd 110B associated with the sus front ends.  We've decided to get a another ADC and adapter.  That will have to be ordered, and generally take 6-8 weeks.  However, it may be possible to "borrow" one from another project until that comes in to "replace" it.  This will leave us with our BNC patch panel and not force me to convert over 20 cables.

I also discovered we need one Contec DIO-1616L-PE Isolated Digital IO board for each Chassis, which I wasn't completely aware of.  This is used to control the ADCs/DACs adapter boards in the chassis.  It means we need still need to put a Binary Output board in the c1iscex chassis.  Hopefully the chassis as they come in come from Downs continue to come with the Contec DIO-1616L-PE boards (they have so far).

The current loadout of the SUS chassis is as follows:

Treton Board

Far left slot, when looking from the front has the OSS-MAX-EXP-ELB-C board, used to communicate with the c1sus computer.

Slot 1 ADC PMC66-16AI6455A-64-50M

Slot 2 DAC PMC66-16AO16-16-F0-OF 

Slot 3-6 BO Contec DIO-32L-PE Isolated Digital Output board

Slot 7 ADC PMC66-16AI6455A-64-50M

Slot 8-9 DAC PMC66-16AO16-16-F0-OF 

Slot 10-11 ADC PMC66-16AI6455A-64-50M

Slot 12 Contect DIO-1616L-PE Isolated Digital IO board

Back  Board

Slot 1 ADC adapter D0902006

Slot 2 DAC adapter D0902496-v1

Slot 7 ADC adapter D0902006

Slot 8-9 DAC adapter D0902496-v1

Slot 10-11 ADC adapter D0902006

 

  773   Wed Jul 30 18:45:01 2008 ranaConfigurationSUSNew SUS Drift Technology
I updated the SUS DRIFT screen again, this time with a new feature.

I used Rolf's idea for the AdvLIGO status system and just made the nominals be an
unused sub-field (.SVAL) of the main INMON record. Then I wrote a .csh script to
use tdsavg to average the current INMON vals and insert that as the .SVAL. The next
script should read the .SVAL and set the HIHI and LOLO based on this.

Of course, the values I have just entered are no good because our suspensions are in
a bad state but we can run this script (SUS/setDriftNoms) next time things are good.

And...even better would be if someone were to do the same but used mDV to grab the
minute trend in the past good times instead of the tdsavg (which can't go in the past).
  16495   Thu Dec 9 00:32:56 2021 TegaUpdateCDSNew SUS medm screen update

The new SUS screen can be reached via sitemap -> IFO SUS button -> NEW ETMX dropdown menu link. Please use and provide feedback. Not sure exactly if we need/want the display screens after the IOP model on the right of the medm screen. I have not been able to locate the corresponding channels but did not want to remove them until I was sure that we don't plan to add these features to our screens. When all bugs have been ironed out, we can use appropriate macro substitution for the other optics.

The next feature to add is the BLRMS to the coil and PD channels. I plan to combine the PEM BLRMS medm implementation with the sus_single_BLRMS model block (located in  /opt/rtcds/userapps/release/cds/c1/models). This way we use the latest BLRMS block in "/opt/rtcds/userapps/release/cds/common/models/BLRMS.mdl" whilst also leveraging the previous work done on the sus_single_BLRMS model, which neatly fits into our current SUS model.

ELOG V3.1.3-