40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 167 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  8499   Fri Apr 26 21:38:06 2013 JenneConfigurationRF SystemPD frequency response

I was sad to see that there wasn't a photo of the POX situation after the fiber work was done on Thursday.

Also, I was out looking at something else, and noticed that the fibers aren't in a very good/safe place from the POX table over to your splitter.  Getting to the POX table is certainly more tricky than the AP table, since the fiber splitter is right next to the AP table, but we should go back and try to make sure the fibers to the more distant tables are laid in a nice, safe way.

Is there a reason that we're not using the clear plastic tubing that Eric bought to put the fibers into?  It seems like that would help a lot in keeping the fibers safe.

I took a few photos of the things that I'm sad about:

1. We should not be keeping fibers on the floor in an area where they can be stepped on.  This will be fixed (I hope) as part of putting the extra coiled length over by the splitter.

IMG_0498.JPG

2. Again, in an area where we semi-regularly walk, the fibers should not be a tripping hazard.  Behind the table legs (rather than under the middle of the table) is safer, and will help tuck them out of the way.

IMG_0499.JPG

3.  It's not obvious when we're pumped down, but we remove the access connector (top right side of this photo), and need to walk in this area.  I can pretty much guarantee that within 1 day of the next time we vent, these fibers will be stepped on, tripped over, and broken if they are not moved to a different location.  I'm not yet sure what the best way to route these fibers is, but this is not it. 

IMG_0500.JPG

Riju, since Eric will be away next week, please let one of us "40m Regulars" know when you plan to come over (at least a few hours ahead of time), and we can give you a hand in protecting these fibers a little bit better.  Thanks!

  8506   Mon Apr 29 17:26:22 2013 RijuConfigurationRF SystemPD frequency response

 Today I have rerouted the fibers on AP table to remove the fiber rolls out of the AP table.  I removed the fibers one by one from both ends - from the 1x16 splitter and from the AP table - keeping the fiber roll intact, and then connected it in reverse way, i.e. the fiber end which was on AP table now is connected to the splitter (since length of the outside the roll is shorter that side) and the fiber end connected to splitter is now rerouted on AP table.

We need to keep the fibers in such a fashion so that no sharp bending occurs anywhere, and also it does not get strained due to its weight, particularly near the 1x16 splitter. Jenne suggested to use a plastic box over the splitter rack to keep the fiber rolls for time-being. We discussed a lot how this can be done nicely; in future we may use array of hooks, Koji suggested to use cable hangers and to tie the rolls using more than one hanging point, Jenne suggested to use the bottom shelf of the rack or to use one plastic box with holes. We tried to make holes on the plastic box using drill, but it developed crack on the box. So ultimately I used the opened box only and put it over the rack.

The corresponding photographs are attached herewith.

Tomorrow we will reroute the fibers for POX table.  

Attachment 1: IMG_0504.JPG
IMG_0504.JPG
Attachment 2: IMG_0503.JPG
IMG_0503.JPG
Attachment 3: IMG_0505.JPG
IMG_0505.JPG
Attachment 4: IMG_0506.JPG
IMG_0506.JPG
Attachment 5: IMG_0508.JPG
IMG_0508.JPG
Attachment 6: IMG_0509.JPG
IMG_0509.JPG
Attachment 7: IMG_0510.JPG
IMG_0510.JPG
  8512   Tue Apr 30 19:39:14 2013 RijuConfigurationRF SystemPD frequency response

Today I have rerouted the fibers on POX table. The aim was to lay it overhead through the plastic pipe. A pipe ~50ft (~15.5m) long was taken for this purpose. I disconnected the two 25m long fibers for POP55 and POX11 PD (those had been already routed) from both of their ends - i.e. from the POX table and also from 1x16 splitter. Jenne and Koji suggested that we may have another two PDs ( POP22 and POP110) on POX table in future. So we used another 25m long fiber for these two (POP22/POP110). We could not use two fibers for these two since we have only four 25m long fibers and one of them we need for POY11 PD on POY table. Jenne and me put the three fibers inside the pipe using a copper tube. The tube then was put on the overhead rack, Manasa helped me to do it. The fiber ends were finally laid on the POX table at one end and connected to the 1x16 splitter at the other end.

The corresponding photos are attached herewith.

Attachment 1: IMG_0511.JPG
IMG_0511.JPG
Attachment 2: IMG_0512.JPG
IMG_0512.JPG
Attachment 3: IMG_0513.JPG
IMG_0513.JPG
Attachment 4: IMG_0514.JPG
IMG_0514.JPG
Attachment 5: IMG_0515.JPG
IMG_0515.JPG
  8520   Wed May 1 17:36:26 2013 RijuConfigurationRF SystemPD frequency response

 Today I routed fiber from 1x16 splitter to POY table. Manasa helped me doing that. The fiber(25m) was laid on overhead rack through plastic pipe of length ~76ft. We put the fiber inside the pipe using one copper tube, and then tied the plastic pipe on the overhead rack. Finally one end of the fiber was laid on POY table and the other end was connected to the 1x16 splitter. The photographs corresponding are attached. There is no picture of splitter end, cause it was dark that time.

Attachment 1: IMG_0517.JPG
IMG_0517.JPG
Attachment 2: IMG_0518.JPG
IMG_0518.JPG
Attachment 3: IMG_0519.JPG
IMG_0519.JPG
  8573   Tue May 14 19:52:58 2013 RijuConfigurationRF SystemPD frequency response

 [Eric, Riju, Annalisa]

Today we have cleared up the fiber spool near AP table. We have put the 1x16 fiber splitter and a box (we made two openings on it) for fiber spool on a different part of the rack. Also put a plastic tubing or the fibers coming out of AP table. Now the fibers coming out from AP table and also from POX table first enter the box through one opening and the end of the fibers come out of the other opening to get connected to to splitter. Photographs of the work are attached. I don't think enough fiber is there to make a similar loop for fiber coming from POY table.

 

 

Attachment 1: IMG_0520.JPG
IMG_0520.JPG
Attachment 2: IMG_0521.JPG
IMG_0521.JPG
  7159   Mon Aug 13 12:17:41 2012 ManasaConfigurationIOOPD from AP table removed

The PD (pda255) at the AP table, close to the MC refl , which Steve mentioned to be not in use, has been removed from the table for testing.

  7205   Thu Aug 16 16:44:55 2012 ManasaConfigurationIOOPD from AP table removed

Quote:

The PD (pda255) at the AP table, close to the MC refl , which Steve mentioned to be not in use, has been removed from the table for testing.

 The PD installed at MC trans to make ringdown measurements has been replaced with the above PDA255. 

  8383   Mon Apr 1 16:24:09 2013 JamieFrogsLSCPD whitening switching fixed (loose connection at break-out box)

Quote:

We discovered that the analog whitening filter of the REFL55_I board is not switching when we operate the button on the user interface. We checked with the Stanford analyzer that the transfer function always correspond to the whitening on.

This turned out to just be a loose connection of the ribbon cable from Contec board in the LSC IO chassis at the BIO break-out box.  The DSUB connector at the break-out box was not strain relieved!  I reseated the connector and strain relieved it and now everything is switching fine.

20130401_161917.jpg

20130401_161858.jpg

I wonder if we'll ever learn to strain relieve...

  916   Wed Sep 3 18:45:01 2008 AlbertoConfiguration PD3 gain
Alberto, Yoichi,

We found that the PD3 servo was unstable with a gain of 1, so we switched it to 0.5
  348   Fri Feb 29 13:51:17 2008 JohnSummaryLSCPD6 response
I checked the response of PD6 using the AM laser. It looks happy enough.

16 averages
-10dBm source power
77.3mV dc on the diode
  349   Sun Mar 2 23:43:45 2008 ranaHowToLSCPD6 response
John's PD plotting script is superior to all of the ones we had before; lets make him post the script so we can all use it.

Looks like PD6 is not too happy after all; the 199 MHz response is not much higher than the 166 MHz response. I thought we were supposed to have them balanced to within 6 dB or so?
  1755   Thu Jul 16 01:00:56 2009 AlbertoUpdateLockingPD9 aligned

Quote:

Quote:

Since lately the alignment of the input beam to the interferometer has changed, I went checking the alignment of the beam on the photodiodea. They were all fine except for pd9, that is AS DD 199. Here the DC is totally null. The beam seems to go right on the diode but the scope on the PD's DC output shows no power. This is really strange and bad.

After inspecting PD9 with the viewer and the cards, the beam looks like it is aligned to the photodiode althought there is no signal at the DC output of the photodetector. So I checked the spectrum for PD9_i and Q (see attachments) and it seems that those channels are actually seeing the beam. I'm going to check the alignemtn again and see the efefct on the spectra to make sure that the beam is really hitting the PD.

 

 I aligned PD9. Here are the spectra confirming that.

p.s.
Ants, theyre everywhere, even inside the AS table. They're taking over the lab, save yourself!
Attachment 1: 2009-07-15_PD9spectrumPDF02.pdf
2009-07-15_PD9spectrumPDF02.pdf
  5794   Thu Nov 3 14:25:52 2011 kiwamuUpdateLSCPDA10A as POP22/110 : too small signal

It turned out that the signal was too small with PDA10A to detect the 22 and 110 MHz RF sidebands.

The DC output coming out from it was about half mV or so (corresponding to few uW in laser power) when the PRCL was locked to the carrier.

This is because PDA10A is a silicon detector which is more sensitive to visible light than IR.

The reason we chose PDA10A was that it has relatively a large diode size of 1 mm in diameter.

However according to the data sheet the responsibility at 1064 nm is about 0.05 A/W which is sad.

I will replace it by PDA10CF, which is made from InGaAs and supposed to have 10 times bigger responsibility.

Though the diode size will be half mm in diameter, which may require another strong lens in front of it.

Quote from #5788
 The POP22/110 RFPD has been installed. It is PDA10A from Thorlabs instead of the usual home-made RFPD.
  + Fine alignment

  5796   Thu Nov 3 16:31:47 2011 kiwamuUpdateLSCPDA10CF as POP22/110 : better

The POP22/110 RFPD has been replaced by PDA10CF. As a result the 22 and 110 MHz signals became detectable.

However the signal level maybe too low according to a quick look with an RF spectrum analyzer.

The level at 22 and 110 MHz were both approximately -70 dBm although these values were measured when the central part was freely swinging.

Perhaps we need to amplify the signals depending on the actual SNR.

 

 Also I have updated the optical tables' wiki page :

http://blue.ligo-wa.caltech.edu:8000/40m/Optical_Tables

Quote from #5794

I will replace it by PDA10CF, which is made from InGaAs and supposed to have 10 times bigger responsibility.

  15128   Wed Jan 15 16:54:51 2020 gautamUpdateGeneralPDA10CF removed from AS table

Per Yehonathan's request, I removed one PDA10CF from a pickoff of REFL on the AS table (it was being used for the mode spectroscopy project). I placed a razor beam dump where the PD used to be, so that when the PRM is aligned, this pickoff is dumped. This is so that team ringdowns can use a fast PD.

  7462   Tue Oct 2 14:20:33 2012 ManasaConfigurationIOOPDA255 not working

The PDA255 that Koji repaired is still not alright. It seems to be saturating again. I've left it in the PD cabinet where it is marked 'PDA 255'. I've asked Steve to order a fast PD at 150MHz, PDA10A because we don't seem to have any at the 40m.

  11   Wed Oct 24 01:43:32 2007 Andrey RodionovOtherGeneralPDF-file -> Will report about first results for XARM during Wednesday meeting

Here is the pdf-file with some graphs showing first results for XARM optimization.

We will discuss alltogether during our Wednesday meeting which starts at 2.40PM. Probably it would be necessary to project this pdf-file to the big screen,
so someone should bring laptop and probably connect it to the projector. I do not have a laptop.

See you on that meeting.
Attachment 1: Andrey_October_24.pdf
Andrey_October_24.pdf Andrey_October_24.pdf Andrey_October_24.pdf Andrey_October_24.pdf Andrey_October_24.pdf Andrey_October_24.pdf Andrey_October_24.pdf Andrey_October_24.pdf
  10229   Thu Jul 17 16:39:34 2014 NichinUpdateElectronicsPDFR debugging attempt : REFL11

In a attempt to debug the values of transimpedance generated by the PDFR system, I did a manual measurement for REFL11 PD.

  • Took the tops off AS and POY tables. (REFL11 and REF PD) Under the supervising eye of Manasa
  • Verify that no extra light is falling on REFL11.
  • Retake DC voltage readings, power readings.
  • Manually set the sweep parameters and record readings from network analyzer.
  • Put the tops back on the tables
  • Calculate transimpedance 

Results:

REF PD(1611):

Pinc = 1.12 mW                 T_dc = 10000 V/A (datasheet)

Vdc = 7.68 V                      T_rf = 700 V/A (datasheet)

Calculated Responsivity = 0.68 A/W (Which matches perfectly with the datasheet value of 0.68 A/W) 

REFL11:

Pinc = 0.87 mV             T_dc = 66.2 V/A (schematic)

Vdc = 32.5 mV      

Calculated Responsivity = 0.56 A/W

 

 

Network analyzer reading at 11 MHz : 0.42

Calculated RF Transimpedance = 460 V/A

40m Wiki : RF Transimpedance = 4 kV/A

I ran the same measurement using PDFR system and got the same results.

Attached: the automatic data and plot obtained.

Conclusion:  The PDFR system and manual measurements agree with each other. However the values do not match with 40m Wiki. I have no clue about which measurement is correct or any mistakes I might be making in the calculations. 

 

Attachment 1: REFL11_17-07-2014_154534.pdf
REFL11_17-07-2014_154534.pdf
Attachment 2: REFL11_17-07-2014_154534.zip
  10232   Thu Jul 17 17:39:57 2014 KojiUpdateElectronicsPDFR debugging attempt : REFL11

What is the coupling factor between the RF in and the RF mon of the demodulator?
I don't assume you have the same amount RF power at those two points unless you have an RF amplifier in the mon path.

  13955   Wed Jun 13 12:21:09 2018 gautamUpdateALSPDFR laser checkout

I want to use the Fiber Coupled laser from the PDFR system to characterize the response of the fiber coupled PDs we use in the BeatMouth. The documentation is pretty good: for a first test, I did the following in this order:

  • Removed the input fiber to the 1x16 splitter located in the rack near the OMC chamber.
  • Connected aforementioned fiber to a collimator.
  • Aligned the output of the collimator onto a razor beam dump.
  • Turned on the laser controller - it came on with a TEC temperature of 22.5 C and I_diode 0 mA, and the "output shorted" LED was ON (red).
  • Turned up the diode current to 80 mA, since the "threshold current" is stated as 75 mA in the manual. In fact, I could see a beam using an IR card at 30 mA already.
  • At 80mA, I measured 3.5 mW of output power using the Ophir.

Seems like stuff is working as expected. I don't know what the correct setpoint for the TEC is, but once that is figured out, the 1x16 splitter should give me 250 uW from each output for 4mW input. This is well below any damage threshold of the Menlo PDs. Then the plan is to modulate the intensity of the diode laser using the Agilent, and measure the optoelectronic response of the PD in the usual way. I don't know if we have a Fiber coupled Reference Photodiode we can use in the way we use the NF1611 in the Jenne laser setup. If not, the main systematic measurement error will come from the power measurement using a Fiber Power Meter.

  10305   Thu Jul 31 12:01:35 2014 NichinUpdateComputer Scripts / ProgramsPDFR update

The Transimpedance plots of PDFR now have a reference plot or baseline plot along with the current measurement, for easy comparision.

Current Work: Getting Matlab's vectfit3 to work simultaneously on the transimpedance readings and print the zeros and poles alongside the plots. 

Attachment 1: REFL11_31-07-2014_115010.pdf
REFL11_31-07-2014_115010.pdf
  10332   Tue Aug 5 17:24:37 2014 NichinUpdateComputer Scripts / ProgramsPDFR update

The PDFR system now has the capability to automatically run vectfit3.mat using a wrapper script named vectorfitzpk.m

This is done via a shell script being called from inside python that inturn runs the matlab script.

  10288   Tue Jul 29 18:58:57 2014 NichinUpdateComputer Scripts / ProgramsPDFR update and Test run

The PDFR system's interface and scripts have been updated to include quite a few more features.

On the interface side, there are buttons to open the previous plot for each PD and also a single button to run the scans on all PDs sequentially. The previous plot buttons actually open a softlink that is updated each time a measurement is taken.

Running a scan now pops up a terminal window to show messages that help understand whats going on.

16.png

In the background, the script now takes in the transfer function of the demodulator board in ZPK format and calibrates it out of each measurement. The parameters are given .dat files making it easier to replace the transfer function. (Remember my last elog which showed that the fitting of transfer functions were not really great and that I am going to use it anyway to get the script updated.)  Also, the script now takes the delay in the RF cables and calibrates out that as well. So we no longer have the huge phase variations and the phase related to transimpedance are visible.

A test run was conducted today. Plots attached.

NOTE: The test can be conducted only on REFL 11,33,55,165 , AS55, and POX11.

POY11 has an optical fiber routed from this system, but there is no space to actually illuminate this PD. So it is currently not included in our system, even though there is a button for this.

POP22 has a fiber illuminating it, but its a unknown broadband PD. I do not know it's DC transimpedance or other values. Its just of matter of updating a few files that feed it's parameters into PDFR.

However, for the above PDs, the demodulator boards have been fit to a transfer function and the script is ready to go as soon as the above problems are fixed.

Conclusion: The plots look noisy. But, the transimpedance now resembles the one on 40-m wiki for all the PDs, both the shape and values.

There will be some errors that are induced because of improper demodulator TF fitting. This has to be taken care of eventually.

Work remaining: Create a canonical set of plots for each PD and set them as the baseline. These canonical plots will be plotted along with each measurement for easy comparison.

A well documented manual for the whole system clearly explaining where and how it takes all the parameters into account so that anybody can easy update just the essential information.

Attachment 2: PDFR_testRun_29-07-2014.pdf
PDFR_testRun_29-07-2014.pdf PDFR_testRun_29-07-2014.pdf PDFR_testRun_29-07-2014.pdf PDFR_testRun_29-07-2014.pdf PDFR_testRun_29-07-2014.pdf PDFR_testRun_29-07-2014.pdf
  10355   Fri Aug 8 16:45:40 2014 NichinUpdateWikiPDFR wiki updated

 The PDFR system has been documented in the 40m wiki and all the relevant information about making changes and keeping it updated have been mentioned.

https://wiki-40m.ligo.caltech.edu/Electronics/PDFR_system

This pretty much wraps up my SURF 2014 project at the 40m lab. 

  10166   Wed Jul 9 17:34:11 2014 NichinUpdateElectronicsPDFR: Beam pointing adjustments and DC measurements

 [Nichin, Manasa]

AIM: Taking DC output readings with multimeter for each PD to create a database (required for transimpedance calculations), by taking off the table tops. Also, making sure each PD is illuminated properly.

What we did:

  • In rack 1Y1: Diode laser controller was set to 150.0 mA at all times. This gave powers in the neighbourhood of 1mW at the end of fibers illuminating all PDs. The laser outputs light of 1064nm wavelength. The laser was switched off in the end.
  • Checked the collimation of the fiber for each PD. In some cases they were not focused to give a sharp spot, so we had to unmount the fibers and fix it and mount them back. Manasa did it initially and I learnt how it was done properly. Eventually I got better and did it myself (under her supervision)
  • Set the mount alignment for maximum illumination of the PD.
  • Record the power falling on the laser and also the DC voltage output. Any light that did not come from my fiber was blocked when taking the readings and then unblocked. I also took care of offset voltage present when taking the DC readings.

Recorded measurements:

REFL11:   Pinc = 0.91 mW         VDC = 34.9 mV 

REFL33:   Pinc = 0.83 mW         VDC = 33.2 mV 

REFL55:   Pinc = 1.08 mW         VDC = 42.7 mV 

REFL165: Pinc = 0.79 mW         VDC = 115.3 mV

AS55:         Pinc = 0.78 mW         VDC = 31.3 mV

POX11:      Pinc = 0.83 mW         VDC = 34.7 mV

POP22**:   Pinc = 1.08 mW         VDC = 5.82 mV

POY11:      Not illuminated; there was no optical fiber mount. Although, there was a fiber near it with a cap on the end. It also looks like there is no space to put in a new mount near the PD. 

REF PD:    Pinc = 1.19 mW         VDC = 8.2 V     (REF PD = New focus 1611)

**Note: The current POP 22 PD does not have 2 different outputs for DC and RF signals. I unplugged the RF cable from the output, took readings with the multimeter and then plugged back the RF cable.

Further work:

I will calculate the responsivity for each PD and compare it to the expected values. 

  10183   Fri Jul 11 11:51:03 2014 NichinUpdateElectronicsPDFR: List of DC transimpedances

The following values are going to be entered in the param_[PDname].yml file for each PD. I am elogging them for future reference.

I got the values from combing schematics and old Elog entries. Please let me know if you believe the values are different.

  • AS55: 66.2 ohms
  • REFL11 : 66.2 ohms 
  • REFL33 : 50.2 ohms
  • REFL55: 50 ohms (Elog 4605)
  • REFL165: 50.2 ohms
  • POY11: 66.2 ohms
  • POX11: 50.2 ohms
  • REF (NF1611): 700 ohms
  • POP22: ?? (This is currently a Thorlab BBPD )
  2432   Sat Dec 19 14:33:25 2009 KojiConfigurationComputersPDFlib lite / gnuplot 4.2.6 on Rosalba/Allegra

In order to enable 'set terminal pdf' in gnuplot on Rosalba/Allegra, I installed PDFlib lite and gnuplot v4.2.6. to them.
(PDFlib lite is required to build the pdf-available version of gnuplot)


Installation of PDFlib lite:

  • Building has been done at rosalba
  • Download the latest distribution of PDFlib lite from http://www.pdflib.com/products/pdflib-7-family/pdflib-lite/
  • Expand the archive. Go into the expanded directory
          tar zxvf PDFlib-Lite-7.0.4p4.tar.gz
          cd ./PDFlib-Lite-7.0.4p4
  • configure & make
          ./configure
          make
  • install the files to the system / configure the dinamic linker
          sudo make install
          sudo ldconfig

Installation of gnuplot:

  • Building has been done at rosalba
  • Download the latest distribution of gnuplot form http://www.gnuplot.info/
  • Expand the archive. Go into the expanded directory
          tar zxvf gnuplot-4.2.6.tar.gz
          cd ./gnuplot-4.2.6.tar.gz
  • configure & make
          ./configure --prefix=/cvs/cds/caltech/apps/linux/gnuplot
          make
          make install
  • Create symbolic links of the executable at
          /cvs/cds/caltech/apps/linux/bin
          /cvs/cds/caltech/apps/linux64/bin
  • Note: Although the original (non-PDF) gnuplot is still at
          /usr/bin/gnuplot
    new one is active because of the path setting
          rosalba:linux>which gnuplot
          /cvs/cds/caltech/apps/linux64/bin/gnuplot

 

  11498   Wed Aug 12 14:35:46 2015 ericqUpdateComputer Scripts / ProgramsPDFs in ELOG

I've tweaked the ELOG code to allow uploading of PDFs by drag-and-drop into the main editor window. Once again we can bask in the glory of 

(You may have to clear your browser's cache to load the new javascript)

Attachment 1: smooth.pdf
smooth.pdf
  5808   Fri Nov 4 13:13:25 2011 ZachUpdateGreen LockingPDH box #17 modified, too

I also modified the Y-Arm PDH box itself slightly. Previously, there was a flying 10k resistor from the SWEEP input to TP2. I don't see the point of this, so I moved it from TP2 across R19 (to the same point where it is on the gyro PDH boxes) to allow for excitation signals to be injected with the loop closed (i.e., with the SWEEP switch off). This is useful for OLTF measurements.

  15218   Fri Feb 21 10:59:08 2020 shrutiUpdateALSPDH error signals?
Here are a few PDH error signals measured without changing the servo gain or phase from that optimized for 231.25 kHz. This was done by keeping the X arm cavity and laser unlocked but keeping the shutter for green open; so I did not force a frequency sweep but saw the unhindered motion of cavity wrt the laser using the PDH servo error monitor channel from the box (not sure if this is the best way to do it?).
 
Koji mentioned that there is a low pass filter with a cutoff frequency probably lower than 700 kHz which at the moment would hinder the efficacy of the locking at higher frequencies. The transfer function on the wiki suggests the same, although we are yet to investigate the circuit.
 
I measured the maximum range in the linear region of the signal, and here are the results:
  • Attachment 1: 231.25 kHz (current PDH sideband mod freq): 1.7 V
  • Attachment 2: 225.642 kHz: 1.2 V
  • Attachment 3: 100 kHz: 900 mV
  • Attachment 4: 763.673 kHz: 220 mV
Right now we have only inverted the phase to try locking at different frequencies (no finer adjustments were performed so elog 15216 cannot be an accurate representation of the true performance)
 
Ideas from the 40m meeting for adjusting the phase:
  1. Delay line for adding extra phase (would require over 40m of cable for 90 deg phase shift)
  2. Using two function generators for generating the sideband, clocked to each other, so that one can be sent to the PZT and the other to the mixer for demodulation.
  3. Use a different LPF (does not seem very useful for investigating multiple possible frequencies)

Once we adjust the phase we may be able to increase the servo gain for optimal locking. Unless it may be a good idea to increase the gain without optimizing the phase?

Attachment 1: IMG_0082.jpg
IMG_0082.jpg
Attachment 2: IMG_0083.jpg
IMG_0083.jpg
Attachment 3: IMG_0084.jpg
IMG_0084.jpg
Attachment 4: IMG_0085.jpg
IMG_0085.jpg
  15219   Fri Feb 21 13:02:53 2020 KojiUpdateALSPDH error signals?

Check out this elog: ELOG 4354

If this summing box is still used as is, it is probably giving the demod phase adjustment.

  5179   Wed Aug 10 20:40:17 2011 JennyUpdatePSLPDH locking: got an error signal

I ended up choosing a different dither frequency for driving the NPRO PZT: 230 kHz, because the phase modulation response in that region is higher according to other data taken on an NPRO laser (see this entry). At 230 there is a dip in the AM response of the PZT.

I am driving the PZT at 230 kHz and 13 dBm using a function generator. I am then monitoring the RF output of a PD that is detecting light reflected off the cavity. (The dither frequency was below the RF cutoff frequency of the PD, but it was appearing in the "DC output", so I am actually taking the "DC output" of the PD, which has my RF signal in it, blocking the real DC part of it with a DC block, and then mixing the signal with the 230kHz sine wave being sent to the PZT.

I am monitoring the mixer output on an oscilloscope, as well as the transmission through the cavity. I am sweeping the laser temperature using a lock in as a function generator sending out a sine wave at 0.2 V and 5 mHz. When there is a peak in the transmission, the error signal coming from the mixer passes through zero.

My next step is to find or build a low pass filter with a pole somewhere less than 100 kHz to cut out the unwanted higher frequency signal so that I have a demodulated error signal that I can use to lock the laser to the cavity.

 

  11959   Fri Jan 29 08:18:13 2016 SteveUpdatePEMPEM

 

Quote:

Air condition maintenance is happening. It should be done by 10am

 

Attachment 1: PEM.png
PEM.png
  17   Fri Oct 26 09:10:17 2007 steveRoutinePEMPEM &PSL trend
The fires are out, lab particle counts are up.
Psl HEPAs are at 100% and mobel HEPAs are just turned on
20 days plot and 5 hrs plot below
Attachment 1: counts&psl.jpg
counts&psl.jpg
Attachment 2: 5dcounts.jpg
5dcounts.jpg
  7230   Sun Aug 19 19:02:47 2012 DenUpdateCDSPEM -> RFM -> OAF

Data from PEM now goes directly to OAF without using RFM. Transmission RFM -> OAF errors are gone as RFM has to read 30 channels less now.

Again kernel "protection error" occured as before with PEM model so OAF model could not start. I changed optimization flag to -02, this fixed the problem.

  4825   Wed Jun 15 16:37:56 2011 JenneUpdatePEMPEM AA Board has been diagnosed and fixed

[Jenne, Steve]

After talking with Steve, I had a look at the PEM's AA board, to see what the problem was. 

Steve said the symptom he had noticed was that the Kepco power supplies which supply the +\- 5 V to the AA board were railing at their current limits as soon as he plugged the board in.  Also, he smelled smoke. 

I started with the power supplies, and saw that the 2 individual supplies each had a dV=5V, and that the one labeled +5V had the red wire on the + output of the power supply, and the black wire on the - output.  The supply labeled -5V had the orange wire on the -output of the power suppy, and the black wire on the + output.  Normally, you would expect that the 2 black wires are also connected together, and perhaps also to ground.  But at least together, so that they share a common voltage, and you get +\- 5V.  However these 2 power supplies are not connected together at all. 

This implies that the connection must be made on the AA boards, which I found to be true.  It seems a little weird to me to have that common ground set at the board, and not at the power supplies, but whatever.  That's how it is.

The problem I found is this:  The keyed connectors were made backward, so that if you put them in "correctly" according to the key, you end up shorting the +5V to the -5V, and the 2 black wires are not connected together.  You have to put the keyed connectors in *backwards* in order to get the correct wires to the correct pins on the board.  See the attached pdf figure.

Since these are internal board connections, and they should not ever be changed now that Steve has put in the adapter thing for the SCSI cable, I'm just leaving them as-is.  Steve is going to write in huge letters in sharpie on the board how they're meant to be connected, although since this problem wasn't caught for many many years, maybe it won't ever be an issue again.  Also, we're going to move over to the new Cymac system soon-ish.  However, whomever made the power cable connector from the box to the board for this AA board was lazy and dumb.

After putting the connectors on the way they needed to be, Steve and I powered up the board, hooked up the SCSI cable in the back, and put a constant voltage (~1.3VDC battery) across various different channels, and confirmed that we could see this voltage offset in Dataviewer. (Kiwamu is hoarding both of our SRS function generators, so we couldn't put in a low freq sine wave like I normally would). Everything looked okie dokie, so I'll check the regular PEM channels tomorrow.

Steve will re-install the board in the rack in the morning.

Attachment 1: 1X7_AAboard_connector_fix.pdf
1X7_AAboard_connector_fix.pdf
  4826   Thu Jun 16 00:39:08 2011 KojiUpdatePEMPEM AA Board has been diagnosed and fixed

As seen in the photo, the board has a strange bulge on the board,
and
the color of the internal line around the bulge got darkened.

I don't trust this board any more. We should switch to the alternative one.

Quote:

Steve will re-install the board in the rack in the morning.

 

  13788   Wed Apr 25 17:44:39 2018 ArnoldUpdatePEMPEM Anti-Alias wiring

Related image

 

  13790   Thu Apr 26 09:35:49 2018 KevinUpdatePEMPEM Anti-Alias wiring

I wired all 32 channels going to the AA board directly to the ADC as described in the previous log. However, instead of using the old AA board and bypassing the whole circuit, I just used a breakout board as is shown in the first attachment. I put the board back in the rack and reconnected all of the cables.

The seismic BLRMs appear to be working again. A PSD of the BS seismometers is shown in attachment 2. Tomorrow I'll look at how much the ADC alone is suppressing the common mode 60 Hz noise on each of the channels.

Steve: 5 of ADC DAC In Line Test Boards [ D060124 ] ordered. They should be here within 10 days.

Attachment 1: board.jpg
board.jpg
Attachment 2: SeismometerPSD.pdf
SeismometerPSD.pdf
  14949   Tue Oct 8 08:08:18 2019 gautamUpdatePEMPEM BLRMS anomaly

Yesterday, Koji and I noticed (from the wall StripTool traces) that the vertex seismometer RMS between 0.1-0.3 Hz in the X-direction increased abruptly around 6pm PDT. This morning, when I came in, I noticed that the level had settled back to the normal level. Trending the BLRMS channels over the last 24 hours, I  see that the 0.3-1 Hz band in the Z direction shows some anomalous behaviour almost in the exact same time-band. Hard to believe that any physical noise was so well aligned to the seismometer axes, I'm inclined to think this is indicative of some electronics issues with the Trillium interface unit, which has been known to be flaky in the past.

Attachment 1: PEManomaly.png
PEManomaly.png
  14989   Wed Oct 23 11:49:21 2019 gautamUpdatePEMPEM BLRMS anomaly

I looked into the seismometer situation a bit more today. Here is the story so far - I think more investigation is required:

  1. There is an abrupt change in the PEM BLRMS channels around 6pm PDT every day. This has been consistently seen for the last two weeks.
  2. The seismometer spectra look normal - see Attachment #1. The reference traces are from some months ago. There is elevated activity between 0.1-0.3 Hz, but this is seen in all the seismometers in all 3 DoFs.
  3. I looked at the minute trend of the raw seismometer outputs (before being BLRMSed) for the last 200 days and don't see any abrupt change in characteristics (the data gap is due to the issue in this thread).
  4. All the correct BLRMS filters seem to be engaged in the respective filter banks.

Attachment #2 has some spectrograms (they are rather large files). They suggest that the increase in noise in the 0.1-0.3 Hz band in the BS seismometer X channel is real - but there isn't a corresponding increase in the other two seismometers, so the problem could still be electronics related.

Quote:

Yesterday, Koji and I noticed (from the wall StripTool traces) that the vertex seismometer RMS between 0.1-0.3 Hz in the X-direction increased abruptly around 6pm PDT. This morning, when I came in, I noticed that the level had settled back to the normal level. Trending the BLRMS channels over the last 24 hours, I  see that the 0.3-1 Hz band in the Z direction shows some anomalous behaviour almost in the exact same time-band. Hard to believe that any physical noise was so well aligned to the seismometer axes, I'm inclined to think this is indicative of some electronics issues with the Trillium interface unit, which has been known to be flaky in the past.

Attachment 1: seisAll_20191021.pdf
seisAll_20191021.pdf
Attachment 2: specGrams.zip
  3977   Tue Nov 23 14:52:28 2010 JenneUpdatePEMPEM Model Started

Joe showed me what was what with adding DAQ channels, and I have begun building a simulink model to acquire the PEM channels. 

My models is in: /cvs/cds/rtcds/caltech/c1/core/advLigoRTS/src/epics/simLink/c1pem.mdl

Next on the to do list in this category: test which input connector goes with which channel (hopefully it's linear, exactly as one would think), and give the channels appropriate names. 

  11265   Fri May 1 13:22:08 2015 ericqUpdateDAQPEM Slow channels added to saved frames

Rana asked me to include add slow outputs (OUT16) of the seismometer BLRMS channels to the frames. 

All of the PEM slow channels are already set up in c1/chans/daq/C1EDCU_PEM.ini, but up to this point, daqd had no knowledge of this file, since it wasn't included in c1/target/fb/master, which defines all the places to look for files describing channels to be written to disk. This file already includes lines for C1EDCU_LSC.ini and such, which from old elogs, looks like was set up by hand for subsystems we care about. 

Hence, since we now care about slow trends for the PEM subsystem, I have added a line to the daqd master file to tell it to save the PEM slow channels. This looks to have increased the size of the individual 16 second frame files from 57MB to 59MB, which isn't so bad.

  11266   Fri May 1 16:42:42 2015 ranaUpdateDAQPEM Slow channels added to saved frames

Still processing, but I think it should work fine once we have a day of data. Until then, here's the summary pages so far, including Vac channels:

http://www.ligo.caltech.edu/~misi/summary/day/20150501/pem/

  1987   Tue Sep 15 15:46:05 2009 steveUpdatePEMPEM and VAC

FSS_RMTEMP is moving up and  daily fluctuations  are  less . 120 and 16 days plots are below.

Attachment 1: 120dpem.jpg
120dpem.jpg
Attachment 2: 16dpem.jpg
16dpem.jpg
  1615   Thu May 21 12:58:32 2009 robConfigurationALARMPEM count-half disabled

I've disabled the alarm for PEM_count_half, using the mask in the 40m.alhConfig file.  We can't do anything about it, and it's just annoying.

  6935   Sat Jul 7 16:34:41 2012 MashaUpdatePEMPEM no longer freaking out (as much).

Hi everybody,

Sorry for flooding the ELOG about the PEM channels. Today I

- Changed all of the GUR1 and GUR2 filters to elliptic, and lowered the orders of their low-pass filters.

- Lowered the order of the low-pass filters on the STS channels

- Changed the parameters in seismic.strip, which I saved as MashaTemplate2.

 

Attached is the most recent status of the channels as seen with StripTools:

Attachment 1: Masha.png
Masha.png
  6936   Sat Jul 7 17:28:11 2012 MashaUpdatePEMPEM no longer freaking out (as much).

Quote:

Hi everybody,

Sorry for flooding the ELOG about the PEM channels. Today I

- Changed all of the GUR1 and GUR2 filters to elliptic, and lowered the orders of their low-pass filters.

- Lowered the order of the low-pass filters on the STS channels

- Changed the parameters in seismic.strip, which I saved as MashaTemplate2.

 

Attached is the most recent status of the channels as seen with StripTools:

I'm not currently sure how to apply my template to seismic.strip shown on the wall (I saved it as seismic.strip on Pianossa and copied the old file to seismic.stripOld). I understand the job is being run on Megatron. I'll play around with this later tomorrow. (In other words, the display currently on the wall, while it does not have the Nan spikes like yesterday and this morning does not currently display the template I made).

  303   Fri Feb 8 17:55:53 2008 joshConfigurationPEMPEM-AS_MIC now in PSL enclosure
I have moved the microphone to the PSL enclosure, hanging near the south (Y) side from a support rod for the overhanging storage area so that it's reasonably close to the PMC. I've fastened it in many places using cable ties to make sure that it won't fall.

Alberto helped me solder together a female BNC-female 3.5 mm stereo adapter so that I can use the DAQ to output through BNC to PC speakers. My plan is do sweep sine output through PC speakers to find the transfer function of sound from outside the enclosure to inside the enclosure and by moving the microphone more centrally over the PSL table, check if there are any strong resonances. Hopefully I can use this technique at other places around the interferometer or measure the effect of installing acoustic foam.
  298   Tue Feb 5 17:39:05 2008 jweinerConfigurationPEMPEM-AS_MIC taken down from AS table, will put in PSL enclosure soon
I took down the microphone that Andrey hung above the AS table his first week in lab. I want to hang the microphone above the PMC to check the effect of acoustic noise on the PMC. The cables were a little more tangled than I thought so I've only taken the microphone down and haven't hung it back up yet, but on Thursday I'll have enough time to carefully put it up inside the PSL and see what I can find out about acoustic noise inside the PSL. I think the microphone should be sensitive enough for the frequencies we're interested in, and I'll hopefully find out if it's sufficient once I put it up in the PSL. The microphone cable and microphone are on top of the PSL for now.
ELOG V3.1.3-