For our future experiments, I thought it would be good to create a new general-purpose workhorse photodetector. Presenting: the omniPD.
My intention is to design something with excellent performance as either a DC or RF receiver, perhaps simultaneously. To do this, I borrowed elements from several things, including:
See the attached schematic.
Diode and bias
As usual, the diode is a reverse-biased 2-mm Perkin-Elmer InGaAs, though others could be substituted (e.g., 3-mm for larger area or a Si diode for lower capacitance). The bias is provided by an AD587 low-noise reference. It is trimmable before going through a 2-pole active lowpass at 0.1 Hz and a current buffer.
The DC signal goes through a large (RF-choking) inductor before being fed into a standard transimpedance amplifier. This is drawn as a low-noise FET chip (OPA140) with high impedance in the schematic, but could easily be a BJT part for brighter applications. There is a transimpedance switching option à la OMC DCPD, using a small-signal relay. The output then goes through two switchable generic filter stages (e.g., for whitening, etc.). The first of these stages has an optional offset injection for DC signal subtraction before further amplification, with the offset voltage derived in a similar way to the PD bias. I made sure to add pads on pin 5 of these stages in case we want to use AD829s for speed.
The RF path nearly identical to the aLIGO LSC RFPD design, but with only two rejection notches and a single readout for simplicity. As with that design, the components can be chosen so that it is a more traditional resonant circuit (rather than notch readout), and I have added a feature where the entire RF path is switchable via relay to a straight 50-ohm resistor for broadband readout. This, again, is using a typical small-signal relay (I know that "RF relays" exist, but I could find no reason this part wouldn't work up to the target of 100 MHz given things like insertion loss and through resistance---in any case, we can change it to an RF relay if we need to).
Since this is supposed to be a generic design, I have made most features optional. For example:
I plan to have a 5x3 header array on the board, with one row all at +5V and the opposite row connected to a BIO connector (with the middle row connected to the individual switches), so that the user can choose---option by option---to have parameters hard-set or controlled externally (e.g., by CDS). A nice thing to add would be a threshold-based encoder board using an ADC chip (either external or perhaps as a daughterboard) so that we can control each PD's state with a single CDS DAC output.
My dream is to fit this in the same housing as the BBPD, since it seems to be a nice design and someone already did it. That said, it's a lot to fit in such a small package, so we'll see. One thing I am very fond of is the ThorLabs-style 3-pin power connector.
Based on LISO modeling, it seems feasible to have an ultra-low-noise ~MHz DC path while simultaneously having excellent RF performance. We don't always require this, but there are at least a few examples I can think of where this would come in handy:
Besides, apart from this nice dual-banding, the PD should be generic enough to be useful for all traditional purposes individually.
I would love it if anyone had any suggestions before I start making the PCB layout.
The switchable generic filters right now leave the inputs floating when the filter is disabled. Would it be better to ground the inputs or just leave the inputs connected and only switch the outputs?
Right-o. This is the kind of switching that existed in, e.g., the eLIGO OMC whitening box, but grounded-input is definitely better. I modified it to use the switching that's used for the VGA in the common-mode servo board. This avoids both floating inputs and also the potential loading that would come from leaving the inputs connected.
1) I am suspicious of the DC part being truly low noise at low frequencies with the switching and extra components. Excess 1/f noise?
2) For the application of balanced ISS PDs, can we really make the package small enough so that they're close together?
3) I wonder about the low noise reference. Its good at DC, but don't we spoil it a little if we pass the DC signal through too many components before it gets to the PD?
4) Would it be possible to not stuff the RF parts and just use this as a DC PD?
1) I think the relays ought not be a problem, judging by their performance on the OMC Z switch. I was under the impression that the MAX333 was an acceptable switch for low-noise signals (it is used immediately after the unity-gain input of the common-mode board, so it is presumed to have a noise floor much lower than an AD829's). That said, the CMB does show anomalously high low-frequency noise. I can do some testing to measure this, but what is the way around it? Use relays for everything? That would be OK, but it takes up a lot more space.
2) From my interrogation by EKG, I imagined that the balanced ISS PD would be its own specialized thing in a custom box. So, I didn't plan for that to be within the scope of this workhorse. Since we already know almost exactly what we will want from a balanced ISS setup, shouldn't we just make another design that is compact and best suited for that purpose?
3) I'm a bit confused here. Do you mean for the bias or for the offset? In either case, all we're doing is adding some extra active low-passing, right? The AD587 has a floor of ~100 nV/rtHz, so the filter brings this (and any junk from the potentiometer) down to the OPA140's floor of 5 nV/rtHz. As for drift, the AD587 is rated to ~10 ppm/K = 100 uV/K, while the OPA140's drift is well under 1 uV/K.
The first package with some replacement optics came in today (8 lenses, 6 mirrors, 2 beamsplitters). First contact has been applied to the optical surfaces of all parts that will go into the setup immediately. When I previously peeled off the FC I did so without an ion gun, which tends to leave charge behind on the cleaned surface . I received the Top Gun unit that was destined for Bridge from Koji (OMC Lab) and made it into a mobile unit like the one at the 40m. Once the gas cylinder comes in ( tomorrow) I can start peeling the FC off and swapping optics.
The gas cylinder eventually made it to the lab and we now have a mobile top gun assembly for the bridge labs. I followed Steve's and Calum's suggestion and triple-rinsed the tube that delivers the nitrogen from the cylinder to the top gun unit with acetone. I set the pressure regulator to 40 psi and let gas stream through the tube before connecting it for ~2 minutes. I did the same with the top gun all hooked up, ~2min at 40psi.
I proceeded to take the first contact off all optics that I put (back) in the experiment and re-aligned the beams to the cavities. I also made some changes to the set-up, swapping some polarization-dependent (but not polarizing) beams splitters to actual polarizing beamsplitters, and replacing some mirrors. which failed the visual inspection even after cleaning. Only criterium was the presence of visible (to the bare eye) point scatter in the central mirror region under 1000 lumen illumination.
Finally, I re-arranged the transmission beat readout to improve the contrast on the Trans Beat PD (currently a New Focus 1811-FS-AC). This PD has split paths for DC and AC, with datasheet-reported transimpedance gains of 10kOhm and 40kOhm, respectively. Using these, the best contrast I calculated was around 50%, which seemed off to me, as it should be much better, since the two cavities are identical, I did not place any lenses in the paths before joining the transmitted beams, and I matched the macroscopic paths traveled by both beams after their cavities.
I instead placed a Thorlabs PDA10CF with DC-125MHz output with 5kOhm transimpedance gain into 50 Ohm. After maximizing the beat amplitude, the contrast I calculated using this PD is 92%, which fits my expectation much better. I'm not sure why it's so different for the 1811. Beam size could be an issue, although I did make sure by calculation that the beam is small enough.
I swapped in the 1811 again for a beat note measurement and found that it still looks like we're limited by scattering below ~50 Hz. On the positive side, the 'noise floor' we're seeing near 1kHz seems to have improved slightly from 50mHz/rtHz to 30mHz/rtHz. I also measured the frontal beat and found that it is nominally identical to the trans beat. After trying to identify scatter-culprits with the PZT buzzer, I had the idea to completely block the transmitted beams, which I did with a pair of black glass multi-bounce dumps. Curtesy of the frontal beat I can still measure the beat note. To my surprise the scatter-hump decreased quite significantly, by about a factor of 10.
This means that
The shelf-shape of the residual noise at low frequencies could mean it's still scatter, just on the input side. Getting closer...
I have been rebuilding the entire optical setup over the past two weeks to make some fundamental changes and fix some things.
Still have to modify the transmission path, I found that the beam is much too large on the beat PD, which causes a lot of scattering off the shiny rim.
Attachment 1 is an overview of the new layout and attachment 2 shows the west AOM transfer function from commercial driver modulation input to laser intensity, measured by a PDA10CF. I aligned the AOMs to give maximum deflection while minimizing RFAM at 35 MHz, their mod frequency. The East path ended up with a lot more phase delay this way because i had to move it further from the transducer. Deflection efficiency is in both cases about 80% at AOM saturation.
I took some photos of the existing layout. I'll just take apart the E beam path, and leave the W path unchanged for now as reference.
I moved the E fiber output coupler closer to the edge of the table, to make this path easier to reach.
Hopped around on the laser hysterisis curve for a minute. To optimize the temperature,
Can anyone tell me the specs / history of some of the custom optics in cryo? I'm mounting the 1m Coastline mirror and will start with that in the PSOMA cavity.
I measured the transmission of the Coastline 1m mirror at 180. ppm (S122C).
Alignment procedure while setting location of optics:
Alignment procedure subsequently:
Here's the layout.
Some easy things that should be changed:
I found this document that has good information on the how to choose the correct gain settings on our QPD.
Note: need to update model to normalize pitch/yaw outputs.
I also found some parameters from the laser spec sheet here.
This took me a bit longer than expected. I wanted to optimize our op lev configuration. I ended up starting to make a kind of pedagogical note on ray transfer matrices, abandoned that halfway and wrote the better part of a python script to optimize an arbitrary configuration with telescopes before and/or after the oscillator, and ended up realizing I was reproducing existing ray tracing software so I went back to the analytic calculation just to get a sense for how things go so I can swap up the op lev.
Let me know if you'd like the .nb from me, or I can put it in Qryo.
Pressure was around 2.5e-5torr when I turned the pump off, 10:15am.
I went to put together the new dewar, but the struts are not quite in the right places and the torque from the tightened struts overcame two of the epoxy sites. I didn't trust the last one on its own, and pulled it off. I'll need to go back to the 40m to bake this again, and apply a thicker layer of epoxy.
I found some new lenses for the telescope:
I'll set up the 1:4 telescope first. I needed to swap out the lens into a better mount, then good to go. QUESTION: Is there a tool for turning the fasteners for the lens mounts? This small flathead feels really precarious... I had quite a bit of trouble getting the beam out of the cryo, so I'm going to go to atmosphere and try again after lunch.
I realized that last plot was kind of misleading, because I shouldn't have been assuming a fixed magnification telescope. Instead, I've just chosen the focal lengths of the lenses we have in the lab and plotted the distances from oscillator to telescope, and telescope to QPD.
It confirms the basic picture, that I should keep the telescope as close to the QPD as possible, and make the distance from the telescope to the QPD as long as possible while keeping the beam the right size. In practice, this means that more magnification in the telescope is more effective. It also confirms the picture that having the telescope much closer to the QPD than the oscillator probably suppressed our signal.
Entered lab around Wed Dec 23 11:14:29 2020 to bring in optomechanics from Newport, step stool from McMaster, and a few other items for around the lab.
I requested a quote for five RTD mounts from Millitnow so we can have some easy-to-swap RTDs in the can. Picture attached.
from "PRE-AMPLIFIER IMPEDANCE MATCHING FOR CRYOGENIC BPMs" (http://adweb.desy.de/mpy/DIPAC2011/posters/tupd20_poster.pdf)
We managed to kluge together some hosing to go from the cryostat ln2 dewars to the pressurized helium, but needed one more yorlok adapter to make it work. I ordered it from McMaster so we should be able to do the overpressure test as soon as it arrives.
We overpressed two of the nitrogen tanks with kinked pipes--one going to the single tank dewar and the other going to the bottom tank of one of the He dewars.
We hooked up the new swagelok connectors to get pressurized helium into a tube of the proper size to connect to our tank. We are connecting to the dewar with one of the lN2 fill adapters that has both a nitrogen in and an air outlet port; we pressurized the air outlet and put a KF25 blank on the nitrogen fill port (since the pipe on that port is threaded we were able to find an adapter to KF connectors).
We filled both tanks with soapy water (~10 drops of Down to ~2L tank) and pressurized the tanks initially to 1atm above atmosphere. We did not observe any bubbling from the tanks themselves, and though we sometimes observed leaks elsewhere in the system (before the hosing reaches the cryostat), we were generally able to fill these leaks. We eventually pressurized the tanks up to 300kPa, but did not go further because the dewars are only ever overpressured by ~100kPa under normal operation.
On the single tank dewar, we dropped some soap around the kink in the pipe to see if there were bubbles that were not visible to us due to low soap concentration, but still did not observe any leak.
We next emptied the dewars of water and submerged them in a bucket of water (no soap) so that now the air is on the inside of the dewar, the water is on the outside, and no soap is in the system. We first submerged the single tank dewar, which also has an integrated metal heat shield above the tank. The heat shield prevented us from fully emptying the system of air, but we shook the dewar at an angle underwater until we felt confident that no more bubbles emerged when we shook the dewar. We then overpressured the tank, and waited some time. After ~10 minutes, we shook the dewar and released many bubbles, which we take to mean there could be a leak--if the quantity of trapped air remained the same over the 10 minutes, a similarly vigorous shaking should not have released additional bubbles. However, we would feel better if we could see the bubbles forming, so should repeat the test either in a larger clear bucket so we could fully release the trapped bubbles (Johannes has found an appropriate bin) or remove the heat shield (Brittany has wanted to do this for some time).
We also submerged the two-tank dewar in the bucket of water, and observed no leaks. Finally, we removed the two-tank dewar and added some drops of soap to the kink in the pipe to see if we could observe bubbles forming there, but did not find any evidence of a leak.
quick particle trend, goes back 21 days to cover the time since the last trend was posted.
So what's going on with this leap second error?
I found some entries from the 40m with suggested steps on fixing the annual 0x4000 error for realtime models. Looking in the referenced file, I see some lines commented out that look like Anchal's reference elog, followed by a call to some ligo function that might (or might not) take care of the leap second offset issue.
Since I'm unfamiliar with the functions, I'm letting Chris know so I don't break anything.
The particle counter has stopped working.
It is a GT-526 from Met One instrumentals, and they run around 2.5k from the resellers (source: http://www.metone.com/meteorology.php)
I have contacted the company inquiring about how to get it serviced (here: http://www.metone.com/documents/service_and_maintenance/2012/Service_GT-526_NP_2012.pdf)
The above pdf quotes a ~5 day turnaround.
In the meantime, I have picked up the 227A from the ATF since it was sitting on a workbench and not logging any data. I am unsure if it works.
This lab is too dirty. I have Q on board for some serious cleaning, and in this vein, we need to have a better metric of cleanliness. Once we get the standards up, and have the particle count trended and monitored again, we can "do whatever is necessary" if people start to make it dirty again.
To this end, I have purchased some swiffer brooms and swiffer dusters. I bought some extra for the other sub-basement labs since we have 1 crappy mop between 3 of them.
I have talked to Tara and worked out some space on the PSL flow bench for a couple days to do the measurements on the windows in a clean(er) environment. The window cleaning / measuring / etc will take place over the next couple days.
plot showing data taken the last 30 days (max values, minute trend) showing 0.3, 0.5 and 0.7um particle size. Units are counts/ft^3.
wrote a small python script which reads the last measured data from the particle counter every 20s and writes them into epics channels. The script is not controlling the particle counter, the particle counter is still running on it's own with the parameters set in the device itself. The script is only sending a command to get the last measured values. This is only to demonstrate that it the serial port and epics modules are working and it uses fixed parameters. There is only little check for errors like opening the serial port or is there data at all. I will update it in the near future with command line options etc. Will then do the same for the vacuum gauges.
Script can be found in /caltech/scripts/python/
In preparation for some HVAC work in cryo lab, here are the most recent 30 days of hour trends from the particle counter.
I'm guessing the humidity is reported as relative humidity. The channel X1:AUX-LAB_TEMP_F should be reporting the temperature as measured by our AD590 sensor in the cryo cavs electronics rack as an independent check, but something along the way is apparently broken.
i've done some updates to the particle counter script. The current version is 0.3 (particle-0.3.py).
New features are:
i inspected /home/controls/services/particle-0.5.py on cryoaux, which is the readout script for the CryoLab's GT-526 particle counter, which has the optional attachment for humidity and temperature. EPICS channels for temperature and humidity do already exist:
Something is amiss in the python script though. For some reason the 0.7 micrometer particle channel does not appear in the (ordered) list of EPICS channels to be written to. But it is part of the string that is transmitted via serial connection. As a result, the channels are not recording what they're supposed to. C5:PEM-COUNT_HUM was actually recording the temperature all along. I dug around in the logfile and found that the transmitted string looks like this:
'13-MAR-2018 14:35:17, 73410, 9520, 820, 230, 100, 60, 27, 36, 2\r\n'
This gets parsed to the epics channels for the different particle size counts, temperature, and humidity.
Since the 0.7 μm channel was omitted from the target list for the parsing, the readings shifted channels. I haven't fixed this yet, but it should be fairly straight forward.
On the other hand, there is no fractional precision for the temperature readout. It is possible to change the units to Fahrenheit, so we get a factor 2 in precision, but we really want something more precise than integer degrees for the lab temperature monitor.
Not sure what happened between yesterday and today, but dataviewer is now reporting particle counts data that vary with time, including trends. The data only start at around 5pm on Tuesday, so don't capture the time when the work was being done.
The particle counter recorded a large spike in dust around 11 pm last night -- not sure what that would be associated with, since the lab was empty. When was the hard drive bay "Rocket Lake" installed into Aux rack? If it was last night, it's plausible the fans would have directed dust towards the particle counter.
The last spike in dust is from my mopping with a pre-wetted cloth this morning. Here were my uncovering steps:
The timeline so far as I’m aware:
Great, thanks Chris for resetting the DAQ!
Here's one more trend plot for completion... the y-axis is log(counts), though I can't seem to change the axis label in ndscope.
With all the modifications we've been doing, it seemed to me that the gain control knob may have been wrongly accused for bad behavior of pdh2 at high frequencies. It has been bypassed recently, but after other problems have been fixed, I decided to put it back in and see if it works as intended.
I moved R58 back to R70 so that the gain knob is in the feedback path. Fortunately this does not modify the TF at all when the gain knob is in the lowest setting. That's good.
When you turn the knob to high gain, it doesn't work exactly as intended, the gain is not frequency dependent and it seems to act more like a boost then an overall gain stage. The gain increase starts to fall off at about 100kHz.
This is no big deal, we'll take it as it is.
How much gain is "high gain"? The GBW product of the AD829 is 120 MHz, so if it's something huge like G = 1000 then you would expect the pole that low. I'd guess it's not that high...
To get some more phase at the high frequency end of the pdh2 board, I used Rana's advice and added a bypass path for a low-delay, high frequency path.
Previously, the PDH2 board had a pole-zero pair in the U5 stage. There was a pole at around 200Hz, followed by a ~20kHz zero which cancels the cavity pole. This filter is part of a total of 7 AD829s in series with each other, each with some phase delay, totaling about 43 degrees of phase delay at 1MHz.
Instead, I modified the board such that the zero in the U5 stage is moved up to about 150kHz, and there is a parallel path with flat response, which crosses the main path at about 20kHz. This makes the overall transfer function about the same as before, however the response at high frequency is provided by a low delay path.
I achieved this by simply putting a 2.5MOhm resistor which goes from the output of U1 (the input buffer) to the inverting input of U6 (the output buffer). So now there are only 2 op amps in this path, not 7. When I first did this, the two paths were actually subtracting, so I bypassed the U2 stage which was a simple inverting unity gain stage. The new total transfer function only has 15 degrees of delay at 1MHz. An improvement indeed!
The plot shows the old TF (red), the new slow path (green) which is summed with a flat TF (not shown) to produce the total new TF (blue).
* The gain pot on the front panel does not modify the high frequency path, though this was already sort of true before (see previous log).
* The overall gain can still be modified by changing the gain in the U1 input buffer stage.
Youtube on phase noise in osc (https://youtu.be/wByzymJ0Ppc)
Now that we are generating noise budgets, we'd like to compare our observed phase noise with that expected from the physical noise sources. Chris pointed us to some useful papers a while back, and I'm going to start documenting my further reading on the PSOMA wiki's noise budget page.
I took these diagnostic steps:
I didn't replicate 'MHz drift over several minutes' exactly, but I suspect our beat note is pushing the BW limit of the phasemeter.
my guess exactly. I will ask Moku people about it, but my guess is that we need to do a traditional phase lock using some mixers, etc like what Shruti had working at the 40m. I suggest scrounging some parts from somewhere in WB / 40 for this week, but fill up our purchase spreadsheet with some RF shopping list that we ran go over in our meeting tomorrow (Thurs)
nice idea with the triangle wave. I was thinking of putting some white noise into the FM dev input of the Marconi, but your way is easier. Will definitely need Marconi for the PLL setup.
Continuing this, I measured the spectrum of the NS beat note over 20 min (10 min x 2) with persistance on to see how much the note drifts. I observed about 1 MHz/min drift on moku spectrum analyzer (attachment 1).
Afterwards, I measured the same beat note on the phasemeter over 5 minutes. Indeed, it appears the phasemeter loses lock after several minutes (attachment 2), whereupon it drifts by again 1 MHz/min. (attachment 2). I did notice this behavior on some of the data I took last week, but couldn't explain it and attriubuted it to the phasemeter settling in (which in retrospect doesn't make sense, because the BW is kHz while the 'settling' would have been for tens of seconds).
Rana and I measured the current noise of the ITC510 using SR560 + moku, both driving the laser diode and a 20 Ohm dummy load. We noticed some unusual-looking noise on the moku display, and I'll post some details when I've had a chance to plot the data.
Attachment 1 shows the measurement setup. In the upper diagram, we've connected the ITC502 to the N RIo laser using the usual DB9 cable, but with a breakout board at the driver and clips sent to a high impedance voltmeter on moku. In the lower diagram, we've replaced the DB9 cable with two wirebound resistors stuck in the DB9 connector of the breakout board (50 Ohm across pins 1,5 for the interlock; 20 Ohm across pins 3 and 7 to simulate the diode).
The current noise as measured by the Moku spectrum analyzer while driving the N laser is in attachment 2. Obviously it's high... I'll start adding this curve to future beat note measurements involving the ITC510. To get the current amplitude spectral density from the Moku's reported power in dBV, I divided by the sensing resistance (which I took to be 20 Ohm) and resolution bandwidth of the spectrum analyzer. I'm not sure this is the correct sensing resistance -- the laser datasheet shows 20 Ohm parallel, not in series, with the current drive. x-axis in Hz.
Things still look pretty weird. Today I'll measure the photodiode dark noise (the previous curve was theoretical, based on the known transimpedance of the 1811 and properties of the PDH electronics).
There will be a planned electrical outage tomorrow morning at 6 am. I turned off the following electronics before leaving the lab:
Entered lab about Mon Nov 30 10:21:35 2020, after taking a COVID test through Caltech's new surveillance testing program.
I'll pick up where Shruti left off on the beat note. The comb of sidebands becomes a single line remains a comb when the PID is off; Koji suggests maybe the (PLL) PID is oscillating at 10Mhz.
exit Mon Nov 30 16:12:04 2020
Entered Tue Dec 1 10:59:48 2020
Turning on the lasers in a more controlled way today, trying to reach datasheet nominal setpoint
I'm getting turned around, so I'll summarize the state of the drivers and lasers. Yellow highlight indicates this is a best guess based on things like dates on the DCC, but I haven't verified by eye (by opening the driver chassis or making a measurement).
Something seems wrong with the W laser path. At the nominal laser setpoint, the E path puts out a steady 5.33 mW; the W path puts out up to 1.9ish mW, but the power is fluctuating between 1 and 2 mW.
Spent some time changing the W/E mixing BS into a michelson BS for the W path (uneven arms). The AS beam from one leg was substantially brighter (by eye and ~10x on the PD) than the other. I confirmed that the mirror is HR for 1550. Probably just clipping, I had the plate BS kinematic mount in the wrong handedness to avoid remounting it; this was misguided anyway, I return it to original state. When I realigned the PLL path (identical to before this Michelson excursion), the forest of modes returned to the gaussian envelope state (not the bessel 2 looking envelope from yesterday). Could this be alignment / path length dependent? I returned the lasers to nominal T and I, and the gaussian envelope remains, so optical path is my best guess.
A little later, I lowered the TEC setpoint for W laser, and the Bessel envelope returned. However, whereas yesterday the 2nd sideband had a maximum now the 1st sideband is maximized.
Another feature that's been puzzling me -- when I sweep the temperature or current monotonically in a direction that moves the beat to 0Hz, the forest moves towards 0 until about 50 MHz. Below 50MHz, the modes are suppressed nearly to the noise floor; I think the carrier is just visible above the floor, but above 50Mhz the carrier is 50 dB above the floor. The cutoff is sharp, and if I continue sweeping temperature or current in the same direction the modes eventually reappear above 50 MHz moving up. My guess is it's another 'feature' of the analog spectrum analyzer that I haven't worked out (maybe secretly normalizing out the 1/f? but it's faster than 1/f rolloff), and that something cuts off low frequency sensitivity. Seeing as I'm well within 200MHz, I'm switching to the moku to check.
While the ipad charges, made this table of the modes I'm seeing at the nominal T_set of 23 C (10.940 kOhm) for W laser, 25 C (10.050 kOhm) for E laser. The marker tells me sideband spacing is 9.6 MHz; the W current drive HF mon has a line at 9.7 MHz, so it does seem these are related. I've attached the oscilloscope trace, where you can see that the W laser drive HF mon (chan 4) has RMS noise at least 100x the noise on E laser HF mon. The oscillation is dominated by the peak at 9.7 MHz, though there are a few others. Maybe the solution is just to swap in another laser driver -- this driver is a modified version an out of date revision of the circuit. Tomorrow I will swap in the combi controller for the W current driver and see if that helps.
exit Tue Dec 1 18:08:59 2020
Entered somewhat before Thu Dec 3 10:18:07 2020
finishing up the PLL. I still need to set an appropriate gain for the LO, but in the meantime I'll try to use the Moku's laser lock feature
This is pretty straightforward. Moku has an internal oscillator and lets you control the LP (corner frequency) and controller filter (proportional gain, integrator frequency, differentiator frequency, integrator saturation level, differentiator saturation level). I'm driving the E laser HF and LF inputs from the Moku outputs. Quickly acquire a lock and play around with filter settings for a while.
exit Thu Dec 3 12:30:47 2020
Entered lab, then grabbed a spool of cable from EE, started elog Fri Dec 4 10:37:52 2020
thought about filters. The narrowest line I managed (yes really) is in the attached screenshot. I amplified +40 dB with Agilent 8447A before the splitter.
exit Fri Dec 4 16:14:19 2020
Doesn't the phase meter just read out the noise even with no locking? I thought that was going to be the magic.
For locking, the mixer readout is in units of phase and the laser current modulation gives a proportional frequency modulation with no frequency wiggles until > 1 MHz. So it should phase lock with no integrator, but I'm not sure if the free running noise will drive it out of the phase lock or not. I wonder if its possible to use the phase meter as an error signal. It would be much easier to lock frequency instead of phase via a mixer.
enter Thu Dec 10 10:04:54 2020
Hm, hadn't tried the phasemeter application. I'll check it out now... if I understand your second comment, you're saying because
an error signal proportional to phase is already integrating the frequency error. Makes sense, but does 'easier to lock frequency instead of phase via a mixer' follow, or is that unrelated?
The Moku phasemeter does produce a nice power spectrum. Here it is up to 200 Hz, I'm working with Anchal's ctn-scripts and pymoku to get the higher frequencies.
Still odd that the beat amplitude is so small. Let's check:
Looks like neither beam is producing the expected photocurrent, but because the error is not the same factor for both beams I suspect alignment / beam size. I'm aligning with some apertures to avoid smearing the beam on lenses. Aligning each beam led to more power, but my procedure doesn't simultaneously align both beams.
exit Thu Dec 10 15:11:30 2020