40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 9 of 344  Not logged in ELOG logo
ID Date Authordown Type Category Subject
  26   Mon Oct 29 12:20:15 2007 waldmanConfigurationOMCChanged OMS filters
I changed the OMS configuration so that some of the OMC-SUS LED channels go to a breakout box so that we can input the PDH error signal. After lunch, we will try to lock the cavity with a PDH error signal and digital filters. Then its on to dither locked stuff. Note that this LED business will have to be changed back some day. For now, it should be extremely visible because there are dangling cables and a hack job interface lying around.
  27   Mon Oct 29 23:10:05 2007 waldmanConfigurationOMCLost in DAQspace
[Pinkesh, Sam]

In setting up a Digital based control of the hanging OMC, we naively connect the Anti-Imaging filter output to an Anti-Aliasing input. This led to no end of hell. For one thing, we found the 10 kHz 3rd order butterworth at 10 kHz, where it should be based on the install hardware. One wonders in passing whether we want a 10 kHz butter instead of a 15 kHz something else, but I leave that for a later discussion. Much more bothersome is a linear phase shift between output and input that looks like ~180 microseconds. It screams "What the hell am I!?" and none of us could scream back at it with an answer. I believe this will require the Wilson House Ghost Busters to fully remedy on the morrow.
Attachment 1: SS.pdf
SS.pdf
Attachment 2: SS.gif
SS.gif
  37   Wed Oct 31 09:45:28 2007 waldmanOtherOMCResolution to DAQland saga
[Jay, Sam]

We did a rough accounting for the linear delay this morning and it comes out more or less correct. The 10 kHz 3rd order butterworth AA/AI filter gives ~90 degrees of phase at 6 kHz, or 42 microseconds. Taken together, the two AA and AI filters are worth 80 microseconds. The 1.5 sample digital delay is worth 1.5/32768 = 45 microseconds. The remaining 160 - 125 = 35 microseconds is most likely taken up by the 64 kHz to 32 kHz decimation routine, assuming this isn't accounted for already in the 1.5 sample digital delay.

It remains to be seen whether this phase delay is good enough to lock the laser to the OMC cavity
  42   Wed Oct 31 23:55:17 2007 waldmanOtherOMCQPD tests
The 4 QPDs for the OMC have been installed in the 056 at the test setup. All 4 QPDs work and have medm screens located under C2TPT. The breadboard mounted QPDs are not very well centered so their signal is somewhat crappy. But all 4 QPDs definitely see plenty of light. I include light and dark spectra below. QPDs 1-2 are table-mounted and QPD 2 is labeled with a bit of blue tape. QDPs 3-4 are mounted on the OMC. QPD3 is the near field detector and QPD4 is the far field. In other words, QPD3 is closest to the input coupler and QPD4 is farthest.

Included below are some spectra of the QPDs with and without light. For QPDs 1 & 2, the light source is just room lights, while 3&4 have the laser in the nominal OMC configuration with a few mWs as source. The noise at 100 Hz is about 100 microvolts / rtHz. If I recall correctly, the QPDs have 5 kOhm transimpedance (right Rich?) so this is 20 nanoamps / rtHz of current noise at the QPD.
Attachment 1: QPD_SignalSpectrum.pdf
QPD_SignalSpectrum.pdf
Attachment 2: QPD_SignalSpectrum.gif
QPD_SignalSpectrum.gif
  43   Thu Nov 1 01:28:04 2007 waldmanOtherOMCFirst digital lock of OMC
[Pinkesh, Sam]

We locked a fiber based NPRO to the suspended OMC tonight using the TPT digital control system. To control the laser frequency, we took the PZT AI output and ran it on a BNC cable down the hallway to the Thorlabs HV box. The Thorlabs is a singled ended unit so we connected the AI positive terminal only and grounded the BNC to the AI shield. We could get a -6 to 1.5 V throw in this method which fed into the 10 k resisotr + 9 V battery at the input of the HV box. The HV out ran to the NPRO PZT fast input.

We derived our error signal from a PDA255 in reflection with a 29.5 MHz PDH lock. The signal feeds into one of the unused Tip/Tilt AA channels and is passed to the PZT LSC drive through the TPT_PDH1 filter bank. In the PZT_LSC filter we put a single pole at 1 Hz which, together with the phase we mentioned the other night (180 degrees at 3 kHz) should allow a 1 kHz-ish loop. In practice, as shown below, we got a 650 Hz UGF with 45 degrees of phase margin and about 6 dB of gain margin.

The Lower figure shows the error point spectrum with 3 settings. REF0 in blue shows lots of gain peaking at 1.5 kHz-ish, just where its expected - the gain was -40. The REF1 has gain of -20 and shows no gain peaking. The current trace in red shows some gain peaking cuz the alignment is better but it also has included a 1^2:20^2 boost which totally crushes the low frequency noise. We should do a better loop sweep after getting the alignment right so we can see how much boost it will really take.

Just for fun, we are leaving it locked overnight and recording the PZT_LSC data for posterity.
Attachment 1: 071101_PZT_firstLoopSweep.pdf
071101_PZT_firstLoopSweep.pdf
Attachment 2: 071101_PZT_firstLoopSweep.gif
071101_PZT_firstLoopSweep.gif
Attachment 3: 071101_OMC_FirstLock_spectra.pdf
071101_OMC_FirstLock_spectra.pdf
Attachment 4: 071101_OMC_FirstLock_spectra.gif
071101_OMC_FirstLock_spectra.gif
  58   Fri Nov 2 12:18:47 2007 waldmanSummaryOMCLocked OMC with DCPD
[Rich, Sam]

We locked the OMC and look at the signal on the DCPD. Plots included.
Attachment 1: 071102_OMC_LockedDCPD.gif
071102_OMC_LockedDCPD.gif
Attachment 2: 071102_OMC_LockedDCPD.pdf
071102_OMC_LockedDCPD.pdf
  59   Sat Nov 3 16:20:43 2007 waldmanSummaryOMCA good day's work

I followed up yesterday's test of the PZT with a whole mess of characterizations of the PZT control and finished the day by locking the OMC with a PZT dither lock and a 600 Hz loop. I haven't analyzed any of the data yet, so its not calibrated in physical units and etc. etc. etc. Since a lot of the sweeps below are of a "drive the PZT, look at the PDH signal" nature, a proper analysis will require taking out the loop and calibrating the signals, which alas, I haven't done. Nonetheless, I include all the plots because they are pretty. The files included below are:

  • DitherLock_sweep: Sweep of the IN2/IN1 for the dither lock error point showing 600 Hz UGF
  • HiResPZTDither_sweep: Sweep of the PZT dither input compared to the PDH error signal. I restarted the front end before the sweep was finished accounting for the blip.
  • HiResPZTDither_sweep2: Finish of the PZT dither sweep


More will be posted later.
Attachment 1: 071103_DitherLock_sweep.png
071103_DitherLock_sweep.png
Attachment 2: 071103_DitherLock_sweep.pdf
071103_DitherLock_sweep.pdf
Attachment 3: 071103_HiResPZTDither_sweep.png
071103_HiResPZTDither_sweep.png
Attachment 4: 071103_HiResPZTDither_sweep.pdf
071103_HiResPZTDither_sweep.pdf
Attachment 5: 071103_HiResPZTDither_sweep2.png
071103_HiResPZTDither_sweep2.png
Attachment 6: 071103_HiResPZTDither_sweep2.pdf
071103_HiResPZTDither_sweep2.pdf
  60   Sun Nov 4 23:22:50 2007 waldmanUpdateOMCOMC PZT and driver response functions
I wrote a big long elog and then my browser hung up, so you get a less detailed entry. I used Pinkesh's calibration of the PZT (0.9 V/nm) to calibrate the PDH error signal, then took the following data on the PZT and PZT driver response functions.:

  • FIgure 1: PZT dither path. Most of the features in this plot are understood: There is a 2kHz high pass filter in the PZT drive which is otherwise flat. The resonance features above 5 kHz are believed to be the tombstones. I don't understand the extra motion from 1-2 kHz.
  • Figure 2: PZT dither path zoom in. Since I want to dither the PZT to get an error signal, it helps to know where to dither. The ADC Anti-aliasing filter is a 3rd order butterworth at 10 kHz, so I looked for nice flat places below 10 KHz and settled on 8 kHz as relatively harmless.
  • Figure 3: PZT LSC path. This path has got a 1^2:10^2 de-whitening stage in the hardware which hasn't been digitally compensated for. You can see its effect between 10 and 40 Hz. The LSC path also has a 160 Hz low path which is visible causing a 1/f between 200 and 500 Hz. I have no idea what the 1 kHz resonant feature is, though I am inclined to point to the PDH loop since that is pretty close to the UGF and there is much gain peaking at that frequency.
Attachment 1: 071103DitherShape.png
071103DitherShape.png
Attachment 2: 071103DitherZoom.png
071103DitherZoom.png
Attachment 3: 071103LSCShape.png
071103LSCShape.png
Attachment 4: 071103DitherShape.pdf
071103DitherShape.pdf
Attachment 5: 071103DitherZoom.pdf
071103DitherZoom.pdf
Attachment 6: 071103LSCShape.pdf
071103LSCShape.pdf
Attachment 7: 071103LoopShape.pdf
071103LoopShape.pdf
  63   Mon Nov 5 14:44:39 2007 waldmanUpdateOMCPZT response functions and De-whitening
The PZT has two control paths: a DC coupled path with gain of 20, range of 0 to 300 V, and a pair of 1:10 whitening filters, and an AC path capacitively coupled to the PZT via a 0.1 uF cap through a 2nd order, 2 kHz high pass filter. There are two monitors for the PZT, a DC monitor which sniffs the DC directly with a gain of 0.02 and one which sniffs the dither input with a gain of 10.

There are two plots included below. The first measures the transfer function of the AC monitor / AC drive. It shows the expected 2 kHz 2d order filter and an AC gain of 100 dB, which seems a bit high but may be because of a filter I am forgetting. The high frequency rolloff is the AA and AI filters kicking in which are 3rd order butters at 10 kHz.

The second plot is the DC path. The two traces show the transfer function of DC monitor / DC drive with and with an Anti-dewhitening filter engaged in the DC drive. I fit the antidewhite using a least squares routine in matlab constrained to match 2 poles, 2 zeros, and a delay to the measured complex filter response. The resulting filter is (1.21, 0.72) : (12.61, 8.67) and the delay was f_pi = 912 Hz. The delay is a bit lower than expected for the f_pi = 3 kHz delay of the AA, AI, decimate combination, but not totally unreasonable. Without the delay, the filter is (1.3, 0.7) : (8.2, 13.2) - basically the same - so I use the results of the fit with delay. As you can see, the response of the combined digital AntiDW, analog DW path is flat to +/- 0.3 dB and +/- 3 degrees of phase.

Note the -44 dB of DC mon / DC drive is because the DC mon is calibrated in PZT Volts so the TF is PZT Volts / DAC cts. To calculate this value: there are (20 DAC V / 65536 DAC cts)* ( 20 PZT V / 1 DAC V) = -44.2 dB. Perfect!

I measured the high frequency response of the loop DC monitor / DC drive to be flat.
Attachment 1: 07110_DithertoVmonAC_sweep2-0.png
07110_DithertoVmonAC_sweep2-0.png
Attachment 2: 071105_LSCtoVmonDC_sweep4-0.png
071105_LSCtoVmonDC_sweep4-0.png
Attachment 3: 07110_DithertoVmonAC_sweep2.pdf
07110_DithertoVmonAC_sweep2.pdf 07110_DithertoVmonAC_sweep2.pdf
Attachment 4: 071105_LSCtoVmonDC_sweep4.pdf
071105_LSCtoVmonDC_sweep4.pdf 071105_LSCtoVmonDC_sweep4.pdf
  79   Wed Nov 7 14:01:31 2007 waldmanOmnistructureOMCFrequency and Intensity noise
One of the biggest problems I had using the PZT to lock was excessive noise. I did a little noise hunting and found that the problem was the cable running from the rack to the laser fast input. As a reminder, the laser has a 4 MHz / volt fast input. We require about 300 MHz to go one FSR, so there is a Thorlabs HV box between at the NPRO fast input which takes 0-10 V -> 0-150 V. The 150 V HV range is worth about 600 MHz of NPRO frequency.

OLD SETUP: Single side of DAC differential (10 Vpp) -> 9V in series with 10 kOhm -> 10 kOhm input impedance of Thorlabs HV -> NPRO

We used the single side of the DAC differential because we didn't have a differential receiver. This turned out to be a bad idea because the cable picks up every 60 Hz harmonic known to man kind.

NEW SETUP: Digital conditioning -> DAC differential (digitally limited to 0 - 1 V) -> SR560 in A-B mode gain 10 (0 - 10 V output)-> Thorlabs HV -> NPRO.

This has almost no 60 Hz noise and works much, much better. Moral of the story, ALWAYS USE DIFFERENTIAL SIGNALS DIFFERENTIALLY !

Note that I may be saturating the SR560 with 10 V output, Its spec'd for 10 Vpp output with 1 VDC max input. I don't know whether or not it can push 10 V out....
  86   Fri Nov 9 00:01:24 2007 waldmanOmnistructureOMCOMC mechanical resonances (Tap tap tappy tap)
[Pinkesh, Aidan, Sam]

We did a tap-tap-tappy-tap test of the OMC to try to find its resonances. We looked at some combination of the PDH error signal and the DCPD signal in a couple of different noise configurations. The data included below shows tapping of the major tombstone objects as well the breadboard. I don't see any strong evidence of resonances below the very sharp resonance at 1300 Hz (which I interpret as the diving board mode of the breadboard). If I get free, I 'll post some plots of the different breadboard resonances you can excite by tapping in different places.

(The "normalized" tapping response is abs(tap - reference)./reference.)
Attachment 1: Fig1.png
Fig1.png
Attachment 2: Fig2.png
Fig2.png
Attachment 3: Fig4.png
Fig4.png
Attachment 4: Fig2.pdf
Fig2.pdf
Attachment 5: Fig1.pdf
Fig1.pdf
Attachment 6: Fig4.pdf
Fig4.pdf
Attachment 7: ResonanceData.zip
  179   Fri Dec 7 11:33:24 2007 waldmanOmnistructureOMCPZT wiring
The 2 pin LEMO connector has got an unmarked pin and a pin marked by a white half-circle.
The unmarked pin is connected to the side of the PZT attached to the mirror.
The marked pin is connected to the side of the PZT attached to the tombstone.
  206   Thu Dec 20 19:05:34 2007 waldmanHowToOMCHOWTO build front ends
For instance, to build the TPT front end code.

  • Save your file /cvs/cds/advLigo/src/epics/simLink/tpt.mdl
  • go to /cvs/cds/advLIGO on the TPT machine
  • do make clean-tpt tpt install-tpt
  • do rm /cvs/cds/caltech/chans/daq/C2TPT.ini (this step is needed because the DAQ install code isn't quite right at the time of this writing.
  • do make install-daq-tpt
  • run starttpt to restart the tpt computer.

Enjoy.
  207   Thu Dec 20 19:10:03 2007 waldmanUpdateOMCStressful reattachment of heater
Photos may follow eventually, but for now here's the rundown. I scraped the heater clean of the thermal epoxy using a clean razor blade. Then I stuffed a small piece of lint free cloth in the OTAS bore and wrapped the OMC in tin foil. With a vacuum sucking directly from the face of the OTAS, I gently scraped the glue off the OTAS aluminum. I wiped both the OTAS and the heater down with an isoproponal soaked lint-free cloth. I put a thin sheen of VacSeal on the face of the heater, wiping off the excess from the edges with a cloth. Then I clamped the heater to the OTAS using 2" c-clamps from the tombstone back to the heater front, making sure the alignment of the OTAS was correct (connector on the absolute bottom, concentric with the OTAS outer diameter). I added a second clamp, then beaded the outside of the joint with a little bit extra VacSeal, just for kicks. I'll leave it covered at least overnight, and maybe for a day or two.

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

  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
  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
  12242   Tue Jul 5 14:12:56 2016 varunUpdateElectronicsAntialiasing Filter Update

I am trying to design an antialiasing filter, which also has two switchable whitening stages. I have designed a first version of a PCB for this.

The board takes differential input through PCB mountable BNCs. It consists of an instrumentaiton amplifier made using quad opamp ADA4004, followed by two whitening blocks, also made using ADA4004, which can be bypassed if needed, depending upon a control input. The mux used for this purpose is Maxim MAX4158EUA. These two whitening blocks are followed by 2 the LPF stages. A third LPF stage could be added if needed. These use AD829 opamps. After the LPFs are two amplifiers for giving a differential output through two output BNCs. The schematic is shown in attachment 1: "AA.pdf". The top layers of the layout are shown in attachment 2 (AAtop.pdf), the bottom layers in attachment 3 (AAbottom.pdf), and the entire layout in attachment 4 (AAbrd.pdf). 

The board has 6 layers (in the order from top to bottom):

1) Top signal layer; 

2) Internal plane 1 (GND),

3) Internal plane 2 (+15V),

4) Internal plane 3 (-15V),

5) Internal plane 4 (GND),

6) Bottom signal layer. 

Power: +15, -15 and GND is given through a 4 pin header connector. 

The dimensions of the board are 1550 mil \times 6115 mil (38.1mm\times155.3mm) and the overall dimensions including the protruding BNC edges are 1550 mil \times 7675 mil (38.1mm\times194.9mm)

I would like to have inputs on the layout telling me if any component/trace needs to be changed/better placed, any other things about the board need to be changed, etc.

 

P.S.: I have also added a zipped folder "AA.zip" containing the schematic and board files, as well as the above pdfs.

Attachment 1: AA.pdf
AA.pdf
Attachment 2: AAtop.pdf
AAtop.pdf
Attachment 3: AAbottom.pdf
AAbottom.pdf
Attachment 4: AAbrd.pdf
AAbrd.pdf
Attachment 5: AA.zip
  12266   Thu Jul 7 12:44:52 2016 varunUpdateCDSDAFI update

Attached is a diagram, showing the entire (planned) signal flow of the DAF model. Some thoughts on the implementation after discussion with eric:

1) Since the LSC control signals and ASC signals are running on the c1lsc FE at the same rate as DAFI (16kHz), it would be wise to start from these.

   Current implementation: has a matrix at the end of the LSC PD signals, which selects one of the PD signals and outputs it to the DAFI via IPC communication.

    Proposed Changes: Add another matrix at the end of the LSC PD signals, to give to the second stereo output. Similarly, add two matrices each at the end of the LSC control signals and     the ASC signals. Each matrix must select one of the signals and output it to the DAF via IPC.

2) The PEM running on the c1sus FE system will have to be brought to DAFI in a similar fashon. However, since c1sus runs at 2kHz, there is a possibility of imaging while the signal is    transfered to the DAFI. This could be taken care of by an anti imaging filter, or inserting zeros between two samples coming at to the 16 kHz system from the 2kHz system and then low-passing it to remove the aliased parts. (similar to upsampling)

3) For the SUS control signals, input can be given from a matrix prepared for each optic seperately.

Attachment 1: DAFI.pdf
DAFI.pdf
  12282   Fri Jul 8 22:26:03 2016 varunUpdateCDSDAFI Update: Changes in LSC model

I have added the control signals DARM_CTRL, MICH_CTRL, PRCL_CTRL, SRCL_CTRL, CARM_CTRL, XARM_CTRL, YARM_CTRL, MC_CTRL to the DAFI model from the LSC model via IPC commn.

The changes done to the LSC model include addition of an extra block going to DAFI (attachment 2, red rectangle in attachment 1), and addition of an extra overall output from the LSC, called DAFI_OUT2, which goes to DAFI through IPC link C1:LSC-DAF_2 (attach. 3). Now two distinct inputs can be given to the DAFI, whose intended purpose is to act as two distinct audio signals in the stereo output, but can also be used for arbitrary math. 

I am going to add the following PEM channels as DAF inputs subsequently, in a similar 2 input fashon.

SEIS_GUR1_X_OUT
SEIS_GUR1_Y_OUT
SEIS_GUR1_Z_OUT
SEIS_GUR2_X_OUT
SEIS_GUR2_Y_OUT
SEIS_GUR2_Z_OUT
SEIS_STS_1_X_OUT
SEIS_STS_1_Y_OUT
SEIS_STS_1_Z_OUT
ACC_MC1_X_OUT 
ACC_MC1_Y_OUT
ACC_MC1_Z_OUT
ACC_MC2_X_OUT
ACC_MC2_Y_OUT
ACC_MC2_Z_OUT

 

 

Attachment 1: lsc.png
lsc.png
Attachment 2: lsctodaf.png
lsctodaf.png
Attachment 3: lsctodaf1.png
lsctodaf1.png
  12287   Sun Jul 10 20:08:44 2016 varunUpdateCDSDAFI Update: Changes in LSC and PEM models

I have added the PEM signals mentioned in the previous elog as DAF inputs through PCIE IPC, and compiled and restarted the c1pem and c1daf models. 

Attached are the pictures of the simulink diagram of the addition in the PEM and the DAF. 

Since the signals are moving from a 2kHz clock rate machine to a 16kHz clock rate machine, some imaging effects are possible, which I have to look into.

Attachment 1: pemtodaf.png
pemtodaf.png
Attachment 2: pemindaf.png
pemindaf.png
  12303   Thu Jul 14 23:38:59 2016 varunUpdateCDSc1lsc FE unresponsive

Today, at around 10:30, c1lsc machine froze and stopped responding to ping and ssh after I compiled and restarted c1daf. I think it is due to a large array in one of my codes. The daqd.log file shows the following:


..................................................................
CA.Client.Exception...............................................
    Warning: "Virtual circuit unresponsive"
    Context: "c1lsc.martian.113.168.192.in-addr.arpa:5064"
    Source File: ../tcpiiu.cpp line 945
    Current Time: Thu Jul 14 2016 22:27:42.102649102
..................................................................

I think the c1lsc FE may need a hard reboot.

  12304   Fri Jul 15 12:21:28 2016 varunUpdateCDSc1lsc FE unresponsive

c1lsc is up and running, Eric did a manual reboot today.

Quote:

Today, at around 10:30, c1lsc machine froze and stopped responding to ping and ssh after I compiled and restarted c1daf. I think it is due to a large array in one of my codes. The daqd.log file shows the following:


..................................................................
CA.Client.Exception...............................................
    Warning: "Virtual circuit unresponsive"
    Context: "c1lsc.martian.113.168.192.in-addr.arpa:5064"
    Source File: ../tcpiiu.cpp line 945
    Current Time: Thu Jul 14 2016 22:27:42.102649102
..................................................................

I think the c1lsc FE may need a hard reboot.

 

  12307   Sat Jul 16 00:30:42 2016 varunUpdateCDSDAFI update: Frequency warping | c1lsc unresponsive

Summary: I am trying to implement frequency warping/pitch shifting on the real time FE. Here is a description long overdue:

Description: The overall idea is as follows:

The DFT of a frame x_i[n]  is given by X_i[k] = \sum_{n=0}^{m-1}x_i[n]e^{-j2\pi \frac{kn}{m}}. A matrix W containing all W_{kn} = e^{-j2\pi \frac{kn}{m}} for k, n = 1, 2, ..., m can be calculated and predefined in the code. The input arrival rate is 16384 Hz, i.e. once in every 60 $\mu$s time window. Hence, the fourier coefficients can be updated cumulatively in each cycle using the current value of the input, previous value of the fourier coefficient and the components of the W matrix. This will distribute the computational load of the FFT into all the time windows. Similar operations can be carried out for the inverse STFT.

I have written and run a pseudo-real time code on my CPU. The following is the essence:
 Let the frame-length be M, and the intended scale factor of the frequency warping be 'r'. The frame overlap is 50%. At each clock cycle, the following tasks are performed:  (1 to 3 are routine tasks performed at every clock cycle, 4 is a special task performed only when a frame is filled.)
 1) Take input and apply hanning window to it.
 2) Cumulate X_i[k] for every k using the value of x_i[n] (the input) at that particular instant. Also start to cumulate X_{i+1}[k], which will be later transfered to X_i[k].
 3) Because of 4), we now have 'r+1' filled frames corresponding to output fft. Now take the ifft using two consecutive frames corresponding to only two time series points. The computations required for this task are the same as the computations required for calculation of the fourier coefficients iteratively, since the entire time series ifft is not computed.
 4) Do these special tasks after each frame gets filled:
      At this point, the ffts of the current frame and a previous frame is ready. Let us call them X1 and X2.
      Calculate phase difference between the two.
      Calculate all the interpolated |Y_i| in between these two frames depending upon the scale factor.
      Assign phase of X1 to first Y frame and assign increasing phase to all the other Y frames.
      and also do all the usual non-special tasks.

This code takes about 9-10 microseconds for a cycle with special tasks, and 5-6 microseconds for a cycle with routine tasks on my laptop (brought down from 100 microseconds peak time in the earlier offline implementation due to elemination of explicit dft and reduction in fft size), for a frame size of 32 samples. However, when fed into the c1lsc FE, it crashes, as it has done once again today evening, in the same fashon as yesterday. There could be 2 possible reasons:

1) Size of the array containing the W_{kn} matrix elements is too large for the FE memory,

2) the computations are taking up more than 60 microseconds.

Since there are already a few codes with similar array sizes, I am more inclined to think that 2) is more likely.

Another problem that I am anticipating is that for a 32 point dft and a sampling rate of 16kHz, the frequency resolution achieved is about 500 Hz, which is not sufficient if we need to represent seismic signals. The only way I can think of, for representing such signals with a small number of fft points, is to reduce the effective sampling rate, i.e. do DSP on inputs at a much lower rate than 16kHz (say 1kHz, which will give a resolution of ~30 Hz, or 2kHz giving a resolution of ~60Hz). Another advantage of this method is that it frees up more clock cycles for computation, thus the computational load can be further distributed.  The problem in this implementation is that it will increase the delays.

  12309   Mon Jul 18 18:44:52 2016 varunUpdateCDSc1lsc FE recovered

c1lsc FE is up and running.

Details:

2) The machine was manually rebooted.

3) c1daf was recompiled and installed, with the problematic piece of code removed.

4) NTP timing was adjusted.

5) Frame Builder was restarted.

6) All models on c1lsc machine were restarted.

Attachment 1 shows the CDS status after the recovery. I wont be trying to run frequency warping immediately, I will first finish implementing the other harmless modules first.

Attachment 1: CDS_status160718.png
CDS_status160718.png
  12319   Thu Jul 21 12:03:35 2016 varunUpdateCDSDAFI update: Humming noise in DAFI output

 

Summary: There was always a constant humming noise in the output of speakers of both the audio channels. Tried to resolve the problem. Details are given below:

Details: The source of the noise was the typical 60 Hz (and harmonics), ~13 mV peak to peak output, in at least three channels of the DAC. (two coming from the DAF module, and one not related to the DAF.) Attachment 1 shows the noise in both the DAF channels. As compared to that, the signal coming through the AGC weak, about 6 mV RMS, about the same order as noise. In order to resolve this, the gain of the AGC was increased, so that the RMS output voltage of the Fibox (FBAO, the one at the output) was about 1.23 V RMS. It is approximately equal to +4 dBu, which is the typical expected output of the Fibox, according to the datasheet.

Attachment 1: New_Doc_13.pdf
New_Doc_13.pdf New_Doc_13.pdf
  12320   Thu Jul 21 14:27:24 2016 varunUpdateCDSDAFI Update: Arbitrary Math block

Summary: I have added an arbitrary math block to the DAFI model, which takes two inputs, say X and Y, and can perform various unary and binary operations on them:

Details:

  • Unary Operations:
  1. Delay - There exists a text-based input to specify the amount of delay to be given to a particular signal.
  2. sin()
  3. cos()
  • Binary Operations:
  1. Weighted addition and multiplication: The output is calculated according to the relation: A*X + B*Y + C*X*Y. A, B, C are constant inputs, which can be given through text-based inputs in the GUI.
  2. MAX{X,Y}
  3. MIN{X,Y}

Attachment 1 shows the existing DAFI gui, updated with cascading of various DSP blocks, upto three levels, button-based ENABLE and DISABLE controls for all blocks except arb. math (the control on arb. math. is achieved by clicking on the block.) On clicking the arb. math block one is taken to the dedicated arb. math screen, which has enable buttons for all the processes listed above. A screenshot of this screen is in attachment 2. There is one control input, which controls all the unary operations on X and the binary operations on X and Y, and another control input which controls the unary operations on Y. switching on a particular arb. math process gives a particular control input, which choses the appropriate section of the code. At a time, only one process from the top grey block (corresponding to unary operations on X and binary operations on X and Y) and one process from the bottom grey block (corresponding to unary operations on Y) can be selected. Thus, the outputs which go from the arb. math block to the intermediate matrices (MATRIX1L or MATRIX2L) are:

a) Either an output of unary operation on X or a binary operation on X and Y, the specific one depending upon the control input,

    and

b) Output of a unary operation on Y, again the specific one depending upon the control input

Thus there is apparent asymmetricity in the action of the arb. math block on the two inputs. However, this is done in order to reduce to total number of outputs and control signals, and this can be easily taken care of by interchanging the inputs before the block. 

While compiling this code, the c1lsc machine had crashed once, it was found that this was due to a stray "printf()" command in the c code. This glich in the code now stands rectified  There is a possibility that the previous incidents of the code crashing could also be due to the existence of a printf() command. 

Preliminary Testing: I have done a preliminary testing of the arb math block, i.e. verified that on enabling the sin and cos processes, the output is less that 1, on swithching on the process of weighted avarage and multiplication, the output looks like it is right, for a few simple values of A, B, C, like 0, 1, etc. The delay block however is giving zero output for delay of more than 6 samples.

 

 

 

 

Attachment 1: dafioverview.png
dafioverview.png
Attachment 2: arbmath.png
arbmath.png
  12321   Thu Jul 21 15:03:13 2016 varunUpdateCDSDAFI Update

1) I have added the status summary of the DAFI block to the main FE status overview screen in the c1lsc cloumn. (attachment 1)

2) I have edited all the kissel matrix buttons appropriately, and given them appropriate lables. (attachment 2)

Attachment 1: festatus.png
festatus.png
Attachment 2: matrices.png
matrices.png
  12324   Thu Jul 21 22:02:35 2016 varunUpdateCDSDAFI update: Frequency warping

The code for frequency warping contained a "printf()" command, which had caused the system to crash in one another instance (refer elog 12320) . Hence, I tried running the code tody by removing this line. Unfortunately, this did not work. the model still crashed. Attached is the screenshot of the FE status.

Attachment 1: 07212016.png
07212016.png
  3897   Thu Nov 11 15:27:43 2010 valera, steveConfiguration ISS AOM installed

 We installed the ISS AOM in the PSL. The AOM was placed right after the EOM. The beam diameter is ~600 um at the AOM. The AOM aperture is 3 mm.

We monitored the beam size by scanning the leakage beam through the turning mirror after the AOM. The beam diameter changed from 525 um to 515 um at a fixed point. We decided that the AOM thermal lensing is not large enough to require a  new scan of the mode going into the PMC and we can proceed with PMC mode matching using the scan that was taken without the AOM (to be posted).

  5010   Thu Jul 21 09:04:59 2011 valera, steveUpdateSUSoplev gains were not optimized

 

Hi Steve,

 
I did change the ETMY optical lever configuration: http://131.215.115.52:8080/40m/4795
And I left it in that state per Jamie's request.
 
I was going to work on the servo tuning but found that the whitening was not working at that time.
What I was going to do is to measure the open loop gain to make sure the servo is stable, then 
measure the noise and minimize the rms motion by tuning the gain and the filter transfer function.
 
I plan to come to the 40m lab on August 22 for two weeks.
 
Valera.
  3038   Wed Jun 2 18:36:20 2010 valeraDAQCDSNoise generators in LSP

Alex wrote a new code to implement LSP noise generator. The code is based on 64 bit random number generator from Numerical Recipes 3rd ed ch 7.1 (p 343).

Joe made two instances in the LSP model.

The attached plot shows the spectra and coherence of two generators. The incoherence is ~1/Navg - statistically consistent with no coherence.

Attachment 1: noisegenerators.pdf
noisegenerators.pdf
  3048   Thu Jun 3 22:33:31 2010 valeraSummaryCDSsimulated plant work

 I put matlab files and a summary into the 40m wiki for the fitting of the 40m Optickle transfer functions and generating digital filters for the simulated plant:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Generating_DOF-%3EPD_digital_filters_based_on_Optickle_modeling

The filters are not loaded yet. Joe and Alex will make a rcg code to make a matrix of filters (currently 5x15=75 elements) which will enable the simulated plant tf's.

Joe and I tried to put a signal through the DARM loop but the signal was not going through the memory location in the scx part of the simulated plant.

 

Edit by Joe:

I was able to track it down to the spx model not running properly.  It needed the Burt Restore flag set to 1.  I hadn't done that since the last rebuild, so it wasn't actually calculating anything until I flipped that flag.  The data is now circulating all the way around.  If I turn on the final input (the same one with the initial 1.0 offset), the data circulates completely around and starts integrating up.  So the loop has been closed, just without all the correct filters in.

  3070   Fri Jun 11 22:09:58 2010 valeraHowToCDSfoton

 It appears that foton does not like the unstable poles, which we need to model the transfer functions.

But one can try to load the filters into the front end by generating the filter file e.g.:

#
# MODULES DARM_ASDC
 
#
################################################################################
### DARM_ASDC                                                                   ###
################################################################################
# SAMPLING DARM_ASDC  16384
# DESIGN   DARM_ASDC  
### ####
DARM_ASDC  0 21 6  0  0 darm 1014223594.005454063416 -1.95554205062071  0.94952075557861 0.06176931505784 -0.93823068494216
                         -2.05077577179611   1.05077843532639  -2.05854170261687  1.05854477394411
                         -1.85353637553024   0.86042048250739  -1.99996540107622  0.99996542454814 
                         -1.93464836371852   0.94008893626414  -1.89722830906561  0.90024221050918
                         -2.04422931770060   1.04652211283968  -2.01120153956052  1.01152717233685 
                         -1.99996545575365   0.99996548582538  -1.99996545573320  0.99996548582538

 

 

 

Unfortunately if you open and later save this file with foton it will strip the lhp poles.

  3074   Sun Jun 13 08:28:44 2010 valeraUpdateLocking40m Upgrade Optickle Model

 In my calculation of the digital filters of the optical transfer functions the carrier light is resonant in coupled cavities and the sidebands are resonant in recycling cavities (provided that macroscopic lengths are chosen correctly which I assumed).

  3558   Sat Sep 11 22:42:07 2010 valeraUpdatePSLPSL update

- The PMC REFL PD was moved from the temporary location to the one called for by the PSL layout (picture attached). The leakage beams were dumped.

- The FSS reference cavity was aligned using temporary periscope and scanned using NPRO temperature sweep. The amplitude of the sweep (sine wave 0.03 Hz) was set such that the PMC control voltage was going about 100 V p-p with. With rough alignment the visibility was as high as 50% - it will be better when the cavity is locked and better aligned but not better than 80% expected from the mode astigmatism that Tara and I measured on Thursday. The astigmatism appear to come from the FSS AOM as it depends on the AOM drive. We reduced the drive control voltage from 5 V to 4V beyond that the diffraction efficiency went below 50%. The FSS REFL PD was set up for this measurement as shown in the attached picture. There is also a camera in transmission not shown in the picture.

Attachment 1: DSC_2502.JPG
DSC_2502.JPG
Attachment 2: DSC_2505.JPG
DSC_2505.JPG
  3560   Sun Sep 12 23:02:53 2010 valeraUpdate PMC mode matching

Kiwamu and I found that the first lens in the PMC mode matching telescope was mislabeled. It is supposed to be PLCX-25.4-77.3-C and was labeled as such but in fact it was PLCX-25.4-103.0-C. This is why the PMC mode matching was bad. We swapped the lens for the correct one and got the PMC visibility of 82%. The attached plot shows the beam scans before and after the PMC. The data were taken with the wrong lens. The ABCD model shown in the plot uses the lens that was there at the time - PLCX-25.4-103.0-C. The model for the PMC is just the waist of 0.371 mm at the nominal location. The snap shot of the ABCD file is attached. The calculation includes the KTP for FI and LiNb for EOM with 4 cm length. The distances are as measured on the table.

Attachment 1: pmc.pdf
pmc.pdf
Attachment 2: pmc-abcd.tiff
  3561   Sun Sep 12 23:16:52 2010 valeraUpdate FSS mode matching

The attached plot shows the beam scans of the beam leaking from the back mirror of the PMC to the BS cube that first turns the S-pol beam 90 deg to the AOM and then transmits the AOM double passed and polarization rotated P-pol beam to the reference cavity. The beam from the PMC is mode matched to the AOM using a single lens f=229 mm. The ABCD file is attached. The data were taken with VCO control voltage at 5 V. We then reduced the voltage to 4 V to reduce the astigmatism. Tara has the data for the beam scan in this configuration in his notebook.

The beam from AOM is mode matched to the reference cavity using a single lens f=286.5 mm. The ABCD file is attached.

Attachment 1: fss.pdf
fss.pdf
Attachment 2: fssaom-abcd.tiff
Attachment 3: fssrc-abcd.tiff
  3574   Wed Sep 15 01:58:28 2010 valeraUpdatePSLFSS locking

The RefCav is locked and aligned. I changed the fast gain sign by changing the jumper setting on the TTFSS board. The RefCav visibility is 70%. The FSS loop ugf is about 80 kHz (plot attached. there is 10 dB gain in the test point path. this is why the ugf is at 10 dB when measured using in1 and in2 spigots on the front of the board.)  with FSS common gain max out at 30 dB. There is about 250 mW coming out of the laser and 1 mW going to RefCav out of the back of the PMC. So the ugf can be made higher at full power. I have not made any changes to account for the PMC pole (the FSS is after the PMC now). The FSS fast gain was also maxed out at 30 dB to account for the factor of 5 smaller PZT actuation coefficient - it used to be 16 dB according to the (previous) snap shot. The RefCav TRANS PD and camera are aligned. I tuned up the phase of the error signal by putting cables in the LO and PD paths. The maximum response of the mixer output to the fast actuator sweep of the fringe was with about 2 feet of extra cable in the PD leg.

I am leaving the FSS unlocked for the night in case it will start oscillating as the phase margin is not good at this ugf.

Attachment 1: DSC_2510.JPG
DSC_2510.JPG
  3579   Wed Sep 15 19:29:13 2010 valeraSummary PSL power budget
 Location  Power (mW)
 NPRO - after HWP  252
 Rejected by input FI polarizer  38
 After output FI polarizer  175
 Into PMC  164
 PMC reflected  37
 PMC transmitted  71
 PMC leakage  1.5
 After PMC TRANS PD/Camera BS

 1.2

 After RefCav EOM  1.1
 Into RefCav  0.3

 Notes:

- NPRO injection current 1.0 A

- PMC losses ~32%

- FSS AOM diffraction efficiency ~52%

  3580   Fri Sep 17 01:36:14 2010 valeraUpdate PMC line width

The attached plots show the PMC cavity line width measurement with 1 mW and 160 mW into the PMC. The two curves on each plot are the PMC transmitted power and the ramp of the fast input of the NPRO. The two measurements are consistent within errors - a few %. The PMC line width  3.5 ms (FWHM) x 4 V / 20 ms (slope of the ramp) x 1.1 MHz / V (NPRO fast actuator calibration from Innolight spec sheet) = 0.77 MHz.

Here is the output of the calculation using Malik Rakhmanov code:

 

modematching =  8.4121e-01

transmission1 =   2.4341e-03

transmission2 =   2.4341e-03

transmission3 =   5.1280e-05

averageLosses =  6.1963e-04

visibility =  7.7439e-01

Here are the inputs for the calculation in the param.m:

 

fw = 0.77e6;                % width of resonance (FWHM) in Hz

Plas = 0.164;                % power into the PMC in W

 

% the following number refer to the in-lock cavity state

 

Pref = 0.037;                % reflected power in W

Ptr = 0.0712;                 % transmitted power in W

Pleak = 0.0015;              % power leaking from back of PMC in W

 

 

Attachment 1: TEK00009.PNG
TEK00009.PNG
Attachment 2: TEK00010.PNG
TEK00010.PNG
  3899   Thu Nov 11 18:05:55 2010 valeraUpdatePSLPMC mode matching at full laser power

 The PMC mode matching was initially done at low power ~150 mW. It was expected and found that at full power ~2 W (injection current 2.1 A) the mode matching got much worse:

the visibility degraded from 80% to 50% (1 - refl locked/refl unlocked) . The thermal lensing could be in the laser, EOM, or FI.

The first attached plot shows the scan of the beam after the EOM at low and full laser power. At full power the waist position is 10 mm after the turning mirror after the EOM and the waist size is 310 um.

The second plot shows the ABCD calculation for the mode matching solution.

I removed the MM lens PLCX-25.4-77.3-C and placed the PLCX-25.4-180.3-UV about 20 mm after the first PMC periscope mirror (the second mirror after the EOM).

The PMC visibility improved to 94% and the power through the PMC, as measured by the PMC transmission PD, went up by a factor of 2.

Attachment 1: scan.pdf
scan.pdf
Attachment 2: pmc2-abcd.png
pmc2-abcd.png
  3913   Sat Nov 13 16:57:21 2010 valeraConfigurationElectronicsPRM Side OSEM transimpedance change

Now that we have increased the range of the AA to +/- 10 V I have increased the PRM side OSEM transimpedance from 29 kV/A to 161 kV/A by changing the R64 in the satellite box. The first attached plot shows the ADC input spectrum before and after the change with analog whitening turned off. The PD voltage readback went up from 0.75 to 4.2 V. The second attached plot shows the sensor, ADC, and projected shot noise with analog whitening turned on and compensated digitally. The ADC calibration is 20 V/ 32768 cts. The PRM damping loops are currently disabled.

I checked for oscillation by looking at the monitor point at the whitening board. There was no obvious oscillation on a scope - the signal was 20 mV p-p on 1 us scale which was very similar to the LL channel.

Attachment 1: PRM-SD-ADC.pdf
PRM-SD-ADC.pdf
Attachment 2: PRM-SD-Current.pdf
PRM-SD-Current.pdf
  3915   Sun Nov 14 11:56:59 2010 valeraUpdateCDSTest of ADC noise

 

We missed a factor of 2 in the ADC calibration: the differential 16 bit ADC with +/-10 V input has 20 V per 32768 counts (1 bit is for the sign). I confirmed this calibration by directly measuring ADC counts per V.

So the ADC input voltage noise with +/-10V range around 100 Hz is 6.5e-3 cts/rtHz x 20V/32768cts =  4.0 uV/rtHz. Bummer. 

The ADC quantization noise limit is 1/sqrt(12 fs/2)=1.6e-3 cts/rtHz. Where the ADC internal sampling frequency is fs=64 kHz. If this would be the limiting digitization noise source then the equivalent ADC input voltage noise would be 1 uV/rtHz with +/-10 V range.

  3933   Tue Nov 16 15:32:18 2010 valeraUpdateElectronicsOSEM noise at the output of the satellite box

 I measured the SRM OSEM (no magnets at the moment) noise out of the satellite box with a SRS785 spectrum analyzer. I inserted a break out board into the cable going from the satellite box to the whitening board. The transimpedances of the SRM OSEMs are still 29.2 kOhm. The DC voltages out of the SRM satellite box are about 1.7 V. The signal was AC coupled using SR560 with two poles at 0.03 Hz and a gain of 10.

The noise is consistent with the one measured by the ADC except for the 3 Hz peak which does not show up in the ADC spectrum from Sunday. The peak appears in several channels I looked at. The instrument noise floor was measured by terminating the SR560 with 50 Ohm.

I recommend to change all OSEM transimpedance gains from 29 to 161 kV/A. Beyond this gain one will rail the AA filter module when the magnet is fully out of the OSEM.

The OSEM noise at 1 Hz is about factor of 10 above the shot noise. The damping loops impress this noise on the optics around the pendulum resonance frequency. Also the total contribution to the MC cavity length is sqrt(12) time the single sensor as there are 12 OSEMs contributing to MC length. The ADC noise is currently close but never the less not limiting the OSEM noise below 100 Hz. It can be further reduced by getting an extra factor of 2-3 in whitening gain above ~0.3 Hz. The rms of the ADC input of the modified PRM SD (R64 = 161 kOhm) channel is 10-20 cts during the day with damping loop off and whitening on.

The transimpedance amplifier LT1125CS is also not supposed to be limiting the noise. At 1 Hz the 1/f part of the noise: In<1pA/rtHz and Vn<20nV/rtHz.

Attachment 1: osemnoise.pdf
osemnoise.pdf
  4335   Tue Feb 22 00:18:47 2011 valeraConfiguration c1ioo and c1ass work and related fb crashes/restarts

I have been editing and reloading the c1ioo model last two days. I have restarted the frame builder several times. After one of the restarts on Sunday evening the fb started having problems which initially showed up as dtt reporting synchronization error. This morning Kiwamu and I tried to restart the fb again and it stopped working all together. We called Joe and he fixed the fb problem by fixing the time stamps (Joe will add details to describe the fix when he sees this elog).

The following changes were made to c1ioo model:

- The angular dither lockins were added for each optics to do the beam spot centering on MC mirrors. The MCL signal is demodulated digitally at 3 pitch and 3 yaw frequencies. (The MCL signal was reconnected to the first input of the ADC interface board).

- The outputs of the lockins go through the sensing matrix, DOF filters, and control matrix to the MC1,2,3 SUS-MC1(2,3)_ASCPIT(YAW) filter inputs where they sum with dither signals (CLOCK output of the oscillators).

- The MCL_TEST_FILT was removed

The arm cavity dither alignment (c1ass) status:

- The demodulated signals were minimized by moving the ETMX/ITMX optic biases and simultaneously keeping the arm buildup (TRX) high by using the BS and PZT2. The minimization of the TRX demodulated signals has not been successful for some reason.

- The next step is to close the servo loops REFL11I demodulated signals -> TMs and TRX demodulated signals -> combination of BS and PZTs.

The MC dither alignment (c1ioo) status:

- The demodulated signals were obtained and sensing matrix (MCs -> lockin outputs) was measured for pitch dof.

- The inversion of the matrix is in progress.

- The additional c1ass and c1ioo medm screens and up and down scripts are being made.

ELOG V3.1.3-