40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 88 of 330  Not logged in ELOG logo
ID Date Author Type Category Subject
  12217   Mon Jun 27 15:47:17 2016 SteveUpdateGeneralQPR clean room gloves

I got some QPR Nitrile gloves. They are LIGO approved.White nitrile gloves are naturally anti-static- 109 ohms

Their touch not as good as laytex  gloves but try to use them.

 

  12216   Mon Jun 27 15:26:03 2016 SteveOmnistructureALARMfire alarm test

The fire alarm came on around 15:05  for about 2-3 minutes. We all  left the lab and counted heads.  I called Paul Mackel x2646 (cell 626/ 890- 3259) at Fire Protection Services. He said that this alarm test was planned and we should of got an email notice. Perhaps I missed that notes.

Quote:

Fire alarm went off several minutes ago. Talked to security and they said there was no fire. It beeped twice again just now. No one has been working on the IFO today.

 

Attachment 1: fireAlarmTest.png
fireAlarmTest.png
  12215   Mon Jun 27 15:12:09 2016 varunUpdateCDSDAFI update: stereo output

Using an RC to BNC connector from the inner drawer, I have added a second output cable going from the output Fibox in the control room to the audio mixer.

Quote:

I have updated the DAFI with the following changes:

1) Separated both the channels of stereo output completely, as well as in the GUI.

2) Added text monitors for the inputs and outputs.

The stereo output is now ready except for a cable going from the second channel of the output fibox to the audio mixer.

Attached is the main DAF_OVERVIEW screen and its link button from the LSC screen labelled "DAFI"

Quote:

I wish to have stereo audio output for the DAF module. Hence, there needs to be a second output from the DAF. I added this second output to the model. Following are the details:

FiBox: It consists of two analog inputs which are digitized and multiplexed and transmitted optically. (only 1 fiber is needed due to multiplexing). Attachment 1 shows the fibox with its 2 analog inputs (one of which, is connected), and 1 fiber output. The output of the DAF goes to the FiBox. Until today, the Fibox recieved only 1 analog input. This analog signal comes from the DAC-8 (count starting from 0), which is located at "CH 1 OUT" SMA output in the "MONITORS" bin on the racks (attachment 2).

I have added another output channel to the DAF model both in software and in hardware. The DAF now also uses DAC-9 analog output which goes to the second analog input of the FiBox. The DAC-9 output is located at "CH 2 OUT" SMA output in the "MONITORS" bin on the racks (attachment 4).

After making the changes, the Fibox is shown in attacment 3.

Testing: The LSC input on passing through the DAF block is given through two different DAC outputs, to the same Fibox channel (one after the other), and the output is heard. More concrete testing will be done tomorrow. It will be as follows:

1) Currently, I need to search for a suitable cable that would connect the second channel of the output fibox to the audio mixer. After doing this, end to end testing of both channels will be done.

2) I could not access the AWG, probably because the DAQ was offline today afternoon. Using a signal from the AWG will give a more concrete testing of the stereo output.

3) After this, I will separate the two channels of the stereo completely (currectly they are seperated only at the DAF output stage)

4) I also will edit the medm gui appropriately.

 

Quote:

I have added Enable buttons for each of the DSP blocks, and labels for the matrix elements. The input matrix takes inputs from each of the 4 channels: ADC1, ADC2, LSC and EXC, and routes them to the audio processing blocks (attachment 2). The output matrix (attachment 3) takes the outputs of the various DSP blocks and routes them to the output and then to the speakers. 

 

 

 

Attachment 1: IMG_20160627_151753247.jpg
IMG_20160627_151753247.jpg
  12214   Sun Jun 26 15:27:28 2016 ranaFrogsIOOPMC /MC lopced

Found PMC unlocked for many hours so I relocked it. IMC relocked by itself, but the input switch seems to be flickering to fast. Also the Keep Alive bit is not flashing. no

  12213   Thu Jun 23 17:24:32 2016 ericqUpdateGeneralTweaks

I spent some time this afternoon reviving some of my CESAR/ESCOBAR shenanigans on the Y arm. I found it neccesary to adjust a few things.

  • PMC realigned 
  • ETMY oplev centered
  • Y End green realigned
  • PSL/Y Green beat realigned

Afterwards, ALSY noise levels were good. 

  12212   Wed Jun 22 14:03:42 2016 VarunUpdateElectronicsAnti-Aliasing Filter circuit schematic

I found an anti-aliasing circuit on the 40m wiki. It consists of A differential LPF made using THS4131 low noise differential op-amp (one of the main applications of which is preprocessing before the ADC), and a notch. I modified it to arrange for the desired bandwidth (about 8 kHz) and notch after the Nyquist frequency at 36 kHz. I simulated it to get the attached results:

Attachment 1: It shows the input PSD (same as the one posted in the previous elog), the filter transfer function, and The resulting output.

Attachment 2: The circuit schematic. The initial part using THS4131 is a differential LPF and the subsequent RC network is the notch.

Attachment 3: This shows the ratio of the aliased downconverted signal to the the in-band signal, representative of the contamination in each bin. Here too, the aliased signals are negligible as compared to the low frequencies but they are not negligible as compared to the higher frequencies (above 10 kHz) into which they would get downconverted due to sampling. However, here, the attenuation at 8kHz is less than 6 dB while in the previous circuit, it was about 12 dB. One problem with this circuit is at about 6kHz, there is aliased signal from the 65k to 98kHz band, but this can be taken care of by adding an LPF later.

Quote:

Summary: The aim is to design an analog anti-aliasing (AA) filter placed before the ADC, whose function is to filter out components of the input spectrum that have frequencies higher than the Nyquist frequency. This needs to be done so that there is no contamination of aliased downconverted high-frequency signals into the ADC output. I have put down and simulated a circuit to do this, based on the spectra of a few interferometer signals that eric Provided. Attachment 1 shows such an input PSD, treated with whitening filter, before the AA. The sampling rate is 65536 Hz and hence the Nyquist freq. is 32768 Hz.

Motivation: Attachments 2 and 3 show the plot of required attenuation for various frequencies above the Nyquist. We can see a peak at 36 kHz, which will alias to about 29kHz. It will require about 70 dB attenuation here. This indicates that use of a notch filter combined with a low pass filter can be used.

Details of Schematic: Attachment 4 shows the schematic of a Boctor low pass notch filter, cascaded by a 2nd order LPF. The stopband frequency of the boctor filter can be tuned to around 36 kHz. Its main advantage for the boctor is better insensitivity to component value tolerances, use of a single op amp, and relatively independent tuning of parameters.  The various component values are calculated from here. The transfer functions for the circuit shown in attachment 4 were simulated using TINA - a spice based simulation software. The transfer function is shown in attachment 5.

A few more calculations: Attachment 6 shows the output psd after the signal has been treated with AA. Attachments 7 and 8 show the ratio of aliased downconverted signal and the unaliased signal of the output. Here, we can see that above about 13 kHz, the ratios go above -40dB, which is apparently undesirable. However, we also see from the transfer function of the filter that the gain falls to less than -20dB after about this frequency, and the aliased signals are atleast 20 dB lower than this, atleast upto about 29 kHz in attachment 7 and about 25 kHz in attachment 8. This means that the aliased signals are negligible as compared to the low frequencies even if they are not negligible as compared to the higher frequencies (above 13 kHz) into which they would get downconverted due to sampling. But these higher frequencies (above 13 kHz) themselves are small.

The filter overall, is 4th order. Considering this and the above discussion, I need to decide what changes to make in the existing schematic. For now, I could discuss with eric to finalize the opamp and start building the pcb board design.

 

Attachment 1: io.pdf
io.pdf
Attachment 2: AA.JPG
AA.JPG
Attachment 3: ratios_v2.pdf
ratios_v2.pdf
  12211   Wed Jun 22 10:15:45 2016 varunUpdateCDSDAFI update: stereo output

I have updated the DAFI with the following changes:

1) Separated both the channels of stereo output completely, as well as in the GUI.

2) Added text monitors for the inputs and outputs.

The stereo output is now ready except for a cable going from the second channel of the output fibox to the audio mixer.

Attached is the main DAF_OVERVIEW screen and its link button from the LSC screen labelled "DAFI"

Quote:

I wish to have stereo audio output for the DAF module. Hence, there needs to be a second output from the DAF. I added this second output to the model. Following are the details:

FiBox: It consists of two analog inputs which are digitized and multiplexed and transmitted optically. (only 1 fiber is needed due to multiplexing). Attachment 1 shows the fibox with its 2 analog inputs (one of which, is connected), and 1 fiber output. The output of the DAF goes to the FiBox. Until today, the Fibox recieved only 1 analog input. This analog signal comes from the DAC-8 (count starting from 0), which is located at "CH 1 OUT" SMA output in the "MONITORS" bin on the racks (attachment 2).

I have added another output channel to the DAF model both in software and in hardware. The DAF now also uses DAC-9 analog output which goes to the second analog input of the FiBox. The DAC-9 output is located at "CH 2 OUT" SMA output in the "MONITORS" bin on the racks (attachment 4).

After making the changes, the Fibox is shown in attacment 3.

Testing: The LSC input on passing through the DAF block is given through two different DAC outputs, to the same Fibox channel (one after the other), and the output is heard. More concrete testing will be done tomorrow. It will be as follows:

1) Currently, I need to search for a suitable cable that would connect the second channel of the output fibox to the audio mixer. After doing this, end to end testing of both channels will be done.

2) I could not access the AWG, probably because the DAQ was offline today afternoon. Using a signal from the AWG will give a more concrete testing of the stereo output.

3) After this, I will separate the two channels of the stereo completely (currectly they are seperated only at the DAF output stage)

4) I also will edit the medm gui appropriately.

 

Quote:

I have added Enable buttons for each of the DSP blocks, and labels for the matrix elements. The input matrix takes inputs from each of the 4 channels: ADC1, ADC2, LSC and EXC, and routes them to the audio processing blocks (attachment 2). The output matrix (attachment 3) takes the outputs of the various DSP blocks and routes them to the output and then to the speakers. 

 

 

Attachment 1: C1DAF_OVERVIEW.png
C1DAF_OVERVIEW.png
Attachment 2: DAF_link_from_LSC.png
DAF_link_from_LSC.png
  12210   Wed Jun 22 08:40:42 2016 ranaUpdateLSCY arm @ 30kHz UGF w/POY, AO

Below 100 Hz, I suppose this means that the X arm is now limited by the quadrature sum of the X and Y arm seismic noise.

  12209   Tue Jun 21 14:12:10 2016 SteveUpdatePEM vacuum envelope wiped

I wiped down the cranes with wet towel and Mario our janitor did the chamber tops with the tubes.

The optical tabels were not touched.

The outside temp peaked at 44 C yesterday

 

Attachment 1: 60dPEM.png
60dPEM.png
  12208   Tue Jun 21 11:49:29 2016 ericqFrogsCDSmedm command not working

The workstations' .bashrc is a symbolic link to /users/controls/.bashrc

In it, someone commented out the critical line:

#source /ligo/cdscfg/workstationrc.sh

I uncommented it. medm (and all of the other things like cdsutils) work again.

I blame jamie.

  12207   Tue Jun 21 11:26:42 2016 varunFrogsCDSmedm command not working

"medm: command not found" error when run through command line both in pianosa and rossa in both editing and execution modes. It however gets executed and edited through the sitemap button. Don't know the source of the problem. Gautam did check the .bashrc file. aliases for SITEMAP and m40m are intact in the .bashrc file.

  12205   Tue Jun 21 04:01:09 2016 ericqUpdateLSCY arm @ 30kHz UGF w/POY, AO

With the newly amplified POY signal, locking the mode cleaner to the Y arm at ~30kHz bandwidth was quite straightforward. The offset jumps still happen, and are visible in POY11_I_ERR, but are never big enough to cause much power degradation in TRY (except when turning on CM board boosts, but its still not enough to lose lock). The script which accomplishes this is at scripts/YARM, and is in the svn. The MC2/AO crossover is at about 150Hz with 40deg margin.

For now, I'm using IN1 of the CM board, because I haven't removed the op27s that I put into IN2's gain stages. I believe the slew rate limitations of these prevent them from working completely during the offset jumps. I'll put AD829s back soon. 

At first, I had ITMX misalgined to use AS55 as an out of loop sensor, then I aligned and locked the X arm on POX to compare.

Weirdly enough, locking the mode cleaner to the Y arm with 30kHz UGF and two boosts on make no real visible difference in the X arm control signal. This is strange, as the whole point of this affair was to remove the presumably large influence of frequency noise on the X arm signals... Maybe this is injecting too much POY sensor noise?

 

Attachment 1: inloop_outloop.pdf
inloop_outloop.pdf
Attachment 2: xarm.pdf
xarm.pdf
  12204   Mon Jun 20 18:07:15 2016 gautamUpdateCOCContrast as a function of RoC of ETMX
Quote:

So, it seems that changing the ETMX for one of the spares will change the contrast defect from ~0.1% to 0.9%. True? Seems like that might be a big deal.

That is what the simulation suggests... I repeated the simulation for a PRFPMI configuration (i.e. no SRM, everything else  as per the most up to date 40m numbers), and the conclusion is roughly the same - the contrast defect degrades from ~0.1% to ~1.4%... So I would say this is significant. I also attempted to see what the contribution of the asymmetry in loss in the arms is, by running over the simulation with the current loss numbers of 230ppm for Yarm and 484ppm for the X arm, split equally between the ITMs and ETMs for both cases, and then again with lossless arms - see attachment #1. While this is a factor, this plot seems to suggest that the RoC mismatch effect dominates the contrast defect...

Attachment 1: contrastDefectComparison.pdf
contrastDefectComparison.pdf
  12203   Mon Jun 20 16:33:09 2016 VarunUpdateElectronicsAnti-Aliasing Filter circuit schematic

Summary: The aim is to design an analog anti-aliasing (AA) filter placed before the ADC, whose function is to filter out components of the input spectrum that have frequencies higher than the Nyquist frequency. This needs to be done so that there is no contamination of aliased downconverted high-frequency signals into the ADC output. I have put down and simulated a circuit to do this, based on the spectra of a few interferometer signals that eric Provided. Attachment 1 shows such an input PSD, treated with whitening filter, before the AA. The sampling rate is 65536 Hz and hence the Nyquist freq. is 32768 Hz.

Motivation: Attachments 2 and 3 show the plot of required attenuation for various frequencies above the Nyquist. We can see a peak at 36 kHz, which will alias to about 29kHz. It will require about 70 dB attenuation here. This indicates that use of a notch filter combined with a low pass filter can be used.

Details of Schematic: Attachment 4 shows the schematic of a Boctor low pass notch filter, cascaded by a 2nd order LPF. The stopband frequency of the boctor filter can be tuned to around 36 kHz. Its main advantage for the boctor is better insensitivity to component value tolerances, use of a single op amp, and relatively independent tuning of parameters.  The various component values are calculated from here. The transfer functions for the circuit shown in attachment 4 were simulated using TINA - a spice based simulation software. The transfer function is shown in attachment 5.

A few more calculations: Attachment 6 shows the output psd after the signal has been treated with AA. Attachments 7 and 8 show the ratio of aliased downconverted signal and the unaliased signal of the output. Here, we can see that above about 13 kHz, the ratios go above -40dB, which is apparently undesirable. However, we also see from the transfer function of the filter that the gain falls to less than -20dB after about this frequency, and the aliased signals are atleast 20 dB lower than this, atleast upto about 29 kHz in attachment 7 and about 25 kHz in attachment 8. This means that the aliased signals are negligible as compared to the low frequencies even if they are not negligible as compared to the higher frequencies (above 13 kHz) into which they would get downconverted due to sampling. But these higher frequencies (above 13 kHz) themselves are small.

The filter overall, is 4th order. Considering this and the above discussion, I need to decide what changes to make in the existing schematic. For now, I could discuss with eric to finalize the opamp and start building the pcb board design.

Attachment 1: in.pdf
in.pdf
Attachment 2: 32to65att.pdf
32to65att.pdf
Attachment 3: 65to98att.pdf
65to98att.pdf
Attachment 4: lpf_notch.JPG
lpf_notch.JPG
Attachment 5: lpf_notch.pdf
lpf_notch.pdf
Attachment 6: out.pdf
out.pdf
Attachment 7: out_ratio1.pdf
out_ratio1.pdf
Attachment 8: out_ratio2.pdf
out_ratio2.pdf
  12202   Mon Jun 20 14:03:04 2016 jamieConfigurationCDSEndRun GPS receiver upgraded, fixed

I just upgraded the EndRun Technologies Tempus LX GPS receiver timing unit, and it seems to have fixed all the problems.  cool

Thanks to Steve for getting the info from EndRun.  There was indeed a bug in the firmware that was fixed with a firmware upgrade.

I upgraded both the system firmware and the firmware of the GPS subsystem:

Tempus LX GPS(root@Tempus:~)-> gntpversion 
Tempus LX GPS 6010-0044-000 v 5.70 - Wed Oct 1 04:28:34 UTC 2014
Tempus LX GPS(root@Tempus:~)-> gpsversion 
F/W 5.10 FPGA 0416
Tempus LX GPS(root@Tempus:~)->

After reboot the system is fully functional, displaying the correct time, and outputting the correct IRIG-B data, as confirmed by the VME timing unit.

I added a wiki page for the unit: https://wiki-40m.ligo.caltech.edu/NTP

 

Steve added this picture

Attachment 1: GPSreceiverWorking.jpg
GPSreceiverWorking.jpg
  12201   Mon Jun 20 11:19:41 2016 jamieConfigurationCDSGPS receiver not resetting properly
Quote:

I called https://www.endruntechnologies.com/pdf/USM3014-0000-000.pdf  and they said it's very likely just needs a software update. They will email Jamie the details.

I got the email from them.  There was apparently a bug that manifested on February 14 2016.  I'll try to software update today.

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

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

I called https://www.endruntechnologies.com/pdf/USM3014-0000-000.pdf  and they said it's very likely just needs a software update. They will email Jamie the details.

Quote:

The GPS receiver (EndRun Technologies box in 1Y5? (rack closest to door)) seems to not coming back up properly after the reboot.  The front pannel says that it's "LKD", but the "sync" LED is flashing instead of solid, and the time of year displayed on the front panel is showing day 6.  The fb1 symmetricom driver and VME timing module are still both seeing day 299, though.  So something may definitely be screwy with the GPS receiver.

 

  12199   Mon Jun 20 09:36:10 2016 SteveUpdateSUS EQ 3.1 m Big Bear Lake, CA

No suspention lost damping.

 

Attachment 1: eq3.1BigBearLakeCA.png
eq3.1BigBearLakeCA.png
  12198   Mon Jun 20 08:26:56 2016 SteveUpdatePSLAOM pictures

Good job Johannes and Subham.

 

Attachment 1: AOMinplace.jpg
AOMinplace.jpg
Attachment 2: inplaceAOM.jpg
inplaceAOM.jpg
Attachment 3: AOMin.png
AOMin.png
  12197   Mon Jun 20 01:38:04 2016 ranaUpdateCOCContrast as a function of RoC of ETMX

So, it seems that changing the ETMX for one of the spares will change the contrast defect from ~0.1% to 0.9%. True? Seems like that might be a big deal.

  12196   Fri Jun 17 22:36:11 2016 JohannesUpdatePSLAOM installation

Subham and I have placed the AOM back into the setup right in front of the PMC.

Steps undertaken:

  1. The HEPA filters were turned off for some reason. They were turned back on, running at 100% while the enclosure was open.
  2. Before the installation, after initial realignment, the PMC TRANSPD read out 748 mV.
  3. The laser injection current was dialed down to 0.8 A (just above the threshold, judging by PMC cameras.
  4. AOM was attached to the new mount while staying connected to its driver. Put in place, a clamp prevents the cable from moving anywhere near the main beam.
  5. Aligned AOM to beam, centering the beam (by eye) on front and back apertures.
  6. We then applied an offset to the AOM driver input, eventually increasing it to 0.5 V. A secondary beam became clearly visible below the primary beam.
  7. In order to place the razor blade dump (stemming from a box, labeled "cleaned for atm use") before the PMC, where the beam separation was about 3 mm, to make sure we can hit the edged area, we had to place the dump at an angle, facing up.
  8. Keeping the 0.5V offset on the driver input, with the lights off, we increased the laser diode current in steps of ~200 mA to its original value of 2.1A, while checking for any IR light scattered from the beam dump. Not a trace.
  9. At original current setting, we realigned the beam into the PMC, and obtained 743 mV on the TRANSPD in the locked state.
  10. Closed off PSL table, dialed HEPAs down to 50%

              

 

Attachment 1: aom_new_mount.jpg
aom_new_mount.jpg
  12195   Fri Jun 17 15:22:31 2016 gautamUpdateVACN2 supply line restored after retiling
Quote:

The drill room floor will be retiled Thursday, June 16. Temporary nitrogen line set up will allow emptying the hole area.

 

Ifo room entry will be through control room.

 

The retiling work has finished, Steve and I restored the N2 supply configuration to its normal state. The sequence of steps followed was:

  1. Went to the X end and closed the following valves, roughly in this order: VAEE, VAEV, VABS, VABSCI, VASV, VASE, V4, V1.
  2. Checked the RPM on the various turbo pump controllers to make sure they were in their nominal states
  3. Disconnect the electrical connections to V1, V4, V5 and VA6 - just to make sure some spurious signal doesn't unintentionally open any of these valves while we are mucking around with the N2 supply
  4. Close the valves on the N2 cylinders in the drill room. Disconnect the temporary nitrogen line (at this point, the N2 pressure to the IFO valves goes down from ~7-PSI to 0), reconnect the old supply chain, taking care that we aren't unintentionally loosening any of the Swagelock connections while unscrewing stuff
  5. Replaced one of the N2 cylinders that was running low.
  6. Reopen the cylinders, restore N2 pressure to IFO valves to ~70PSI.
  7. Do steps 1-3 in reverse: i.e. reconnect power to all valves, open them in the reverse order we closed them while monitoring the state of the various turbo pumps. 
  8. Acknowledged the error message on the C0VAC medm screen

Note: the valve isolating the RGA automatically shutoff during this work, possibly because it detected a pressure above its threshold - after checking the appropriate pressure gauges, we reopened this valve as well. 

The attached screenshot suggests that everything went as planned and that the vacuum system is back to normal...

 

 

Attachment 1: c0vac_06172016.png
c0vac_06172016.png
  12194   Thu Jun 16 23:02:57 2016 gautamUpdateCOCContrast as a function of RoC of ETMX
Quote:

That sounds weird. frownIf the ETMY RoC is 60 m, why would you use 57.6 m in the simulation? According to the phase map web page, it really is 60.2 m.

This was an oversight on my part. I've updated the .kat file to have all the optics have the RoC as per the phase map page. I then re-did the tracing of the Y arm cavity mode to determine the appropriate beam parameters at the laser in the simulation, and repeated the sweep of RoC of ETMX while holding RoC of ETMY fixed at 60.2m. The revised contrast defect plot is attached (this time it is the contrast defect, and not the contrast, but since I was running the simulation again I thought I may as well change the plot). 

As per this plot, if the ETMX RoC is ~54.8m (the closer of the two spares to 60.2m), the contrast defect is 0.9%, again in good agreement with what the note linked in the previous elog tells us to expect...

Attachment 1: contrastDefect.pdf
contrastDefect.pdf
  12193   Thu Jun 16 18:42:12 2016 ranaUpdateCOCContrast as a function of RoC of ETMX

That sounds weird. frownIf the ETMY RoC is 60 m, why would you use 57.6 m in the simulation? According to the phase map web page, it really is 60.2 m.

  12192   Thu Jun 16 18:08:57 2016 JohannesUpdatePSLBefore the AOM installation

There was only one razor blade beam dump labeled for atmospheric use left, but that's all we need. Steve is working on restocking. I placed the modified AOM mount on the PSL table near its intended location (near the AOM where it doesn't block any beams).

Things to keep in mind:

  • The laser power needs to be turned down for the installation of the AOM. Current laser settings are: Crystal Temperature: 29.41 C, Diode Current: 2.1 A.
  • The AOM driver must not be left unterminated when turned on (which it currently is and will be).
  • The HEPA filters are currently running at ~50%. While the PSL enclosure is open for the work we'll set them to 100% and lower them after a job well done.

The setup:

The AOM has a deflection angle of about 20 mrad, which requires about 10cm of path for a separation of 2mm of the two beams. I need to survey closer and confirm, but I hope I can fit the beam dump in before the PMC (this of course also depends on the spot size). Alternatively, the PMC hopefully isn't resonant for anything remotely relevant at 80MHz offset, in which case we can also place the beam dump in its reflection path.

So this is the plan:

  • Determine coupling efficiency into PMC for reference
  • Turn down laser power
  • No signal on AOM driver modulation input
  • Mount AOM, place in beam path, and align
  • Correct alignment into PMC?
  • Secondary beam detectable? Adjust modulation input and laser power until detectable.
  • Find a place for beam dump
  • Confirm that primary beam is not clipping with PMC
  • Turn up laser power
  • Determine coupling efficiency with restored power to compare

Any thoughts? Based on the AOMs resting place I assumed that it is supposed to be installed before the PMC, but I'm actually not entirely sure where it was sitting before.

  12191   Thu Jun 16 16:11:11 2016 jamieUpdateCDSupgrade aborted for now

After poking at the new configuration more, it also started to show instability.  I couldn't figure out how to make test points or excitations available in this configuration, and adding in the full set of test point channels, and trying to do simple things like plotting channels with dtt, the frame writer (fw) would fall over, apparetnly unable to keep up with the broadcast from the dc.

I've revered everything back to the old semi-working fb configuration, and will be kicking this to the CDS group to deal with.

  12190   Thu Jun 16 15:57:46 2016 gautamUpdateCOCContrast as a function of RoC of ETMX

Summary

In a previous elog, I demonstrated that the RoC mismatch between ETMX and ETMY does not result in appreciable degradation in the mode overlap of the two arm modes. Koji suggested also checking the effect on the contrast defect. I'm attaching the results of this investigation (I've plotted the contrast, C = \frac{P\mathrm{_{max}}-P\mathrm{_{min}}}{P\mathrm{_{max}}+P\mathrm{_{min}}}  rather than the contrast defect 1-C).

Details and methodology

  • I used the same .kat file that I had made for the current configuration of the 40m, except that I set the reflectivities of the PRM and the SRM to 0. 
  • Then, I traced the Y arm cavity mode back to the node at which the laser sits in my .kat file to determine what beam coming out of the laser would be 100% matched to the Y arm (code used to do this attached)
  • I then set the beam coming out of the laser for the subsequent simulations to the value thus determined using the gauss command in finesse.
  • I then varied the RoC of ETMX (I varied the sagittal and tangential RoCs simultaneously) between 50m and 70m. As per the wiki page, the spare ETMs have an RoC between 54 and 55m, while the current ETMs have an RoC of 60.26m and 59.48m for the Y and X arms respectively (I quote the values in the "ATF" column). Simultaneously, at each value of the RoC of ETMX, I swept the microscopic position of the ETMX HR surface through 2pi radians (-180 degrees to 180 degrees) using the phi functionalilty of finesse, while monitoring the power at the AS port of this configuration using a pd in finesse. This guarantees that I sweep through all the resonances. I then calculate the contrast using the above formula. I divided the parameter space into a grid of 50 points for the RoC of ETMX and 1000 points for the microscopic position of ETMX. 
  • I fixed the RoC of ETMY as 57.6m in the simulations... Also, the maxtem option in the .kat file is set to 4 (i.e. higher order modes with indices m+n<=4 are accounted for...)

Result:

Attachment #1 shows the result of this scan (as mentioned earlier, I plot the contrast C and not the contrast defect 1-C, sorry for the wrong plot title but it takes ~30mins to run the simulation which is why I didn't want to do it agian). If the RoC of the spare ETMs is about 54m, the loss in contrast is about 0.5%. This is in good agreement with this technical note by Koji - it tells us to expect a contrast defect in the region of 0.5%-1% (depending on what parameter you use as the RoC of ETMY). 

Conclusion:

It doesn't seem that switching out the current ETM with one of the spare ETMs will result in dramatic degradation of the contrast defect...

Misc notes:

  1. Regarding the phase command in Finesse - EricQ pointed out that the default value of this is 3, which as per the manual could give unphysical results sometimes. The flags "0" or "2" are guaranteed to yield physical results always according to the manual, so it is best to set this flag appropriately for all future Finesse simulaitons. 
  2. I quickly poked around inside the cabinet near the EX table labelled "clean optics" to see if I could locate the spare ETMs. In my (non-exhaustive) search, I could not find it in any of the boxes labelled "2010 upgrade" or something to that effect. I did however find empty boxes for ETMU05 and ETMU07 which are the ETMs currently in the IFO... Does anyone know if I should look elsewhere for these?
    EDIT 17Jun2016: I have located ETMU06 and ETMU08, they are indeed in the cabinet at the X end...
  3. I'm attaching a zip file with all the code used to do this simulation. The phase flag has been appropriately set in the (only) .kat file. setLaserQparam.py was used to determine what beam parameter to assign to be perfectly matched to the Y arm. modeMatchCheck_ETM.py was used to generate the contrast as a function of the RoC of ETMX.
  4. With regards to the remaining checks to be done - I will post results of my investigations into the HOM scans as a function of the RoC of the ETMs and also the folding mirrors shortly... 
Attachment 1: contrastDefect.pdf
contrastDefect.pdf
Attachment 2: finesseCode.zip
  12189   Thu Jun 16 12:06:59 2016 ericqUpdateLSCRF Amp installed at POY11 RF output

I have installed a ZFL-500LN on the RF output of POY11. This should reduce the effect of the CM board voltage offsets by increasing the size of the error signal coming into the board. Checking with an oscilloscope at the LSC rack, the single arm PDH peak to peak voltage was something like 4mV, now it is something like 80mVyes

The setup is similar to the REFL165 situation, but with the amplifier in proximity with the PD, instead of at the end of a long cable at the LSC rack. 

The PD RF output is T'd between an 11MHz minicircuits bandpass filter and a 50 Ohm terminator (which makes sure that signals outside of the filter's passband don't get reflected back into the PD). The output of the filter is connected directly to the input of the ZFL-500LN, which is powered (temporarily) by picking off the +15V from the PD interface cable via Dsub15 breakout. (I say temporarily, as Koji is going to pick out some fancy pi-filter feedthrough which we can use to make a permanent power terminal on the PD housing.)

The max current draw of this amplifier is 60mA. Gazing at the LSC interface (D990543), I think the +15V on the DSUB cable is being passed from the eurocard crate; I don't see any 15V regulator, so maybe this is ok...

The free swinging PDH signal looked clean enough on a scope. Jamie is doing stuff with the framebuilder, so I can't look at spectra right now. However, turning the POY whitening gain down to +18dB from +45dB lets the Y arm lock on POY with all other settings nominal, which is about what we expect from the nominal +23dB gain of the amplifier.

I would see CM board offsets of ~5mV before, which was more a little more than a linewidth before this change. Now it will be 5% of that, and hopefully more manageable.

  12188   Thu Jun 16 11:25:00 2016 JohannesUpdateLSCY-Arm round-trip loss measurement with ALS

Using the ALS green beat and armlength feedback I mapped an IR resonance of the Y-Arm by stepping through a ramp of offset values.

First I optimized the IR alignment with the dither scripts while LSC kept the arm on resonance, and then transitioned the length control to ALS. The beat frequency I obtained between the Y-arm green and the PSL was about 25 MHz. Then I applied a controlled ramp signal (stepping through small offset increments applied to LSC-ALSY_OFFSET, while logging the readback from channels LSC-TRY_OUT16 and ALS-Y_FC_SERVO_INMON with an averaging time of 1s.

The plots show the acquired data with fits to  T(x)=\frac{T_0}{1+\frac{(x-x_0)^2}{\mathrm{HWHM}^2}}+\mathrm{offset} and f(x)=mx+b, respectively.

 

The fits, weighted with inverse rms uncertainty of the data points as reported by the cds system, returned HWHM = 0.6663 ± 0.0013 [offset units] and m = -0.007666 ± 0.000023 [MHz/offset unit], which gives a combined FWHM = 10,215 ± 36 Hz. The error is based purely on the fit and does not reflect uncertainties in the calibration of the phase tracker.

This yields a finesse of 388.4 ± 1.4, corresponding to a total loss (including transmissivities) of 16178 ± 58 ppm. These uncertainties include the reported accuracies of FSR and phase tracker calibration from elog 9804 and elog 11761.

The resulting loss is a little lower than that of elog 11712, which was done before the phase tracker re-calibration. Need to check for consistency.

Attachment 1: T_vs_steps.pdf
T_vs_steps.pdf
Attachment 2: f_vs_steps.pdf
f_vs_steps.pdf
  12187   Thu Jun 16 11:10:17 2016 SteveUpdateSUSspare ETMX optics preparation to be hanged

D Location

Number on

Drawing

 

Component

Name

 

 Baked Clean

 Pieces Needed

 

Pieces

In Stock

(on tower )

Notes
         
31,20,19,13 viton tips   not cut yet baked material in stock
30 6-32x0.75" stops 4 (4)  
29 steel music wire 0.017" not baked on roll  needs good wipes
28  1/4 "washer 4 (4)  
27 lock washer 4 50 install
26 Ag plated 1/4-20x1.25 4 (4)  
25 Ag plated1/4-25x.75 & not plated 20 (20)  
24 SS 4-40x.5 2 (2)  
23 SS 4-40x.38 4 (4)  
22 spring plunger 4+2 (4+2)  
         
         
18 magnets, 1.9mm od, length 3.2 mm 5 ~30 not coated, rusty

buy Ni coated ones for future use from www.electroenergy.com

 

17 guide rod, 0.635 mm od, 3.3 mm 3 6 Al
16 wire standoff, 1 mm od, 4.8 mm 2 2 Al and ruby (ruby groove not centered)
15 short OSEMs 5 6  
14 spare ETMX in 40m wiki 1 1  confirmed in cabinet
         
12 dumbbell standoff 5 6  
11 Al stiffening plate 1 (1)  
10 wire clamp B in sus block 2 (2)  
9 wire clamp A 1 (1)  
8-7 lower clamp for lifting optics 2 (2)  
6 upper clamp to hold down optic 1 (1)  
5-4 left-right side of tower  1 ea (1ea)  
3 tower base 1 (1)  
2 sus block 1 (1)  
1 lower and upper OSEM holders 1ea (1ea)  
         
48 sandind fixture for magnet&dumbbell      
45 magnet-dumbbell assemblly fixture 1 1  
43 guide-wirestandoff gluing fixture 1 1

Ok for larger RUBY,

unit is not in perfect condtition but usefull

 

         
  First contact   3-15-2013 purchase

Pick up  FC from Gary with purchasing date 7-7-2015

or later

  FCPEEK peeler ring disk for TM cleaning 10 front,10 back side  have sheets only 32&19mm ID punches ordered
  GordonBrush custom for LIGO optical cleaning ~5 1 (3/8wide nylonSS) more from Calum available
  EP30-2 epoxy have  have expiration date 9-24-2016

NOT finished, last edited 7-7

Attachment 1: SOSsus_Page_1.png
SOSsus_Page_1.png
Attachment 2: SOSsus_Page_2.png
SOSsus_Page_2.png
Attachment 3: ETMXspareTowerFace.jpg
ETMXspareTowerFace.jpg
Attachment 4: ETMXspareTowerBack.jpg
ETMXspareTowerBack.jpg
Attachment 5: magnets-dumbbells.jpg
magnets-dumbbells.jpg
  12186   Thu Jun 16 08:52:14 2016 SteveUpdateGeneralilluminators turned off

PSL, BS, ITMY and ETMX the illuminators were left on over night.

  12185   Wed Jun 15 22:12:55 2016 varunUpdateCDSDAFI update: stereo output

I wish to have stereo audio output for the DAF module. Hence, there needs to be a second output from the DAF. I added this second output to the model. Following are the details:

FiBox: It consists of two analog inputs which are digitized and multiplexed and transmitted optically. (only 1 fiber is needed due to multiplexing). Attachment 1 shows the fibox with its 2 analog inputs (one of which, is connected), and 1 fiber output. The output of the DAF goes to the FiBox. Until today, the Fibox recieved only 1 analog input. This analog signal comes from the DAC-8 (count starting from 0), which is located at "CH 1 OUT" SMA output in the "MONITORS" bin on the racks (attachment 2).

I have added another output channel to the DAF model both in software and in hardware. The DAF now also uses DAC-9 analog output which goes to the second analog input of the FiBox. The DAC-9 output is located at "CH 2 OUT" SMA output in the "MONITORS" bin on the racks (attachment 4).

After making the changes, the Fibox is shown in attacment 3.

Testing: The LSC input on passing through the DAF block is given through two different DAC outputs, to the same Fibox channel (one after the other), and the output is heard. More concrete testing will be done tomorrow. It will be as follows:

1) Currently, I need to search for a suitable cable that would connect the second channel of the output fibox to the audio mixer. After doing this, end to end testing of both channels will be done.

2) I could not access the AWG, probably because the DAQ was offline today afternoon. Using a signal from the AWG will give a more concrete testing of the stereo output.

3) After this, I will separate the two channels of the stereo completely (currectly they are seperated only at the DAF output stage)

4) I also will edit the medm gui appropriately.

 

Quote:

I have added Enable buttons for each of the DSP blocks, and labels for the matrix elements. The input matrix takes inputs from each of the 4 channels: ADC1, ADC2, LSC and EXC, and routes them to the audio processing blocks (attachment 2). The output matrix (attachment 3) takes the outputs of the various DSP blocks and routes them to the output and then to the speakers. 

 

Attachment 1: IMG_20160615_145535907.jpg
IMG_20160615_145535907.jpg
Attachment 2: IMG_20160615_145413005_HDR.jpg
IMG_20160615_145413005_HDR.jpg
Attachment 3: IMG_20160616_101229499.jpg
IMG_20160616_101229499.jpg
Attachment 4: IMG_20160616_101157096.jpg
IMG_20160616_101157096.jpg
  12183   Wed Jun 15 11:21:51 2016 jamieUpdateCDSstill work to do to transition to new configuration/code

Just to be clear, there's still quite a bit of work to fully transition the 40m to this new system/configuration.  Once we determine a good configuration we need to complete the install, and modify the setup to run the two binaries instead of just the one.  The data is also being written to a raid on the new fb1, and we need to decide if we should use this new raid, or try to figure out how to move the old jetstor raid to the new fb1 machine.

  12182   Wed Jun 15 10:19:10 2016 SteveConfigurationCDSGPS antennas... debugging

Visual inspection of rooftop GPS antennae:

The 2 GPS antennas are located on the north west corner of CES roof. Their condition looks well weathered. I'd be surprised if they work.

The BNC connector of the 1553 head is inside of the conduit so it is more likely to have a better connection than the other one.

I have not had a chance to look into the "GPS Time Server" unit.

Attachment 1: GPStimeServer.jpg
GPStimeServer.jpg
Attachment 2: GPSsn.jpg
GPSsn.jpg
Attachment 3: GPSantennas.jpg
GPSantennas.jpg
Attachment 4: GPSantHead.jpg
GPSantHead.jpg
Attachment 5: GPSantHead2.jpg
GPSantHead2.jpg
Attachment 6: GPSantCabels.jpg
GPSantCabels.jpg
  12181   Wed Jun 15 09:52:02 2016 jamieUpdateCDSVery encouraging results from overnight split daqd test

laughVery encouraging results from the test last night.  The new configuration did not crash once overnight, and seemed to write out full, second trend, and minute trend frames without issueyes.  However, full validity of all the written out frames has not been confirmed.

overview

The configuration under test involves two separate daqd binaries instead of one.  We usually run with what is referred to as a "framebuilder" (fb) configuration:

  • fb: a single daqd binary that:
    • collect the data from the front ends
    • coallate full data into frame file format
    • calculates trend data
    • writes frame files to disk.

The current configuration separates the tasks into multiple separate binaries: a "data concentrator" (dc) and a "frame writer" (fw):

  • dc:
    • collect data from front ends
    • coallate full data into frame file format
    • broadcasts frame files over local network
  • fw:
    • receives frame files from broadcast
    • calculates trend data
    • writes frame files to disk

This configuration is more like what is run at the sites, where all the various components are separate and run on separate hardware.  In our case, I tried just running the two binaries on the same machine, with the broadcast going over the loopback interface.  None of the systems that use separated daqd tasks see the failures that we've been seeing with the all-in-one fb configuration (and other sites like AEI have also seen).

My guess frown is that there's some busted semaphore somewhere in daqd that's being shared between the concentrator and writer components.  The writer component probably aquires the lock while it's writing out the frame, which prevents the concentrator for doing what it needs to be doing while the frame is being written out.  That causes the concentrator to lock up and die if the frame writing takes too long (which it seems to almost necessarily do, especially when trend frames are also being written out).

results

The current configuration hasn't been tweaked or optimized at all.  There is of course basically no documentation on the meaning of the various daqdrc directives.  Hopefully I can get Keith Thorne to help me figure out a well optimized configuration.

There is at least one problem whereby the fw component is issuing an excessively large number of re-transmission requests:

2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 6 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 8 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 3 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 5 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 5 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 5 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 5 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 6 packets; port 7097
2016-06-15_09:46:23 [Wed Jun 15 09:46:23 2016] Ask for retransmission of 1 packets; port 7097

It's unclear why.  Presumably the retransmissions requests are being honored, and the fw eventually gets the data it needs.  Otherwise I would hope that there would be the appropriate errors.

The data is being written out as expected:

 full/11500: total 182G
drwxr-xr-x  2 controls controls 132K Jun 15 09:37 .
-rw-r--r--  1 controls controls  69M Jun 15 09:37 C-R-1150043856-16.gwf
-rw-r--r--  1 controls controls  68M Jun 15 09:37 C-R-1150043840-16.gwf
-rw-r--r--  1 controls controls  68M Jun 15 09:37 C-R-1150043824-16.gwf
-rw-r--r--  1 controls controls  69M Jun 15 09:36 C-R-1150043808-16.gwf
-rw-r--r--  1 controls controls  69M Jun 15 09:36 C-R-1150043792-16.gwf
-rw-r--r--  1 controls controls  68M Jun 15 09:36 C-R-1150043776-16.gwf
-rw-r--r--  1 controls controls  68M Jun 15 09:36 C-R-1150043760-16.gwf
-rw-r--r--  1 controls controls  69M Jun 15 09:35 C-R-1150043744-16.gwf

 trend/second/11500: total 11G
drwxr-xr-x  2 controls controls 4.0K Jun 15 09:29 .
-rw-r--r--  1 controls controls 148M Jun 15 09:29 C-T-1150042800-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 09:19 C-T-1150042200-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 09:09 C-T-1150041600-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 08:59 C-T-1150041000-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 08:49 C-T-1150040400-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 08:39 C-T-1150039800-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 08:29 C-T-1150039200-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 08:19 C-T-1150038600-600.gwf

 trend/minute/11500: total 152M
drwxr-xr-x 2 controls controls 4.0K Jun 15 07:27 .
-rw-r--r-- 1 controls controls  51M Jun 15 07:27 C-M-1150023600-7200.gwf
-rw-r--r-- 1 controls controls  51M Jun 15 04:31 C-M-1150012800-7200.gwf
-rw-r--r-- 1 controls controls  51M Jun 15 01:27 C-M-1150002000-7200.gwf

The frame sizes look more or less as expected, and they seem to be valid as determined with some quick checks with the framecpp command line utilities.

  12180   Tue Jun 14 20:10:19 2016 varunUpdateCDSDAFI GUI update

I have added Enable buttons for each of the DSP blocks, and labels for the matrix elements. The input matrix takes inputs from each of the 4 channels: ADC1, ADC2, LSC and EXC, and routes them to the audio processing blocks (attachment 2). The output matrix (attachment 3) takes the outputs of the various DSP blocks and routes them to the output and then to the speakers. 

Attachment 1: C1DAF_OVERVIEW.png
C1DAF_OVERVIEW.png
Attachment 2: input_matrix.png
input_matrix.png
Attachment 3: output_matrix.png
output_matrix.png
  12179   Tue Jun 14 19:37:40 2016 jamieUpdateCDSOvernight daqd test underway

I'm running another overnight test with new daqd software on fb1.  The normal daqd process on fb has been shutdown, and the front ends are sending their signals to fb1.

fb1 is running separate data concentrator (dc) and  frame writer (fw) processes, to see if this is a more stable configuration than the all-in-one framebuilder (fb) that we have been trying to run with.  I'll report on the test tomorrow.

  12178   Tue Jun 14 16:53:16 2016 ranaUpdateSUSETMX watch

What about ETMY? and are these really microradians or just some made up cal?

  12177   Tue Jun 14 15:55:17 2016 ericqUpdateSUSETMX watch

Within two hours, it was already all over the place. 

It has been Decided: we will assemble a suspension with the spare ETM optic with the current-generation standoff for installation ASAP. I.e. no new custom parts. We will continue pursuing the new standoff design, but we need our interferometer back.

  12176   Tue Jun 14 11:52:08 2016 JohannesUpdateGeneralEPICS Installation | SURF 2016

We generally want to keep the configuration of the 40m close to that of the LIGO sites, which is why we chose BusWorks, and it is also being established as a standard in other labs on campus. Of course any suitable DAQ system can do the job, but to stay relevant we generally try to avoid patchwork solutions when possible. Did you follow Aidan's instructions to the book? I haven't set up a system myself, yet, so I cannot say how difficult this is. If it just won't work with the Raspberry Pi, you could still try using a traditional computer.

Alternatively, following Jamie's suggestions, I'm currently looking into using python for the modbus communications (there seem to be at least a few python packages that can do this), which would reportedly make the interfacing and integration a lot easier. I'll let you know when I make any progress on this.

Quote:

About acquiring data: Initially I couldn't start with proper Acromag setup as the Raspberry pi had a faulty SD card slot. Then Gautam gave me a working pi on which I tried to install EPICS. I spent quite a time today but couldn't setup acromag over ethernet.  But, it would be great if we have a USB DAQ card. I have found a good one here http://www.mccdaq.com/PDFs/specs/USB-200-Series-data.pdf It costs around 106$ including shipping (It comes with some free softwares for acquiring data) . Also, I know an another python based 12bit DAQ card (with an inbuilt constant current source) which is made by IUAC, Delhi and more information can be found here http://www.iuac.res.in/~elab/expeyes/Documents/eyesj-progman.pdf  It costs around 60$ including shipping.

About temperature sensing: The RTD which I found on Omega's list is having a temperature resolution of 0.1 deg C. I have also asked them for the one with good resolution. Also according to their reply, they have not performed any noise characteristics study for those RTDs.

 

 

  12175   Tue Jun 14 11:29:25 2016 JohannesSummaryASCYArm OpLev Calibration

In preparation for the armloss map I checked the calibration of the Y-Arm ITM and ETM OpLevs with the method originally described in https://nodus.ligo.caltech.edu:8081/40m/1247. I was getting a little confused about the math though, so I attached a document at the end of this post in which I work it out for myself and posteriority. Stepping through an introduced offset in the control filter for the corresponding degree of freedom, I recorded the change in transmitted power and the reading of the OpLev channel with the current calibration. One thing I noticed is that the calibration for ITM PIT is inverted with respect to the others. This can of course be compensated at any point in any readout/feedback chain, but it might be nice to establish some sort of convention where positive feedback to the mirror will increase the OpLev reading.

The calibration factors I get are within ~10% of the currently stored values. The table (still incomplete, need to relate to the current values) summarizes the results:

Mirror DoF Current Relative New
Y-Arm OpLev Calibration
ETM PIT   0.974 ± 0.029  
  YAW   1.077 ± 0.021  
ITM PIT   -0.972 ± 0.020  
  YAW   0.920 ± 0.048  

The individual graphs:

ETM PIT

ETM YAW

ITM PIT

ITM YAW

 

The math:

 

 

Attachment 1: CavityCoupling.pdf
CavityCoupling.pdf CavityCoupling.pdf
  12174   Tue Jun 14 10:13:34 2016 SteveUpdateVACtemporary N2 supply line

The drill room floor will be retiled Thursday, June 16. Temporary nitrogen line set up will allow emptying the hole area.

 

Ifo room entry will be through control room.

 

Attachment 1: afterN2work.png
afterN2work.png
  12173   Mon Jun 13 20:01:30 2016 varunUpdateCDSDAFI GUI 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 a summary of the gui i have made towards a general purpose DAF module linked to the LSC. 

Details:  attachment 1 shows the top level overview of the daf module.

The "INPUTS" button shown redirects to the medm screen shown in attachment 2, which is a collection of inputs going into the module.

Each of the buttons shown in "C1DAFI_INPUTS.png" is further linked to various i/o boxes like adc1, adc2, lsc signal and exitation. An example is shown in attachment 3. This is the specific I/O box for the LSC signal.

The field labelled "INPUT_MTRX" is linked to a matrix which routes these 4 inputs to various DSP blocks. Similarly, the "OUTPUT_MTRX" tab is useful for choosing which output goes to the speaker. 

Time and computational load monitoring is done in the "GDS_TP" tab which links to the medm screen shown in attachment 4.

Currently the AGC is successfully implemented as one of the DSP block. The details of the AGC implementation were given in a previous elog: https://nodus.ligo.caltech.edu:8081/40m/12159

I need to make a few changes to the code for Frequency Shifting and Whitening before uploading them on the FE. I will put the details soon.

Some more things that I think need to be added: 

1) "Enable" buttons for each of the DSP blocks.

2) Labels for each of the matrix elements.

3) Further headers and other description for each of the tabs 

Attachment 1: C1DAF_OVERVIEW.png
C1DAF_OVERVIEW.png
Attachment 2: C1DAF_INPUTS.png
C1DAF_INPUTS.png
Attachment 3: C1DAF_LSC.png
C1DAF_LSC.png
Attachment 4: MONITOR.png
MONITOR.png
  12172   Mon Jun 13 19:30:58 2016 AakashUpdateGeneralEPICS Installation | SURF 2016

About acquiring data: Initially I couldn't start with proper Acromag setup as the Raspberry pi had a faulty SD card slot. Then Gautam gave me a working pi on which I tried to install EPICS. I spent quite a time today but couldn't setup acromag over ethernet.  But, it would be great if we have a USB DAQ card. I have found a good one here http://www.mccdaq.com/PDFs/specs/USB-200-Series-data.pdf It costs around 106$ including shipping (It comes with some free softwares for acquiring data) . Also, I know an another python based 12bit DAQ card (with an inbuilt constant current source) which is made by IUAC, Delhi and more information can be found here http://www.iuac.res.in/~elab/expeyes/Documents/eyesj-progman.pdf  It costs around 60$ including shipping.

About temperature sensing: The RTD which I found on Omega's list is having a temperature resolution of 0.1 deg C. I have also asked them for the one with good resolution. Also according to their reply, they have not performed any noise characteristics study for those RTDs.

 

  12171   Mon Jun 13 10:01:58 2016 SteveUpdateSUSETMX jumps

 

Quote:

ETMX has been jumping around again lately. Just now, I zeroed the ETMX alignment offsets in the SUS model, and centered the ETMX oplev spot via slow machine sliders. OSEM damping is on, oplev damping is off. Let's see how it moves around in the next day or so. 

GPS: 1149635923 

UTC: Jun 10 2016 23:18:26

 

Attachment 1: noDamping24hrs.png
noDamping24hrs.png
Attachment 2: ETMXjumps.png
ETMXjumps.png
  12170   Mon Jun 13 09:08:17 2016 SteveUpdatePSLPMC slow drift

The PMC transmission slow degration or it's input beam is not stable.

 

Attachment 1: PMCslowDrift.png
PMCslowDrift.png
  12169   Fri Jun 10 18:16:59 2016 varunUpdatePSLRealignment of pre mode cleaner

The mode cleaner was misaligned probably due to the earthquake (the drop in the MC transmitted value slightly after utc 7:38:52 as seen in the second plot). The plots show PMC transmitted and MC sum signals from 10th june 07:10:08 UTC over a duration of 17 hrs. The PMC was realigned at about 4-4:15 pm today by rana. This can be seen in the first plot.

Attachment 1: pmctrans_mcsum_signals.png
pmctrans_mcsum_signals.png
  12168   Fri Jun 10 16:19:03 2016 ericqUpdateSUSETMX watch

ETMX has been jumping around again lately. Just now, I zeroed the ETMX alignment offsets in the SUS model, and centered the ETMX oplev spot via slow machine sliders. OSEM damping is on, oplev damping is off. Let's see how it moves around in the next day or so. 

GPS: 1149635923 

UTC: Jun 10 2016 23:18:26

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

The GPS receiver (EndRun Technologies box in 1Y5? (rack closest to door)) seems to not coming back up properly after the reboot.  The front pannel says that it's "LKD", but the "sync" LED is flashing instead of solid, and the time of year displayed on the front panel is showing day 6.  The fb1 symmetricom driver and VME timing module are still both seeing day 299, though.  So something may definitely be screwy with the GPS receiver.

  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.

 

ELOG V3.1.3-