40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 106 of 341  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  10186   Fri Jul 11 17:49:12 2014 NichinUpdateElectronicsNew Prologix GPIB-Ethernet controller

I have configured a NEW Prologix GPIB-Ethernet controller to use with HP8591E Spectrum analyzer that sits right next to the control room computers.

Static IP: 192.168.113.109

Mask: 255.255.255.0

Gateway: 192.168.113.2

I have no clue how to give it a name like "something.martian" and to update the martian host table (Somebody please help!!)

 

  10190   Sun Jul 13 11:37:36 2014 JamieUpdateElectronicsNew Prologix GPIB-Ethernet controller

Quote:

I have configured a NEW Prologix GPIB-Ethernet controller to use with HP8591E Spectrum analyzer that sits right next to the control room computers.

Static IP: 192.168.113.109

Mask: 255.255.255.0

Gateway: 192.168.113.2

I have no clue how to give it a name like "something.martian" and to update the martian host table (Somebody please help!!) 

The instructions for adding a name to the martian DNS table are in the wiki page that I pointed you to:

https://wiki-40m.ligo.caltech.edu/Martian_Host_Table

  10192   Mon Jul 14 12:49:07 2014 NichinUpdateElectronicsNew Prologix GPIB-Ethernet controller

Quote:

Quote:

I have configured a NEW Prologix GPIB-Ethernet controller to use with HP8591E Spectrum analyzer that sits right next to the control room computers.

Static IP: 192.168.113.109

Mask: 255.255.255.0

Gateway: 192.168.113.2

I have no clue how to give it a name like "something.martian" and to update the martian host table (Somebody please help!!) 

The instructions for adding a name to the martian DNS table are in the wiki page that I pointed you to:

https://wiki-40m.ligo.caltech.edu/Martian_Host_Table

The instructions at https://wiki-40m.ligo.caltech.edu/Martian_Host_Table   are outdated!

The name server configuration is currently at /etc/bind/zones/martian.db [ source: elog:10067 ]

 

Anyway, I need superuser access to edit the files, which I don't have. Even if I did know the password, I don't think it's a good idea for me to be messing around. So any of the 40m folks please update the martian table to include:

santuzza.martian  192.168.113.109

 

  10193   Mon Jul 14 13:03:23 2014 AkhilSummaryElectronicsTiming Issues of Mini Circuits UFC-6000: Solved

Main Problem:

The frequency counter (FC) takes in an analog RF input(signal) and outputs the frequency of the signal(Ranging from 1 MHz- 6000 MHz) in the digital domain (into a processor). The FC samples the data with a given sample rate( user defined) which ranges from 0.1 s to 1 s(faced problems in fixing this initially).  For data acquisition, we have been using a Raspberry Pi(as a processor) which is connected to the martian network and can communicate with the computers inside the 40m.  The ultimate challenge which I faced( and been knocking my head off from past two-three weeks) is the synchronization of clocks between the Raspberry Pi and the FC i.e the clock which the FC uses to sample and dump data( every 'x' s) and the clock inside the raspberry pi( used  in the loop to wait for a particular amount of time the frequency counter takes to dump successive data).

 

Steps Taken:

  • To address this problem, first I added an external clock circuit which monitors the Raspberry Pi and the FC to dump and read data at a particular rate(which is equal to the sampling rate of the FC)In detail: http://nodus.ligo.caltech.edu:8080/40m/10129. 
  • While doing so, at first the level trigger algorithm was used which means that the external clock frequency was half as that of  the reciprocal of the sampling rate and a trigger was seen every time the level shifts from +DC to -DC(of the external square wave).
  • But this did not completely mitigate the issues and there were still few issues on how quickly the ADC reads the signal and R Pi processes it.
  • To minimize these issues completely, an edge trigger algorithm which detects a pos edge(rising)  of the clock was used. The clock  frequency is now equal to the reciprocal of the sampling rate. This algorithm showed better results and greatly minimized the drift of the sampling time.

Psuedo Code(code attached):

open device : FC via USB-HID;

open device : ADC via I2C;

always(for t= recording time):

            read data from ADC(external clock);

            if pos edge detected:

                    read data from FC and store it in a register;

             else read data from ADC;

end

write data stored in the register to a file( can be an Epics channel or a text file);

 

Results:

The attached are the plots showing the time between samples for a large number of samples taken for different sampling times of the FC. The percentage error is the percentage of standard error in the timing between two samples for the data for the entire measurement. It can be inferred that this error has been cut down to the order of ms.

 

To do next:

  • I have started taking phase measurements( analysis and plots will follow this elog) and also the PSD plots with the improved timing characteristics.

 

 

 

             

 

Attachment 1: 0.2timinganalysis.png
0.2timinganalysis.png
Attachment 2: 0.3timinganalysis.png
0.3timinganalysis.png
Attachment 3: 0.5timinganalysis.png
0.5timinganalysis.png
Attachment 4: 1stiminganalysis.png
1stiminganalysis.png
Attachment 5: pdf.zip
  10194   Mon Jul 14 14:28:27 2014 KojiSummaryElectronicsTiming Issues of Mini Circuits UFC-6000: Solved

Looks good. Now you have the internal timer to verify the external clock.
If you can realize the constant rate sampling without employing the external clock, that's quite handy.

  10196   Mon Jul 14 16:51:07 2014 NichinUpdateElectronicsMartian table updated, Named server restarted

 [Nichin, Jenne]

The martian lookup tables are located at /etc/bind/zones/martian.db  and etc/bind/zones/rev.113.168.192.in-addr.arpa

Jenne updated these to include santuzza.martian  192.168.113.109

 

 

The method to restart named server given at  https://wiki-40m.ligo.caltech.edu/Martian_Host_Table  also does not work.

I restarted it using  >sudo /etc/init.d/bind9 restart

The named server is now updated and works fine. :)  I will update the 40m wiki now.

  10199   Tue Jul 15 01:31:13 2014 AkhilSummaryElectronicsTiming Issues of Mini Circuits UFC-6000: Solved

The attached are the PSD plots with improved FC timing(with the same code as in http://nodus.ligo.caltech.edu:8080/40m/10151). More plots(Phase and PSD) to follow.

 

 

 

Attachment 1: qnoise.png
qnoise.png
Attachment 2: qnoise.pdf
qnoise.pdf
  10202   Tue Jul 15 12:36:17 2014 NichinUpdateElectronicsRF cables rerouted

Quote:

 

I have not connected them to the RF switch yet. ( until I figure out how to get both the switches working properly)

 I went into the lab and connected the RF cables to the Mux. Will take measurements for each PD henceforth.

  10212   Wed Jul 16 01:46:41 2014 NichinUpdateElectronicsTest run of PDFR system

A test run was conducted on the PDFR system last afternoon and transimpedance plots were generated for 6 of the PDs. The laser was shut down after the test run.

I have not verified (yet) if the transimpedance values indicated by the plots are correct or not. The values mostly look INCORRECT. But the peaks are exactly where they need to be. *phew!*

Reasons: Incorrect calibration, Light other than from the PDFR system fibers on the PDs

Will have to work on debugging all this.

Attachment 1: PDFR_testRun_15-07-2014.pdf
PDFR_testRun_15-07-2014.pdf PDFR_testRun_15-07-2014.pdf PDFR_testRun_15-07-2014.pdf PDFR_testRun_15-07-2014.pdf PDFR_testRun_15-07-2014.pdf PDFR_testRun_15-07-2014.pdf
  10214   Wed Jul 16 02:22:10 2014 KojiUpdateElectronicsTest run of PDFR system

Log-log ... 

  10221   Wed Jul 16 21:24:41 2014 ReetikaUpdateElectronicsVCO Driver inside 40m

  

I found the VCO driver, that Rana asked me to locate, inside the 40m. I already have one VCO from PSL lab. Now, I have kept both of them inside the 40m lab(one on the cart in the side of the Y-arm and the other near the X-arm electronics table).

  10222   Wed Jul 16 22:17:40 2014 AkhilSummaryElectronicsBode Plots and complete Characterization of Frequency Counter

Goal:

To estimate the transfer function and the noise in the FC that is a part of the FOL-PID loop.

Measurements Taken:

The setup used for the measurements is described in my previous elogs.

The input modulation signal and the FC output were recorded simultaneously for a certain period of time and the phase and gain are estimated from the data.

Analysis(Data and code attached):

The recordings must contain equal number of data points(around 6000 data points in my measurements) for analysis.

The steps I followed to generate these plots are:

  • Took the FFT of both FC out data(from FC) and Modulation input(from SRS via ADC).
  • Estimated the phase angles at the particular modulation frequencies from the FFT data(in Matlab using  angle(x) for phase at the frequency f(x);x: is the frequency bin)
  • Then for the phase of the system at a particular modulation frequency, 

                              Phase(system) =Phase(FC Signal) - Phase(Input Signal)

  • Plotted the acquired phase vs the modulation frequency on a Semi-log graph.

Results:

From the plots its can be inferred that :the delay of the FC is almost 0 until the modulation of 0.1 Hz. Then there are phase shifts of  +/- 180 degrees showing that the system has multiple poles and zeroes(will be estimated after I have phase plots at few more carrier frequencies).

To Do Next

Phase plots for varying carrier frequencies and different sampling times.

Installation of FC inside the 40m.

Attachment 1: Phase_Data.zip
Attachment 2: Bode100MHz.png
Bode100MHz.png
  10223   Wed Jul 16 23:02:16 2014 KojiSummaryElectronicsBode Plots and complete Characterization of Frequency Counter

If I assume 1sample delay for 0.1s sampling rate, the delay is Exp[-I 2 pi f T], where T is the sampling period.

This means that you expect only 36 deg phase delay at 1Hz. In reality, it's 90deg. Huge!

Also there are suspicious zeros at ~1.6Hz and ~3Hz. This may suggest that the freq counter is doing some
internal averaging like a moving average.

It would be interesting to apply a theoretical curve on the plot. It's an intellectual puzzle.

  10227   Thu Jul 17 16:07:34 2014 Emily UpdateElectronicsVCO Driver

I took back he VCO driver that Reetika brought over to the 40m from the PSL lab.  

  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.

  10238   Fri Jul 18 17:10:57 2014 NichinSummaryElectronicsCharacterization of demodulator boards.

Rack 1Y2, I took transfer function measurements for each of the following demodulator boards: REFL11, REFL33, REFL55, REFL165, AS55, POP22, POX11 and POY11.

What I did:

1) Removed the wire at PD Input to demodulator board.

2) Put the MOD output from network analyzer into PD input of board.

3) Ran a sweep from 100kHz to 100MHz.

4) Measured the transfer function between PD RF MON and PD Input. (The PD RF MON signal came out of the RF multiplexer, so the mux is included as well )

5) Put the original wire back at PD Input.

Results:

The plots clearly show an attenuation of 20dB (factor of 10) for all the demodulator boards. This explains why my transimpedance measurements are off by 10 times.

Note: for REFL 165, there was an extra 100MHz high pass filter installed at PD Input. I did not remove this and made my measurements along with this.

To Do:

a) Modify the PDFR system to calibrate out this attenuation.

b) Measure the transfer function between the input and output of RF mux, so that we can have just the transfer function between PD input an PD RF MON (for documentation's sake)

 

Attachment 1: Demodulators_TF.pdf
Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf
  10239   Fri Jul 18 19:32:50 2014 AkhilSummaryElectronicsFilters used inside the Frequency Counter

 

 Thanks Koji , for your  hint for the brain teasing puzzle. I was looking into Filters that are usually used in devices like counters, DSO and other scopes. I found that , to improve the quality of the measurement one of the best approach  is averaging. I looked deeper into averaging and found out this:

There are two general use-cases for averaging . The first, successive sample averaging, takes a single acquisition and averages between its samples. The second, successive capture averaging, combines the corresponding  samples of multiple captures to create a single capture. Successive sample averaging is also called boxcar filtering or moving average filtering. In an implementation of this type of averaging each output sample represents the average value of M consecutive input samples. This type of averaging removes noise (one of the reasons the noise level was not bad: http://nodus.ligo.caltech.edu:8080/40m/10151) by decreasing the device's bandwidth(could be one of the reasons why the FC operates in 4 different frequency ranges). It applies an LPF function with a 3dB point approximated by  0.433 * s / M, where M is the number of samples to be averaged, and s is the sample rate in samples per second. 

Now I tried verifying the 3 dB points in the gain plots I generated :

For 1 s Sampling time : the 3 dB point for such a Boxcar filter should be at 0.433* 1/M. If we assume that it averages for 2 samples, M=2 which gives the 3dB point at 0.288 Hz but occurs somewhere between 0.3 and 0.4 Hz.  (http://nodus.ligo.caltech.edu:8080/40m/140619_120548/GainVsFreq.png)

For 0.1s Sampling time: the 3dB point should be at 2.17 Hz and in reality is 2.5 Hz(http://nodus.ligo.caltech.edu:8080/40m/140701_211904/gain.png).

Also, This type of filter will have very sharp nulls at frequencies corresponding to signals whose periods are integer sub-multiples of M/s. As seen my previous plots (http://nodus.ligo.caltech.edu:8080/40m/10118 , http://nodus.ligo.caltech.edu:8080/40m/10070) there are sharp nulls at frequencies

0.4 Hz for 1S sampling time and

at 1.5 Hz,3 Hz for 0.1 S sampling time as correctly predicted.

The moving average filter is  L-sample moving average FIR, with the frequency response as:   H(ω) = (1/L) (1 − e− jω L)/(1 − e− jω)..

There is an overall delay of (M - 1)/2 samples from such a length-M causal FIR filter. 

The expected bode plots for such a filter with L= 5 is attached(attachment 2).

Attachment 1: TheoreticalGainPlot.png
TheoreticalGainPlot.png
Attachment 2: TFexpected.png
TFexpected.png
  10243   Sun Jul 20 09:26:27 2014 EvanUpdateElectronicsMC servo card modifications in DCC

Quote:

[Rana, Jenne]

We have decided to keep better track (using new-fangled digital "computers") of our modifications to electronics boards. 

The idea will be to create a new DCC document for every electronics board (when we pull a board and modify it, it should receive this treatment) that we have, and that document will become a history of the board's life.  Version 1 will be a copy of the original drawing.  Version 2 should be a modified version of that drawing with the current situation.  All future versions should be modified from the most recent version, to reflect any changes.  Notes for each updated version should include an elog reference to the work, so that we know why we did things, and have a place to find photos of the actual modifications.  Elogs should also include a link to the DCC version.  DCC titles should include the phrase "40m Revisions" for ease of searching.

Patient Zero for this new system will be the PMC servo card.  The DCC number is D1400221.  As of this moment, this just has the V1 original drawing with no modifications.

This has been included in the 40m's DCC document tree that Jamie started back in November 2012.

Patient One for this new system will be the MC servo card. The DCC number is D1400242. Currently, v1 is just the original drawing with no modifications. I've updated the DCC document tree at E1400326 accordingly.

It looks like we can use Jenne's information in 40m:9892 to deduce the modifications that have been made (alternatively, someone can just pull the board and examine it on the bench).

  10246   Mon Jul 21 12:16:27 2014 AkhilSummaryElectronicsFilters used inside the Frequency Counter

The expected bode plots for such a filter with L= 4 is attached and compared with the measured.

RXA: When comparing two things, please put them onto the same plot so that they can be compared.

Attachment 1: FC_TF_Characterization.png
FC_TF_Characterization.png
  10250   Tue Jul 22 08:24:42 2014 EvanUpdateElectronicsMC servo card: modified schematic

Quote:

Patient One for this new system will be the MC servo card. The DCC number is D1400242. Currently, v1 is just the original drawing with no modifications. I've updated the DCC document tree at E1400326 accordingly.

It looks like we can use Jenne's information in 40m:9892 to deduce the modifications that have been made (alternatively, someone can just pull the board and examine it on the bench).

The attached zip file has a modified schematic of the MC servo card (011/MC), as deduced from Jenne's photos. Someone should go through and verify that the schematic is correct. Then it can go on the DCC as D1400242-v2.

To modify the schematic, I used Inkscape (the svg files for each sheet are included in the zip file). Then to generate the pdf, I ran

for i in sheet*.svg; do inkscape -A "${i/svg/pdf}" "$i"; done

pdftk sheet*.pdf cat output D1400242

Attachment 1: D1400242.zip
  10252   Tue Jul 22 15:50:35 2014 NichinSummaryElectronicsCharacterization of demodulator boards.

Quote:

Rack 1Y2, I took transfer function measurements for each of the following demodulator boards: REFL11, REFL33, REFL55, REFL165, AS55, POP22, POX11 and POY11.

What I did:

1) Removed the wire at PD Input to demodulator board.

2) Put the MOD output from network analyzer into PD input of board.

3) Ran a sweep from 100kHz to 100MHz.

4) Measured the transfer function between PD RF MON and PD Input. (The PD RF MON signal came out of the RF multiplexer, so the mux is included as well )

5) Put the original wire back at PD Input.

Results:

The plots clearly show an attenuation of 20dB (factor of 10) for all the demodulator boards. This explains why my transimpedance measurements are off by 10 times.

Note: for REFL 165, there was an extra 100MHz high pass filter installed at PD Input. I did not remove this and made my measurements along with this.

To Do:

a) Modify the PDFR system to calibrate out this attenuation.

b) Measure the transfer function between the input and output of RF mux, so that we can have just the transfer function between PD input an PD RF MON (for documentation's sake)

 

I repeated the exact steps above and made sure everything was back where it should be after I was done.

Reason I had to retake the measurements:

My script for acquiring data from the AG4395A network analyzer was such that it first acquired the magnitude data from channel 1 and then recorded phase data from channel 2 without holding its trace. Hence the phase and magnitude data were not exactly in sync with each other. So, when I tried to fit the data to a model using vector fitting, I ended up with very bad results.

I have now changed every single script relating to the network analyzer to just get the real and imaginary data in one go and then calculate the phase using this data.

The fitting process is now in progress and results will be up shortly.

Attachment 1: Demodulators_TF.pdf
Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf
  10261   Wed Jul 23 11:15:54 2014 AkhilUpdateElectronicsInstallation of FCs in the 40m

 As a part of installation of two(X-ARM and Y-ARM) frequency counters in the 40m, I have tested their performance when using them both on a single Raspberry Pi. The timing plots are attached. There are almost no timing issues in this configuration and it can be said that there is no harm using both of the FCs on the same platform.

We will be installing the FC box inside the lab and carry out few tests with RF mon beat note inputs.

Attachment 1: Timingwith2FCs.png
Timingwith2FCs.png
  10263   Wed Jul 23 11:54:27 2014 NichinUpdateElectronicsCharacterization of demodulator boards.

Quote:

 

I repeated the exact steps above and made sure everything was back where it should be after I was done.

Reason I had to retake the measurements:

My script for acquiring data from the AG4395A network analyzer was such that it first acquired the magnitude data from channel 1 and then recorded phase data from channel 2 without holding its trace. Hence the phase and magnitude data were not exactly in sync with each other. So, when I tried to fit the data to a model using vector fitting, I ended up with very bad results.

I have now changed every single script relating to the network analyzer to just get the real and imaginary data in one go and then calculate the phase using this data.

The fitting process is now in progress and results will be up shortly.

The plots in the previous Elog includes delay and a little attenuation by RF cables and the RF mux.

Today I separately calculated the delay and attenuation for an RG405 cable (550 cm) and the RF mux(using really small RF cables). These delays should be accounted for when fitting the transfer function of Demodulator boards and transimpedance of PDs.

The plots are in both semilogx and linear.

Attachment 1: 1.pdf
1.pdf 1.pdf
Attachment 2: 2.pdf
2.pdf 2.pdf
  10265   Wed Jul 23 18:53:11 2014 NichinUpdateElectronicsTime delay in RG405 coaxial cables

 A time delay can be modeled as the exponential transfer function :  e(-sTd)  as seen HERE . Therefore the slope of the phase gives us the time delay.

A RG405 coaxial cable, exactly 5.5 meters in length, was fit to an ideal delay function e(-sTd) , with Td = 150 ns.

The plots shows the actual data, fit data and data after correction using the ideal model stated above.

Conclusion:

Delay in RG405 cables is approximately 27.27 ns per meter. This value can be used to correct the phase in measurements of transimpedance for each PD by dividing out the ideal transfer function for time delay.

[EDIT: This looks like we have about 12 % the speed of light inside the RF cables. Too small to be true. I will check tomorrow if the Network analyzer itself has some delay and update this value.]

The varying attenuation of about 1dB due to the cable is not compensated by this. We need to separately include this.

Things to do:

1) Get the length of RF cables that is being used by each PD, so that the compensation can be made.

2) Calculate the attenuation and delay caused by RF multiplexer and Demodulator boards. Include these in the correction factor for transimpedance measurements. 

 

 

 

 

 

 

 

 

 

 

Attachment 1: RFcable1.pdf
RFcable1.pdf
Attachment 2: RFcable2.pdf
RFcable2.pdf
  10266   Wed Jul 23 19:30:34 2014 NichinUpdateElectronicsTime delay in the RF multiplexer (Rack 1Y1)

A time delay can be modeled as the exponential transfer function :  e(-sTd)  as seen HERE . Therefore the slope of the phase gives us the time delay.

The transfer function of RF multiplexer in rack 1Y1 (NI PXI-2547) was fit to an ideal delay function e(-sTd) , with Td = 59 ns.

The plots shows the actual data, fit data and data after correction using the ideal model stated above.

Conclusion:

Delay the RF Multiplexer is approximately 59 ns. This value can be used to correct the phase in measurements of transimpedance for each PD by dividing out the ideal transfer function for time delay.

 

Attachment 1: RFmux1.pdf
RFmux1.pdf
Attachment 2: RFmux2.pdf
RFmux2.pdf
  10280   Mon Jul 28 10:42:43 2014 NichinUpdateElectronicsDemodulator board's characterization

 I used vector fitting to fit the transfer functions between RF input and PD RF MON of demodulator boards. These fittings can certainly do a lot better on LISO, but for the time being I will assume these to be good enough and change the main PDFR scripts to calibrate out this factor and get a decent reading of PD transimpedance. Then it will just be a matter of changing the transfer function parameters. A lot of work needs to be done on the PDFR interface and plot features.

Attached: The plots showing data and fits.

Attachment 1: Demod_Fit.pdf
Demod_Fit.pdf Demod_Fit.pdf Demod_Fit.pdf Demod_Fit.pdf Demod_Fit.pdf Demod_Fit.pdf Demod_Fit.pdf Demod_Fit.pdf
  10304   Thu Jul 31 11:54:54 2014 AkhilSummaryElectronicsPZT Calibration

 Koji asked me to get the calibration of the PZT counts to Volts for the the X and Y ends. Yesterday, I went inside the lab and took some measurements from the digital readout of the PZT by giving in a DC offset(-5 to +5 volts) to PZT_Out and read out from these channels:

For X-end:  C1:ALS-X-SLOW_SERVO1_IN1

For Y-end:  C1:ALS-Y-SLOW_SERVO1_IN1

Since a 20dB attenuator was placed in the path of X-arm readout while taking the Transfer functions(Detail), I did the calibration measurements without removing it from the path. However, for the Y arm there was no attenuator in the readout path.

The obtained calibration values are :

X- arm PZT : [146.3 +/- 2.37 ]  counts/Volt 

Y- arm PZT :  [ 755.1 +/- 3.6]    counts/Volt

The attached are the fit and data plots for the above calibration.

Attachment 1: PZT_Y_Calibration.pdf
PZT_Y_Calibration.pdf
Attachment 2: PZT_X_Calibration.pdf
PZT_X_Calibration.pdf
  10306   Thu Jul 31 12:23:38 2014 KojiSummaryElectronicsPZT Calibration

1) Don't be brainless. Redo the fitting of the Y arm. Obviously the fit is not good.

2) How can you explain the value from the ADC bit and range?

e.g. +/-10V range 16bit ADC => 2^16/20 = 3276.8 count/V

  10307   Thu Jul 31 14:23:28 2014 AkhilSummaryElectronicsPZT Calibration

 

 The PZT seems to saturate at around +/- 3500 counts. So for the Y arm, I excluded the saturated points and fitted the data points again.

As for the calibration number, we expect the 3276.8 count/V for +/- 10 V range of a 16 bit ADC but the number is ~800 count/V. I couldn't figure out a reason why the number is so different.

The new calibration values are :

X- arm PZT : [146.3 +/- 2.37 ]  counts/Volt   (with a 20 dB attenuator included in the path)

Y- arm PZT :  [ 797 +/- 3.6]    counts/Volt  

I will get the calibration in MHz/V of PZT actuation and check whether these numbers make any sense.

Attachment 1: PZT_Y_Calibration.pdf
PZT_Y_Calibration.pdf
  10324   Fri Aug 1 18:48:46 2014 AkhilSummaryElectronicsPZT Calibration

 

 The PZT actuation on the laser frequency in MHz/V ( assuming the previous calibration here of the PZT count/V) is :

X- arm: 33.7 MHz/V

Y- arm: 14.59 MHz/V

This number seems to be wrong by a factor of 10. 

So we[I and EricQ] decided to trace the cables that run into the ADC from the PZT Out. We found a black LEMO box in the path to ADC,which is  an anti-aliasing filter for each input channel. However,in theory the response of this filter should be flat up until a few kHz i.e. for  the DC gain it should be 1. But we will manually test it and look at the DC gain of the LEMO box.

 

 

  10490   Wed Sep 10 20:24:00 2014 JenneUpdateElectronicsPOY RF cable loose

Sitting down to work on the IFO, I couldn't lock the Yarm.  I looked at the error signal as well as the transmission on Dataviewer, as usual, and saw that the POY error signal was almost non-existant. 

Since there was work on the POY table today (Steve removed the oplev test setup, elog 10489 and Q centered the SRM oplev after doing SRMI alignment, no elog yet), I went out to have a look at the table. 

There was nothing occluding the POY beam, which I traced back to the edge of the table.  The beam looked nice and round, so I decided that wasn't it.  I jiggled the PD cables, and lo and behold, the POY RF out cable almost came off in my hand it was so loose.  My suspicion is that whomever was the last to put the POY RF out back didn't tighten the cable and then the work today jiggled the cable loose.  I tightened the cable, and by the time I was back to the control room the arm was locked and Koji was already running the alignment scripts.

  10774   Wed Dec 10 15:05:32 2014 JenneUpdateElectronicsXend QPD whitening board modified already

In April, Koji logged that he had made some changes to the Yend QPD whitening board (elog 9854).  Today, I pulled the Xend board to see if it had the same modifications.  The filter shapes all seem to be the same (as in, the capacitors at the output filters were removed, etc.), and the final gain is the same.  I just realized that I didn't explicitly check if the whitening switches were pulled to ground to permanently turn on the whitenening, but hopefully I'll be able to see that in the photo. 

I have not made any changes today (yet) to the board, so the overall gain is still accessible via EPICS.  I wanted to do a quick check that we won't be saturating things at full power with the maximum gain, before I make a change.

IMG_1776.JPG

EDIT:  After comparing the photos here and in elog 9854, the X end board has the filter shape modifications that were done some time ago, but the whitening is not permanently enabled.  For the Yend board, Koji added a jumper wire connecting (for example) R97 and R106 to the grounded side of C69.  This jumper wire is not in place on the X qpd board.

Before I re-pull the board and modify it, I want to make sure I know what I'm going to do for the gain slider override.

  10782   Thu Dec 11 16:42:12 2014 JenneUpdateElectronicsXend QPD whitening board plan

Here is a little PDF of what I plan to do to both of the transmission QPD whitening boards later today.  The idea is to take away the remote gain slider inputs, and force the gains to always be at +30dB.

The red and blue notes are from Koji's elog 9854, and the green are my plans for today. 

I will cut the traces from the gain slider inputs, and pull the negative input of the AD620 to ground.  The positive input will be connected to the +5 voltage line, with a divider so that the positive input to the AD620 is about 666mV. 

The AD602 will be maxed out at +30dB with anything over 625mV. 

QPDwhiteningModification_11Dec2014.pdf

Unless there are objections, I will start these modifications in an hour or so.  I will also make the Xarm whitening always-on, just like Koji has already done for the Yend.

EDIT, JCD, 12Dec2014:  These are not the modifications that were made.  Please see ____ for actual modifications.

  10794   Fri Dec 12 19:54:21 2014 JenneUpdateElectronicsXend QPD whitening board modified

Okay, I have finished modifying the Xend QPD whitening board, although I will likely need to change the gain on Monday.

Rather than following my plan in elog 10782, I removed the AD602's entirely, and just use the AD620's as the amplifiers.  We don't need remotely adjustable gains, and the AD620s are a less noisy part.

I set the gain to be 30dB using a 1.65k resistor for R_G, which turns out to be too high.  After I installed the board and realized that my counts were much higher than they used to be, I realized that what we had been calling +30dB was in fact +13.2dB. ( I am assuming that the ADC for the gain sliders were putting out a maximum of +10V.  The AD620 used to have a 1/10 voltage divider at the input, and an overall gain of 1, so the output of the AD620 was 100mV.  This goes into pin 16 of the AD602, which has gain of 32*V_set + 10.  Which gives 32*0.1+10=13.2dB.  Ooops.  We've been lying to ourselves. )

Anyhow, before I made the gain realization, I was happily going along, setting the AD620s' gains all to 30dB. I also copied Koji's modification from April of this year, and permanently enabled the whitening filters.

Here is the schematic of what ended up happening.  The red modifications were already in place, and the greens are what I did today.

QPDwhiteningModification_XtransCompleted_12Dec2014.pdf

You can see the "before" picture in my elog Wednesday, elog 10774.  Here is an "after" photo:

IMG_1779.JPG

Here is a spectrum comparing the dark noise of the Xend QPD after modification to the current Yend QPD (which is still using the AD602 as the main instrumentation amplifier).  I have given the Yend data an extra 16.8dB to make things match.

QPD_Xtrans_Ytrans_12Dec2014.pdf

And, here is a set of spectra comparing both ends, dark noise versus single arm lock.  While I'll have to sacrifice a lot of it, there's oodles more SNR in the Xend now.  The Yend data still has the "gain fixing" extra 16.8dB.

QPD_Xtrans_Ytrans_DarkVsLock_12Dec2014.pdf

The Xend quadrant input counts (before the de-whitening filters) now go up to peak values of about 1,000 at single arm lock.  If (optimistically) the we got full power recycling and the arms got to powers of 300, that would mean we would have 300,000 counts, which is obviously way more than we actually have ADC range for.  Currently, the Yend quadrant input counts go as high as 50, which with arm powers of 300 would give 15,000 counts.  I think I need to bring the Xend gain down to about the level of the Yend, so that we don't saturate at full arm powers.  I can't remember right now - are the ends 14-bit or 16-bit ADCs?  If they're 16-bit, then I can set the gain somewhere between the current X and Y values.

 Finally, I added a section of the 40m's DCC document tree for the QPD whitening:  E1400473, with a page for each end.  Xend = D1400414, Yend = D1400415.

  10795   Sat Dec 13 00:35:11 2014 ranaUpdateElectronicsXend QPD whitening board modified

 

 16 bit. There aren't any 14-bit ADCs anywhere in LIGO. The aLIGO suspensions have 18-bit DACs.

The Y-End gains seem reasonable to me. I think that we only use TRX/Y as error signals once we have arm powers of >5 so we should consider if the SNR is good enough at that point; i.e. what would be the actual arm motion if we are limited only by the dark noise?

I seem to remember that the estimate for the ultimate arm power is ~200, considering that we have such high losses in the arms.

  10799   Mon Dec 15 22:30:50 2014 JenneUpdateElectronicsYend QPD modified

Details later - empty entry for a reply.

Short story - Yend is now same as Xend filters-wise and lack of gain sliders -wise.  Both ends have 13.7k resistors around the AD620 to give them gains of ~4.5.

Xend seems fine.

Yend seems not fine.  Even the dark noise spectrum sees giganto peaks.  See Diego's elog 10801 for details on this investigation.

  10801   Mon Dec 15 22:45:59 2014 JenneUpdateElectronicsYend QPD modified

 

 [Jenne, Rana, Diego]

We did some test on the modified QPD board for the Yend; we saw some weird oscillations at high frequencies, so we went and check more closely directly within the rack. The oscillations disappear when the cable from the QPD is disconnected, so it seems something is happening within the board itself; however, looking closely at the board with an oscilloscope in several locations, with the QPD cable connected or disconnected, there is nothing strange and definitely nothing changing if the cable is connected or not. In the plots there are the usual channels we monitor, and the 64kHz original channels before they are downsampled.

Overall it doesn't seem being a huge factor, as the RMS shows at high frequencies, maybe it could be some random noise coming up, but anyway this will be investigated further in the future.

Attachment 1: QPD_Ytrans_oscillating_15Dec2014.pdf
QPD_Ytrans_oscillating_15Dec2014.pdf
Attachment 2: QPD_IOPchannels_Ytrans_oscillating_15Dec2014.pdf
QPD_IOPchannels_Ytrans_oscillating_15Dec2014.pdf
  10879   Thu Jan 8 19:02:42 2015 JaxSummaryElectronicsMC demod modifications

Here's a summary of the changes made to the D990511 serial 115 (formerly known as REFL 33), as well as a short procedure. It needed tuning to 29.5MHz and also had some other issues that we found along the way. 

So here's a picture of it as built:

The changes made are:

1. U11 and U12 changed from 5MHz LP to 10 MHz LP filters.

2. Resistors R8 and R9 moved from their PCB locations to between pins 1 (signal) and 3 (ground) of U11 and U12, respectively. These were put in the wrong place for proper termination so it made sense to shift them while I was already replacing the filters.

Also, please note- whoever labeled the voltages on this board needed an extra cup of coffee that day. There are two separate 15V power supplies, one converted from 24V, one directly supplied. The directly supplied one is labeled 15A. This does NOT mean 15 AMPS.

Transfer functions:

Equipment: 4395A, Signal generator (29.5 MHz), two splitters, one mixer

You can't take the TF from PD in to I/Q out directly. Since this is a demod board, there's a demodulating (downconverting) mixer in the I and Q PD in paths. Negligible signal will get through without some signal applied to the L input of the mixer. In theory, this signal could be at DC, but there are blocking capacitors in the LO in paths. Therefore, you have to upconvert the signal you're using to probe the board's behavior before it hits the board.  Using the 4395A as a network analyzer, split the RF out. RFout1 goes to input R, RFout2 goes to the IF port of the mixer. Split the signal generator (SG). SG1 goes to LO in, SG2 goes to the L port of the mixer. The RF port of the mixer (your upconverted RFout2) goes to PD in, and the I/Q out goes back to the A/B port of the 4395A - at the same frequency as the input, thanks to the board's internal downconversion. 

Phase measurement:

Equipment: Signal generator (29.5 MHz), signal generator (29.501 MHz), oscilloscope

Much simpler: 29.5 MHz to the LO input (0 dBm), 29.501 MHz to the PD input (0 dBm), compare the phases of the I/Q outputs on the oscilloscope. There are four variable capacitors in the circuit that are not on the DCC revision of the board - C28-31. On the LO path, C28 tunes the I phase, C30 tunes the Q phase. On the PD path, C29 and 31 appear to be purely decorative - both are in parallel with each other on the PD in Q path, I'm guessing C29 was supposed to be on the PD in I path. Fortunately, C28 and C30 had enough dynamic range to tune the I/Q phase difference to 90 degrees.

Before tuning:

After tuning:

 

  10954   Thu Jan 29 09:50:47 2015 manasaUpdateElectronicsIOO rack amplifier panel

The RF amplifier panel on the IOO rack (Attachment 1) will be used to also hold the RF amplfiers for the frequency counters. The amplifiers mounted on it right now are getting +15 (orange wire) and GND (black wire) from the rack power supply (Attachment 2).

Proposed plan to install RF amplifiers:

1. Disconnect the D sub connector that powers the amplifiers and pull out the panel. The rack power supplies will NOT be shut down for this. 

2. Mount the RF amplifiers with bypass capacitors. There will be 4 amplifiers ZFL-500LN mounted on the same panel (2 for each frequency counter).

3. While putting back the panel on the IOO rack, we will need to shut down the +15V and -15V sources to connect the amplifiers to the rack power supply.

I will do this over this weekend so that we dont lose any locking time. If anybody has any concerns, let me know

Attachment 1: panel_front.jpg
panel_front.jpg
Attachment 2: panel_back.jpg
panel_back.jpg
  11022   Fri Feb 13 14:27:30 2015 ericqUpdateElectronicsSecond QPD Whitening Switch enabled

I have re-enabled the second whitening stage switching on each quadrant of each end's QPD whitening board, to try and avoid saturations at full power. Looking at the spectra while single arm locked, I confirmed that the FM2 whitening switch works as expected. FM1 should be left on, as it is still hard-wired to whiten. 

The oscillations in the Y QPD still exist. Jenne is updating the schematics on the DCC.

  11023   Fri Feb 13 14:59:13 2015 ericqUpdateElectronicsSecond QPD Whitening Switch enabled

Went to zero CARM offset on ALS; transmission QPDs are still saturating :(

Maybe we need to switch off all whitening.

  11024   Fri Feb 13 17:07:51 2015 JenneUpdateElectronicsSecond QPD Whitening Switch enabled

I first updated the DCC branches for the Xend and Yend to reflect the as-built situation from December 2014, and then I updated the drawings after Q's modifications today.

  11025   Fri Feb 13 18:56:44 2015 ranaUpdateElectronicsSecond QPD Whitening Switch enabled

Depends on the plots of the whitening I guess; if its low freq sat, then we lower the light level with ND filters. If its happening above 10 Hz, then we switch off the whitening.

Quote:

Went to zero CARM offset on ALS; transmission QPDs are still saturating :(

Maybe we need to switch off all whitening.

 

  11049   Thu Feb 19 04:09:21 2015 ericqUpdateElectronicsSecond QPD Whitening Switch enabled

X end QPD has recieved 0.2+0.4 absorptive ND filters. Y end QPD got one at 0.6. This appears to have mitigated the saturations for now; the unwhitened signals no longer go negative. The digital gains have been reset. 

 

  11225   Sun Apr 19 15:03:26 2015 JenneUpdateElectronicsLow noise pre-amps?

Does anyone know where the Busby or Rai low noise pre-amp boxes are? 

I think I need one in order to measure the noise of the Marconi.  Right now, I am trying to measure the amplitude noise, but I'm not seeing anything on the SR785 above the analyzer's noise level.

  11226   Mon Apr 20 16:18:29 2015 JenneUpdateElectronicsLow noise pre-amps: returned

The Rai box was in the Cryo lab, and the Busby box was in the TCS lab.  Neither had been signed out.  Lame.  Anyhow, thanks to Evan and Zach's memories of having seen them recently, they have been returned to the 40m where they belong.  (Also, I grabbed a spare Marconi while I was over there, for the phase noise measurement).

  11228   Mon Apr 20 21:26:46 2015 ranaUpdateElectronicsLow noise pre-amps: returned

+1 to both Evan and Zach for prompt info and +2 to you for getting more stuff than you started looking for. -2 karma to whomever had swiped them and hoarded without signing. You should put a 40m sticker on both of them. Make sure to check / use fresh batteries. The Busby box is BJT based and works on low impedance sources, the Rai box works on anything, but (I am guessing) has less CMRR.

Quote:

The Rai box was in the Cryo lab, and the Busby box was in the TCS lab.  Neither had been signed out.  Lame.  Anyhow, thanks to Evan and Zach's memories of having seen them recently, they have been returned to the 40m where they belong.  (Also, I grabbed a spare Marconi while I was over there, for the phase noise measurement).

 

  11237   Wed Apr 22 17:04:11 2015 ranaUpdateElectronicsMC REFL PD back from the dead

Just randomly found this old entry from 3 years ago. We should never have installed a GAP 2000 - they are an inferior type of InGaAs diode. We should add to our list replacing these with a 2 mm EG&G diode.

How many 2 mm EG&G InGaAs diodes do we have Steve? Can you please find a good clean diode case so that we can store them in the optics cabinet on the south arm?

Quote:

 [Yuta, Manasa]

We replaced the dead photodiode on MC REFL PD with a new one (GAP 2000). We measured the frequency response of the PD and tuned the resonant frequency using inductor L5 (in the circuit diagram) to be 29.575MHz - over an average of 10 measurements.

 

  11238   Thu Apr 23 08:43:40 2015 SteveUpdateElectronicsEG&G InGaAs diodes in stock

RFpds box is moved from RF cabinet E4 to clean cabinet S15

Inventory updated at https://wiki-40m.ligo.caltech.edu/RF_Pd_Inventory

Large Area InGaAs PIN Photodiode -- C30642GH      6 pieces in stock

Product Details
in: Photodiodes

 

Large Area InGaAs PIN Photodiode -- C30642GH -- View Larger Image

Large Area InGaAs PIN Photodiode with a 2,0 mm active diameter chip in TO-5 package with flat glass window

Large area InGaAs PIN photodiode with useful diameter of 2,0 mm in a T0-5 package with a flat glass window. The C30642GH provides high quantum efficiency from 800nm to 1700nm. It features high responsivity, high shunt resistance, low dark current, low capacitance for fast response time and uniformity within 2% across the detector active area.

ELOG V3.1.3-