40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 227 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  13458   Wed Nov 29 21:40:30 2017 johannesOmnistructureComputersSlow DAQ replacement computer progress

[Aaron, Johannes]

We configured the AtomServer for the Martian network today. Hostname is c1auxex2, IP is 192.168.113.49. Remote access over SSH is enabled.

There will be 6 acromag units served by c1auxex2.

Hostname Type IP Address
c1auxex-xt1221a 1221 192.168.113.130
c1auxex-xt1221b 1221 192.168.113.131
c1auxex-xt1221c 1221 192.168.113.132
c1auxex-xt1541a 1541 192.168.113.133
c1auxex-xt1541b 1541 192.168.113.134
c1auxex-xt1111a 1111 192.168.113.135

Some hardware to assemble the Acromag box and adapter PCBs are still missing, and the wiring and channel definitions have to be finalized. The port driver initialization instructions and channel definitions are currently locally stored in /home/controls/modbusIOC/ but will eventually be migrated to a shared location, but we need to decide how exactly we want to set up this infrastructure.

  • Should the new machines have the same hostnames as the ones they're replacing? For the transition we simply named it c1auxex2.
  • Because the communication of the server machine with the DAQ modules is happening over TCP/IP and not some VME backplane bus we could consolidate machines, particularly in the vertex area.
  • It would be good to use the fact that these SuperMicro servers have 2+ ethernet ports to separate CDS EPICS traffic from the modbus traffic. That would also keep the 30+ IPs for the Acromag thingies off the Martian host tables.
  13185   Thu Aug 10 14:25:52 2017 gautamUpdateCDSSlow EPICS channels -> Frames re-enabled

I went into /opt/rtcds/caltech/c1/target/daqd, opened the master file, and uncommented the line with C0EDCU.ini (this is the file in which all the slow machine channels are defined). So now I am able to access, for example, the c1vac1 channels.

The location of the master file is no longer in /opt/rtcds/caltech/c1/target/fb, but is in the above mentioned directory instead. This is part of the new daqd paradigm in which separate processes are handling the data transfer between FEs and FB, and the actual frame-writing. Jamie will explain this more when he summarizes the CDS revamp.

It looks like trend data is also available for these newly enabled channels, but thus far, I've only checked second trends. I will update with a more exhaustive check later in the evening.

So, the two major pending problems (that I can think of) are:

  1. Inability to unload models cleanly
  2. Inability of dataviewer (and cdsutils) to open testpoints.

Apart from this, dataviewer frequently hangs on Donatella at startup. I used ipcs -a | grep 0x | awk '{printf( "-Q %s ", $1 )}' | xargs ipcrm to remove all the extra messages in the dataviewer queue.


Restarting the daqd processes on fb1 using Jamie's instructions from earlier in this thread works - but the mx_stream processes do not seem to come back automatically on c1lsc, c1sus and c1ioo (reasons unknown). I've made a copy of the mxstreamrestart.sh script with the new mxstream restart commands, called mxstreamrestart_debian.sh, which lives in /opt/rtcds/caltech/c1/scripts/cds. I've also modified the CDS overview MEDM screen such that the "mxstream restart" calls this modified script. For now, this requires you to enter the controls password for each machine. I don't know what is a secure way to do it otherwise, but I recall not having to do this in the past with the old mxstreamrestart.sh script.

  13189   Fri Aug 11 00:10:03 2017 gautamUpdateCDSSlow EPICS channels -> Frames re-enabled

Seems like something has failed after I did this - full frames are no longer on Aug 10 being written since ~2.30pm PDT. I found out when I tried to download some of the free-swinging MC1 data.

To clarify, I logged into fb1, and ran sudo systemctl restart daqd_*. The only change I made was to uncomment the line quoted below in the master file.

Looking at the log using systemctl, I see the following (I just tried restarting the daqd processes again):

Aug 11 00:00:31 fb1 daqd_fw[16149]: LDASUnexpected::unexpected: Caught unexpected exception      "This is a bug. Please log an LDAS problem report including this message.
Aug 11 00:00:31 fb1 daqd_fw[16149]: daqd_fw: LDASUnexpected.cc:131: static void LDASTools::Error::LDASUnexpected::unexpected(): Assertion `false' failed.
Aug 11 00:00:32 fb1 systemd[1]: daqd_fw.service: main process exited, code=killed, status=6/ABRT
Aug 11 00:00:32 fb1 systemd[1]: Unit daqd_fw.service entered failed state.
Aug 11 00:00:32 fb1 systemd[1]: daqd_fw.service holdoff time over, scheduling restart.
Aug 11 00:00:32 fb1 systemd[1]: Stopping Advanced LIGO RTS daqd frame writer...
Aug 11 00:00:32 fb1 systemd[1]: Starting Advanced LIGO RTS daqd frame writer...
Aug 11 00:00:32 fb1 systemd[1]: daqd_fw.service start request repeated too quickly, refusing to start.
Aug 11 00:00:32 fb1 systemd[1]: Failed to start Advanced LIGO RTS daqd frame writer.
Aug 11 00:00:32 fb1 systemd[1]: Unit daqd_fw.service entered failed state.

Oddly, I am able to access second trends for the same channels from the past which will be useful for the MC1 debugging). Not sure whats going on.


The live data grabbing using cdsutils still seems to be working though - so I've kicked MC1 again, and am grabbing 2 hours of data live on Pianosa.

Quote:

I went into /opt/rtcds/caltech/c1/target/daqd, opened the master file, and uncommented the line with C0EDCU.ini (this is the file in which all the slow machine channels are defined). So now I am able to access, for example, the c1vac1 channels.

The location of the master file is no longer in /opt/rtcds/caltech/c1/target/fb, but is in the above mentioned directory instead. This is part of the new daqd paradigm in which separate processes are handling the data transfer between FEs and FB, and the actual frame-writing. Jamie will explain this more when he summarizes the CDS revamp.

It looks like trend data is also available for these newly enabled channels, but thus far, I've only checked second trends. I will update with a more exhaustive check later in the evening.

So, the two major pending problems (that I can think of) are:

  1. Inability to unload models cleanly
  2. Inability of dataviewer (and cdsutils) to open testpoints.

Apart from this, dataviewer frequently hangs on Donatella at startup. I used ipcs -a | grep 0x | awk '{printf( "-Q %s ", $1 )}' | xargs ipcrm to remove all the extra messages in the dataviewer queue.


Restarting the daqd processes on fb1 using Jamie's instructions from earlier in this thread works - but the mx_stream processes do not seem to come back automatically on c1lsc, c1sus and c1ioo (reasons unknown). I've made a copy of the mxstreamrestart.sh script with the new mxstream restart commands, called mxstreamrestart_debian.sh, which lives in /opt/rtcds/caltech/c1/scripts/cds. I've also modified the CDS overview MEDM screen such that the "mxstream restart" calls this modified script. For now, this requires you to enter the controls password for each machine. I don't know what is a secure way to do it otherwise, but I recall not having to do this in the past with the old mxstreamrestart.sh script.

 

  13192   Fri Aug 11 11:14:24 2017 gautamUpdateCDSSlow EPICS channels -> Frames re-enabled

I commented out the line pertaining to C0EDCU again, now full frames are being written again.

But we no longer have access to the slow EPICS records.

I am not sure what the failure mode is here - In the master file, there is a line that says the EDCU list "*MUST* COME *AFTER* ALL OTHER FAST INI DEFINITIONS" which it does. But there are a bunch of lines that are testpoint lists after this EDCU line. I wonder if that is the problem?

Quote:

Seems like something has failed after I did this - full frames are no longer on Aug 10 being written since ~2.30pm PDT. I found out when I tried to download some of the free-swinging MC1 data.

 

  13197   Fri Aug 11 18:53:35 2017 gautamUpdateCDSSlow EPICS channels -> Frames re-enabled
Quote:

Seems like something has failed after I did this - full frames are no longer on Aug 10 being written since ~2.30pm PDT. I found out when I tried to download some of the free-swinging MC1 data.

To clarify, I logged into fb1, and ran sudo systemctl restart daqd_*. The only change I made was to uncomment the line quoted below in the master file.

Looking at the log using systemctl, I see the following (I just tried restarting the daqd processes again):

Aug 11 00:00:31 fb1 daqd_fw[16149]: LDASUnexpected::unexpected: Caught unexpected exception      "This is a bug. Please log an LDAS problem report including this message.
Aug 11 00:00:31 fb1 daqd_fw[16149]: daqd_fw: LDASUnexpected.cc:131: static void LDASTools::Error::LDASUnexpected::unexpected(): Assertion `false' failed.
Aug 11 00:00:32 fb1 systemd[1]: daqd_fw.service: main process exited, code=killed, status=6/ABRT
Aug 11 00:00:32 fb1 systemd[1]: Unit daqd_fw.service entered failed state.
Aug 11 00:00:32 fb1 systemd[1]: daqd_fw.service holdoff time over, scheduling restart.
Aug 11 00:00:32 fb1 systemd[1]: Stopping Advanced LIGO RTS daqd frame writer...
Aug 11 00:00:32 fb1 systemd[1]: Starting Advanced LIGO RTS daqd frame writer...
Aug 11 00:00:32 fb1 systemd[1]: daqd_fw.service start request repeated too quickly, refusing to start.
Aug 11 00:00:32 fb1 systemd[1]: Failed to start Advanced LIGO RTS daqd frame writer.
Aug 11 00:00:32 fb1 systemd[1]: Unit daqd_fw.service entered failed state.

Oddly, I am able to access second trends for the same channels from the past which will be useful for the MC1 debugging). Not sure whats going on.


The live data grabbing using cdsutils still seems to be working though - so I've kicked MC1 again, and am grabbing 2 hours of data live on Pianosa.

So we tried this again with a fresh build of daqd_fw, and it still fails.  The error message is pointing to an underlying bug in the framecpp library ("LDASTools"), which may be tricky to solve.  I'm rustling the appropriate bushes...

  8957   Thu Aug 1 21:28:09 2013 gautamUpdateCDSSlow channels set-up in ALS

The following slow channels have been added and are now being recorded by FB.

 

C1:ALS-X_OVEN_TEMP

C1:ALS-Y_OVEN_TEMP

C1:ALS-BEATX_FREQ

C1:ALS-BEATY_FREQ


Details:

In order to integrate the data collected by the Raspberry-Pi from the Y-end doubling oven temperature controller and also the data from the frequency counter which will be hooked up to monitor the beat frequency, Koji helped me set up some slow EPICS record channels (in ALS as we felt this was most appropriate). The procedure for setting up slow channels was as follows (virtually identical to what is detailed in this elog:

  1. Add the channel names to the file C0EDCU.ini (path = /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini).
  2. Make a database (.db) file so that these channels are actually recorded (path = /cvs/cds/caltech/target/c1aux/als.db).
  3. Restart framebuilder. 
  4. Verify that the channels indeed exist and can be read and written to using ezcaread and ezcawrite.

I will now integrate these channels into my scripts, and make some simple MEDM screens.

 

  12651   Wed Nov 30 14:54:01 2016 JohannesUpdateCDSSlow machine replacement

I was talking with Larry yesterday, and he suggested the rack-mounted supermicro machines SYS-5017A-EP (~$400) or SYS-5018A-FTN4 (~$600) that he uses for moving data around in LIGO. They have 2 gigabit ethernet ports and can thus function as modbus gateways, conveniently placed in the rack close to the slow DAQ/DIO chassis and running some local ubuntu or other distro (I think Aidan uses CentOS in the PSL lab). These only have atom processors, which would be sufficient for the slow machine replacement, but there are many more powerful models with sometimes subtle differences. If we motion towards a more complete GigECam coverage in the lab it could be better to kill two birds with one stone and get something a little faster that can do the video capture/processing, since these machines will be distributed more or less strategically around the lab. Just a thought, as I have currently no clear idea what resources are required for this or how much we're throwing at this GigECam upgrade.

 

Quote:

I've attached a schematic for how we will connect the Acromag mosules to the slow channel I/O curently going to c1auxex. The following changes are made:

  • We are getting rid of the slow readbacks from the Anti-Image and Oplev boards, as Rana says they are unnnecessary.
  • The whitening switching for the QPD is currently done by a Contec "fast" binary I/O module, but can be managed by acromag instead. This alllows CAB_1Y9_34 to  be fed directly into the Acromag box since all of its connections can now be managed slow. 
  • There's no need to change the PD whitening scheme around (since the signals never get huge), so we can set those to always be on and then lose those Contec channels. This means all of the necessary pins on CAB_1Y9_10 can go to Acromag. 
  • All the other backplane cables go the the fast machines only. 

 

 

  11754   Wed Nov 11 22:50:39 2015 KojiConfigurationCDSSlow machine time&date

I was gazing at the log file for Autolocker script (/opt/rtcds/caltech/c1/scripts/MC/logs/AutoLocker.log )
and found quite old time stamps. e.g.

Old : C1:IOO-MC_VCO_GAIN             1991-08-08 14:36:28.889032 -3
New : C1:IOO-MC_VCO_GAIN             1991-08-08 14:36:36.705699 18
Old : C1:PSL-FSS_FASTGAIN            1991-08-09 19:05:39.972376 14
New : C1:PSL-FSS_FASTGAIN            1991-08-09 19:05:44.939043 18

It was found that the date/time setting of some of the slow machines (at least c1psl and c1iool0) is not correct.
I could not figure out how to fix it.

Question: Is this anything critical?

Another thing: While I was in c1iool0 I frequently saw the message like

c1iool0 > 0xc461f0 (CA event): Events lost, discard count was 514

Is this anything related to EPICS Freeze?

controls@nodus|~ > telnet c1psl.martian
Trying 192.168.113.53...
Connected to c1psl.martian.
Escape character is '^]'.
c1psl > date
Aug 09, 1991 19:13:26.439024274
value = 32 = 0x20 = ' '
c1psl >
telnet> q
Connection closed.

controls@nodus|~ > telnet c1iool0.martian
Trying 192.168.113.57...
Connected to c1iool0.martian.
Escape character is '^]'.

c1iool0 > date
Aug 08, 1991 14:44:39.755679528
value = 32 = 0x20 = ' '
c1iool0 > 0xc461f0 (CA event): Events lost, discard count was 514
Change MC VCO gain to -3.
0xc461f0 (CA event): Events lost, discard count was 423
Change MC VCO gain to 18.
Change boost gain to 1.
Change boost gain to 2.

 

  4201   Tue Jan 25 20:42:46 2011 OsamuUpdateGreen LockingSlow servo for green laser

I implemented a slow servo for green laser thermal control on c1scx.mdl. Ch6,7 of ADC and ch6 of DAC are assigned for this servo as below;

 

Ch6 of ADC: PDH error signal

CH7 of ADC: PZT feedback signal

CH6 of DAC: feedback signal to thermal of green laser

 

Note that old EPICS themal control cable is not hooked anymore.

I made a simple MEDM screen(...medm/c1scx/master/C1SCX_BCX_SLOW.adl) linked from GREEN medm screen (C1GCV.adl) on sitemap.

During this work, I noticed that some of the epics switch is not recovered by autoburt. What I noticed is filter switch of SUSPOS, SUSPIT, SUSYAW, SDSEN, and all coil output for ETMX.

I had no idea to fix them, probably Joe knows. I guess other suspensitons has the same problems.

  4202   Tue Jan 25 21:57:59 2011 KojiUpdateGreen LockingSlow servo for green laser

1. The dewhitening filter CH6 had no output. I disconnected the cable and put it to the monitor out of the AI filter.
So the dewhitening is not in the loop.

2. I have made a thermal control filter

BANK1: pole 0Hz, zero 1mHz / LF boost stage
BANK2: pole 1mHz, zero 30mHz / LPF stage
BANK3: pole 1Hz, zero 0.1Hz / phase compensation stage
Gain: 0.05

It seems working with the gain of 0.05. As the thermal is very strong, the output has less than 10.
This means the we are effectively only using ~4bit. We need external filter.

Note that output of 30000counts were about 3V at  CH6.

3. Measured End PZT feedback with and without the thermal control. The UGF seems to be 0.2Hz.
The suppression at 10mHz is ~100. This is so far OK.

Quote:

I implemented a slow servo for green laser thermal control on c1scx.mdl. Ch6,7 of ADC and ch6 of DAC are assigned for this servo as below;

 

Ch6 of ADC: PDH error signal

CH7 of ADC: PZT feedback signal

CH6 of DAC: feedback signal to thermal of green laser

 

Note that old EPICS themal control cable is not hooked anymore.

I made a simple MEDM screen(...medm/c1scx/master/C1SCX_BCX_SLOW.adl) linked from GREEN medm screen (C1GCV.adl) on sitemap.

During this work, I noticed that some of the epics switch is not recovered by autoburt. What I noticed is filter switch of SUSPOS, SUSPIT, SUSYAW, SDSEN, and all coil output for ETMX.

I had no idea to fix them, probably Joe knows. I guess other suspensitons has the same problems.

 

Attachment 1: 110125_Xend_thermal.pdf
110125_Xend_thermal.pdf
  665   Mon Jul 14 00:36:19 2008 JohnSummaryPSLSlow sweep of laser temp - PMC PZT response
John, Rana

Follow up to # 663

Top trace: C1: PSL-PMC_PZT
Middle: C1: PSL-FSS_SLOWDC
Bottom: C1: PSL-PMC_PMCTRANSPD

The only calibration I could find for the PMC PZT (LLO e-log Sep 3 2003 - 23 MHz/V) predicts 31V for an FSR. I did a rough calibration and got our FSR to be around 210 V. I assumed 713 MHz for an FSR and applied this calibration (~3.4 MHz/ V) to the PZT data.

In terms of volts per metre our PZT gives 2.54 nm/ V whereas the LLO PZT is 17.16 nm/ V.
Attachment 1: SlowTsweep.png
SlowTsweep.png
  15159   Mon Jan 27 18:16:30 2020 gautamConfigurationComputersSluggish megatron?

I've also been noticing that the IMC Autolocker scripts are running rather sluggishly on Megatron recently. Some evidence - on Feb 11 2019, the time between the mcup script starting and finishing is ~10 seconds (I don't post the raw log output here to keep the elog short). However, post upgrade, the mean time is more like ~45-50 seconds. Rana mentioned he didn't install any of the modern LIGO software tools post upgrade, so maybe we are using some ancient EPICS binaries. I suspect the cron job for the burt snapshot is also just timing out due to the high latency in channel access. Rana is doing the software install on the new rossa, and once he verifies things are working, we will try implementing the same solution on megatron. The machine is an old Sun Microsystems one, but the system diagnostics don't signal any CPU timeouts or memory overflows, so I'm thinking the problem is software related...

Quote:

The burt snapshotting is still not so reliable - for whatever reason, the number of snapshot files that actually get written looks random. For example, the 14:19 backup today got all the snaps, but 15:19 did not. There are no obvious red flags in either the cron job logs or the autoburt log files. I also don't see any clues when I run the script in a shell. It'll be good if someone can take a look at this.

  15164   Tue Jan 28 15:39:04 2020 gautamConfigurationComputersSluggish megatron?

There were a bunch of medm processes stalled on megatron (connected with screenshot taking). To see if they were interfering with the other scripts, I killed all of the medm processes, and commented out the line in the crontab that runs the screenshots every 10 mins. Let's see if this improves stability.

  4844   Mon Jun 20 18:12:20 2011 NicoleUpdateSUSSmall Table Cleaned and Levelled

P6220198.JPG

The small optical bench (next to the MC-2 Chamber and the tool box tower) has been cleared of the misc. object previously on it, cleaned, and leveled (after much calibration X___X).

PLEASE, PLEASE, PLEASE do NOT MOVE OR HIT THE TABLE! It was incredibly painful to level.

This is how leveling the table made me feel...

P6220199.JPG

VERY SAD...so do not move please!

The shaker has already been moved to the table and the amplifier for my shaking experiment is located behind the table (not on the table, as to prevent scratching).

 

 

  5483   Tue Sep 20 16:31:24 2011 KeikoUpdateIOOSmall modulation depth

 Modulation resonator box is removed and the modulation depth is small right now.

I have broke the BNC connector on the modulation resonator box. The connector was attached by the screw inside very loosely and when we connect and disconnect the BNC cables from outside, extra force was applied to the cable inside and it was broke. It is being fix by Kiwamu and will be back in a bit.

 

 

 

 

  5484   Tue Sep 20 16:38:25 2011 KeikoUpdateIOOSmall modulation depth

Resonator box and the modulations are back now. But the modulation depth seems to be a bit smaller than yesterday, looking at the optical spectrum analyser.

 

Quote:

 Modulation resonator box is removed and the modulation depth is small right now.

I have broke the BNC connector on the modulation resonator box. The connector was attached by the screw inside very loosely and when we connect and disconnect the BNC cables from outside, extra force was applied to the cable inside and it was broke. It is being fix by Kiwamu and will be back in a bit

 

  10942   Tue Jan 27 04:11:21 2015 JenneUpdateLSCSmall tweaks to the locking

[Jenne, Diego, EricQ]

We did a series of small things that may have helped with the locking, although we didn't actually get anywhere closer in CARM offset.

  • Removed the demodulation phase from the UGF servos.
    • We don't care about the phase value, just the magnitude.
    • Since we are using these through transitions between error signals, as well as with different filters coming on and off, the demodulation phase isn't constant, so the UGF servo is getting the wrong answer, and was throwing us out of lock.
    • The problems that Rana and I saw last time we had the sum of the sqrt were later discovered to be attributable to losing the peak in the noise, and hitting saturation limiters in the model, so not the fault of the sum of the squares.
    • I don't actually take the square root.  As Koji pointed out, the very next thing that happens to the signal is mag2dB, which is usually 20*log10(mag).  To compensate for the fact that I'm not taking the square root, I just use 10*log10(mag).  This removes one element of non-linearity, and leaves it at about the same number of square-ings as the complex division.
    • The excitation and measurement still happen after the multiplication.
    • The UGF screens will be updated tomorrow to reflect the change.
  • Added the new error signal rows to the LSC model's DAQ list.  So, now DARM_A_ERR and DARM_B_ERR are both acquired (and the same for CARM, MICH and PRCL).  This is to allow us to look at _DQ channels with dataviewer and DTT without having to clear the testpoints all the time.
    • We were running into too many channels being recorded, so we are not keeping the SRCL A & B signals right now.  Also, the CESAR signals that are no longer in use have been removed from the DAQ list.
  • Added a comb to the ASDC and POPDC signals, to remove the 60Hz harmonics from the MICH error signal.
    • The harmonics of the 60Hz line were dominating by more than an order of magnitude the RMS for the MICH control signal.  We couldn't afford too much phase at a few tens of Hz, so we do not notch out the original 60Hz line, although it isn't as big as, say, the 180Hz line.  So, I think that the notches are for the 2nd, 3rd, 4th and 5th order harmonics of 60Hz.  This significantly improved the RMS of the MICH output signal.
  • Lowered the MICH UGF slightly, from 48Hz to 41Hz. 
    • We wanted to go lower, to maybe 30Hz-ish, but we don't have the phase margin.  The roll mode notch is in the way, so we compromised at 41Hz.  With the comb mentioned above, the MICH control signal looks much more reasonable, and we're not injecting oodles of sensing noise into the BS.
    • Together with the comb, this ensures that we are not constantly railing the MICH output limiter, which lost us lock several times.
  • Increased the POPDC analog whitening gain from 0dB to 18dB.  We will certainly saturate POPDC when the carrier is resonant, but we were hoping to improve our SNR in our MICH error signal.  It helped noticeably, although we'll have to think about the fact that if it saturates while we're trying to acquire, the AS/POP composite signal won't be any good, and we'll kick the optics.  Also, we may have to lower the gain again as the carrier comes in to resonance.  Anyhow, something to think about.  Right now the gain is left at 18dB, and the dark offsets are set to match.
  • We may have been using the wrong side of the MICH offset, according to Q's plots.  We determined tonight that we want a (-) in the MICH gain, although the offset values can stay the same.  Even though we tried this, we didn't really get any farther in CARM offset reduction.
  • We took 2 sets of CARM and DARM loops.  They are both at 50% MICH offset, although I don't remember which sign the first one had.  The second one, at arm powers of 1.4, definitely had the new negative MICH gain. 
    • The first loop was taken at 50% MICH offset (don't remember which sign), and arm powers of about 1.15.
    • The second loop was taken at 50% MICH offset with negative gain, and arm powers of about 1.4.
    • While these numbers are not so different, maybe the first one was at roughly 300pm, and the second was at roughly 200pm, the loop shapes change dramatically.
    • The phase goes flat and we lose some of the phase margin.  Also, the magnitude is starting to get wiggly at lower frequencies.
    • See the transfer functions attached below.
  • While we were sitting at about arm powers of 1.4, with the 50% MICH offset with the negative sign in the gain, we set the REFL 11 demod phase.  It was 18.9deg (I don't remember from when), but we set it to 2.9deg to minimize the PRCL actuation in the Q-phase.  Oscillator was at 443Hz, about 10 counts. 
    • The coherence between the sqrtInvTrans signal and REFL11I looked pretty good from a few Hz to a few tens of Hz. 
    • It was late, so we decided to try transitioning over to REFL11I, and failed at the first very baby step.  So.  Ooops.
    • We should look more carefully at the TF between our current CARM signal and REFL11I.
    • We should also seriously consider using a normalized RF signal.  The SNR in the transmission PDs is just fine, although POPDC isn't a perfect choice at such high MICH offsets.
Attachment 1: CARM_27Jan2015_JCD.pdf
CARM_27Jan2015_JCD.pdf
Attachment 2: DARM_27Jan2015.pdf
DARM_27Jan2015.pdf
  10944   Tue Jan 27 15:45:26 2015 diegoUpdateLSCSmall tweaks to the locking

The UGF Servo medm page has been updated to reflect the last changes, namely the return of the sum of squares and the disappearance of Test3.

 

  9341   Mon Nov 4 23:11:00 2013 JenneUpdateLSCSmall updates to LSC screen

I made some small edits to the LSC screen. 

* When I added columns for the new AS110 PD, I had forgotten to make the Trigger matrix and Power Normalization matrix icons on the screen bigger, so we weren't seeing the last 2 columns in the overview screen.

* I added "show if not zero" oscillator icons to the Sensing Matrix part of the LSC overview screen, so that it's easier at a glance to see that there is an oscillator on.

  16775   Wed Apr 13 16:23:54 2022 Ian MacMillanUpdateGeneralSmell in 40m

[Ian, Paco, JC]

There is a strange smell in the 40m. It smells like a chemically burning smell maybe like a shorted component. I went around with the IR camera to see if anything was unusually hot but I didn't see anything. The smell seems to be concentrated at the vertex and down the y-arm

  9639   Fri Feb 14 12:39:02 2014 JenneUpdatesafetySmoke detector cleaned

Facilities just came by and cleaned the smoke detector that is above Steve's desk.  It's next to an air vent, so I guess it collects dust more than a "typical" smoke detector.

  4811   Mon Jun 13 18:40:08 2011 Jamie, JoeUpdateCDSSnags in the repair of LSC CDS

We've run into a problem with our attempts to get the LCS control back up and running.

As reported previously, the Dolphin fiber connection between c1lsc and c1sus appears to be dead.  Since we have no replacement fiber, the solution was to move the c1lsc machine in to the 1X4 rack, which would allow us to use one of the many available short Dolphin cables, and then use a long fiber PCIe extension cable to connect c1lsc to it's IO chassis.  However, the long PCIe extension cable we got from Downs does not appear to be working with our setup.  We tested the cable with c1sus, and it does not seem to work.

We've run out of options today.  Tomorrow we're going to head back to Downs to see if we can find a cable that at least works with the test-stand setup they have there.

  292   Fri Feb 1 15:04:54 2008 josephbConfigurationCamerasSnap with looping functionality available
New GiGE camera code is available in /cvs/cds/caltech/target/Prosilica/40mCode/. Currently only runs on Mafalda.

Snap has expanded functionality to continuously loop infinitely or for a maximum number of images set by the user. File names generated with the loop option have the current Unix time and .tiff appended to them. So -f './test' will produce tiff files with format "test1234567.tiff". The -l option sets the number of seconds between images.

"./Snap -l 5 -i -f './test' " will cause the program to infinitely loop, saving images every 5 seconds. Using "-m 10" instead of "-i" will take a series of 10 images every 5 seconds (so taking a total of 50 seconds to run).

It also now defaults to 16-bit (in reality only 10 bit) output instead of 8 bit output. You can select between the two with -F 'Mono8' or -F 'Mono16'.

Use --help for a full list of options.

Note that if you ctrl-c out of the loop, you may need to run ./ResetCamera 131.215.113.104 (or whatever the IP is - use ./ListCameras to determine IP if necessary) in order to reset the camera because it doesn't close out elegantly at the moment.
  1206   Mon Dec 29 21:38:57 2008 YoichiUpdateComputersSnapshots of MEDM screens
I wrote scripts to take snapshots of MEDM screens in the background.
These scripts work even on a computer without a physical display attached.
You don't need to have X running.
So now the scripts run on nodus every 5 minutes from cron.
The screen shots are saved in /cvs/cds/caltech/statScreen/images/

There is a wiki page for the scripts.
http://lhocds.ligo-wa.caltech.edu:8000/40m/captureScreen.sh

Someone has to make a nice web page summarizing the captured images.
  1221   Fri Jan 9 17:30:10 2009 KakeruUpdateComputersSnapshots of MEDM screens
I wrote a web page which shows snapshots of MEDM screens generated by Yoich's script (e-log #1206).
https://nodus.ligo.caltech.edu:30889/medm/screenshot.html
This page refreshes itself every 5 minutes automatically.

The .html file is generated by /cvs/cds/caltech/statScreen/bin/genHtml.pl
This script generates the .html file contains snapshots listed on /cvs/cds/caltech/statScreen/etc/medmScreens.txt every 5 minutes with cron.
When you wont to display other screens, please edit this .txt file and wait 5 minutes!


To make thumbnails, I wrote /cvs/cds/caltech/statScreen/bin/genThumbnail.pl
This script reads /cvs/cds/caltech/statScreen/etc/medmScreens.txt, too.
(Sometimes, it makes thumbnails with larger storage...)


Quote:
I wrote scripts to take snapshots of MEDM screens in the background.
These scripts work even on a computer without a physical display attached.
You don't need to have X running.
So now the scripts run on nodus every 5 minutes from cron.
The screen shots are saved in /cvs/cds/caltech/statScreen/images/

There is a wiki page for the scripts.
http://lhocds.ligo-wa.caltech.edu:8000/40m/captureScreen.sh

Someone has to make a nice web page summarizing the captured images.
  13072   Mon Jun 19 18:32:18 2017 jigyasaUpdateComputer Scripts / ProgramsSoftware Installation for image analysis

The IRAF software from the National Optical Astronomy Observatory has been installed locally on Donatella(for testing) following the instructions listed here at http://www.astronomy.ohio-state.edu/~khan/iraf/iraf_step_by_step_installation_64bit
This is a step towards "aperture photometry" and would help identify point scatterers in the images of the test masses.

I will be testing this software, in particular, the use of DAOPHOT and if it seems to work out, we may install it on the shared directory.
Hope this isn't an inconvenience.

 

 

  25   Mon Oct 29 11:07:22 2007 waldmanSoftware InstallationOMCSoftware install on OMS
[Alex, Sam]

We spent a little time this morning working on OMS and getting things restarted. A few changes were made. 1) We put openmotif on OMS so that the burtrb doesn't throw that crappy libXm any more. 2) We upgraded OMS to a 32 kHz sampling rate from 2 kHz. All the filters will have to be changed. We also added a PDH filter path to maybe feedback PDH signals cuz that will be cool. Maybe someday I will write up the very cool channel adding procedure.
  12433   Tue Aug 23 17:05:20 2016 PrafulUpdateElectronicsSoldered Circuit Working

I remade another soldered circuit, adding extra 100uF electrolytic bypass capacitors at the input and output of the voltage regulator and ensuring that every grounded component now has its own path to ground rather than going through other elements. This circuit now seems to be working just like the solderless circuit. Attached is the transfer function of the soldered circuit, which matches with the result from the solderless circuit.

 

soldered_transfer_function.png

solderless_transfer_function.png

Here are both on the same figure- they are about overlapping but are slightly different if you zoom in enough.

both_transfer.png

I have also attached a new version of the circuit schematic to reflect the changes and to make the physical layout more clear.

simple_ampv2.pdf

My next step for these last few days this summer will be designing a PCB using Altium. I've emailed Varun about how to use Altium on the iMac but he hasn't responded. If anyone else knows how to use the software, please let me know.

Attachment 2: soldered_transfer_function.png
soldered_transfer_function.png
Attachment 3: soldered_transfer_function.png
soldered_transfer_function.png
Attachment 5: solderless_transfer_function.png
solderless_transfer_function.png
Attachment 6: both_transfer.png
both_transfer.png
Attachment 8: both_transfer.png
both_transfer.png
Attachment 10: simple_ampv2.pdf
simple_ampv2.pdf
  15201   Mon Feb 10 09:40:54 2020 Larry WallaceSummaryGeneralSolidWorks Computer Upgrade and Printer repair

On February 5, 2020, the Dell engineering workstation located in the 40M lab, was replaced with a newer Engineering workstation, per a request from Koji . The new workstation should perform a good deal better over the older unit. It has more cores, more memory and a better video card. Since this unit is being used by the 40M group, the Comsol s/w pkg. was also installed on the unit.

During the computer swap, Koji had a problem with a print job and it was discovered the bottom tray of the HP5550 printer was broken. The broken tray was replaced from another unit that was being disposed of.

  13561   Fri Jan 19 20:59:07 2018 Udit KhandelwalUpdateGeneralSolidworks Rendering

Rendered the SOS assembly (D960001) with correct materials and all and it looks very nice. Will extend this to the building cad later.

  14813   Thu Jul 25 20:08:36 2019 gautamUpdateComputersSolidworks machine

I brought one CPU (Dell T3500) and one 28" monitor from Mike Pedraza's office in Downs to the 40m. It is on Steve's desk right now, pending setup. The machine already has Solidworks and Altium installed on it, so we can set it up at our leisure. The login credentials are pasted on the CPU with a post-it should anyone wish to set it up.

  2003   Fri Sep 25 17:51:51 2009 KojiUpdateMOPASolved (Re: Total MOPA power is constant, but the NPRO's power has decreased after last night's activities?)

Jenne, Koji

The cause of the decrease was found and the problem was solved. We found this entry, which says

Yoich> We opened the MOPA box and installed a mirror to direct a picked off NPRO beam to the outside of the box through an unused hole.
Yoich> We set up a lens and a PD outside of the MOPA box to receive this beam. The output from the PD is connected to the 126MON cable.

We went to the PSL table and found the dc power cable for 126MOPA_AMPMON was clipping the 126MON beam.
We also made a cable stay with a pole and a cable tie.

After the work, 126MON went up to 161 which was the value we saw last night.


We also found that the cause of the AMPMON signal change by the DAQ connection, mentioned in this entry:

Jenne> 6.  We teed off of the AMPMON photodiode so that we could see the DC values on a DMM. 
Jenne> When we used a T to connect both the DMM and the regular DAQ cable, the DMM read
Jenne> a value a factor of 2 smaller than when the DMM was connected directly to the PD.

We found a 30dB attenuator is connected after the PD. It explains missing factor of 2.

Quote:

[Koji, Jenne]

Steve pointed this out to me today, and Koji and I just took a look at it together:  The total power coming out of the MOPA box is constant, about 2.7W.  However, the NPRO power (as measured by 126MOPA_126MON) has decreased from where we left it last night.  It's an exponential decay, and Koji and I aren't sure what is causing it.  This may be some misalignment on the PD which actually measures 126MON or something though, because 126MOPA_LMON, which measures the NPRO power inside the NPRO box (that's how it looks on the MEDM screen at least...) has stayed constant.  I'm hesitant to be sure that it's a misalignment issue since the decay is gradual, rather than a jump. 

Koji and I are going to keep an eye on the 126MON value.  Perhaps on Monday we'll take a look at maybe aligning the beam onto this PD, and look at the impedance of both this PD, and the AMPMON PD to see why the reading on the DMM changed last night when we had the DAQ cable T-ed in, and not T-ed in. 

 

  15232   Thu Feb 27 17:59:02 2020 gautamUpdateLSCSome AO thoughts

While my checks of the AO signal path have thrown up some unanswered questions, I don't think there's any evidence in those measurements to suggest the AO crossover can't be realized. Thinking about it today though - I was wondering if it could be that the IN1 gain slider of the CM board is configured optimally. Looking back at some data, when the ALS CARM offset is zeroed, the CM_SLOW digitized data has a peak-to-peak range of ~200 cts. This is paltry. One possibility is that as I am upping the AO path gain, I'm simply injecting the electronics noise of the CM board into the IMC error point. I'd say it is safe to up the IN2 gain by 20dB to -12 dB, in which case the peak-to-peak would be ~2000 cts, still only 10% of the ADC range. It'll be straightforward to re-scale the CARM_B loop gain to account for this. Let's see if this helps.

I'd also like to measure the spectrum of the REFL11_I signal in a few different states. I think I should be able to do this using the OUT2 of the CM servo board. These are the things to try tonight:

  • Try CARM RF handoff with CM_SLOW gain starting at -12dB instead of -32dB.
  • Measure spectrum of REFL11_I when it is in the linear range.
  9784   Thu Apr 3 18:55:10 2014 ericqSummaryLSCSome CARM related modeling

 The other day, Jenne and I were comparing my MIST simulation to her Optickle simulation for the CARM transfer functions I posted some days ago. She told me that the arms are not exactly where they should be for the whole "PRC length tuning to account for sideband reflection phase off resonant cavity" deal. 

Specifically, as in the wiki (but with newer modulation frequencies), I calculated the ideal arm length to be 37.795 m some time ago, when doing PRC length simulations, and Jenne has told me that the X arm is more like 37.6m, and Y is 37.9. So, I updated my simulations, and found the following:

This does weird things to the f2 sideband buildup on resonance in the PRFPMI configuration:

asIsPRCRes.pdf idealPRCRes.pdf

(POP is way huger than than the TR's, because the POP pd's are artificially "inside" the cavity, whereas TRX/Y is actually transmitted through an ETM)

This is not necessarily directly something to worry about, but I think the following may be. It looks like this arm length mismatch actually causes the PRCL demodulation phase in REFL 165 to change dramatically with the CARM offset. (REFL33 seems fine, though. 5 degrees causes less than a 1% effective gain change.) 

 3fPrclAnglesCarm.pdf

My simulations don't include any signal recycling yet, so I don't have anything to show if there is a similar effect for SRCL, but it wouldn't surprise me... 

 

  15017   Wed Nov 6 19:26:57 2019 gautamUpdatePSLSome PSL cable admin

Koji and I taked about cleaning up some of the flaky cable situation on the PSL table a while ago. The changes were implemented and are documented in Attachment #1. Now the Pomona box between the Thorlabs HV Driver and the NPRO head is sitting on the PSL table (sandwiched between some teflon pieces I found in cabinet S4 along the south arm), and the cables between these two devices are better strain relieved. I turned off the Thorlabs HV supply while working on the PMC table. The IMC could be locked after this work. Probably won't solve the long standing FSS mysteries but probably can't hurt.

Unrelated to this work: I also removed a Bias tee that was just hanging out on top of the FSS electronics, which was used for the modeSpec project.

Attachment 1: PSLcableAdmin.jpg
PSLcableAdmin.jpg
  4034   Thu Dec 9 01:54:15 2010 JenneUpdateElectronicsSome Refl 11 fixes

The Backstory:

Kevin was working on characterizing all of our RF photodiodes for the upgrade, and he discovered that REFL11 didn't work, as described in elog 3890.  Rana was working on fixing it, but then he went off to Japan.

Today's Activities:

I visually inspected the components inside the RF cage on the REFL 11 circuit board inside the PD.  Most of them were okay, but the connection between L5 and C33 (the big tunable inductor and the next capacitor in the path) was totally flaky.  the leg of the inductor had been soldered directly to the trace on the PCB, and the inductor was a little bit tipped over, and pulling the trace off the board.  I wiggled it a little while trying to see what was going on, and the trace broke.  Since there is nothing going on between L5 and C33, just the trace, I used a piece of resistor lead to attach the two.  The connection now seems very robust.  I'm a little worried about the connection between the inductor and the board on the other side, but I can't see it since it's under the inductor itself.

Also, the soldering of L4 (a standard surface mount component type body) to the board seemed totally shoddy.  I was desoldering the first side, and the whole inductor popped off.  It was clear that the inductor was making a physical connection to the board, but not a nice solid electrical connection.  So I resoldered it on.  (On Alberto's schematics, it is listed as a 633nH inductor.  I can't find any of this value, so I just put the same one back on.  The best I could do to confirm the component was still okay was measure its resistance, and compare that to a similar inductor of a similar value.  It seemed okay.)

After that I powered up the PD, and took an electrical transfer function, just to have a look-see.  It seems kind of okay, although the resonance seems to be closer to 13MHz than 11MHz. 

Since we would like to remove the capacitor that is in parallel with the diode itself, which will then change all of the resonant conditions on other components, I didn't worry too much about the resonant peak for tonight.  We're going to have to look in on this though.

Also, I'm leaving the optical check-out for Kevin, so he will let us know if I magically fixed the PD, or if it needs some more work.

Photos of the circuit board (mostly Alberto's mods) before and after I fitzed with it are on Picasa

The Future:

More testing. Probably more fixing.

 

  10656   Fri Oct 31 02:19:37 2014 ericqUpdateLSCSome SRMI progress

Earlier today, I did some simulations that suggested that PRC lengths on the order of a cm from our current estimated one could result in degenerate PRCL and MICH signals in REFL165 at 3nm CARM offset. I attempted more demod-angle derived cavity PRC length measurements with REFL11 and REFL55, but they weren't consistent with each other...

In any case, adding dual recycling, even with a SRC length off by 1cm in either direction, doesn't seem to exhibit the same possibility, so I spent some time tonight seeing if I could make any progress towards DRMI locking. 

I was able to lock SRY using AS55 in a very similar manner to PRY, after adjusting the AS55 demod angle to get the error signal entirely in I. I used this configuration to align the SRM to the previously aligned BS and ITMY. Oddly, I was not able to do anything with SRX as I had hoped; the error signal looks very strange, looking more like abs(error signal). 

I then was able to lock the SRMI on AS55 I & Q, the settings have been saved in the IFO configure screen.  I've used AS55Q for PRMI locking with a gain of -0.2, so I started with that; the final gain ended up being -0.6. PRMI/PRY gain for prcl is something like 0.01, so since I used a gain of 2 for locking SRX, I started the SRCL gain around 0.02, the final gain ended up being -0.03. I basically just guessed a sign for AS110 triggering. Once I lucked upon a rough lock, I excited the PRM to tune the AS55 angle a few degrees; it was luckily quite close already from the SRY adjustment. AS110 needed a bigger adjustment to get the power into I. (AS55: -40.25->-82.25, AS110: 145->58, but I put AS55 back for PRMI)

I briefly tried locking the DRMI, but I was really just shooting in the dark. I went back and measured various sensing amplitudes/angles in SRMI and PRMI configurations; I'm hoping that I may be able to simulate the right gains/angles for eventual DRMI locking.

  9654   Wed Feb 19 11:00:16 2014 ericqUpdateLSCSome Simulation Efforts

 Q EDIT: THIS IS WRONG. I LOCKED PRC ON THE CARRIER

 As Koji measured the other day: MICH and PRCL seem very degenerate in the 3f REFL PDs. 

I'm using this as a motivation to do some simulation in MIST and try to understand the best way to implement the 3F locking scheme. Hopefully my thinking below isn't nonsense...

First, I modeled the PRC with no arm cavities and the estimated cavity length I got with the PRM kick measurement, and looked at the REFL sensing matrix.

PRMISensingAsIs.pdf

This agrees with the observed degeneracy. I then modeled the case of the PRC length that gives coincident SB resonance, again with no arm cavities.

PRMISensingCoinc.pdf

Now there is good separation in REFL165. (REFL33 still looks pretty degenerate, however). This raised the question, "What does the angle between MICH and PRCL in REFL165 do as a function of macroscopic PRC length?" 

MICHvPRCLangle.pdf

  • We see ~90 degrees at coincident resonance
  • Shortening the cavity, which we did to account for the arms, quickly shrinks the angle
  • Presuming we moved to make the cavity 4cm shorter implies we had ~45 degrees between MICH and PRCL in REFL165 before the move. (Is this consistent with earlier observations?)

To me, this implies that locking the PRC on 3F from scratch won't be simple. However, the whole point of the PRC length choice is to have coincident SB resonance when the arms are resonating.

So: even if we're not spot on, we should be relatively close to the PRC length where having arms resonant gives us simultaneously resonant upper and lower sidebands, where MICH and PRCL should be orthogonal-ish. I.e. building up a little bit of IR power in the arms may start to break the degeneracy, perhaps allowing us to switch from 1F to 3F locking, and then continue reducing the CARM offset. 

So, I ultimately want to model the effect of arm power buildup on the angle between MICH and PRCL in the 3f PDs. This is what I'm currently working on. 

So far, I have reproduced some of the RC modeling results on the wiki to make sure I model the arms correctly. (I get 37.7949 m as the ideal arm length for a modulation freq of 11.066134 MHz vs. 37.7974m for 11.065399 MHz as stated on the wiki). Next, I will confirm the desired PRC length that accounts for the arms, and then look at the MICH vs PRCL angle in the REFL PDs as a function of arm power or detuning. 

ArmLengthChoice.pdf

  9656   Wed Feb 19 14:14:46 2014 ericqUpdateLSCSome Simulation Efforts

 Q EDIT: THIS IS WRONG. I LOCKED PRC ON THE CARRIER

Koji noted oddities in the sensing matrix results I had gotten; namely that the plots showed REFL33 not changing at all, when we know for a fact that this should not be the case. 

Gabriele lent his eyes to my code, and came up with the idea that the modulation depths I was using were maybe not ideal (.1 for both 11 and 55). This affects REFL33 in that it is not simply Carrier * 33Mhz + 11Mhz * -22Mhz but also 22MHz * 55MHz, etc. 

I got more realistic values from Jenne (0.19 for 11MHz and .26 for 55Mhz) and re-ran the code, with more realistic results. The behavior for 165 has remained the same, but the other signals are more well behaved. 

Moral of the story: the modulation depths affect the 3f signals in a complicated way.

PRMISensingAsIs.pdf

PRMISensingCoinc.pdf

MICHvPRCLangle.pdf

 

 

  9657   Wed Feb 19 16:42:08 2014 ericqUpdateLSCSome Simulation Efforts

Disregard previous ELOGs, I had the PRC locked on carrier 

Locked on the sideband, the MICH / PRCL angle is much less sensitive to the PRC length, and shouldn't in fact be as degenerate as we've seen in reality. 

SBLOCK_PRMISensingAsIs.pdfSBLOCK_MICHvPRCLangle.pdf

So, my simulations no longer provide any reason for the 3F signals to be so degenerate. 

  3249   Tue Jul 20 11:49:31 2010 JenneUpdateSUSSome Suspensions not damping

[Jenne, Koji]

I moseyed into the control room this morning, to find ITMX and ITMY both with their watchdogs tripped.  ITMY (new convention) wouldn't damp.  Koji discovered that there was a sign flip in 2 of the sensors.  A set of reboots of c1susvme1&2 fixed the problem. 

A side note:  For the ETMs, the OSEM sensor readouts are gigantic (~20,000), whereas for the similar channels on all other optics, the readouts are on the order of 1.  After some looking around, it seems that this is just the way things have been (for at least 100 days), and the filters in the SUSPOS and other SUS filter banks have a high pass filter to take care of this.  It's weird, but it seems to be the way it is, and the ETMs damp, so it's all good.

  14397   Fri Jan 11 16:38:57 2019 gautamUpdateGeneralSome alignment checks

The pumpdown seems to be progressing smoothly, so I think we are going to stick with the plan decided on Wednesday, and vent the IFO on Monday at 8am. I decided to do some checks of the IFO alignment.

I turned on the PSL again (so goggles are advisable again inside the VEA until this work is done), re-locked the PMC, and opened the PSL shutter into the vacuum (still low power 100 mW beam going into vacuum). The IMC alignment required minor tweaking, but I recovered ~1300 cts transmission which is what it was --> so we didn't macroscopically change the input pointing into the IMC while working on the IOO table.

Centering the ITMY oplev spot, there is a spot on the AS camera roughly centered on the control room monitor, so the TT pointing must also be pretty close.

Then I centered the ITMY oplev spot to check how well-aligned or otherwise the Michelson was - the BS has no Oplev so there was considerable angular motion of the Michelson spot, but it looked like on average, it was swinging around through a well aligned place. I saved the slow bias voltages for the ITMs and BS in this config.

Then I re-aligned ETMX and checked the green transmission - it was okay, ~0.3, and I was able to increase it to ~0.4 using the EX green PZT mirrors. So far so good.

Finally, I tried to lock the X-arm on IR - after zeroing the offsets on the transmission QPD, there seems to be a few flashes as the cavity swings through resonances, but no discernible PDH error signal. Moreover the input pointing of the IR into the X arm is controlled by the BS which is swinging around all over the place right now, so perhaps locking is hopeless, but the overall alignment of the IFO seems not too bad. Once ETMY is cleaned and put back in place, perhaps the Y arm can be locked.

I shuttered the PSL and inserted a manual beam block, and also turned off the EX laser so that we can vent on Monday without laser goggles.

*Not directly related to this work: we still have to implement the vacuum interlock condition that closes the PSL shutter in the event of a vacuum failure. It's probably fine now while the PSL power is attenuated, but once we have the high power beam going in, it'd be a good to revert to the old standard.

Attachment 1: pd82.png
pd82.png
Attachment 2: LSC_X.png
LSC_X.png
  15620   Thu Oct 8 15:08:25 2020 gautamUpdateGeneralSome boxes moved from 40m entry hallway
  • UPS batteries
  • 2x HEPA filters
  • VWR chemicals (methanol)

These boxes were moved from the 40m hallway to the inside of the VEA so that we have some space to walk around. You can find some pictures here.

  3172   Wed Jul 7 22:22:49 2010 JenneUpdateComputersSome channels not being recorded!!!

[Rana, Jenne]

We discovered to our great dismay that several important channels (namely C1:IOO-MC_L, but also everything on c1susvme2) are not being recorded, and haven't been since May 17th.  This corresponds to the same day that some other upgrade computers were installed.  Coincidence?

We've rebooted pretty much every FE computer and the FrameBuilder and DAQ_CONTROL approximately 18 times each (plus or minus some number).  No matter what we do, or what channels we comment out of the C1SUS2.ini file, we get a Status on the DAQ_Detail screen for c1susvme2 of 0x1000.  Except sometimes it is 0x2000.  Anyhow, it's bad, and we can't make it good again. 

I have emailed Joe about fixing this (with some assistance from Alberto, since we all know how much he likes doing the Nuclear Reboot option for the computers :)

  3176   Thu Jul 8 14:11:16 2010 josephbUpdateComputersSome channels not being recorded!!!

This has been fixed, thanks to some help from Alex. It doesn't correspond to new computers being put in, but rather corresponds to a dcu_id change I had made in the new LSC model.

The fundamental problem is way back when I built the new LSC model using "lsc" as the name instead of something like "tst", I forgot to go to the current frame builder master file (/cvs/cds/caltech/chans/daq/master) and comment out the C1LSC.ini line. Initially there was no conflict with c1susvme, because the initially was dcu_id 13. The dcu_id was eventually changed to 10 from 13 , and thats when it conflicted with the c1susvme2 dcu_id which was also 10. I checked it against wiki edits to my dcu_id list page and I apparently updated the list on May 20th when it changed from 13 to 10, so the time frame fits.  Apparently it was previously conflicting with C0GDS.ini or C1EXC.ini, which both seem to have dcu_id = 13 set, although the C1EXC file is all commented out. The C0GDS.ini file seems to be LSC and ASC test points only.

The solution was to comment out the C1LSC.ini file line in the /cvs/cds/caltech/chans/daq/master file and restart the framebuilder with the fixed file.

Quote:

[Rana, Jenne]

We discovered to our great dismay that several important channels (namely C1:IOO-MC_L, but also everything on c1susvme2) are not being recorded, and haven't been since May 17th.  This corresponds to the same day that some other upgrade computers were installed.  Coincidence?

We've rebooted pretty much every FE computer and the FrameBuilder and DAQ_CONTROL approximately 18 times each (plus or minus some number).  No matter what we do, or what channels we comment out of the C1SUS2.ini file, we get a Status on the DAQ_Detail screen for c1susvme2 of 0x1000.  Except sometimes it is 0x2000.  Anyhow, it's bad, and we can't make it good again. 

I have emailed Joe about fixing this (with some assistance from Alberto, since we all know how much he likes doing the Nuclear Reboot option for the computers :)

 

  3179   Thu Jul 8 15:43:58 2010 ranaUpdateComputersSome channels not being recorded!!!

Quote:

This has been fixed, thanks to some help from Alex. It doesn't correspond to new computers being put in, but rather corresponds to a dcu_id change I had made in the new LSC model.

 Just as I expected, since these hunuman didn't actually check MC_L after doing this stuff, MC_L was only recording ZERO. Joe and I reset and restarted c1susmve2 and then

verified (for real this time) that the channel was visible in both the Dataviewer real time display as well as in the trend.

3-monkeys-ComicPosition.gif

The lesson here is that you NEVER trust that the problem has been fixed until you check for yourself. Also, we must always

specify a very precise test that must be used when we ask for help debugging some complicated software problem.

 

  314   Wed Feb 13 11:41:00 2008 AlbertoUpdateElectronicsSome characterization of the RF Monitor Box (StocMon)
I'm attaching a table with some measurements and the power spectrum from the pd to help evaluate the numbers.

The box output ranges from 0.5V to 2.1V. The coefficient between power and voltage is negative so higher voltage means lower power.

The red numbers are the outputs from each channel at their resonant frequencies. As one can see these are not very well centered on the dynamic range of the power detectors.

The cross coupling seems to be not a problem.

Even if the 166 filter, which handles the smallest of the frequencies and is also the most lossy (for construction reason), mounts a preamplifier, the output is still rather small. this explain also the high bias due to the noise amplification at the maximum power (13dB). A better insertion loss either remaking the filter or re-tuning that one would simplify many problems, i.e. there is not much room in the metal pomona box to fit the amplifier. I might want to consider, after everything else is ready and if I have time before leaving next week, to work on a new 166 filter.
Attachment 1: CircuitCharacterization.png
CircuitCharacterization.png
Attachment 2: alberto.spectrum3.png
alberto.spectrum3.png
  9613   Fri Feb 7 17:52:41 2014 KojiSummaryGeneralSome cleaning up
  • Adjusted the PMC alignment
  • Adjusted the IMC length offsets for the MC servo and the FSS servo
  • Adjusted the MC alignment. Ran /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets
     
  • The Yarm servo was oscillating. Reduced the servo gain from 0.2 to 0.08.
     
  • AS Camera & AS port alignment was adjusted. Now the spot is at the center of the AS camera.
  • Cleaned up the ASC offsets on the suspensions (i.e. C1:SUS-***_(PIT|YAW)_OFFSET) by replacing them by the BIAS adjustment.
  • Saved the alignment values
  • Locked the PRMI with SB with REFL55I for PRCL and AS55Q for MICH
  • Aligned the PRM, then checked the alignment of the REFL PDs
  • The best POP110I was 500cnt.
  • Found REFL165 output was disconnected. It is now restored.
     
  • Used the LSC lockins to figure out the demod phases and the signal amplitudes (relative)

PRCL: 100cnt -> PRM 567.01Hz

Signal in demod Q ch were minimized

REFL11I -19.2deg demod I, Lockin I out (C1:CAL-SENSMAT_PRCL_REFL11_I_I_OUTPUT) 12.6 cnt
REFL33I +130.4deg 1.70cnt
REFL55I +17.0deg 2.30cnt
REFL165I -160.5deg 27.8cnt

MICH: 1000cnt -> ITMX(-1) & (ITMY +1.015 => Minimized the signal in REFL11I to obtain pure MICH)

REFL11I   +0.0     REFL11Q   +0.119
REFL33I   +0.023 REFL33Q   -0.012
REFL55I   +0.023 REFL55Q   -0.113
REFL165I +0.68   REFL165Q +0.038

It seems that REFL165 has almost completely degenerated PRCL and MICH.

  • Try to replace ITMX/Y with BS (+0.16) / PRM (-0.084)

 ITMX(-1)/ITMY(+1.015) actuation was cancelled by BS (+0.16). This introduces PRCL in REFL11I. This was cancelled by PRM (-0.084)

 

REFL11I   +0.0     REFL11Q   +0.13
REFL33I   -0.012  REFL33Q   0.025
REFL55I   +0.041 REFL55Q   -0.45
REFL165I +0.69   REFL165Q +/-0.02

Again, It seems that REFL165 has almost completely degenerated PRCL and MICH.


Locking info:

PRCL:
[Signal source] REFL11I (-19.2deg) x 0.16, OR REFL33I (+130.4deg) x 2.0, OR REFL55I (+17.0deg) x1.0, OR REFL165I (-160.5deg) x0.05
[Trigger] POP110I(-81deg) 100/10, FM trigger 35/2, delay 0.5sec FM2/3/6/9
[Servo] FM4/5 always on. G=-0.02, Limitter ON
[Output] PRM x+1.00

MICH:
[Signal source] AS55Q (-5.5deg) x 1, OR REFL11Q x 0.25, OR REFL55Q x-0.06
[Trigger] POP110I 100/10, FM trigger 35/2, delay 5sec FM2/3/9
[Servo] FM4/5 always on. G=-10, Limitter ON
[Output] ITMX -1.0 / ITMY +1.0 (or +1.015), OR PRM -0.084 / BS +0.16


 

 

  3221   Wed Jul 14 18:09:50 2010 josephb, razibUpdatePhase CameraSome cleanup behind 1Y2 rack of phasecamera electronics

We made an attempt at cleaning up the phase camera setup electronics.

We have moved a portion of the electronics onto the SP table (specifically the mixer, splitters, amplifiers, and associated power).  We put away a large number of cables which were unneeded, both BNC and power cables. The Innolight Mephisto power supply and one signal generator are still behind 1Y2 on top of a non-functioning VME crate.  The second VME crate was put along the south arm where two other VME crates already were.  We placed a fair number of BNC cables and power cords back on their cable racks or approriate storage space, so the rats nests of cables has been reduced.

We moved one power strip from plugging in beyind 1Y1, to the far side of the SP table (closer to the 1Y3 rack), and also found and plugged in another power strip (also on the far side of the SP table) and placed this underneath the SP table to be able to power the signal generator and Innolight Mephisto laser (its not plugged in currently, but we'd like to do so next week).

 

  17170   Mon Oct 3 13:11:22 2022 YehonathanUpdateBHDSome comparison of LO phase lock schemes

I pushed a notebook and a Finesse model for comparing different LO phase locking schemes. Notebook is on https://git.ligo.org/40m/bhd/-/blob/master/controls/compare_LO_phase_locking_schemes.ipynb,

Here's a description of the Finesse modeling:

I use a 40m kat model https://git.ligo.org/40m/bhd/-/blob/master/finesse/C1_w_initial_BHD_with_BHD55.kat derived from the usual 40m kat file. There I added and EOMs (in the spaces between the BS and ITMs and in front of LO2) to simulate audio dithering. A PD was added at a 5% pickoff from one of the BHD ports to simulate the RFPD recently installed on the ITMY table.

First I find the nominal LO phase by shaking MICH and maximizing the BHD response as a function of the LO phase (attachment 1).

Then, I run another simulation where I shake the LO phase at some arbitrary frequency and measure the response at different demodulation schemes at the RFPD and at the BHD readout.

The optimal responses are found by using the 'max' keyword instead of specifying the demodulation phase. This uses the demodulation phase that maximizes the signal. For example to extract the signal in the 2 RF sideband scheme I use:

pd3 BHD55_2RF_SB $f1 max $f2 max $fs max nPickoffPDs

I plot these responses as a function of LO phase relative to the nominal phase divided by 90 degrees (attachment 2). The schemes are:

1. 2 RF sidebands where 11MHz and 55MHz on the LO and AS ports are used.

2. Single RF sideband (11/55 MHz) together with the LO carrier. As expected, this scheme is useful only when trying to detect the amplitude quadrature.

3. Audio dithering MICH and using it together with one of the LO RF sidebands. The actuation strength is chosen by taking the BS actuation TF 1e-11 m/cts*(50/f)**2 and using 10000 cts giving an amplitude of 3nm for the ITMs.

For LO actuation I can use 13 times more actuation strentgh becasue its coild drivers' output current is 13 more then the old ones.

4. Double audio dithering of LO2+MICH detecting it directly at the BHD readout (attachment 3).

Without noise considerations, it seems like double audio dithering is by far the best option and audio+RF is the next best thing.

The next thing to do is to make some noise models in order to make the comparison more concrete.

This noise model will include Input noises, residual MICH motion, and laser noise. Displacement noise will not be included since it is the thing we want to be detected.

Attachment 1: MICH_sens_vs_LO_phase.pdf
MICH_sens_vs_LO_phase.pdf
Attachment 2: LO_phase_sens_vs_LO_phase_RF.pdf
LO_phase_sens_vs_LO_phase_RF.pdf
Attachment 3: LO_phase_sens_vs_LO_phase_double_audio.pdf
LO_phase_sens_vs_LO_phase_double_audio.pdf
ELOG V3.1.3-