40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 98 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  12166   Fri Jun 10 12:09:01 2016 jamieConfigurationCDSIRIG-B debugging

Looks like we might have a problem with the IRIG-B output of the GPS receiver.

Rolf came over this morning to help debug the strange symmetricom driver behavior on fb1 with the new Spectracom card.  We restarted the machine againt and this time when we loaded the drive rit was clocking at a normal rate (second/second).  However, the overall GPS time was still wrong, showing a time in October from this year.

The IRIG-B122 output is supposed to encode the time of year via amplitude modulation of a 1kHz carrier.  The current time of year is:

controls@fb1:~ 0$ TZ=utc date +'%j day, %T'
162 day, 18:57:35
controls@fb1:~ 0$ 

The absolute year is not encoded, though, so the symmetricon driver has the year offset hard coded into the driver (yuck), to which it adds the time of year from the IRIG-B signal to get the correct GPS time.

However, loading the symmetricom module shows the following:

...
[ 1601.607403] Spectracom GPS card on bus 1; device 0
[ 1601.607408] TSYNC PIC BASE 0 address = fb500000
[ 1601.607429] Remapped 0xffffc90017012000
[ 1606.606164] TSYNC NOT receiving YEAR info, defaulting to by year patch
[ 1606.606168] date = 299 days 18:28:1161455320
[ 1606.606169] bcd time = 1161455320 sec  959 milliseconds 398 microseconds  959398630 nanosec
[ 1606.606171] Board sync = 1
[ 1606.616076] TSYNC NOT receiving YEAR info, defaulting to by year patch
[ 1606.616079] date = 299 days 18:28:1161455320
[ 1606.616080] bcd time = 1161455320 sec  969 milliseconds 331 microseconds  969331350 nanosec
[ 1606.616081] Board sync = 1
controls@fb1:~ 0$ 

Apparently the symmetricom driver thinks it's the 299nth day of the year, which of course corresponds to some time in october, which jives with the GPS time the driver is spitting out.

Rolf then noticed that the timing module in the VME crate in the adjacent rack, which also receives an IRIG-B signal from the distribution box, was also showing day 299 on it's front panel display. We checked and confirmed that the symmetricom card and the VME timing module both agree on the wrong time of year, strongly suggesting that the GPS receiver is outputing bogus data on it's IRIG-B output, even though it's showing the correct time on it's front panel.  We played around with setting in the GPS receiver to no avail.  Finally we rebooted the GPS receiver, but it seemed to come up with the same bogus IRIG-B output (again both symmetricom driver and VME timing module agree on the wrong day).

So maybe our GPS receiver is busted?  Not sure what to try now.

 

  12165   Fri Jun 10 09:52:51 2016 SteveUpdateSUS EQ 5.2 mag Borego Spring

EQ  5.2 mag at Jun 10, 8:04 am UTC, Borego Spring, CA  ~150 mi away.........no obvoius damage, damping restored, MC is locking, arms are flashing

 

  12164   Thu Jun 9 19:08:58 2016 VarunUpdateElectronicsAnti-Aliasing Filter update

Eric gave me a psd plot of a signal which would be the input of a channel of the AA filter. the Nyquist freq. is about 32.8kHz.

Following are plots depicting the ratio of the aliased downconverted signal and the signal below 32.8 kHz. The first plot is for (to-be) aliased signal frequencies from 32.8 to 65.5k, and the second plot is for (to-be) aliased signals from 65.5k to 98.3k. In case of the first plot, the 36kHz peak will alias to 29kHz, and is about 30 times (29.5dB) greater than the signal there. Hence, the filter should give about 70dB attenuation there. Since this attenuation is not required by most other frequencies up to 65.5k, an option could be to use a notch filter to remove the frequency peak at 36k, and put a requirement of 45-50 dB attenuation on other frequencies.

In case of the second plot, the frequencies between 90 to 100k again need to be attenuated by more than 70 dB. However, if there is a -20dB/decade slope in stop band, we already have about 10 dB attenuation here as compared to around 32k.

The X axis of both plots is in Hz.

  12163   Thu Jun 9 18:54:40 2016 AakashUpdateGeneralAbout Acromag | SURF 2016

Today I tried to setup Acromag Busworks card. I was able to calibrate and test it over USB but I couldn't test it over ethernet. I'll utilize a few hours tomorrow to test it over ethernet and see if I can make it work. I have also found a few RTDs which I want to use for temperature sensing via four probe method. So, tomorrow I'll get these RTD details revived by Gautam and Steve.

I was wondering if we have a basic DAQ card with maybe 4 channels which is simple to setup like NI DAQ cards.

  12162   Thu Jun 9 15:14:46 2016 jamieUpdateCDSold fb restarted, test of new daqdon fb1 aborted for time being

I've restarted the old daqd on fb until I can figure out what's going on with the symmetricom driver on fb1.

Steve:  Jamie with hair.... long time ago
 

  12161   Thu Jun 9 13:28:07 2016 jamieConfigurationCDSSpectracom IRIG-B card installed on fb1

Something is wrong with the timing we're getting out of the symmetricom driver, associated with the new spectracom card.

controls@fb1:~/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom 127$ lalapps_tconvert 
1149538884
controls@fb1:~/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom 0$ cat /proc/gps 
704637380.00
controls@fb1:~/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom 0$ 

The GPS time is way off, and it's counting up at something like 900 seconds/second.  Something is misconfigured, but I haven't figured out what yet.

The timing distribution module we're using is spitting out what appears to be an IRIG B122 signal (amplitude moduled 1 kHz carrier), which I think is what we expect.  This is being fed into the "AM IRIG input" connector on the card.

Not sure why the driver is spinning so fast, though, with the wrong baseline time.  Reboot of the machine didn't help.

  12160   Thu Jun 9 09:57:06 2016 AakashUpdateGeneralSeismometer Enclosure Development
Me and Gautam yesterday opened the tilt-free seismometer enclosure to see if we could use the thermocouples and
other things previously used by Megan. But we are planning to get new four-wire RTDs for our work.
For the next day or two, I will be trying to set up Acromag Busworks terminal so that the data logging during
this enclosure development experiment becomes perfect and easy. Johannes has sent me the wiki page URL for the same.
  12159   Wed Jun 8 16:12:38 2016 VarunUpdateGeneralDAFI update

Summary: I am implementing digital audio filtering on various interferometer signals in order to listen to the processed audio which will help in characterizing and noise reduction in the interferometer. Following is an implementation of an Automatic Gain control (AGC) block on an LSC input signal.

Details of AGC: Currently, the AGC code implemented on FE takes input to fill a frame, then calculates the power in each frame and gives an appropriate gain to it, so that the new power content is to the required level. It is then written to the output, frame by frame. The frame is currently a rectangular window. The frame length and hop size can be adjusted. Current values are as follows:

frame length is 512 samples

hop length is 128 samples.

The input and output are delayed by 1 frame.

Details of testing: Attachment 1 shows a simulink diagram of the DAF system. Eric made this and I modified it later on. Testing was done using signal from the "LSC1" channel. Attachments 2 and 3 show aquired input and output of the AGC respectively. Gain of the preamp of the LSC input signal was varied over a total time span of 200 s. Each gain value was kept for a duration of about 20 seconds. The varying power levels can be seen in the input plot.

The output shows a uniform power level throughout.

 

Quote:

Tried to implement AGC on FE. Had some trouble bringing the code into the correct form. It looks okay now. However, this agc code as well as idenntity code (input = output) doesnt seem to build on the c1lsc FE. Have not tried too many debugging steps yet, will come and check the problem tomorrow. 

-Varun

Quote:

Wrote and tested a phase vocoder, with two of its applications:

1) Time scaling: This enables change of time duration without affecting the pitch.

2) Frequency warping: This changes the pitch of the sound without affecting the time duration.

1 & 2 tested offline with cavity transmission signal. 1) gives speedup of 2, and 2 gives frequency warping (pitch lowering by a factor of 2)

codes uploaded on github repo

 

 

  12158   Wed Jun 8 13:50:39 2016 jamieConfigurationCDSSpectracom IRIG-B card installed on fb1

[EDIT: corrected name of installed card]

We just installed a Spectracom TSyc-PCIe timing card on fb1.  The hope is that this will help with the GPS timeing syncronization issues we've been seeing in the new daqd on fb1, hopefully elliminating some of the potential failure channels.

The driver, called "symmetricom" in the advLigoRTS source (name of product from competing vendor), was built/installed (from DCC T1500227):

controls@fb1:~/rtscore/tests/advLigoRTS-40m 0$ cd src/drv/symmetricom/
controls@fb1:~/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom 0$ ls
Makefile  stest.c  symmetricom.c  symmetricom.h
controls@fb1:~/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom 0$ make
make -C /lib/modules/3.2.0-4-amd64/build SUBDIRS=/home/controls/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom modules
make[1]: Entering directory `/usr/src/linux-headers-3.2.0-4-amd64'
  CC [M]  /home/controls/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom/symmetricom.o
/home/controls/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom/symmetricom.c:59:9: warning: initialization from incompatible pointer type [enabled by default]
/home/controls/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom/symmetricom.c:59:9: warning: (near initialization for ‘symmetricom_fops.unlocked_ioctl’) [enabled by default]
/home/controls/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom/symmetricom.c: In function ‘get_cur_time’:
/home/controls/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom/symmetricom.c:89:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
/home/controls/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom/symmetricom.c: In function ‘symmetricom_init’:
/home/controls/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom/symmetricom.c:188:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
/home/controls/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom/symmetricom.c:222:3: warning: label ‘out_remove_proc_entry’ defined but not used [-Wunused-label]
/home/controls/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom/symmetricom.c:158:22: warning: unused variable ‘pci_io_addr’ [-Wunused-variable]
/home/controls/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom/symmetricom.c:156:6: warning: unused variable ‘i’ [-Wunused-variable]
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /home/controls/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom/symmetricom.mod.o
  LD [M]  /home/controls/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom/symmetricom.ko
make[1]: Leaving directory `/usr/src/linux-headers-3.2.0-4-amd64'
controls@fb1:~/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom 0$ sudo make install
#remove all old versions of the driver
find /lib/modules/3.2.0-4-amd64 -name symmetricom.ko -exec rm -f {} \; || true
find /lib/modules/3.2.0-4-amd64 -name symmetricom.ko.gz -exec rm -f {} \; || true
# Install new driver
install -D -m 644 symmetricom.ko /lib/modules/3.2.0-4-amd64/extra/symmetricom.ko
/sbin/depmod -a || true
/sbin/modprobe symmetricom
if [ -e /dev/symmetricom ] ; then \
        rm -f /dev/symmetricom ; \
    fi
mknod /dev/symmetricom c `grep symmetricom /proc/devices|awk '{print $1}'` 0
chown controls /dev/symmetricom
controls@fb1:~/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom 0$ ls /dev/symmetricom
/dev/symmetricom
controls@fb1:~/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom 0$ ls -al /dev/symmetricom
crw-r--r-- 1 controls root 250, 0 Jun  8 13:42 /dev/symmetricom
controls@fb1:~/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom 0$ 
  12157   Wed Jun 8 10:20:14 2016 SteveUpdatesafetySURF 2016 safety

Aakash Patil received 40m specific basic safety training.

Quote:
Quote:

Hello, I am Varun Kelkar. I will be working at the 40m lab as a SURF student this summer with Eric Quintero on Audio processing for real time control system signals. This week I will mostly be working on implementing basic DSP C-code offline. Currently I am trying to write a code for noise whitening.

-Varun

Varun has received 40m specific basic safety training today.

 

  12156   Wed Jun 8 08:34:55 2016 jamieUpdateCDSDAQD work ongoing

38 restarts overnight.  Problem definitely not fixed.  I'll be reverting back to old daqd and fb this morning.  Then regroup and evaluate options.

  12155   Tue Jun 7 20:49:50 2016 jamieUpdateCDSDAQD work ongoing

Summary: new daqd code running overnight test on fb1.  Stability issues persist.

The code is from Keith's "tests/advLigoRTS-40m" branch, which is a branch of the current trunk.  It's supposed to include patches to fix the crashes when multiple frame types are written to disk at the same time.  However, the issue is not fixed:

2016-06-07_20:38:55 about to write frame @ 1149392336
2016-06-07_20:38:55 Begin Full WriteFrame()
2016-06-07_20:38:57 full frame write done in 2seconds
2016-06-07_20:39:11 about to write frame @ 1149392352
2016-06-07_20:39:11 Begin Full WriteFrame()
2016-06-07_20:39:13 full frame write done in 2seconds
2016-06-07_20:39:27 about to write frame @ 1149392368
2016-06-07_20:39:27 Begin Full WriteFrame()
2016-06-07_20:39:29 full frame write done in 2seconds
2016-06-07_20:39:43 about to write second trend frame @ 1149391800
2016-06-07_20:39:43 Begin second trend WriteFrame()
2016-06-07_20:39:43 about to write frame @ 1149392384
2016-06-07_20:39:43 Begin Full WriteFrame()
2016-06-07_20:39:44 full frame write done in 1seconds
2016-06-07_20:39:59 about to write frame @ 1149392400
2016-06-07_20:40:04 Begin Full WriteFrame()
2016-06-07_20:40:04 Second trend frame write done in 21 seconds
2016-06-07_20:40:14 [Tue Jun  7 20:40:14 2016] main profiler warning: 1 empty blocks in the buffer
2016-06-07_20:40:15 [Tue Jun  7 20:40:15 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:16 [Tue Jun  7 20:40:16 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:17 [Tue Jun  7 20:40:17 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:18 [Tue Jun  7 20:40:18 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:19 [Tue Jun  7 20:40:19 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:20 [Tue Jun  7 20:40:20 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:21 [Tue Jun  7 20:40:21 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:22 [Tue Jun  7 20:40:22 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:23 [Tue Jun  7 20:40:23 2016] main profiler warning: 0 empty blocks in the buffer

This failure comes when a full frame (1149392384+16) is written to disk at the same time as a second trend (1149391800+600).  It seems like every time this happens daqd crashes.

I have seen other stability issues as well, maybe caused by mx flakiness, or some sort of GPS time synchronization issue caused by our lack of IRIG-B cards.  I'm going to look to see if I can get the GPS issue taken care of so we take that out of the picture.

For the last couple of hours I've only seen issues with the frame writing every 20 minutes, when the full and second trend frames happen to be written at the same time.  Running overnight to gather more statistics.

  12154   Tue Jun 7 18:20:18 2016 VarunUpdateGeneralDAFI update

Tried to implement AGC on FE. Had some trouble bringing the code into the correct form. It looks okay now. However, this agc code as well as idenntity code (input = output) doesnt seem to build on the c1lsc FE. Have not tried too many debugging steps yet, will come and check the problem tomorrow. 

-Varun

Quote:

Wrote and tested a phase vocoder, with two of its applications:

1) Time scaling: This enables change of time duration without affecting the pitch.

2) Frequency warping: This changes the pitch of the sound without affecting the time duration.

1 & 2 tested offline with cavity transmission signal. 1) gives speedup of 2, and 2 gives frequency warping (pitch lowering by a factor of 2)

codes uploaded on github repo

 

  12153   Tue Jun 7 17:21:13 2016 AakashUpdateGeneralSURF 2016

Hi!

I am Aakash Patil. I will be working at the 40m lab as a SURF student with Gautam Venugopalan on enclosures for seismometers to shield them from thermal and magnetic fluctuations. This week I will be working on the development of hardware for four probe measurement along with a constant current source. It will effectively help us in accurate temperature measurement throughout the development of enclosure.

 

  12152   Tue Jun 7 11:12:47 2016 jamieUpdateCDSDAQD UPGRADE WORK UNDERWAY

I am re-starting work on the daqd upgrade again now.  Expect the daqd to be offline for most of the day.  I will report progress.

  12151   Mon Jun 6 16:41:36 2016 ericqUpdateCDSFB upgrade work

Barring objections, starting tomorrow morning, Jamie will be testing the new FB code. The IFO will not be available for other use while this is ongoing.

  12150   Fri Jun 3 17:56:14 2016 VarunUpdateGeneralDAFI update

Wrote and tested a phase vocoder, with two of its applications:

1) Time scaling: This enables change of time duration without affecting the pitch.

2) Frequency warping: This changes the pitch of the sound without affecting the time duration.

1 & 2 tested offline with cavity transmission signal. 1) gives speedup of 2, and 2 gives frequency warping (pitch lowering by a factor of 2)

codes uploaded on github repo

  12149   Fri Jun 3 14:24:13 2016 SteveUpdateSUSlocal EQ 3.1 m

Local EQ 3.1 mag at Jun 2, 2016 11:06:16 PM UTC, Muscoy CA........no damage

Our STS should seen this shake.

 

  12148   Fri Jun 3 13:05:18 2016 ericqUpdateCDSCDS Notes

Some CDS related things:


Keith Thorne has told us about a potential fix for our framebuilder woes. Jamie is going to be at the 40m next week to implement this, which could interfere with normal interferometer operation - so plan accordingly. 


I spent a little time doing some plumbing in the realtime models for Varun's audio processing work. Specifically, I tried to spin up a new model (C1DAF), running on the c1lsc machine. This included:

  • Removing the unused TT3 and TT4 parts from the IOO block in c1ass.mdl, freeing up some DAC outputs on the LSC rack
  • Adding an output row to the LSC input matrix which pipes to a shared memory IPC block. (This seemed like the simplest way for the DAFI model to have access to lots of signals with minimal overhead).
  • Removing two unused ADC inputs from c1lsc.mdl (that went to things like PD_XXX), to give c1daf.mdl the required two ADC inputs - and to give us the option of feeding in some analog signals.
  • Editing the rtsystab file to include c1daf in the list of models that run on c1lsc
  • Editing the existing DAFI .mdl file (which just looked like an old recolored cut-n-paste of c1ioo.mdl) to accept the IPC and ADC connections, and one DAC output that would go to the fibox. 

The simple DAFI model compiled and installed without complaint, but doesn't succesfully start. For some reason, the frontend never takes the CPU offline. Jamie will help with this next week. Since things aren't working, these changes have not been commited to the userapps svn. 

  12147   Fri Jun 3 12:53:44 2016 ericqUpdateElectronicsCommon board Op amp input offsets

I replaced some of the AD829s with other AD829s, but the offset situation didn't improve.

However, I figured that we don't really need the ~100MHZ bandwidth of the AD829, since the IMC loop limits us to a ~10kHz CARM bandwidth. Also, since we don't routinely use IN2 for anything, I felt free to try something else. 

Specifically, I replaced all of the positive gain AD829s in the input 2 gain ladder with OP27s (U8B->U12B on D1500308), which should have input offset voltages ~30x lower than the AD829s. 

Here is a comparison of the outputs these configurations perform, normalized to the output at the +0dB gain setting - where all of the op amps in the gain ladder are bypassed. 

So, most of the transitions now result in an output offset change of less than 0.5mV, which is nice.

The exception seems to be where the +8dB stage is switched in or out. I may try replacing this one, as these transitions cause a lock loss now when trying to lock the arm with high bandwidth using POY.

  12146   Thu Jun 2 16:35:44 2016 KojiUpdateSUS wire standoffs update

Gap of the prism from the mirror

Sag: s = R(1-Cos[ArcSin[d/2/R]])

- Mirror curvature sag for 2mm prism (R=37.75mm): s=13um

- Minimum gap: 20um => s=33um => R=15mm

- Nominal gap: 35um => s=48um => R=10mm

- Maximum gap: 50um => s=63um => R=8mm


The second figure shows somewhat realistic arrangement of the pieces

  12145   Wed Jun 1 16:28:28 2016 ericqUpdateElectronicsCommon board Op amp input offsets

I used a Eurocard extension board to peek at the inputs and outputs of each of the gain-ladder AD829s on input B of the CM board in the +31dB configuration with the input terminated. (i.e with the following stages active in this order: +16dB, +8dB, +4dB, +2dB, +1dB).

The voltages I observed imply that the +8dB stage has an input voltage offset of -2mV, whereas all the other positive gain stages show around +-0.5mV. This could explain the shift observed at the +15->+16 transition. (However, since both input channels show a jump here, maybe its something more systemic about the board...)

In any case, it should be simple enough to swap out a new AD829 in place of U9B and see if it improves things, before getting too deep into the muck. (In principle, the AD829 has offset nulling pins, but I'm not sure how to do it in a non-hacky way since the board doesn't have any pads for it.)

  12144   Wed Jun 1 15:01:56 2016 SteveUpdateSUS wire standoffs update

There are some issues with 5 mm sapphire prism Atm5. It will cause  interference between one of the prisms and the Side OSEM.

Here are some drawings to see the issues with larger wire standoff.

The 2 mm prism will work.with a 1 mm longer dumbell.

Quotes requested from http://photomachining.com/laser-micromachining-photomachining-contact.html and http://www.optocity.com/ 

 

 

  12143   Wed Jun 1 11:19:14 2016 VarunUpdateGeneralUpdate of work till now

Completed:

Wrote and tested a code for AGC using cavity transmission signal and length error signal.

Wrote and tested a code for frequency shifting (downconversion) using mixing and LPF

Wrote a code for whitening using FFT.

Altium working on cit40m iMac

Plans:

Writing codes for Frequency warping and whitening in time domain.

Implement AGC and frequency shifting on the real time control system.

Calculate requirements for Anti-aliasing filter.

  12142   Wed Jun 1 09:06:38 2016 SteveUpdateLSCNew stands for TransMon/Oplev QPDs

Machined from I-beam 6061 T6 Aluminum 5" x 0.5 x 3.25

Quote:

As we realized during the EX table switch, the transmitted beam height from the arm is not exactly 4" relative to the endtable, it is more like 4.75" at the X-end (yet to be investigated at the Y-end). As a result, the present configuration involves the steering optics immediately before the Oplev and TransMon QPDs sending the beam downwards at about 5 degrees. Although this isn't an extremely large angle, we would like to have things more level. For this purpose, Steve has ordered some Aluminium I-beams (1/2 " thick) which we can cut to size as we require. The idea is to have the QPD enclosures mounted on these beams and then clamped to the table. One concern was electrical isolation - but Steve thinks Delrin washers between the QPD enclosure and the mount will suffice. We will move ahead with getting these machined once I investigate the situation at the Y end as well.. The I beams should be here sometime next week...

Atm2, version 2 "pdstand" will allow you to clamp from any direction ( Koji was right )

  12141   Tue May 31 16:52:58 2016 SteveUpdatesafetyNONO

Please do not place anything on the top of the cabinets that is not tied down. It will end up on our head in an earth quake.

 

  12140   Mon May 30 18:19:50 2016 JohannesUpdateCDSASS medm screen update

I noticed that the TRY button in the ASS main screen was linking to LSC_TRX instead of LSC_TRY. Gautam fixed it.

  12139   Fri May 27 11:54:22 2016 VarunUpdateGeneralPackage delivery

A package labelled 'UPS Ground' has arrived.

-Varun

  12138   Fri May 27 02:52:53 2016 ericqUpdateLSCRestoring high BW single arm control

I've been futzing with the common mode servo, trying to engage the AO path with POY for high bandwidth control of a single arm lock. I'm able to pull in the crossover and get a nice loop shape, but keep getting tripped up by the offset glitches from the CM board gain steps, so can't get much more than a 1kHz UGF.

As yutaro measured, these can be especially nasty at the major carrier transitions (i.e. something like 0111->1000). This happens at the +15->+16dB input gain step; the offset step is ~200x larger than the in-loop error signal RMS, so obviously there is no hope of keeping the loop engaged when recieving this kind of kick. Neither of the CM board inputs are immune from this, as I have empirically discovered. I can turn down the initial input gain to try and avoid this step occuring anywhere in the sequence, but then the SNR at high frequencies get terrible and I inject all kinds of crud into the mode cleaner, making the PC drive furious.

I think we're able to escape this when locking the full IFO because the voltages coming out of REFL11 are so much larger than the puny POY signals so the input-referred glitches aren't as bad. I think in the past, we used AS55 with a misaligned ITMX for this kind of single arm thing, which probably gives better SNR, but the whole point of this is to keep the X arm aligned and lock it to the Y-arm stabilized PSL. 

  12137   Thu May 26 18:10:48 2016 VarunUpdateGeneralSURF 2016

Wrote and tested a function for downconversion. It contains a mixer with a sinusoidal input for modulation with the desired frequency and a 2nd order butterworth low pass filter to remove the higher frequency-shifted part of the modulated signal. I have tested this with input of 2kHz giving a good output of 200 Hz on the speaker. Codes are uploaded on github, will update the real time document tomorrow.

 

-Varun

Quote:

Edited the AGC to include overlapping frames yesterday. forgot to put an elog on it!

Quote:

Tested the AGC today with LSC cavity transmission signal and error signal. Not in real time still.

Key to attachments:

cav_tr-eps-converted-to.pdf: LSC cavity transmission signal input

cav_tr_out-eps-converted-to.pdf: LSC cavity transmission signal, output of the AGC.

 

 

  12136   Wed May 25 14:29:31 2016 VarunUpdateGeneralSURF 2016

Edited the AGC to include overlapping frames yesterday. forgot to put an elog on it!

Quote:

Tested the AGC today with LSC cavity transmission signal and error signal. Not in real time still.

Key to attachments:

cav_tr-eps-converted-to.pdf: LSC cavity transmission signal input

cav_tr_out-eps-converted-to.pdf: LSC cavity transmission signal, output of the AGC.

 

  12135   Wed May 25 14:21:29 2016 Max IsiUpdateGeneralSummary page configuration

I have modified the c1summary.ini and c1lsc.ini configuration files slightly to avoid overloading the system and remove the errors that were preventing plots from being updated after certain time in the day.

The changes made are the following:
1- all high-resolution spectra from the Summary and LSC tabs are now computed for each state (X-arm locked, Y-arm locked, IFO locked, all);
2- I've removed MICH, PRCL & SRCL from the summary spectrum (those can still be found in the LSC tab);
3- I've split LSC into two subtabs.

The reason for these changes is that having high resolution (raw channels, 16kHz) spectra for multiple (>3) channels on a single tab requires a *lot* of memory to process. As a result, those jobs were failing in a way that blocked the queue, so even other "healthy" tabs could not be updated.

My changes, reflected from May 25 on, should hopefully fix this. As always, feel free to re organize the ini files to make the pages more useful to you, but keep in mind that we cannot support multiple high resolution spectra on a single tab, as explained above.

  12134   Wed May 25 11:51:40 2016 SteveUpdatesafetySURF 2016 safety
Quote:

Hello, I am Varun Kelkar. I will be working at the 40m lab as a SURF student this summer with Eric Quintero on Audio processing for real time control system signals. This week I will mostly be working on implementing basic DSP C-code offline. Currently I am trying to write a code for noise whitening.

-Varun

Varun has received 40m specific basic safety training today.

  12133   Wed May 25 08:32:55 2016 SteveUpdateSUSlocal EQ 3.5m

Local EQ 3.5 mag  at 2:28 UTC May 24, 2016 Rancho Cucamonga, Ca.....no damage

 

  12132   Wed May 25 02:54:09 2016 ericqUpdateGeneralOdds and ends

WFS locking point seemed degraded; I hand aligned and reset the WFS offsets as usual.

ITMX oplev recentered. While doing so, I noticed an ETMX excursion rear its head for the first time in a long while :crying

There was no active length control on ETMX, only OSEM damping + oplevs. Afterwards, its still moving around with only local damping on. I'm leaving the oplevs off for now.

  12131   Tue May 24 23:17:37 2016 ericqUpdateCOCFinesse modelling - mode overlap scans

I think you should use the current actual PRC & SRC cavity lengths as measured, as it would be simplest to simply replace the folding mirror optics without changing the macroscopic lengths / optic positions. (EDIT: Gautam rightly points out that we have to move things around regardless, since our current lengths include propagation through the folding mirror subtrates)

Moreover, the recycling cavity lengths you posted are not the right "ideal" lengths to use, as they do not account for the complex reflectivities of the sidebands off of the arm cavities (I have made this mistake myself). See this 40m wiki page for details.

In short, given our current modulation frequency, the ideal lengths to use would be:

  • Ideal arm length of 37.795 m
  • Ideal PRC length of 6.753 m
  • Ideal SRC length of 5.399 m

These are the lengths that the recycling cavity optics were positioned for (though we did not achieve them perfectly). If you do a finer PRC/SRC length scan around the DRFPMI resonance of your model, you would presumably see some undesired sideband splitting. 

  12130   Tue May 24 22:49:02 2016 gautamUpdateCOCFinesse modelling - mode overlap scans

Summary:

Having played around with a toy finesse model, I went about setting up a model in which the RC folding mirrors are not flipped. I then repeated the low-level tests detailed in the earlier elog, after which I ran a few spatial mode overlap analyses, the results of which are presented here. It remains to do a stability analysis.

Overview of model parameters (more details to follow):

  • PRC length = 6.7727m (chosen using l_{PRC} = (N+\frac{1}{2})\frac{c}{2f_1}, N=0 - I adjusted the position of the PRM to realize this length in the model, while leaving all the other vertex optics in the same positions as in elog 9590
  • SRC length = 5.4182 (chosen using l_{SRC} = M\frac{c}{2f_2} but not l_{SRC} = N\frac{c}{2f_1}, M and N being integers, for M=2 - as above, I adjusted the position of the SRM to realize this in the model, while leaving all other vertex optics in the same positions as in elog 9590. It remains to be verified if it is physically possible to realize these dimensions in vacuum without any beam clipping etc but I think it should be possible seeing as the PRM and SRM had to be moved by less than 2cm from their current positions..
  • For the losses, I used the most recent numbers we have where applicable, and put in generic 25ppm loss for all the folding mirrors/BS/AR surfaces of arm cavity mirrors/PRM/SRM. Arm round trip loss was equally distributed between ITMs and ETMs
  • Arm lengths used: L_X = 37.79m, L_Y = 37.81m
  • To set the "tunings" of the various mirrors, I played around with a few configurations to see where the various fields resonated - it turns out that for PRM, ITMX, ITMY, ETMX and ETMY, the "phase" in the .kat file can be set as 0. while that for the SRM can be set as 90. In the full L1/H1 interferometer .kat files, these are tuned even further to the (tenth?!) decimal place, but I think these values suffice for out purposes.

Results (general note: positive RoC in these plots mean a concave surface as seen by the beam):

  • Attachments #1, #2 and #3 reproduce the low-level tests performed earlier for this updated model - i.e. I look at the arm transmission with no PRM/SRM, circulating PRC power with no ETMs, and circulating SRC power with no ETMs. Everything looks consistent here... In Attachment #2, there is no legend, but the (almost overlapping) red and green lines are meant to denote the +f1 and +f2 sidebands.
  • Attachments #4 and #5 are a summary of the mode-overlap scans for the PRC and SRC. What I did was to vary the radius of curvature of the RC mirrors (finesse only allows you to vary Rcx and Rcy, so I varied both simultaneously) and calculate the mode overlap between the appropriate pairs of cavities (e.g. PRX and XARM) in the tangential and saggital planes. The take-away here is that there is ~5% mode-mismatch going from an RoC of 1000m to 300m. I've also indicated the sag corresponding to a given RoC - these are pretty tiny, I wonder if it is possible to realize a sag of 1um? I suppose it is given that I've regularly seen specs of surface roughness of lambda/10?
  • Attachment #6 shows the PRC gain (calculated as T_PRC * (transmitted arm power with PRM / transmitted arm power without PRM) as a function of the RoC of PR2 and PR3. As a sanity check, I repeated this calculation with lossless HR surfaces (but with nominal 25ppm losses for AR surfaces of ITMs, and BS etc), shown in Attachment #7. I think these make sense too...
  • Attachment #8 - in order to investigate possible mode mismatch between the arm modes due to different radii of curvature of the ETMs, I kept the ETMY RoC fixed at 57.6m and varied the ETMY RoC between 50m and 70m (here, I've plotted the mode matching efficiency as a function of the RoC of the ETM in the X and Y directions separately - the mode overlap is computed as \frac{1}{\sqrt{2}}(x^2 + y^2) where x and y denote the overlap in the tangential and saggital planes respectively. It would seem that we only lose at most a couple of percent even if the RoCs are mismatched by up to 10m...
  • Attachment #9 - .kat file and the various pykat scripts used to generate these plots...

Next step is to carry out a stability analysis...

  12129   Tue May 24 17:55:17 2016 VarunUpdateElectronicsUsing Altium

Contacted Charles regarding use of Altium. Got to know that Altium is installed on cit40m iMac in Win7 on VirtualBox. Had to update Virtualbox to get it working. Altium now works for sometime, but then fails, saying that it is unlicensed.

  12128   Tue May 24 10:21:36 2016 ericqSummarySUSITMX Oplev loops

I did a quick measurement of the ITMX oplev loops, both pitch and yaw have about the same upper UGF as previous measurements with the previous laser; about 4 Hz. 

  12127   Mon May 23 17:47:51 2016 VarunUpdateGeneralSURF 2016

Tested the AGC today with LSC cavity transmission signal and error signal. Not in real time still.

Key to attachments:

cav_tr-eps-converted-to.pdf: LSC cavity transmission signal input

cav_tr_out-eps-converted-to.pdf: LSC cavity transmission signal, output of the AGC.

  12126   Mon May 23 15:51:32 2016 steveSummarySUSoplev laser summary updated

 

Quote:

 

Quote:

 

Quote:

 

                  2005              ALL oplev servos use Coherent DIODE LASERS # 31-0425-000, 670 nm, 1 mW

    Sep. 28, 2006              optical lever noise budget with DC readout in 40m,  LIGO- T060234-00-R, Reinecke & Rana

    May  22, 2007              BS, SRM & PRM  He Ne 1103P takes over from diode

    May  29, 2007              low RIN He Ne JDSU 1103P selected, 5 purchased sn: T8078254, T8078256, T8078257, T8078258 & T8077178 in Sep. 2007

    Nov  30, 2007               Uniphase 1103P divergence measured

    Nov. 30, 2007               ETMX old Uniphase 1103P  from 2002 dies: .............., running time not known......~3-5 years?

    May 19, 2008               ETMY old Uniphase 1103P from 1999 dies;.....................running time not known.....~    ?

    Oct.  2, 2008                ITMX & ITMY are still diodes, meaning others are converted to 1103P earlier

 

                     JDSU 1103P were replaced as follows:

   May 11, 2011                ETMX replaced, life time 1,258 days  or 3.4 years

   May 13, 2014               ETMX , LT 1,098 days or 3 y

   May 22, 2012               ETMY,  LT 1,464 days or  4 y

   Oct.  5, 2011                BS & PRM, LT 4 years,  laser in place at 1,037 days or 2.8 y

   Sep. 13, 2011               ITMY  old 1103P &    SRM    diode laser replaced by 1125P  ..........old He life time is not known, 1125P in place 1,059 days or 2.9 y

   June 26, 2013              ITMX 622 days or 1.7 y    note: we changed because of beam quality.........................laser in place 420 days or 1.2 y

 

  Sep. 27, 2013               purchased 3 JDSU 1103P lasers, sn: P893516, P893518, P893519 ......2 spares ( also 2 spares of 1125P of 5 mW & larger body )

 

      May  13, 2014             ETMX,  .............laser in place 90 d

      May  22, 2012             ETMY, 

     Oct.  7,  2013             ETMY,  LT  503 d  or  1.4 y............bad beam quality ?

     Aug. 8,  2014              ETMY,  .............laser in place   425 days  or  1.2 y

 

      Sept. 5, 2014              new 1103P, sn P893516  installed at SP table for aLIGO oplev use qualification

     

           May 23, 2016             ITMX dead laser sn P845648 replaced after 1062 days [2.9 yrs] by 1103P, sn P859884, with output output  2.6 mW, nicely round beam quality at 15 meters.

  12125   Mon May 23 10:55:49 2016 steveSummarySUSITMX oplev laser replaced

 

      May 23, 2016             ITMX dead He/Ne laser sn P845648 replaced after 1062 days [2.9 yrs] by 1103P, sn P859884, with output  2.6 mW, nicely round beam quality at 15 meters.

                                                                                                                                                    Power just before viewport 1 mW,  returning light on qpd 154 microW =  7,500 counts

 

  12124   Fri May 20 17:36:06 2016 gautamUpdateLSCNew stands for TransMon/Oplev QPDs

As we realized during the EX table switch, the transmitted beam height from the arm is not exactly 4" relative to the endtable, it is more like 4.75" at the X-end (yet to be investigated at the Y-end). As a result, the present configuration involves the steering optics immediately before the Oplev and TransMon QPDs sending the beam downwards at about 5 degrees. Although this isn't an extremely large angle, we would like to have things more level. For this purpose, Steve has ordered some Aluminium I-beams (1/2 " thick) which we can cut to size as we require. The idea is to have the QPD enclosures mounted on these beams and then clamped to the table. One concern was electrical isolation - but Steve thinks Delrin washers between the QPD enclosure and the mount will suffice. We will move ahead with getting these machined once I investigate the situation at the Y end as well.. The I beams should be here sometime next week...

  12123   Fri May 20 00:06:19 2016 VarunUpdateGeneralSURF 2016

I have written a basic version of AGC, and have done some tests with a data file. will do tests on whitening and agc today. Also, today I have to go to the SSN office. Hence will be late.

 

-Varun

Quote:

Finished writing the code on whitening. I have to still test it. uploaded on github noise cancellation repo. @eric could you give me some data of noise power spectral density for testing the code?

-Varun

Quote:

Hello, I am Varun Kelkar. I will be working at the 40m lab as a SURF student this summer with Eric Quintero on Audio processing for real time control system signals. This week I will mostly be working on implementing basic DSP C-code offline. Currently I am trying to write a code for noise whitening.

-Varun

 

 

  12122   Thu May 19 16:29:20 2016 SteveUpdateendtable upgradeOptical layout almost complete

 

 

  12121   Wed May 18 17:42:52 2016 VarunUpdateGeneralSURF 2016

Finished writing the code on whitening. I have to still test it. uploaded on github noise cancellation repo. @eric could you give me some data of noise power spectral density for testing the code?

-Varun

Quote:

Hello, I am Varun Kelkar. I will be working at the 40m lab as a SURF student this summer with Eric Quintero on Audio processing for real time control system signals. This week I will mostly be working on implementing basic DSP C-code offline. Currently I am trying to write a code for noise whitening.

-Varun

 

  12120   Wed May 18 01:10:22 2016 gautamUpdateCOCFinesse modelling

I've been working on putting together a Finesse model for the current 40m configuration. The idea was to see if I could reproduce a model that is in agreement with what we have been seeing during the recent DRFPMI locks. With Antonio and EricQs help, I've been making slow progress in my forays into Finesse and pyKat. Here is a summary of what I have so far.

  • Arm lengths were taken from some recent measurements done by yutaro and me 
  • Recycling cavity lengths were taken from Gabriele's elog 9590 - it is likely that the lengths I used have errors ~1cm - more on this later. Furthermore, I've tried to incorporate the flipped RC folding mirrors - the point being to see if I can recover, for example, a power recycling gain of ~7 which is what was observed for the recent DRFPMI locks.
  • I used Yutaro's most recent arm loss numbers, and distributed it equally between ITM and ETM for modeling purposes. 
  • For all other optics, I assumed a generic loss number of 25ppm for each surface

Having put together the .kat file (code attached, but this is probably useless, the new model with RC folding mirrors the right way will be what is relevant), I was able to recover a power recycling gain of ~7.5. The arm transmission at full lock also matches the expected value (125*80uW ~ 10mW) based on a recent measurement I did while putting the X endtable together. I also tuned the arm losses to see (qualitatively) that the power recycling gain tracked this curve by Yutaro. EricQ suggested I do a few more checks:

  1. Set PRM reflectivity to 0, scan ETMs and look at the transmission - attachment #1 suggests the linewidth is as we expect 
  2. Set ETM reflectivity to 0, scan PRM - attachment #2 suggests a Finesse of ~60  for the PRC which sounds about right
  3. Set ETM reflectivity to 0, scan SRM and verify that only the 55 MHz sidebands resonate - Attachment #3

Conclusion: It doesn't look like I've done anything crazy. So unless anyone thinks there are any further checks I should do on this "toy" model, I will start putting together the "correct" model - using RC folding mirrors that are oriented the right way, and using the "ideal" RC cavity lengths as detailed on this wiki page. The plan of action then is

  • Evaluating the mode-matching integrals between the PRC and the arm cavities as a function of the radius of curvature of PR2 and PR3
  • Same as above for the SRC
  • PRC gain as a function of RoC of folding mirrors
  • Mode overlap between the modes from the two arm cavities as a function of the RoC of the two ETMs (actually I guess we can fix RoC of ETMy and just vary RoC of ETMx).

Sidenote to self: It would be nice to consolidate the most recent cavity length measurements in one place sometime...

  12119   Tue May 17 14:46:51 2016 SteveUpdateVACRGA scan at day 595

We have good RGA scan now. There was no scan for 3 months.

  12118   Tue May 17 05:50:43 2016 Varun KelkarUpdateGeneralSURF 2016

Hello, I am Varun Kelkar. I will be working at the 40m lab as a SURF student this summer with Eric Quintero on Audio processing for real time control system signals. This week I will mostly be working on implementing basic DSP C-code offline. Currently I am trying to write a code for noise whitening.

-Varun

  12117   Sun May 15 19:48:08 2016 SteveUpdateVACrun out of N2

3-4 hrs ago we run out of nitrogen. We are back to Vacuum Normal

 

 

ELOG V3.1.3-