I was thinking that the "FOSC" product line (which is called a "coupler" instead of a "splitter/combiner") was what we wanted.
Koji brought to my attention that the 90/10 splitters we already have are of this line. So, I rigged a few up to shine a hopefully beating pair of fields on the fiber coupled thorlabs PD.
I was able to get ~80uW each of PSL and AUX X light on the PD, which produced a -10dBm beatnote! Thus, I think these FOSC splitters are indeed what we want.
I then threw this IR beatnote at our ALS signal chain. The beatnote was too big to throw through our ~+27dB RF amps, so I just sent the -10dBm over to the LSC rack.
The IR beat spectrum is somwhat noisier from 10-100Hz, but, more interesting, is that the sub-4Hz noise is identical in the two beats, and very coherent. This excludes ALS noise arising from anything happening in the green beat optics on the PSL table.
Obviously, the high frequency noise is largely the same and coherent too, but also coherent with the AUX X PDH control signal, so it is understood.
Single mode coupler, 2x2, 1064nm +/-20nm, 50/50 ratio, 900micron loose tube jacket, Hi1060flex fiber, 1m fiber length, FC/APC connectors
Four of these items ordered yesterday from http://afwtechnologies.com.au/sm_coupler.html
Yuta retrieved the IR card that had fallen to the bottom of the IOO chamber, just before we put on the access connector yesterday. The clean "pickle picker" long grabber tool worked wonders.
Sorry to say but MC1, MC2, MC3 and PRM face OSEMS are having the same problem of leaking IR into the sensors
The PMC was not locked for 11 minutes on this plot.
The PRM sensors are no longer effected by IR. What changed? The MC still does.
I came in today to check up on the StripTool and burn the Ubuntu LTS (new CDS OS) DVD. I was pretty excited to see the PRM flashes on Mon1.
I waggled the PRM/BS alignments and got a good contrast MICH and then bright flashes in the PRM that totally overload Mon1's CCD.
Now I can see flashes of some IR junk in the X Arm; its way off on the left edge of the mirror, but there's a beam.
For the short term, we can hook up the IO PZTs to some old EPICS channels (like one of the AUX guys in the LSC area), but eventually it has to get hooked up to the new ASC or ASS. We have to bug Joe to see where this shows up in his master diagram.
**Note: if you get lost sometimes when doing the alignments, remember that you can use time_machine_conlog.
rossa:general>./time_machine_conlog 2010/12/31,11:00:00 PDT C1:SUS-ITMX_PIT_COMM
Issuing the conlog command:
/cvs/cds/caltech/conlog/bin/conlog +epics -interp at 2010/12/31,11:00:00 PDT "C1:SUS-ITMX_PIT_COMM"
LIGO controls: values at 2010 12/31 11:00:00 pst
Attached is the last 8 days of Vacuum Pressure trend which includes the pumpdown.
[Gautam, Lydia, Johannes]
The next step is the tip tilt fine alignment of the IR into the arm, using TRY, from which we removed the ND filter for the time being.
Looks like we might have a problem with the IRIG-B output of the GPS receiver.
Rolf came over this morning to help debug the strange symmetricom driver behavior on fb1 with the new Spectracom card. We restarted the machine againt and this time when we loaded the drive rit was clocking at a normal rate (second/second). However, the overall GPS time was still wrong, showing a time in October from this year.
The IRIG-B122 output is supposed to encode the time of year via amplitude modulation of a 1kHz carrier. The current time of year is:
controls@fb1:~ 0$ TZ=utc date +'%j day, %T'
162 day, 18:57:35
The absolute year is not encoded, though, so the symmetricon driver has the year offset hard coded into the driver (yuck), to which it adds the time of year from the IRIG-B signal to get the correct GPS time.
However, loading the symmetricom module shows the following:
[ 1601.607403] Spectracom GPS card on bus 1; device 0
[ 1601.607408] TSYNC PIC BASE 0 address = fb500000
[ 1601.607429] Remapped 0xffffc90017012000
[ 1606.606164] TSYNC NOT receiving YEAR info, defaulting to by year patch
[ 1606.606168] date = 299 days 18:28:1161455320
[ 1606.606169] bcd time = 1161455320 sec 959 milliseconds 398 microseconds 959398630 nanosec
[ 1606.606171] Board sync = 1
[ 1606.616076] TSYNC NOT receiving YEAR info, defaulting to by year patch
[ 1606.616079] date = 299 days 18:28:1161455320
[ 1606.616080] bcd time = 1161455320 sec 969 milliseconds 331 microseconds 969331350 nanosec
[ 1606.616081] Board sync = 1
Apparently the symmetricom driver thinks it's the 299nth day of the year, which of course corresponds to some time in october, which jives with the GPS time the driver is spitting out.
Rolf then noticed that the timing module in the VME crate in the adjacent rack, which also receives an IRIG-B signal from the distribution box, was also showing day 299 on it's front panel display. We checked and confirmed that the symmetricom card and the VME timing module both agree on the wrong time of year, strongly suggesting that the GPS receiver is outputing bogus data on it's IRIG-B output, even though it's showing the correct time on it's front panel. We played around with setting in the GPS receiver to no avail. Finally we rebooted the GPS receiver, but it seemed to come up with the same bogus IRIG-B output (again both symmetricom driver and VME timing module agree on the wrong day).
So maybe our GPS receiver is busted? Not sure what to try now.
It appears that the timing slave in the c1iscex IO chassis is dead. It's front "link" lights are dark, although there appears to be power to the board (other on-board leds are lit). These front lights should either be on and blinking steadily if the board is talking to the timing system, or blinking fast if there is no connection to the timing distribution box. This likely indicates that the board has had some sort of internal failure.
Unfortunately Downs has no spare timing slave boards lying around at the moment; they're all stuffed in IO chassis awaiting shipping. I'm going to email Rolf about stealing one, and if he agrees we'll work with Todd Etzel to pull one out for a transplant
The c1iscex IO chassis seems to be working again, and the iscex front-end is running again.
However, I can't say that I actually fixed the problem.
Originally I thought the timing slave board had died by the fact that the front LED indicators next to the fiber IO were out. I didn't initially consider this a power supply problem since there were other leds on the board that were lit. I finally managed to track down Rolf to give downs the OK to pull the timing boards out of a spare IO chassis for us to use. However, when I replaced the timing boards in the chassis with the new ones, they showed the exact same behavior.
I then checked the power to the timing boards, which comes off a 2-pin connector from the backplane board in the back of the IO chassis. Apparently it's supposed to be 12V, but it was only showing ~2.75V. Since it was showing the same behavior for both timing boards, I assumed that the issue was on the IO chassis backplane.
I (with the help of Todd Etzel) started pulling cards out of the IO chassis (while power cycling appropriately, of course) to see if that changed anything. After pulling out both the ADC and DAC cards, the timing system then came up fine, with full power. The weird part is that everything then stayed fine after we started plugging all the cards back in. We eventually got back to the fully assembled configuration with everything working. But, nothing was changed, other than just re-seating all the cards.
Clearly there's some sort of flaky connection on the IO chassis board. Something is prone to shorting, or something, that overloads the power supply and causes the voltage supply to the timing card to drop.
All I can do at this point is keep an eye on it and go through another round of debugging if it happens again.
If it does happen again, I ask that everyone please not touch the IO chassis and let me look at it first. I want to try to poke around before anyone giggles any cables so I can track down where the issue might be.
I clicked on the FE status screen, just to check on things, and everything on the c1iscex section was red (the IOP and c1scx). Upon deciding that was probably a bad thing, I did a soft reboot from the control room. Now the IOP says "NO SYNC", and the c1scx status thing is totally frozen.
I have sent Jamie a whiny email. He promises to be here soon to fix it.
We discovered that the left network cable is not rigidly connected to the back of the ISCY FE computer. You can easily pull it out a mm disconnecting it. It should click rigidly in place. Not clear if it's the cable or the network card.
Here I have included the full schematic (so far) of the proposed ISS. There are two sheets: the first schematic details the filter stages and their accompanying circuitry while the second schematic details the RMS threshold detection and subsequent triggering.
The first schematic is fairly self explanatory as to what different portions do, and I have annotated much of the second schematic as there are some non-traditional components etc.
I have not yet included some mechanism to adjust the threshold voltage in real time or any of the power regulation, but these should follow fairly quickly.
I have made significant changes to the ISS schematic, mostly in the form of adding necessary subsystems.
Some changes I have made:
On the front page, all inputs and outputs are currently BNC ports, although this is most likely not the final design that will be used. For instance, the ports ENABLE, INPUT GND and INVERT are supposed to be logic inputs for a MAX333a switch. These will most likely be front panel switches that either connect the switch's logic pin to GND (Logic 0) or something like a +5 V supply (Logic 1).
I also have not included power regulation for my board although I have some of the actual D1000217 Chasis Power Regulator boards and I'll incorporate those in my design soon.
More changes that I've made:
After many, many moons of getting to know exactly how frustrating Altium can be, I have completed the PCB layout for my ISS board (final page of ISS_v3.pdf).
Before I get into detail about the PCB, there is one significant schematic change to note: the comparator circuit was changed (with significant help from Koji) so that the voltage reference for boost triggering is established in a more logical way. Instead of the somewhat convoluted topology I had before, now there are only two feedback resistors, R82 and R83. Because their resistances (500k and 50k respectively) are so much larger than the total resistance of the 1k potentiometer (used to establish a tunable threshold voltage), the current flowing through the feedback loop is negligible compared to the 5 mA current flowing through the potentiometer (the pot is rated for 2 W and with 5 mA -> 25 mW dissapation). This allows one to set the threshold voltage for my schmitt trigger, at pin 2 of both the pot and the comparator, entirely with the pot. This trigger also has hysteresis given by the relation deltaV ~ (R83/R82) * (Voh - Vol) where deltaV is the separation between threshold voltages, Voh is the high-level comparator ouput and Vol is the low-level comparator output. Koji simulated this using CircuitLab and I plan to verify the behavior by making a quick prototype circuit.
Now, on to the PCB. The board itself is of a 'standard' LIGO size (11" x 6") has 3 routing layers and 3 internal planes, one for +15 V, one for -15 V and one for GND. In the attached pdf, red is the top routing layer, blue is the bottom layer and brown is the middle routing layer (used for ±5 V exclusively). The grey circles are pads and vias (drilled through) and anything in black is silkscreen overlay. I placed each component and track by hand, attempting to minimize the signal path and following the general rules below,
Sections of the board have been partitioned and labeled with silkscreen overlay to help in both signal pathway recognition as well as eventual troubleshooting.
On the board, I have also included holes so that it can be mounted inside of an enclosure. There is a DCC number printed as well as a 'barcode' (TrueType font: IDAutomationC39S), although they both contain filler asterisks as I haven't published this to the DCC and thus do not have a number.
AOM driving from DAC:
I found that the DAC channels for TT3 and TT4 are connected up in the simulink model, but we aren't using them, since we don't actually have those tip tilts installed. So, we hooked up the TT4 LR DAC output, which is channel 8 on the 2nd set of SMA outputs. We put our AOM excitations into TT4_LR_EXC.
I wanted to check the status of the ISS. The AOM driver response was measured on Friday night.
The beam path has not been disturbed yet.
- I found the AOM crystal was removed from the beam path. It was left so.
- The AOM crystal has +24V power supply in stead of specified +28V.
I wanted to check the functionality of the AOM driver.
- I've inserted a 20dB directional coupler between the driver and the crystal.
To do so, I first turned off the power supply by removing the corresponding fuse block at the side panel of the 1X1 Rack.
Then ZFDC-20-5-S+ was inserted, the coupled output was connected to a 100MHz oscilloscope with 50Ohm termination.
Then plugged in the fuse block again to energize the driver box.
Note that the oscilloscope bandwidth caused reduction the amplitude by a factor of 0.78. In the result, this has already been compensated.
- First, I checked the applied offset from a signal generator (SG) and the actual voltage at the AOM input. The SG OUT
and the AOM control input are supposed to have an impedance of 50Ohm. However, apparently the voltage seen at the
AOM in was low. It behaved as if the input impedance of the AOM driver is 25Ohm.
In any case, we want to use low output impedance source to drive the AOM driver, but we should keep this in mind.
- The first attachment shows the output RF amplitude as a function of the DC offset. The horizontal axis is the DC voltage AT THE AOM INPUT (not at the SG out).
Above 0.5V offset some non linearity is seen. I wasn't sure if this is related to the lower supply voltage or not. I'd use the nominal DC of 0.5V@AOM.
The output with the input of 1V does not reach the specified output of 2W (33dBm). I didn't touch the RF output adjustment yet. And again the suppy is not +28V but +24V.
- I decided to measure the frequency response at the offset of 0.53V@AOM, this corresponds to the DC offset of 0.8V. 0.3Vpp oscillation was given.
i.e. The SG out seen by a high-Z scope is V_SG(t) = 1.59 + 0.3 Sin(2 pi f t) [V]. The AOM drive voltage V_AOM(t) = 0.53 + 0.099 Sin(2 pi f t).
From the max and min amplitudes observed in the osciiloscope, the response was checked. (Attachment 2)
The plot shows how much is the modulation depth (0~1) when the amplitude of 1Vpk is applied at the AOM input.
The value is ~2 [1/V] at DC. This makes sense as the control amplitude is 0.5, the applied voltage swings from 0V-1V and yields 100% modulation.
At 10MHz the first sign of reduction is seen, then the response starts dropping above 10MHz. The specification says the rise time of the driver is 12nsec.
If the system has a single pole, there is a relationship between the rise time (t_rise) and the cut-off freq (fc) as fc*t_rise = 0.35 (cf Wikipedia "Rise Time").
If we beieve this, the specification of fc is 30MHz. That sounds too high compared to the measurement (fc ~15MHz).
In any case the response is pretty flat up to 3MHz.
This is good news. It means that the driver probably won't limit the response of the loop - I expect we'll get 20-30 deg of phase lag @ 100 kHz just because of the acoustic response of the AOM PZT + crystal.
We installed the ISS AOM in the PSL. The AOM was placed right after the EOM. The beam diameter is ~600 um at the AOM. The AOM aperture is 3 mm.
We monitored the beam size by scanning the leakage beam through the turning mirror after the AOM. The beam diameter changed from 525 um to 515 um at a fixed point. We decided that the AOM thermal lensing is not large enough to require a new scan of the mode going into the PMC and we can proceed with PMC mode matching using the scan that was taken without the AOM (to be posted).
In order to allow other individuals besides myself to consider the proposed design of the ISS, I have created a publicly available CircuitLab drawing, which can be found here: CircuitLab Drawing. For simplicity, I have used ideal op-amps without voltage rails or their associated power supplies. In the actual implementation of the ISS, we will most likely also have trim resistors to ensure a zero offset for each op-amp. We interpret the PD as a voltage source for simplicity and I will use an actual summing amplifier in place of the summing junction used in the diagram.
The diagram linked above is simply a naive copy of a design by Rich Abbott so there are most likely mistakes and/or unnecessary elements, but it is a work in progress. I began discussing, with Jamie, the relative use of the first few filter stages in the servo. As far as my understanding goes, the first 'stage' was part of cascade of op-amps that served to convert a differential input from the PD into a single DC signal referenced to ground. Indeed, the first stage of my diagram (U1) is simply a unity-gain low-pass filter with f~5 MHz. Additionally, the second filter 'stage', U2, is also a unity-gain low-pass filter although it introduces a phase shift of 180 deg as the input to the second stage is on the inverting input of the op-amp. These characteristics were determined using LISO and examining the transfer function.
Noise analysis was also performed for the above circuit. The noise from various elements is examined at the output of the servo (labeled as 'outU6' in my LISO file). In the attached diagram, we see the voltage noise at the output from each op-amp as well as the sum of all the various noises, which includes resistor noise and current noise from the inputs of each op-amp. These are LISO's standard considerations and it is also worthwhile to note that the result is not referred to the circuit input, but as we have the transfer function of the whole servo, referring the noise to the input is trivial.
I have also included the following output for the sake of completeness.
from 1 Hz onwards noise by OP:I+ (U3) dominates.
from 38.6812 Hz onwards noise by R(R24) dominates.
from 115.478 Hz onwards noise by R(R11) dominates.
Attached are both the circuit diagram and the liso formatted *.fil for the main branch of the ISS, as well as the resulting transfer function when analyzed. Unfortunately, as noted in the file, not all of the elements are possible to analyze in liso, such as any type of op-amp with more than two inputs and one output (AD602 used in this design has 16 pins with two distinct amplifiers contained within).
I have begun prototyping this circuit on a breadboard.
## ISS Main Branch
## All circuit elements are named according to the circuit diagram
## "D020241-D2.pdf" by R. Abbott.
# Stages are separated by empty lines and elements between stages are
# also separated by empty lines for easy file navigation
# Before the first stage there is a 'fully differentiable' op-amp
# that I believe serves to isolate the device from the power supply
# However, liso does not have the capability to analyze such an op-amp,
Unfortunately, as noted in the file, not all of the elements are possible to analyze in liso, such as any type of op-amp with more than two inputs and one output (AD602 used in this design has 16 pins with two distinct amplifiers contained within).
Typically, you can still find a way to model the important parts of the stages that are not as simply added. In the case of the differential input stage, in particular, it is important to include it because it will usually set the input noise level of the circuit. In this case, the noise is the same as the second stage (U5) and it has a gain of 1, so there is essentially no difference (up to factors of sqrt(2) or 2).
You can edit the opamp.lib file and add in custom components. For the input stage, you can just pretend it is a simple non-inverting amplifier with the specified noise characteristics from the datasheet: un = 1.3n, uc = 50 Hz (see below).
For dual op amps, you can usually just model each part separately. For example, the OPA2604 is a dual op amp that is included in the opamp.lib and can be treated as a single one in a model.
After spending a good deal of time learning how to use the SR785, I was able to characterize my prototype circuit. The transfer function from a swept sine measurement looks very similar to the theoretically calculated transfer function (both of which are attached). The frequency response of the circuit was considered over the range 10 Hz - 10 kHz, which contains the eventual working range of the ISS (at least to my knowledge).
Note that OP27 op-amps were used instead of the high-speed AD829 op-amps that will be implemented in the actual design. This was done as a result of the limitations and inherent noise characteristics of the breadboard on which the prototype was built.
Unfortunately, I saved the wrong dataset (i.e. phase of the transfer function, not magnitude) and thus the presented function here is image generated by the SR785.
RXA: One must learn to use the python-GPIB interface to not lose data in the future.
We took relative intensity noise (RIN) spectra of the ISS error point and the monitor PD (attm1).
In-loop RIN is the sensor PD and "Out of the loop RIN" is the monitor PD.
The ISS gain slider was at 8dB in this measurement.
It looks normal.
An open loop transfer function of the ISS loop was measured (attm2). The UGF was 22kHz with the phase margin of ~22deg.
We should increase the UGF up to ~60kHz
When we increase the gain up to 14dB, the CS saturation warning comes up in the EPICS screen.
We confirmed this by monitoring the CS drive signal with an oscilloscope.
It is the output of an AD602J, which has +/-3V output range.
By increasing the gain of AD602J, we saw that the output signal hits the rail.
There seems to be a lot of high frequency (100kHz - a few MHz) noise, out of the control band.
We also observed that AD602J itself oscillates at about 10MHz (don't remember the exact number) when the gain is increased.
(We saw this even when the loop is off. There is no such an oscillation in the input to the AD602J).
When we took wide band spectra of the CS drive signal, we saw many large harmonics of ~180kHz. We believe these peaks are limiting
our ISS gain now (causing the CS saturation). The harmonics persisted even when we disconnected the PDs. So it is not coming from the light.
We saw the same harmonics in the power lines. They may be the switching noise of the Sorensens.
We took spectra of those harmonics, but the netgpibdata.py somehow did not save the data from AG4395A correctly. I have to debug this.
Stefan removed DC offsets from the AD829s (many of them are used in the ISS board) by turning the pots for offset adjustment.
This eliminated the problem of getting a large DC CS feedback (observable in C1:PSL-ISS_CSDRIVE_MEAN) when the gain is increased.
During the investigation, I noticed that increasing the PMC gain too much (~22dB) caused an oscillation of the PMC loop and consequently made
the ISS saturate. When the ISS is behaving bad, we should check the PMC gain.
Currently, the ISS is running OK with the gain = 8dB. I modified the mcup script to set the ISS gain to 8dB when the MC is locked.
Wait for Peter's answer about spare ISS boards.
Power line filtering.
Find the cause of AD602J oscillation (Well this is the one mounted upright. So just mounting it normally might solve the problem :-).
This plot shows the RIN as measured by the ISS. Its ~2 x 10^-7, whereas its supposed to be more like 3 x 10^-8.
The ISS has DC coupled RIN channels (with a _F suffix) and AC coupled RIN channels (with a _FW suffix). By using a swept sine, Rob determined that the AC coupled channels have an AC coupling pole at ~80 Hz. The attached plot uses this and then has the overall gain adjusted to match with the _F channels below 10 Hz.
The _F channels can be converted directly into RIN by just dividing the spectra by the mean value of the time series. The dark offset of these channels is small and so this only introduces a ~5-10% calibration error.
Question #1: Why is the RIN so bad? According to the MEDM screen, the photocurrent on the MON/SENS PDs is 1.9/1.3 mA. That's sort of low, but should still allow us to get 5x10^-8 in RIN.
Question #2: Does it make an effect on the current DC Readout work? IF so, should we try to fix up the ISS in a temporary way? Since the in-loop and out-of-loop detectors are completely coherent, all of the noise is likely just unsuppressed noise from the laser. We are unable to increase the gain because of the high frequency noise from the NPRO.
Let's remember to replace this ISS with a new one that can drive an AOM. Need a volunteer to get us a new ISS.
Right near the end of summer, I had an ISS board that was nominally working, but had a few problems I couldn't really sort out. Since I've been back, I've spent a lot of time just replacing parts, trying different circuit topologies and generally attempting to make the board function as I hoped it might in all those design stages. Below is a brief list of some of the problems I've been fixing as well as the first good characterization of the board transfer function that I've been able to get.
We'll start with some of the simple problems and proceed to more complicated ones.
The above list encompasses all the issues I've had in making the ISS board function correctly. No other major problems exist to my knowledge.
I was able to measure both the open- and closed-loop transfer functions of the servo with the SR785. The results are shown below.
The transfer function with the boosts on caps at a particular value set by op-amp railing, i.e. below 100 Hz, the op-amps are already putting out their max voltage. This is the usual physical limitation when measuring the transfer function of an integrator. We can also see that the measured phase follows the simulated phase above ~300 Hz. The 'phase matching' at low frequency is again do to the op-amp railing in the servo output..
The closed-loop gain is shown below,
The measured closed-loop gain with the boosts on again matches the LISO simulation quite well except at low frequency where we are limited by op-amp railing. We compare the measured closed-loop transfer function to the desired noise suppression stipulated in my previous elog 9331,
And we might hopefully conclude that my servo functions as desired. One should note that the op-amp railing seen in these measurements is not indicative of limitations we might face in some application of the ISS for the following reason. These transfer functions were measured with a 100 mV excitation signal (it is necessary to keep this signal amplitude large enough so that the inherent signal-to-noise ratio of the excitation source is large enough for accurate measurement) which leads to somewhat prompt railing of the op-amps. When the ISS operates to actually stabilize a laser, the input error signal will be much smaller (on the order of a few 10's of mV or less) and will decrease significantly assuming correct operation of the ISS. This means we won't see the same type of gain limitations.
What now, you ask?
Aside from the problem with the AD8436 chip, the ISS board seems to be functioning correctly. The transfer functions we have measured are correct to within the component tolerances and all of the various subsystems are behaving as they were designed to. Moving toward the goal of having this system work in situ for the CTN experiment, I need to do the following things,
So close, or so I say all the time
I wanted to look into the ISS situation. Some weeks ago, I found the PD that was previously used as the in-loop photodiode. I wanted to use this and measure the open-loop RIN at a few places (to see if there's any variation and also to check its functionality). However, I didn't get very far tonight - for a start, the PD height is 3" (while our beam height is 4" everywhere outside the vacuum), and I needed to put together a circuit to supply the 5V bias and +/- 15 V since the transimpedance is done on the head. I was only able to do a low-level functionality test tonight, checked that the DC voltage output varied linearly with the incident power (calibrated against an NF1611 photodiode, data will be put up later). I didn't get to measuring any noise performance - is an incandescent light bulb still shot noise limited at ~10 Hz < f < 10kHz? Some notes:
Unconnected to this work - this problem reared its ugly head again (i noticed it yesterday morning already actually). I don't have the energy to embark on a fix tonight, Koji is going to be in the lab all day tomorrow and so he will fix it.
that little PD in the black mount was never very good. The AD829 is not a good opamp for transimpedance and especially not good for low frequencies. Stefan Ballmer and I were able to get 2e-8 out of these (@100 Hz) many years ago.
I wonder if we have some of Zach's M2ISS photodetectors around, perhaps in QIL or Cryo. I doubt that any of them are in use now. Those had good performance nad BNC output.
Ok I was using the PD in the black mount because Rana recommended it a few weeks ago.
Regarding the M2ISS, I acquired the hardware from QIL some months ago, including a circuit board, and 2 PDs. These had LEMO outputs though (not BNC), and the mounts are not 4". These photodiodes are what I'm using as the airBHD DCPDs right now, and some photos are here - are these the photodiodes you mentioned? Or are there yet more M2ISS photodiodes? I remember Johannes had some custom mounts extruded to make them 4" high, do you mean those? Can I retrieve them his Cryo setup?
BTW, my elog scraping shows only one spectra from Stefan in the ATF elog, and the performance there is more like 1e-7/rtHz @ 100 Hz, and that’s using a dedicated high BW servo circuit, not the SR560. Am I just missing the measurement of 2e-8/rtHz?