This BBPD is the spare that we pulled out and is installed for ALSX-PSL beat note detection.

[Nichin, Eric G, Koji]

Continuing out work from elog:10037, we wanted to check if the frequency response of AS55. Having figured out exactly how to use the Laser diode controller (LDC 3744C), we hooked up a fiber power meter to the optical fiber illuminating AS55 (that we disconnected from its mount last Friday ) and raised up the current to 150mA to get almost 0.8mW power reading.

When aligning the fiber to illuminate the PD, we found that the beam was pretty wide. So we pulled out the collimator and tweaked it to get a focused beam. The fiber was mounted back and was aligned to get a maximum DC reading. The multimeter readout 30mV finally. Taking the transimpedence as 200ohm approx., the hot current is about 1.5mA.

Network analyzer was now connected to the modulation input of the laser and the RF output from REF DET and AS55 (inputs to RF switch at rack 1Y1) were connected as input to measure the transfer function. We got just noise on the scope of NA. So, then we tried REFL33 as the Input and still got nothing (We were also not sure if this PD was properly illuminated, we did not check). However the REF DET was giving a nice response on the scope. Turns out all the PDs were disconnected form the Demodulator (D990511) on rack 1Y2.

On closer inspection the RF cable between domodulator and RF switch that was labelled AS55 had a loose SMA connector at the switch end. I will have to fix that tomorrow . For the time being Koji connected the cable labelled REFL33 to the AS55 demodulator and we finally got a response form the AS55 PD on the NA. However no readings were recorded. The power supply to REF DET was turned off in the end as Eric G claimed that it has been ON for almost a year now, which is not a good thing. Also, we removed the modulation input from NA to the diode laser and terminated the input with a 50ohm terminator.

We planned to pull out and check each and every RF cable (especially the SMA ends for faulty soldering and loose connections) and fix/ replace them as needed.

Not "hot" current but "photo" current. Is this my bad!?

It was me who told Nichin that the DC transimpedance was 200Ohm. But according to this entry I checked the RF transimpedance of AS55 before.
In my code, the DC transimpedance was defined to be 50Ohm. If we believe it, 30mV corresponds to 0.6mA.

The goal is to characterize the Mini-Circuits RF FC (Model UFC-6000)  by plotting Gain Plots.

Work Done:

The sampling rate of the UFC-6000 RF FC is 1s (should look into making the sampling time smaller). So to satisfy Nyquist criterion, the maximum modulation frequency is 0.5 Hz beyond which  aliasing effects are seen.

The measurements taken (mentioned in my previous elog) are used to plot Gain vs Modulation frequency for carrier frequencies of  5 MHz and 25 MHz.

Calculations:

A modulated signal can be represented as X(t)= A*sin (Fc*t+D*sin(Fm*t+phase1))  where Fc and Fm are carrier and modulation frequencies respectively and D is the modulation depth.

This signal Y(t) is input to the FC and the output frequencies of the FC are recorded.

Let the output of the FC is Y(t)= A'*sin(Fc*t+D'*sin(Fm'*t+phase2));

Gain = D'/D;

phase = phase2 - phase1;

D' is calculated by subtracting the carrier frequency from the output frequency and calculating the amplitude of the resulting fitted sine wave.

The phase can be calculated if the phase of the input is known(which will be done next).

Plotting the Bode plots would give response of the FC to modulation.

The plots generated  will be used to estimate:

1) Transfer Function of FC to be known to build an FOL-PID loop.

2) Quantization noise from Power Spectral Density(PSD) vs Hz.

To Do Next:

1)Calculate the phase difference  to complete the Bode plot. This would require interfacing of the ADC on raspberry pi.

2)Estimate the quantization noise from the digital output.

EDIT: Please ignore the following data. The revised data and plot are in Elog 10089 

Yesterday evening, I conducted the same measurements done in Elog-10059 using the same REF PD (NF 1611) and the same model of BBPD, but on different piece that needed to be checked. 

I moved the NA from near rack 1Y1 to the Jenne laser table and back again after the readings were done.

 Acquiring data

• The following conditions were set on Network Analyzer Agilent 4395:

1) Frequency sweep range: 1MHz to 300 MHz.

2) Number of Points sampled in  the range: 201

3) Type of sweep: Logarithmic

• Set the NA to give the corresponding transfer function value (output of BBPD over output of 1611) and also Phase response in degrees.
• Save the data into floppy disk for processing on the computer.

 Results

The Plots of transimpedence obtained are attached. The data and matlab code used is in the zip file.

The transimpedance of  Broadband photodiode (D1002969-v8) was around 50kV/A-70kV/A (Unusually high) for most of the range (2), but the value started falling as the frequency approached 200 MHz.

The high impedance might be because the PD is faulty.   

 [Nichin, Eric G]

As mentioned in Elog 10062, we found RF cables running between demodulators in rack 1Y2 and RF switch in 1Y1 to have bad SMA connectors (No shield / bad soldering / no caps).

we pulled out all the cables belonging to PD frequency response measurement system , 8 in total, and all of them about 5.5m in length.

Their labels read :

REFL33, REFL11, REFL55, AS55, POX11, REFL165, POP22 and POP110. 

All of them are now sitting inside a plastic box in the contorl room.

On another note, instead of fixing all the cables ourselves, Steve and Eric G decided to order custom made RF cables from Pasternack as professionally soldered cables are worth it. We have placed an order for 2 cables (RG405-550CM) to check out  and test them before we order all of the cables.

Oh, nice! This must be a new technique to have a higher transimpedance by breaking the PD.

Now both BBPDs are showing abnormally high impedance.
(Remember, you have not revised your previous entry after my pointing out you have a bug in the code.)

You should break down the measurement into each raw numbers for validation.
And if this high impedance is still true, you should point out what is causing of this anomaly.

 Here is the logic that I have been using to calculate the transimpedence of PDs. Please let me know if you think anything is wrong.

Sorry for the late update Koji.

There was a bug in my code that was pointed out by koji and here is the revised plot of transimpedence. The correct code attached.

The transimpedence value is unusually high, about 50kV/A-70kV/A for most of the range. The same was observed when the transimpedence was calculated on another BBPD in Elog.

It is highly unlikely that both the BBPDs are faulty and might be because I am doing the calculations wrong. Must dig deeper into this. Maybe it is a good idea to try the shot noise method of calculating the transimpedence and see how the values turn out. Will do that ASAP.

  [Nichin, Koji] 

Today evening, me and koji decided to get down to the problem of why the trasimpedence plots were not as they were supposed to be for Broadband photodiode (D1002969-v8) S1200269. There were a few problems that we encountered:

• Turns out the REF PD was not illuminated properly, for maximum output. The DC output voltage turned out to be much higher than the previous measurement. Since I assumed that the REF PD had not been touched since the first day I took readings, I did not check this.
• The fork holding the Test PD was a bit out of shape and only one side of it was clamping down the PD. This made the PD vulnerable swivel about that one side. We replaced it with a new one.
• I was setting the current diving the Jenne laser to about 20mA and this resulted in nocthes at higer frequencies in the network analyzer due to over driving of the diode laser. Once we reduced this to about 12.5-13 mA they disappeared. Also, the current limit setting was set at 40mA which is way too high for the jenne laser and might have resulted in damaging it if someone had accidentally increased the current. We have now set it at 20mA.

After these changes the measurements are as follows:

I moved the NA from near rack 1Y1 to the Jenne laser table. 

 Acquiring data

• Jenne Laser driving current: 12.8mA 
• The following conditions were set on Network Analyzer Agilent 4395:

1) Frequency sweep range: 1MHz to 300 MHz.

2) Number of Points sampled in  the range: 801

3) Type of sweep: Logarithmic

• Set the NA to give the corresponding transfer function value (output of BBPD over output of 1611) and also Phase response in degrees.
• Save the data into floppy disk for processing on the computer.

 Results

DC output voltage of REF PD: 0.568V

DC output voltage of BBPD: 18mV

Power incident on REF PD and BBPD respectively: 0.184mW  and 0.143mW

Hence, Responsivity for REF PD and BBPD respectively:  0.315 A/W and 0.063 A/W 

Responsivity given in the Datasheet for REF PD and BBPD : 0.68 A/W and 0.1 A/W

The reason for these differences are unknown to me and must be investigated.

The Plots of transimpedence obtained are attached. The data and matlab code used is in the zip file.

The transimpedance of  Broadband photodiode (D1002969-v8) S1200269 was around 1kV/A-2kV/A for most of the range, but the value started falling as the frequency approached 100 MHz. This BBPD is best when used at 10-30 MHz.

 The new RF cables arrived. But unfortunately we did not realize that RG405 was a Semi-rigid coax cable, with a copper shielding. These are meant to be installed in setups that will not be changed / disturbed. We need to order a different set of cables. The new cables have joined the other cables in the plastic box mentioned above.

For now to check if the old setup is still working, I have installed an RF cable (that we earlier pulled out and looks like in good shape, labelled REFL33) between the AS55 Demodulator output PD RF MON in rack 1Y2 and the network analyzer input. Since Manasa and the others were busy working with the interferometer, I did not switch on the laser and did not take any readings. The power supply to REF DET remains off.

I will continue with the measurements tomorrow morning and also try to get the data wirelessly using Alex's code. 

[Nichin, Manasa]

I wanted to make sure Alex's system of Diode laser + laser controller + optical splitter was working fine and then make a manual measurement for AS55 PD. Manasa was supervising my work and helping me with unhooking the fibers and taking power meter readings. I have tuned on the power to REF DET from under the POY table.

I switched on the laser sitting in the 1Y1 rack and turned up the driving current to 240mA. On checking the laser power readings at AS55 (AS table) and REF DET (POY table) simultaneously, we got readings of 1.6mA and 2.4mA respectively. This much difference in readings was not expected and I did not continue taking the readings for transimpedence measurement.

I will rectify if this unequal splitting of power by the 1x16 optical splitter is going to cause any difficulties for the automated PDFR system measurement technique and resolve it if needed.

 I have been trying to use an ADC with the Raspberry Pi to be able to measure the phase difference between FC input and output signals.I had a hard time interfacing the ADC  with the Pi (setup attached) even after trying to debug the issue for last two days. So I and Eriq Q performed a system reboot on the Pi and tried all the possible ways for the Pi to detect the ADC but we were not able to. At the end we decided to order another IC(Microchip MCP 3008) which we hope can be interfaced with the Pi. Till then I will finish to write data from the FC into pipes so that the control computers can access the real time data. I will also look the correctness of the sampling time that is provided by the spec of the MCL-Mini circuits that is if we could really achieve 0.1 s sampling time with the FC.

 [Nichin]

I finally did carry out a measurement on the network analyzer. This proves that the previous system will work properly. Just the optical splitter problem is to be taken care of.

For this, after Elog 10102, I did not touch any of the tables or photodiodes. Only turned on the laser at 1Y1 and took readings from the NA located nearby. I switched off the laser after measurements. The power to REF PD remains on.

I plotted transimpedence plots in the usual way and got ridiculous values of 15 ohms at 55MHz. Obviously there is the problem of varying amount of power illuminating the REF PD and AS55.

So, I just plotted the bode plots of transfer function got from the NA to check if the characteristics of AS55 looks as it was supposed to be and Yes! I got a nice peak at 55MHz.

Acquiring data

 RACK 1Y1

• Diode Laser driving current: 240mA 
• The following conditions were set on Network Analyzer Agilent 4395:

1) Frequency sweep range: 1MHz to 100 MHz.

2) Number of Points sampled in  the range: 801

3) Type of sweep: Linear

• Set the NA to give the corresponding transfer function value (output of AS55 over output of 1611) and also Phase response in degrees.
• Save the data into floppy disk for processing on the computer.

The experimental values obtained were:

DC output voltage of REF PD: 7.48V

DC output voltage of AS55: 53.7mV

Power incident on REF PD and AS55 respectively: 2.4mW  and 1.6mW

Taking the DC transimpedence of AS55 as 66.2 ohms (from schematic given at D1300586-v1) and for REF PD as 1E04 ohms

Hence, Responsivity for REF PD and AS55 respectively are:  0.312 A/W and 0.51 A/W

The data and code used are in the zip file.

 Finally, the 0.1s sampling rate of the frequency counter(FC) has been achieved. For this I had to :

 Send in byte codes to set a particular range of the frequency counter.

I was digging  in to find how exactly the circuit inside the frequency counter works and how the processor inside is able to read and write bytes through a HID-USB interface. I found out that the 'AutoRange' setting (which I have been using so far) has an independent  multiplexing circuit  which consumes some time(that varies with the drift in frequencies) and thus, the the processor waits for some specific time for this process and cannot reach the minimum 0.1 s sampling time. To mitigate this issue, I set the range bytes to the appropriate range of frequencies so that I can bypass the MUX  delay. Here is the list of Range and frequencies for the FC:

Range 1:    1 - 40 MHz

Range 2:    40 - 190 MHz

Range 3:    190 - 1400 MHz

Range 4 :   1400 - 6000 MHz

I then took measurements for sampling time of 0.1 s at carrier frequencies of 5 MHz and 25 MHz from SRS DS345  and plotted the improvised gain plots(attached) to those in my previous elog(10070)  with the same procedure mentioned before.

To do Next:

Plot the gain plots for higher carrier frequencies till range 3 using Marconi Function generator.

Write the data from FC into C1: ALS-Y_SLOW_SERVO1_OFFSET EPICS channel.

 The attached are the gain plots at carrier frequencies of 100 MHz, 500 MHz and 1 GHz measured using IFR 2023B (Marconi).

 [ Nichin, Eric G]

RF cables have been installed between deomodulator output PD RF MON and the RF switch for the following PDs:

 REFL33, AS55, REFL55,REFL165,REFL11,POX11,POP22

The cables are labelled on both ends and have been run on the overhead tray.

The cabling looks neat on 1Y2, but not so much in 1Y1(RF switch). I will better organize them later.

There were quite a few more demodulator units labelled with PD names. Do any of them need to be included in the automated frequency response measurement system? Please let me know so that I can include them to the RF switch and check them for proper illumination, which i will do for all the above PDs next week.

Test run:

I tested the RF switch selection code and then the data acquisition code for the NWAG4395A network analyzer and they both seemed to work fine. I selected the channel to which AS55 is hooked up to and then remotely got its transfer function.

There is quite some noise in the system as the plot shows. Especially the phase. Maybe my driving power was a bit too low. Have to figure out the reason behind this.

Further work:

• Make sure all the PDs are properly illuminated.
• Create a DC voltage reading's database for all PDs.
• Canonical plots for each PD to compare with the current data.
• Implement a script to fit the transfer function and extract required information about the PD.

 Goal:

To complete the characterization of the Mini Circuits UFC-6000  RF Frequency Counter to be used for beat note measurement  as a part of frequency offset locking loop. The aim of this setup was to obtain the bode plots and PSD plots for the FC.

Detail about the Setup:

UFC RF Frequency Counter: Described in detail in one of my previous elog (http://nodus.ligo.caltech.edu:8080/40m/10020) 

Raspberry Pi: Raspberry Pi will be running Raspbian which is a version of Linux, and not a RTOS. When sampling data at a certain frequency we want samples to occur at fixed time intervals corresponding to the sampling period. A normal operating system cannot provide us with this functionality, and there will be jitter (variation) in the time difference between consecutive samples. Whether this is an issue depends on how much jitter we have and what the specific application is. In our application(measuring phase and noise), the jitter has to be taken into consideration. Hence for data acquisition we need  to sample with much more tightly defined sampling periods (reduced jitter) which can be done by providing an external timing standard(Like a square pulse of the frequency same as the sampling rate of the FC ).

ADC : The ADC serves for two different conversion processes in the setup:

            1)  For converting modulating analog signal(from SRS 30 MHz Wave Generator) into digital signal for data analysis on Raspberry Pi.

            2)  To provide an external clock reference to the Raspberry Pi.

Interfacing ADC(ADS1115) with Pi:

Configuring the ADS1115 - Configuration Register

In order to set the modes of operation defined above we must set the config register within the ADS1115. A register is simply a memory location within the chip. Registers are made up of bytes (8 bits) of data. Registers are typically either one or two bytes long. The bits are:

Bit [15] This bit is used to start a conversion, by setting this bit to 1 a conversion is initiated. When reading the config register this bit remains equal to 0 while the conversion is carried out, and is set to 1 once the conversion is complete, we can monitor this bit to find the status of a conversion

Bits [14:12] These bits set which pin to use as input to the ADC. Note that we can choose either single ended or differential mode through setting these bits. Note that each configuration has two inputs AIN~p~ and AIN~n~. By setting AIN~n~ to GND we obtain a single ended input with AIN~p~ as the input.

Bits [11:9] These bits set which setting of the programmable gain amplifier to use

Bit [8] Continuous conversion / No Continuous conversion

Bits [7:5] Set the samples per second (sps) value

Bit [4:2] Comparator setup, we will not use the comparator so these bits are irrelevant

Bit [1:0] Comparator mode, set to 11 to disable the comparator.

 Four channels are used in differential mode for A-D conversion of two analog signals, one the slow modulating signal input and the other for a square signal of 10 Hz (same as sampling rate of FC(0.1 s)).

The raspberry Pi reads the external trigger from ADC and starts reading input from the FC only when the square signal is 1. Thus in this way we can avoid the clock jitter and timing can be as accurate as the RTOS.

Function Generators:

Three function generators are used in the setup:

1. IFR Marconi Generator used for RF Carrier signal.
2. SRS 30 MHz Function Generator used for slow modulating signal (upto 5Hz).
3. SRS 30 MHz signal for square wave used as clock(10 Hz).

 The setup is attached as pdf. The computer scripts will follow this elog.

Measurements Taken:

The input and output modulated signals are recorded and the delay and noise of the FC are to be estimated.

 In the order that makes more sense to me, it looks like you have:

REFL11, REFL33, REFL55, REFL165,

AS55

POX11

POP22

We don't really need POP22 right now, although we do want the facility to do both POP22 and POP110 for when we (eventually) put in a better PD there.  Also, we want cabling for POP55, so that we can illuminate it after we re-install it.  If we're working on 2f PDs, we might as well consider AS110 also, although I don't know that there was a fiber layed for it.  The big one that you're missing is POY11.

When I was trying to plot PSD of the measurements, I still couldn't get better resolution. There still seems to be a problem with timing and synchronization of the R Pi with the FC even after addition of the external trigger circuit. Now, I am looking to debug this issue. Attached are the plots showing missing data points and data from the FC at uneven spacing(zoomed in plot).

The RF cables have been routed incorrectly. The cables run to the module from the front of the rack. We cannot close the doors to the racks if they are to remain this way.

I have asked Nichin to reroute the cables properly.

 A new RF cable has been included for POY11. Cabling for POP55 and POP110 might or might not exist. I will check and report it.

RF cables have been rerouted from the side of the rack, under the supervising eye of Manasa.

I moved the red ladder from near 1X4 to 1Y1 and back again.

Current list of RF cables:

REFL11, REFL33, REFL55, REFL165,

AS55

POX11

POP22

POY11

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

This Red Ladder movement also probably included some bumping of the MC2 stack (be more careful when working in the lab). Around 5 PM today, the MC lost lock.

When I came in later, I found that the MC was flashing the TEM17,9 mode and had been misaligned like this for ~1 hour. I looked through the MC SUS sensor trends and moved MC2 back to its old position to get the locking back. I disabled the WFS, tweaked the TEM00 mode alignment using only MC2 sliders, and then re-enabled WFS. Its been OK for the past 5 hours.

 Although there were few timing issues with the FC and the Raspberry Pi at the lowest sampling time of the FC (0.1s) even after adding an external trigger circuit, it turned out that most of these issues are not prevalent at higher sampling times(>0.5 s)(narrow peaks of PSD seen for higher sampling times). Rana suggested me to look at the PSD plots at different sampling times of the FC so that we can decide which would be the optimal sampling time to work with the FC before replacing the spectrum analyzer. I took the measurements with the setup discussed in my previous elog(http://nodus.ligo.caltech.edu:8080/40m/10129) . However, the  noise of the R Pi- FC interface should be taken care of (I will discuss it with my mentors).

Attached are the plots at 100 MHz carrier frequency at  different sampling times of the FC( 0.1s, 0.2s, 0.3s, 0.5s, 1s) (pdfs and code attached in a zip file)

RXA: Put all the plots in a single PDF file and use the same axis limits for all plots so that its easy to compare.      (Attached in PSD.pdf)

The RF multiplexer is configured as shown in the figure. It is now effectively a 15x1 RF mux.

To select a required channel:

Run the script as shown below 

/opt/rtcds/caltech/c1/scripts/general/rfMux.py

>python rfMux.py ch11

For channel 10 to 16, you can just enter the required channel number and it is routed to the output.

For channel 1 to 8, you only need to input the required channel number as above. No need to run the code again to select ch9 after selecting ch1-8

How the NI-8100 controller works:

Whenever any channel of one switch is selected, the output of the other switch is set to its ch0 (ch1 and ch9 in the figure).

So selecting ch1-8 will automatically select ch9 as output for the other switch. IF you send a command to select ch9 afterwards, the first switch will be automatically set to ch1 and not stay on what you had selected before.

I finally made good on the LIFE TIME WARRANTY on the ancient, Jamie-made 1811 power supply with the faulty switch:

Back to fully working form.  Hopefully I'll still be around the next time it breaks in 16 years.

 Placed in PD cabinet in Y arm, next to the OTHER Jamie-made 1811 power supply from 1998.

We need to work farther on checking out the end transmission QPD electronics situation. 

In bullet-point form, we need to:

* Ensure that the Weiss QPD head modifications have been made on these diodes.  (cf. Rai W's LLO elogs on QPDs)

* Ensure that the QPD biases are somewhere in the range of 10-15V, not the old 100V.  (Because we only need HV to make the capacitance low for RF use. Low voltage means less power dissipation in the head)

* Ensure the Rana/Rob modifications have been propagated to the whitening boards, so that we have full dynamic range.  (Steve is looking for the marked up paper schematics)

* Replace signal path resistors with low noise metal film resistors.

* Check QPDs / whitening boards for oscillation (with a scope probe), ensure that we chose an appropriate analog gain.

In thinking about the transimpedances that we want, we thought about the current that we expect.  We should get about 100 mW of light transmitted through the ETMs when we have full IFO lock.  There is a 50/50 BS to split the light between the QPD and the Thorlabs transmission diode, so we have about 50 mW incident on the QPDs, which is about 13 mW per quadrant.  With a sensitivity of about 0.15 Amps/Watt for silicon, this means that we're expecting to see about 2 mA of current per quadrant once we have the IFO fully resonant. We want this to correspond to about 5V, which means we want a transimpedance gain of around 2.5 kOhm. 

For the things that need checking, each quadrant has:

Photodiode  ------  Gain Switch 1 ----- Gain Switch 2  ------ Gain Switch 3 ------ Variable Gain Amplifier ------- Whitening stage 1 (z @ 4 Hz, p @ 40 Hz)  ------- Whitening stage 2 (z @ 4 Hz, p @ 40 Hz)

We want to check on the status of each of these switches, and whether they actually do what they say on the QPD Head screens.  Q has checked out and fixed the bit outputs for the whitening stages, but the rest still needs to be checked out.  Also note that the Switch 1, Switch 2 and Switch 3 are common to all 4 quadrants (i.e. enabling switch 1 on one quadrant enables it on all quadrants), but the variable gains and the whitening stages are individual for each quadrant.

Today, me and Manasa went inside the lab to figure out a place for the place for the FC. The whole setup will be placed in a chassis box . The chassis in figure(setupforFC.pdf) will be placed in the highlighted(red) box in the figure(setup.png). All the cables will be routed to the computers from behind the box and the RF cables from the beat box will be routed from the front end of the box. The two raspberry Pi boxes will be placed inside the box and the Frequency counters will be mounted as shown so that the frequency count can be seen from outside. 

 [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:   P_inc = 0.91 mW         VDC = 34.9 mV 

REFL33:   P_inc = 0.83 mW         VDC = 33.2 mV 

REFL55:   P_inc = 1.08 mW         VDC = 42.7 mV 

REFL165: P_inc = 0.79 mW         VDC = 115.3 mV

AS55:         P_inc = 0.78 mW         VDC = 31.3 mV

POX11:      P_inc = 0.83 mW         VDC = 34.7 mV

POP22**:   P_inc = 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:    P_inc = 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. 

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

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 )
  

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

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.

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.

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

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.

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

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.

Log-log ... 

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

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.

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.

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

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. 

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.

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)