This afternoon I started setting up the Supermicro 5017A-EP that will replace c1vac1/2. Following Johannes's procedure in 13681 I installed Debian 8.11 (jessie). There is a more recent stable release, 9.5, now available since the first acromag machine was assembled, but I stuck to version 8 for consistency. We already know that version to work. The setup is sitting on the left side of the electronics bench for now.

Today I finished setting up the server that will replace the c1vac1/2 machines. I put it on the martian network at the unassigned IP 192.168.113.72. I assigned it the hostname c1vac and added it to the DNS lookup tables on chiara.

I created a new targets directory on the network drive for the new machine: /cvs/cds/caltech/target/c1vac. After setting EPICS environment environment variables according to 13681 and copying over (and modifiying) the files from /cvs/cds/caltech/target/c1auxex as templates, I was able to start a modbusIOC server on the new machine. I was able to read and write (soft) channel values to the EPICS IOC from other machines on the martian network.

I scripted it as a systemd-managed process which automatically starts on boot and restarts after failure, just as it is set up on c1auxex.

Wiring of the power, Ethernet, and indicator lights for the vacuum Acromag chassis is complete. Even though this crate will only use +24V DC, I wired the +/-15V connector and indicator lights as well to conform to the LIGO standard. There was no wiring diagram available, so I had to reverse-engineer the wiring from the partially complete c1susaux crate. Attached is a diagram for future use. The crate is ready to begin software developing on Monday. 

All 7 Acromag units are now installed in the vacuum chassis. They are connected to 24V DC power and Ethernet.

I have merged and migrated the two EPICS databases from c1vac1 and c1vac2 onto the new machine, with appropriate modifications to address the Acromags rather than VME crate.

I have tested all the digital output channels with a voltmeter, and some of the inputs. Still more channels to be tested.

I’ll follow up with a wiring diagram for channel assignments.

I've set up a closed subnetwork for interfacing the vacuum hardware (Acromags and serial devices) with the new controls machine (c1vac; 192.168.113.72). The controls machine has two Ethernet interfaces, one which faces outward into the martian network and another which faces the internal subnetwork, 192.168.114.xxx. The second network interface was configured via the following procedure.

1. Add the following lines to /etc/network/interfaces:

allow-hotplug eth1
iface eth1 inet static
address 192.168.114.9
netmask 255.255.255.0

2. Restart the networking services:

3. Enable DNS lookup on the martian network by adding the following lines to /etc/resolv.conf:

search martian
nameserver 192.168.113.104

4. Enable IP forwarding from eth1 to eth0:

5. Configure IP tables to allow outgoing connections, while keeping the LAN invisible from outside the gateway (c1vac):

6. Finally, because the EPICS 3.14 server binds to all network interfaces, client applications running on c1vac now see two instances of the EPICS server---one at the outward-facing address and one at the LAN address. To resolve this ambiguity, two additional enviroment variables must be set that specify to local clients which server address to use. Add the following lines to /home/controls/.bashrc:

EPICS_CA_AUTO_ADDR_LIST=NO
EPICS_CA_ADDR_LIST=192.168.113.72

A list of IP addresses so far assigned on the subnetwork follows.

I've completed bench testing of all seven vacuum Acromags installed in a custom rackmount chassis. The system contains five XT1111 modules (sinking digital I/O) used for readbacks of the state of the valves, TP1, CP1, and the RPs. It also contains two XT1121 modules (sourcing digital I/O) used to pass 24V DC control signals to the AC relays actuating the valves and RPs. The list of Acromag channel assignments is attached.

I tested each input channel using a manual flip-switch wired between signal pin and return, verifying the EPICS channel readout to change appropriately when the switch is flipped open vs. closed. I tested each output channel using a voltmeter placed between signal pin and return, toggling the EPICS channel on/off state and verifying the output voltage to change appropriately. These tests confirm the Acromag units all work, and that all the EPICS channels are correctly addressed.

New hardware has been installed in the vacuum controls rack. It is shown in the below post-install photo.

• Supermicro server (c1vac) which will be replacing c1vac1 and c1vac2.
• 16-port Ethernet switch providing a closed local network for all vacuum devices.
• 16-port IOLAN terminal server for multiplexing/Ethernetizing all RS-232 serial devices.

Below is a high-level summary of where things stand, and what remains to be done.

Completed:

✔ Set up of replacement controls server (c1vac).

• Supermicro 1U rackmount server, running Debian 8.5.
• Hosting an EPICS modbus IOC, scripted to start/restart automatically as a system service.
• First Ethernet interface put on the martian network at 192.168.113.72.
• Second Ethernet interface configured to host a LAN at 192.168.114.xxx for communications with all vacuum electronics. It connects to a 16-port Ethernet switch installed in the vacuum electronics rack.
• Server installed in vacuum electronics rack (see photo).

✔ Set up of Acromag terminals.

• 6U rackmount chassis frame assembled; 15V DC, 24V DC, and Ethernet wired.
• Acromags installed in chassis and configured for the LAN (5 XT1111 units, 2 XT1121 units).

✔ EPICS database migration.

• All vacuum channels moved to the modbus IOC, with the database updated to address the new Acromags. [The new channels are running concurrently at "C1:Vac2-...." to avoid conflict with the existing system.]
• Each hard channel was individually tested on the electronics bench to confirm correct addressing and Acromag operation.

✔ Set up of 16-port IOLAN terminal server (for multiplexing/Ethernetizing the serial devices).

• Configured for operation on the LAN. Each serial device port is assigned a unique IP address, making the terminal server transparent to client TCP applications.
• Most of the pressure gauges are now communicating with the controls server via TCP.

Ongoing this week:

• [Jon] Continue migrating serial devices to ports on the terminal server. Still left are the turbo pumps, N2 gauge, and RGA.
• [Jon] Continue developing Python code for communicating with gauges and pumps via TCP sockets. A beta version of gauge readout code is running now.
• [Chub] Install feedthrough panels on the Acromag chassis. Connect the wiring from feedthrough panels to the assigned Acromag slots.
• [Chub/Jon] Test all the hard EPICS channels on the electronics bench, prior to installing the crate in the vacuum rack.
• [Chub/Jon] Install the crate in the vacuum rack; connect valve/pump readbacks and actuators; test each hard EPICS channel in situ.
• [Jon] Once all the signal connections have been made, in situ testing of the Python interlock code can begin.

All the serial vacuum signals are now interfaced to the new digital controls system. A set of persistent Python scripts will query each device at regular intervals (up to ~10 Hz) and push the readings to soft channels hosted by the modbus IOC. Similar scripts will push on/off state commands to the serial turbo pumps.

IP Addresses/Comm Settings

Each serial device is assigned an IP address on the local subnet as follows. Its serial communication parameters as configured in the terminal server are also listed.

Hardware Modifications

• Each of the five vacuum gauge controllers has an RJ45 adapter installed directly on its DB9/DB25 output port. Because the RJ45 cable now plugs directly into the terminal server, instead of passing through some additional adapters as it formerly did, it was necessary to reverse the wiring of the controller TXD and RXD pins to Ethernet pins. The DB9/25-to-RJ45 adapters on the back of the controllers are now wired as follows.
  • For the MKS controllers: DB2 (RXD) --> Eth4;  DB3 (TXD) --> Eth5;  DB5 (RTN) --> Eth6
  • For the Granville-Phillips controllers: DB2 (TXD) --> Eth5;  DB3 (RXD) --> Eth4;  DB7 (RTN) --> Eth6
• I traced a communications error with the GP307 gauge controller all the way back to what I would have suspected least, the controller itself. The comm card inside each controller has a set of mechanical relay switches which set the communications parameters (baud rate, parity, etc.). Knowing that this controller was not part of the original installation, but was swapped in to replace the original in 2009, I pulled the controller from the rack and checked the internal switch settings. Sure enough, the switch settings (pictured below) were wrong. In the background of the photo is the unit removed in 2009, which has the correct settings. After setting the correct communications parameters, the controller immediately began communicating with the server. Did these readouts (PRP, PTP1) never work since 2009? I don't see how they could.

The foam in the cable tray wall passage had been falling on the floor in little bite-sized pieces, so I investigated and found a fiber cable that had be chewed/clawed through.  I didn't find any droppings anywhere in the 40m, but I decided to bait an un-set trap and see if we'd find activity around it. There has been none so far.  If there is still none tomorrow, I will move the trap and keep looking for signs of rodentia.  At the moment, the trap is in a box in front of the double doors at the north end of the control room.  Next it will be place in the IFO room, up in the cable tray. 

gautam: the fiber that was damaged was the one from the LSC rack FiBox to the control room FiBox. So no DAFI action for a bit...

I added lubricating oil to roughing pumps RP1 and RP3 yesterday and this morning.  Also, I found a nearly full 5 gallon jug of grade 19 oil in the lab.  This should set us up for quite a while.  If you need to add oil the the roughing pumps, use the oil in the quart bottle in the flammables cabinet.  It is labeled as Leybold HE-175 Vacuum Pump Oil.  This bottle is small enough to fill the pumps in close quarters.

The Central Plant building will be undergoing seismic upgrades in the near future.  The adjoining north wall along the Y arm will be the first to have this work done, from inside the Central Plant.  Project manager Eugene Kim has explained the work to me and also noted our concerns.  He assured me that the seismic noise from the construction will be minimized and we will always be contacted when the heaviest construction is to be done.

Tomorrow at 11am, I will bring Mr. Kim and a few others from the construction team to look at the wall from inside the lab.  If you have any questions or concerns that you want to have addressed, please email them to me or contact Mr. Kim directly at x4860 or through email at eugene.kim@caltech.edu . 

The schematic of the homodyne configuration is shown below.

Following are the list of components

• The fiber mismatch between the couplers and the delay fiber could affect the coupling efficiency

I went through all the elog entries related to CCD calibration. I was wondering if we can use Spectralon diffuse reflectance standards (https://www.labsphere.com/labsphere-products-solutions/materials-coatings-2/targets-standards/diffuse-reflectance-standards/diffuse-reflectance-standards/) instead of a white paper as they would be a better approximation to a Lambertian scatterer.

Telescope design:
On calculating the accessible u-v ranges and the % error in magnification (more precisely, %deviation), I got %deviation of order 10 and in some cases of order 100 (attachments 1 to 4), which matches with Pooja's calculations. But I'm not able reproduce Jigyasa's %error calculations where the %error is of order 10^-1. I couldn't find the code that she had used for these calculations and I even mailed her about the same. We can still image with 150-250 mm combination as proposed by Jigyasa, but I don't think it ensures maximum usage of pixel array. Also for this combination the resulting conjugate ratio will be greater than 5. So, use of plano-convex lenses will reduce spherical aberrations. I also explored other focal length combinations such as 250-500 mm and 500-500mm. In these cases, both the lenses will have f-numbers greater than 5. But the conjugate ratios will be less than 5, so biconvex lenses will be a better choice.

Constraints: available lens tube length (max value of d) = 3" ; object distances range (u) = 70 cm to 150 cm ; available cylindrical enclosures (max value of d+v) are 52cm and 20cm long (https://nodus.ligo.caltech.edu:8081/40m/13000).

I calculated the resultant image distance (v) and the required distance between lenses (d), for fixed magnifications (i.e. m = -0.06089 and m = -0.1826 for imaging test masses and beam spot respectively) and different values of 'u'. This way we can ensure that no pixels are wasted. The focal length combinations - 300-300mm (for imaging beam spot), and 100-125mm (for imaging test masses) - were the only combinations that gave all positive values for 'd' and 'v', for given range of 'u' (attachments 5-6). But here 'd' ranges from 0 to 30cm in first case, which exceeds the available lens tube length. Also, in the second case the f-numbers will be less than 5 for 2" lenses and thus may result in spherical aberration.

All this fuss about f-numbers, conjugate ratios, and plano-convex/biconvex lenses is to reduce spherical aberrations. But how much will spherical aberrations affect our readings? 

We have two 2" biconvex lenses of 150mm focal length and one 2" biconvex lens of focal length 250mm in stock. I'll start off with these and once I have a metric to quantify spherical aberrations we can further decide upon lenses to improve the telescopic lens system.

Went through all of Pooja's elog posts, her report and am currently cleaning up her code and working on setting up the simulations of spot motion from her work last year. I've also just begun to look at some material sent by Gautam on resonators.

This week, I plan to do the following:

1) Review Gabriele's CNN work for beam spot tracking and get his code running.

2) Since the relation between the angular motion of the optic and beam spot motion can be determined theoretically, I think a neural network is not mandatory for the tracking of beam spot motion. I strongly believe that a more traditional approach such as thresholding, followed by a hough transform ought to do the trick as the contours of the beam spot are circles. I did try a quick and dirty implementation today using opencv and ran into the problem of no detection or detection of spurious circles (the number of which decreased with the increased application of median blur). I will defer a more careful analysis of this until step (1) is done as Gautam has advised.

3) Clean up Pooja's code on beam tracking and obtain the simulated data.

4) Also data like this  (https://drive.google.com/file/d/1VbXcPTfC9GH2ttZNWM7Lg0RqD7qiCZuA/view) is incredibly noisy. I will look up some standard techniques for cleaning such data though I'm not sure if the impact of that can be measured until I figure out an algorithm to track the beam spot.

A more interesting question Gautam raised was the validity of using the beam spot motion for detection of angular motion in the presence of other factors such as surface irregularities. Another question is the relevance of using the beam spot motion when the oplevs are already in place. It is not immediately obvious to me how I can ascertain this and I will put more thought into this.

I'm not able to get trends of the TM adjustment test that Rana had asked us to perform, from the dataviewer. It's throwing the following error:

Connecting to NDS Server fb (TCP port 8088)
Connecting.... done
Server error 7: connect() failed
datasrv: DataWrite failed: daq_send: Resource temporarily unavailable
T0=19-07-20-01-27-39; Length=600 (s)
No data output.

What channels are you trying to read?

Still removing old cable, terminal blocks and hardware.  Once new strain reliefs and cable guides are in place, I will need to disconnect cables and reroute them.  Please let me know dates and times when that is not going to interrupt your work! 

{Yehonathan, Gautam}

In order to measure the loss in the arm cavities in reflection, we use the DC method described in T1700117.

It was not trivial to find free channels on the LSC rack. The least intrusive way we found was to disconnect the ALS signals DSUB9 (Attachment 1) and connect a DSUB breakout board instead (Attachment 2).

The names of the channels are ALS_BEATY_FINE_I_IN1_DQ for AS reflection and ALS_BEATY_FINE_Q_IN1_DQ for MC transmission. Actually, the script that downloads the data uses these channels exactly...

We misalign the Y arm (both ITM ad ETM) and start a 30 rep measurement of the X arm loss cavity using /scripts/lossmap_scripts/armLoss/measureArmLoss.py and download the data using dlData.py.

We analyze the data. Raw data is shown in attachment 3. There is some drift in the measurement, probably due to drift of the spot on the mirror. We take the data starting from t=400s when the data seems stable (green vertical line). Attachment 5 shows the histogram of the measurement

X Arm cavity RT loss calculated to be 69.4ppm.

We repeat the same procedure for the Y Arm cavity the day after. Raw data is shown in attachment 5, the histogram in attachment 6.

Y Arm cavity RT loss calculated to be 44.8ppm. The previous measurement of Y Arm was ~ 100ppm...

Loss map measurement is in order.

As requested, I placed an order for an assortment of new RF cables: SMA male-male, RG405.

• x3 12"
• x3 24"
• x2 48"

They're expected to arrive mid next week.

I re-ordered the below cables, this time going with flexible, double-shielded RG316-DS. Jordan will pick up and return the RG-405 cables after the holidays.

Our favorite (flexible) RF cable is Belden's 1671J (Jacketed solder-soaked coax cable). It is compatible RG405. I'm not sure if there is off-the-shelf SMA cables with 1671J.

After the disk system trouble, we could not make the RTS running at the nominal state. A part of the troubleshoot FB1 was rebooted. But the we found that the GPS time was a year off from the current time

controls@fb1:/diskless/root/etc 0$ cat /proc/gps 
1283046156.91
controls@fb1:/diskless/root/etc 0$ date
Thu Sep  2 18:43:02 PDT 2021
controls@fb1:/diskless/root/etc 0$ timedatectl 
      Local time: Thu 2021-09-02 18:43:08 PDT
  Universal time: Fri 2021-09-03 01:43:08 UTC
        RTC time: Fri 2021-09-03 01:43:08
       Time zone: America/Los_Angeles (PDT, -0700)
     NTP enabled: no
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2021-03-14 01:59:59 PST
                  Sun 2021-03-14 03:00:00 PDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2021-11-07 01:59:59 PDT
                  Sun 2021-11-07 01:00:00 PST

Paco went through the process described in Jamie's elog [40m ELOG 16299] (except for the installation part) and it actually made the GPS time even strange

controls@fb1:~ 0$ cat /proc/gps
967861610.89

I decided to remove the gpstime module and then load it again. This made the gps time back to normal again.

controls@fb1:~ 0$ sudo modprobe -r gpstime
controls@fb1:~ 0$ cat /proc/gps
cat: /proc/gps: No such file or directory
controls@fb1:~ 1$ sudo modprobe gpstime
controls@fb1:~ 0$ cat /proc/gps
1314671254.11

I gave some of the data analysts a look around because they asked and nothing was currently going on in the 40m. Nothing was changed.

We came this morning and noticed the FSS_FAST channel was moving very rapidly. Short inspection showed that MC3 watchdog got tripped. After reenabling the watchdog the issue was fixed and the MC is stable again.

There is a spike in the seismometers 8 hours ago and it was probably due to the 4.2 magnitude earthquake that happened in Malibu beach around that time.

The fan behind the PSL controller is injecting excess band limited noise

Background

While doing noise hunting to improve the BHD lock stability, we noticed peculiar noise bumps in the BH44 error point near (but not exactly at) the even line-harmonics (for example 120 Hz, 240 Hz, ...). Other channels such as C1:HPC-BHDC_SUM, C1:LSC-PRCL_IN1, or even C1:LSC-XARM_IN1 didn't show these features, so we looked at C1:IOO-MC_F_DQ (which represents the free running laser noise above 100 Hz) and to our surprise found this excess noise!

Noise hunting around PSL

Since this noise is present upstream, we decided to hunt around using C1:IOO-MC_F_DQ. We set up a diaggui measurement to do some "live demodulation" as suggested by Koji in order to understand the nature of this noise. In order to get some "video bandwidth" we set up a power spectrum measurement from 114 Hz to 140 Hz (to monitor the usual 120 Hz line noise peak) with a bandwidth of 1 Hz. A single exponential average gave us the 1 Hz narrow spectrum in "real time", from which we noticed its nonstationary character. The band limited excess noise is the result of a peak hovering in the range of 125 to 131 Hz. With this diagnostic set up, we started hunting for its source.

1. We checked the fan behind the PSL controller (Attachment #1). 
   1. After disconnecting the molex powering it with +15 VDC the noise dissappeared!

To show the impact in the complete noise spectrum, we took a 10 fixed average measurement with and without the fan being on. The result is in Attachement #2. The spectra are shown along with their rms, which is significantly reduced when the fan is off near the 100 Hz frequency band (where these bumps appear). Anyways, we have left the fan on because the PSL controller needs it so the problem remains, but we have at least identified the source.

This is a simple representation of the schematic:

          gnd
#          |
#          Cw2
#          |
#          n23
#          |
#          Lw2
#          |
#           n22
#          |
#          Rw2                 
#                 |                   |\             
#           n2- - - C2 - n3 -  - -  - |  \           
#            |    |      |   |        |4106>-- n5 - Rs -- no
# iinput    Rd   L1     L2 R24    n6- |  /     |           |
#      nin - |    |      |   |    |   |/       |         Rload     
#           Cd   n7     R22 gnd   |            |           |           
#            |    |      |        | - - - R8 - -          gnd               
#           gnd  R1     gnd      R7  
#                 |               |
#         gnd               gnd
#                  
#
#

I chose the values of the components in a realistic way, that is using part available from Coilcraft or Digikey.

Using LISO I simulated the Tranfer Function and the noise of the circuit.

I'm attaching the results.

I'll post the 55MHz rfpd later.

oops, forgotten the third attachment...

here it is

I read a few datasheets of the C30642GH photodiode that we're going to use for the 11 and 55 MHz. Considering the  values listed for the resistance and the capacitance in what they define "typical conditions" (that is, specific values of bias voltage and DC photocurrent) I fixed Rd=25Ohms and Cd=175pF.

Then I picked the tunable components in the circuit so that we could adjust for the variability of those parameters.

Finally with LISO I simulated transfer functions and noise curves for both the 11 and the 55MHz photodiodes.

I'm attaching the results and the LISO source files.

Use 10 Ohms for the resistance - I have never seen a diode with 25 Ohms.

p.s. PDFs can be joined together using the joinPDF command or a few command line options of 'gs'.

I spent some time trying to understand how touching the metal cage inside or bending the PCB board affected the photodiode response. It turned out that there was some weak soldering of one of the inductors.

 Hartmut suggested a possible explanation for the way the electronics transfer function starts picking up at ~50MHz. He said that the 10KOhm resistance in series with the Test Input connector of the box might have some parasitic capacitance that at high frequency lowers the input impedance.

Although Hartmut also admitted that considering the high frequency at which the effect is observed, anything can be happening with the electronics inside of the box.

I upgraded the old REFL199 to the new REFL55.

To do that I had to replace the old photodiode inside, switching to a 2mm one.

Electronics and optical transfer functions, non normalized are shown in the attached plot.

The details about the modifications are contained in this dedicated wiki page (Upgrade_09 / RF System / Upgraded RF Photodiodes)

These are the dark noise spectrum that I measured on the 11MHz and 55MHz PD prototypes I modified.

The plots take into account the 50Ohm input impedance of the spectrum analyzer (that is, the nosie is divided by 2).

With an estimated transimpedance of about 300Ohm, I would expect to have 2-3nV/rtHz at all frequencies except for the resonant frequencies of each PD. At those resonances I would expect to have ~15nV/rtHz (cfr elog entry 2760).

Problems:

1. For the 55MHz PD the resonance peak is too small
2. In the 55 MHz: noise is present at about 7MHz
3. In the 11MHz PD there's a lot of noise below 10 MHz.

I have to figure out what are the sources of such noises.

Suggestions?

After adding an inductor L=100uH and a resistor R=10Ohm in parallel after the OP547A opamp that provide the bias for the photodiode of REFL11, the noise at low frequency that I had observed, was significantly reduced.

See this plot:

A closer inspection of the should at 11MHz in the noise spectrum, showed some harmonics on it, spaced with about 200KHz. Closing the RF cage and the box lid made them disappear. See next plot:

The full noise spectrum looks like this:

A big bump is present at ~275MHz. it could important if it also shows up on the shot noise spectrum.

From the measurements of the 11 MHz RFPD at 11Mhz I estimated a transimpedance of about 750 Ohms. (See attached plot.)

The fit shown in the plot is: Vn = Vdn + sqrt(2*e*Idc) ; Vn=noise; Vdn=darknoise; e=electron charge; Idc=dc photocurrent

The estimate from the fit is 3-4 times off from my analsys of the circuit and from any LISO simulation. Likely at RF the contributions of the parassitic components of each element make a big difference. I'm going to improve the LISO model to account for that.

The problem of the factor of 2 in the data turned out to be not a real one. Assuming that the dark noise at resonance is just Johnson's noise from the resonant circuit transimpedance underestimates the dark noise by 100%.

Putting my hands ahead, I know I could have taken more measurements around the 3dB point, but the 40m needs the PDs soon.

Something must be wrong. 

1. Physical Unit is wrong for the second term of "Vn = Vdn + Sqrt(2 e Idc)"

2. Why does the fit go below the dark noise?

3. "Dark noise 4 +/- NaN nV/rtHz"   I can not accept this fitting.

Also apparently the data points are not enough.

 1) True. My bad. In my elog entry (but not in my fit code) I forgot the impedance Z= 750Ohm (as in the fit) of the resonant circuit in front of the square root: Vn = Vdn + Z * sqrt( 2 e Idc )

2) That is exactly the point I was raising! The measured dark noise at resonance is 2x what I expect.

I also admitted that the data points were few, especially around the 3dB point.

Today I'm going to repeat the measurement with a new setup that lets me tune the light intensity more finely.

All the details and data will be included in the wiki page (and so also the results for AS55). Here I just show the comparison of the transfer functions that I measured and that I modeled.

I applied an approximate calibration to the data so that all the measurements would refer to the transfer function of Vout / PD Photocurrent. Here's how they look like. (also the calibration will be explained in the wiki)

.

The ratio between the amplitude of the 55Mhz modulation over the 11MHz is ~ 90dB

The electronics TF doesn't provide a faithful reproduction of the optical response.

 Here's another measurement of the noise of the REFL11 PD.

This time I made the fit constraining the Dark Noise. I realized that it didn't make much sense leaving it as a free coefficient: the dark noise is what it is.

Result: the transimpedance of REFL11at 11 MHz is about 4000 Ohm.

Data looks perfect ... but the fitting was wrong.

Vn = Vdn + Z * sqrt( 2 e Idc ) ==> WRONG!!!

Dark noise and shot noise are not correlated. You need to take a quadratic sum!!!

Vn^2 = Vdn^2 + Z^2 *(2 e Idc)

And I was confused whether you need 2 in the sqrt, or not. Can you explain it?
Note that you are looking at the raw RF output of the PD and not using the demodulated output... 

Also you should be able to fit Vdn. You should put your dark noise measurement at 10nA or 100nA and then make the fitting.

Here's the (calibrated) transimpedance of the new REFL55 PD.

T(55.3) / T_(11.06) = 93 dB

After munching analytical models, simulations, measurements of photodiodes I think I got a better grasp of what we want from them, and how to get it. For instance I now know that we need a transimpedance of about 5000 V/A if we want them to be shot noise limited for ~mW of light power.

Adding 2-omega and f1/f2 notch filters complicates the issue, forcing to make trade-offs in the choice of the components (i.e., the Q of the notches)

Here's a better improved design of the 11Mhz PD.

 This should be better. It should also have larger resonance width.

How much is the width?

 The transfer function phase drops by 180 degrees in about 2MHz. Is that a good way to measure the width?

To measure the width of a resonance, the standard method is to state the center frequency and the Q. Use the definition of Q from the Wikipedia.

As far as how much phase is OK, you should use the method that we discussed - think about the full closed loop system and try to write down how many things are effected by there being a phase slope around the modulation frequency. You should be able to calculate how this effects the error signal, noise, the loop shape, etc. Then consider what this RFPD will be used for and come up with some requirements.

The measured transimpedance of the latest POY11 PD matches my model very well up to 100 MHz. But at about ~216MHz I have a resonance that I can't really explain.

 The following is a simplified illustration of the resonant circuit:

Perhaps my model misses that resonance because it doesn't include stray capacitances.

While I was tinkering with it, i noticed a couple of things:

- the frequency of that  oscillation changes by grasping with finger the last inductor of the circuit (the 55n above); that is adding inductance

- the RF probe of the scope clearly shows me the oscillation only after the 0.1u series capacitor

- adding a small capacitor in parallel to the feedback resistor of the output amplifier increases the frequency of the oscilaltion

I started putting together the components that are coint to go inside the frequency generation box. Here's how it looked like:

The single component are going to be mounted on a board that is going to sit on the bottom of the box.

I'm thinking whether to mount the components on an isolating board (like they did in GEO), or on an aluminum board.

I emailed Hartmut to know more details about his motivations on making that choice.

The choice of 100 Ohm for the isolating resistor was mainly empirical. I started with 10, then 20 and 50 until I got a sufficient suppression of the resonance. Even just 10Ohm suppressed the resonance by several tens of dB.

In that way the gain of the loop didn't change. Before that, I was also able to kill the resonance by just increasing the loop gain from 10 to 17.  But, I didn't want to increase the closed-loop gain.

One thing that I tried, on Koji's suggestion, was to try to connect the RF output of the PD box to an RF amplifier to see whether shielding the output from the cable capacitance would make the resonance disappear: It did not work.