Due to testing of CTN:2406 I expect the beatnote to be away from 27.34 MHz. So I have changed the beatntoe detector to wideband New Focus 1811 for the long weekend. It has badnwidth of 125 MHz.
All details regarding TTFSS boxes present in CTN has been updated at this page in ATFWiki
I have added fields of who made the changes, on which box and on which board to make this change log more readable. These fields should be followed from now on.
Relevant circuit schematics, photos and zero models are kept in ctn_electroncs/TTFSSzeroCTN repo to keep a version history of changes as well. This should be updated everytime any change is made to the boxes from now on.
Note: The current updates were made by using Andrew's change log and verifying that no other changes have been mentioned in our elog history other than the change log. However, if the real circuit has any changes which people did not log, then they are not present in these schematics or model. These, if they exist, will be added as soon as we find them.
I'm skeptical of your FSS changes over the past year. Can you please link to the DCC entry that has the actual, real, as-built, as-modified FSS schematics? i.e. including all changes no matter how minor.
Following Rana's test done in 40m:1986, I have programmed the lab to go through a similar test. Following things will happen:
So this will happen three times. In between, the cavity heater PID control will have 7.5 hrs to stabilize the beatnote frequency and at 3:00 am as usual beatnote measurement will happen.
All channels are being recorded at FB4 in QIL so we can look back the relevant channels after the test is over. Putting a sticky note in QIL for not to interrupt FB4.
I have written a script which will trigger Moku every day at 3 am to take a beatnote timeseries measurement. It will then calculated the ASD of the data and will save important experiment configuration details in a log file. This will happen in ctn_noisebudget/Data/dailyBeatNoteSpectrum directory.
I have currently configured it to take timeseries for 60s with 10 kHz tracking bandwidth using Koji's SN101 beatnote detector. The cavity temperature control is working nicely with keeping the beatnote close to the peak frequency of 27.34 MHz, within 500 kHz of it atleast.
Attached is the latest noise budget calculated using the new object-oriented script.
Parameter files and all noise contribution PSD data.
Note that since we used Penn et al. JOSA B 36, 4, pp C15-C21 values for shear and bulk loss angles of the coating and used Hong et al . PRD 87, 082001 (2013) calculation procedure, as pointed in CTN:2401, the estimated coating brownian noise contribution is more than previously calculated and dominates the total estimated noise from about 20 Hz to 20 kHz. Also, the PLL noise was switched with Moku Frequency Noise measured in CTN:2357
The experiment configuration file is attached. Major differences are:
Beatnote Measurement Data
We need to switch out normal flat-faced beam dumps with triangular cavity beam dumps in all places where they are not present. Following is a summary of beam dump status
Total Normal Beam Dumps behind PMCs: 12
I have started daily acquisition of beatnote from today onwards. This directory will contain beatnote spectrums taken everyday along with a yaml file containing logged channel values for experiment configuration. Our aim is to collect this data so that overall degradation/enhancement of beatnote can be plotted with time along with any significant changes in the crucial experiment parameters. This will also help in identifying gains or loss after any change on the table or scripts.
The new noisebudget code follows Hong et al . PRD 87, 082001 (2013) calculations to calculate Coating Brownian noise. This calculation uses different loss angles for bulk and shear strain. In fact, the calculation uses different loss angles for each layer as well if known. The closest reported values I could find are from Penn et al. JOSA B 36, 4, pp C15-C21 (2019). They used mechanical ringdown measurements of large disks and COMSOL modeling to estimate the bulk and shear loss angles.
I used these values and compared the change in the estimate of coating Brownian noise contribution. Attached is the result.
If the loss angles values reported by Penn et al. are correct, then our Coating Brownian noise would actually be buried beneath all other noise contributions. So I'm not sure what is correct, what is not? Is my understanding of this wrong somewhere?
The old calculations were described in CTN:2250.
I would like some guidance on this.
Edit Wed Aug 28 10:49:45 2019 anchal:
I did a mistake in the plot earlier. The new data was in PSD, not ASD, so it needed to be square-rooted before comparing with the old data. I've updated the plot now.
It seems like the induction of new values and new method changed the effective coating loss angle (used in the previous calculations). If Penn et al. values are correct the expected Coating Brownian noise contribution has actually increased by about a factor of 5. However, I'm not sure where the previously used effecting coating loss angle value of (2.41 +/- 0.2)e-5 came from. Complete noisebudget is coming soon.
The cavity temperature control (aftter the last fixes by Andrew) seem to be working good actually now that the Vacuum Can temperature is stabilized nicely. SO I didn't want to interfere with the PID's job which it seems is trying to reach to the set point almost critically. However, today, the beatnote came below 125 MHz, so we were in range with New Focus 1811 to take the spectrum. So I did it.
I used the coupled output from 20 dB coupler to feed the moku and use it's phase meter along with SR785 witht he previous PLL setup. Since the beatnote was still drifitng by around 10 kHz/24 sec, I took spectrum with linewidth of 1 Hz and used 20 averages to catch the PLL frequency noise in between its jumps. Simultaneously (almost), I took measurements with moku also to see if we can reliably switch over to moku. Good thing about moku is that it is faster in adjusting it's carrier frequency to lock to the signal and hence the jumps are unnoticeable. The attached plots are the measurements.
Scott and I have written a modified PSD calculation function, which does everything same as a normal weltch function would do, but on top of it, it provides 15.865% and 84.135% percentile of all the individual segments the function used to calculate PSD. Also, the reported value is median and not mean. Further, this function implements welch function with different sizes of npersegment to ensure more averaging at higher frequencies and equal number of points in each decade. All this is done in mokuReadFreqNoise.py which uses modeifiedPSD.py. Linear detrending of data is also used before calculating the PSDs from the timeseries data provided by moku.
Code and Data
I aligned the south cavity today achieving a nice 70% mode matching. While doing so, I realized a big issue that was gone unseen before the heater circuit blew up. I saw that since the vacuum can temperature control was active and was making a lot of jumps here and there all over the 1.5 A range, the Sorenson power supply isn't so good in keeping up with such sudden current changes. In effect, I think the Vacuum Can Heater's PID control signal gets coupled to the overall power supply coming from Sorenson.This +- 24 V rail was connected to EOM drivers earlier. Because of the poor design of EOM drivers, the EOM's are constantly at a DC voltage of +24V from this Sorrenson Power supply with only a passive filter. I could see today that when vacuum can PID was on, the laser frequency was haphazardly changing making it much more difficult to align the cavity. I was able to align it in minutes once I switched off the vacuum can PID.
So moral of the story is, keep the vacuum can heater circuit alone and Sorrenson Power supply is exclusive for it.
I shifted the EOM driver's power supply to Kepco which supplies for other rack-mount electronics as well.
Utilizing the fact that the heater stopped last Friday, I fitted the day to extract out a time constant for cooling down of the Vacuum Can through the present insulation. Attached is the fit. The time constant has come out to 2.298 +/- 0.001 hr.
Infact, I should use this data in future to calculate current time constant of temperature decay of the can through the insulation.
I updated ctn_scripts\channelFramebuilderConfigFileCreator.py to work with the new format of modbus hosting through docker (and cleaned it a bit). Also, from now on, C3CTN.ini will stay in the ctn_scripts repo to have version control.
I have run this once and followed instructions from CTN:2014 to restart frambuilder daqd process so that all new channels are logged as well.
I found out that FB4 is not recording the channels that I have added later. I need to look into this as well.
See CTN:2394 for the symptoms and investigation. Open this post at CTN:2395 to see the chain of previous work on this circuit.
I had aligned the North Cavity before the weekend and was about to align south one today when I saw that the modematching on the North Cavity has fallen to 20%. This is a tell-tale sign of vacuum can temperature changing too much. When I checked, indeed the temperature sensors were railing to their lower most value of 26.599 Celcius. Same for both in-loop and out of loop sensors. While the table top temperature sensor was giving a meaningful value.
I first checked point by point the temperature sensor board LIGO-D1800304. From ADC all the way back to the AD590s.The two sensors were indeed giving a voltage of 4.8 V through a transimpeadance of 16.25k which meant 295.385 uA of current corresponding to 22.23 Celcius. So indeed the sensors were telling me that the can had cooled down to almost room temperature over the past 2 days.
I checked the framebuilder logs to figure out what has happened. The temperature was being stabalized at 34.38 Celcius by the PID script. At around 15;20:25 Aug 16, 2019 PDT, the temperature starts decaying. Infact, I should use this data in future to calculate current time constant of temperature decay of the can through the insulation. The table temperature was around 19 Celcius all this time. I found out that FB4 is not recording the channels that I have added later. I need to look into this as well.
Attached is the decay plot of the temperature
After a deep search through elog, CTN:2043 and CTN:2045 are the most relevant latest post. Kira and Kevin worked on this heater drier circuit and I'm doubting that something blew up in this circuit CTN:1903. I guess this would be my first point of attack.
Another possibility is that the heater load got disconnected. Well, I just checked the resistances and I get values of 38, 70, 70 and 38 Ohms. These are the right values according to CTN:1750. This is not the issue.
Lastly, the worst possible issue would be that the temperature sensors are reporting wrong temperature. But looking at the the properexponential decay of temperature reported by them, I would first assume that they are working fine.
We were suspicious that the reason the transfer function was decreasing with an increase in power was actually due to the monitoring circuit, specifically the MAX2470 RF Buffer. To test this hypothesis I took a power sweep with an EOM driver (SN07) which only contained the 5V regulator and the Buffer, along with all the components associated with these devices. There was no transistor, as well as no diodes at the input power supply. The overall change from -5 dBm to 15 dBm was only around 0.1dB. This indicates the monitoring circuit does not provide an explanation for the reduction in gain seen at higher power levels.
I investigated the possibility of increasing the EOM Drivers gain by replacing the R5 resistor with a different value, as this should be what effects the gain of a common base amplifier.
It seems we cannot use this method to increase the gain of the driver.
Have you seen this related paper on direction dependent loss that might be interesting?
What are the specifics of the discrepancy? If your TR effect changes, it won't have perfect cancellation with TE, so thermo-optic noise could indeed be much worse.
I saved the traces of old and new noise budgets as txt files and then plotted them together to understand the differences between the codes. One can refer to CTN:2250 for a summary of calculations of old noise budget.
There is no distinction in the calculation of this contribution after the changes made in CTN:2388, but there is still a difference (which reaches to around 20% above 1 kHz). This is maybe because of interpolation errors when taking the differences. But I'm not sure about this. This can take a sanity check from others as well.
The following calculations had no differences between the two noise budgets and the contribution differences are also none or minimal.
To determine if the loss in gain seen by the new eom driver (SN:06) was due to the driver itself or just because of the addition of the bias tee, I took the transfer function of the old eom driver with and without the bias tee. This plot shows the LTspice simulated transfer function with and without the bias tee, as well as the effect of adding the bias tee to either driver. Here are some take-aways:
It seems we cannot introduce a bias tee without facing a reduction in the gain of the driver.
Following points are in relation to previously used noisebudget.ipynb file.
Following points are in relation to the new code at https://git.ligo.org/cit-ctnlab/ctn_noisebudget/tree/master/noisebudget/ObjectOriented.
The new noise budget code is ready. However, there are few discrepancies which still need to be sorted.
The code could be found at https://git.ligo.org/cit-ctnlab/ctn_noisebudget/tree/master/noisebudget/ObjectOriented
Please look into How_to_use_noiseBudget_module.ipynb for a detailed description of all calculations and code structure and how to use this code.
In the previous code, while doing calculations for Thermoelastic contribution to Photothermal noise, the code used a weighted average of coefficients of thermal expansion (CTE) of each layer weighted by their thickness. However, in the same code, while doing calculations for thermoelastic contribution to coating thermo-optic noise, the effective CTE of the coating is calculated using Evans et al. Eq. (A1) and Eq. (A2). These two values actually differ by about a factor of 4.
Currently, I have used the same effective CTE for coating (the one from Evans et al) and hence in new code, prediction of photothermal noise is higher. Every other parameter in the calculations matches between old and new code. But there is a problem with this too. The coating thermoelastic and coating thermorefractive contributions to photothermal noise are no more canceling each other out as was happening before.
So either there is an explanation to previous codes choice of using different effective CTE for coating, or something else is wrong in my code. I need more time to look into this. Suggestions are welcome.
The effective coating CTR in the previous code was 7.9e-5 1/K and in the new code, it is 8.2e-5 1/K. Since this value is calculated after a lot of steps, it might be round off error as initial values are slightly off. I need to check this calculation as well to make sure everything is right. Problem is that it is hard to understand how it is done in the previous code as it used matrices for doing complex value calculations. In new code, I just used ucomplex class and followed the paper's calculations. I need more time to look into this too. Suggestions are welcome.
Because of the previous data comparing the open box vs the closed box was varying unexpectedly, I re-ran the experiment with both sets of data taken on the same day.
Now both sets of data show very similar curves, with the box open data slightly above the closed data in most areas. Maybe the last data was different due to other systematic conditions on that day, but it does seem like now the difference is gone. Both sets follow the original closed box data measurement from before.
I set up the transfer function for three scenarios using a -5 dBm, 5 dBm, and 15 dBm signal for each:
In every case, there is a decrease in the magnitude of the transfer function with an increase in signal.
EOM Driver Link: https://dcc.ligo.org/cgi-bin/private/DocDB/ShowDocument?.submit=Identifier&docid=D1200794&version=
List of EOM Drivers in the lab: https://nodus.ligo.caltech.edu:30889/ATFWiki/doku.php?id=main:experiments:psl:electronics
Measurement setup and analysis:
Calling out for help
Edit Fri Aug 9 09:50:24 2019 anchal:
The last measurement was taken in the wrong way and hence it was mismatched. The ground pin was connected to the wrong position. I retook data today and seems like EOM path and is all healthy :). But the other mismatches still need to be investigated. The Code and Data are updated through git.
Edit Thu Jan 23 19:33:55 2020 anchal:
The mismatched were there because the stage saturates when boost is on. Need to take that measurement with appropriate offset applied through AO Offset. This is done in this CTN:2518.
I have borrowed the SRS DB64. It is in QIL.
I replaced the EOM driver that was attached to the south EOM with the Bias Tee and the driver which I tuned with the Bias Tee and Dummy EOM. After some minor tuning, I was able to move the transfer functions peak back over 37 MHz. I took the spectrum of the RF monitoring port while a 16.5 dBm signal was present on the RF in port from OCXO after placing an 8 dBm attenuator. We noticed that the max peak at 37 MHz was around -3.49 dBm which corresponds to a signal with an amplitude of 6.4122 V by converting to voltage, multiplying by sqrt(2) and dividing by the value of the simulated TF at 37MHz which is about 0.0328. This is less than the expected 20 V amplitude from a 16.5 dBm signal with the transfer function from the previous post (https://nodus.ligo.caltech.edu:8081/CTN/2376). This motivated us to take transfer functions at different input powers to see if it does change. We can see that it does a fair amount for large input signals. I can offer no explanation at this time.
This is the time series from the AC port of the 1811 new focus photodiode which is set up for RAM measurement. A strange waveform is present, it has a peak to peak voltage of around 2.9 V and a frequency of around 60 kHz.
Our previous plan turned out to be ineffective due to the mirror not transmitting all of the P polarization, but only a fraction. We now used the PBS within the faraday isolator (FI) as a pickoff, and rotate the HW plate at the input to control the power reflected. When the HW plate is maximized for transmission through the FI, I measured 13.4 mW into the FI, 12.00 mW at the output and 1.18 mW picked off. I then used a mirror to steer the picked-off beam onto the 1811 new focus photodetector. Using the DC coupled output I maximized the output on an o-scope, which was at the level of 400 mV. The AC output was then connected to the HP4395A analyzer from which the data was taken.
Edit: I have now put a focusing mirror with a focal length of 5cm before the PD, the o-scope now reads 3.41 V. A pdf of the layout with these updates can be found at https://nodus.ligo.caltech.edu:30889/ATFWiki/lib/exe/fetch.php?media=main:experiments:psl:ctn_optical_layout.pdf
The plan is to put a half-wave plate before the mirrors which steer the beam into the faraday isolator before the South cavity. The mirror which will act as a pickoff is only reflective to S polarization at 45 degrees, so with the HW plate, we can get enough light in transmission to measure RFAM with a photodetector.
Edit Thu Aug 1 16:11:12 2019 ScottA :
4 Vpp is actually 16 dBm, so we need to feed 16 dBm power from OCXO to the EOM. So we'll need ~10dB attenuation but everythign will still work.
Here is the result of taking the transfer function of the EOM Driver (DCC: D1200794-v3) with the bias tee and a dummy EOM from the RF input to the RF monitor output. A Black 143-10J12L tunable inductor (438 nH - 788 nH) was used to bring the peak over 37 MHz. The data was taken using an Agilent 4395A Analyzer which was controlled using the .py .yml and .ini files provided in the zip.
I just took Scott's notebook and added code to integrate the input-referred temperature noise power spectral densities over different bandwidths of frequencies to see what noise we should expect with 16 Hz sampling and what does the measured data suggests. The expected total noise sum is below 1mK for bandwidth up to 10 Hz and the measured total noise is below 0.3 mK up to 10Hz bandwidth. In my opinion, this circuit has passed the test if our experiment and the analysis is correct subject to Rana's opinion.
The data was taken from a 5-hour window from 8 am to 1 pm yielding 288000 data points per channel. First I take the channels and subtract them in three different ways, 0-1 1-3 and 3-0 to yield all possible unique differences. Then I take the PSD of the data and take the square root. The output is given in the first graph showing very similar trends for all three differences.
Then I assumed all channels have the same transfer function but different offsets, so each PSD of the difference channels has the sum of the noise of both devices in quadrature. By adding difference PSDs with the channel we want and subtracting the other we get the noise of a single device squared. Taking the square root we can pull out the individual noise spectral density for each channel. It is interesting to note here some values from the PSD difference operation resulted in a negative value which was lost when square rooted.
The third graph shows the ASD of the voltage noise coming from the 15V power supply which powers the IC's and AD590s on the temperature board. There is a spike at 4 Hz in the plus and minus channel, which is a mystery as of now. I also shorted the input of the ADC to ground on channel two in order to measure the input-referred noise of the ADC itself. I used the ADC noise and the noise from the plus and minus rail to model this power noise contribution coming in through the AD590, OPA827, and OP27 of the circuit and added it to the noise sum at the output modeled in zero. To determine how much the noise propagates through the circuit, I multiplied each noise source to an IC first by its power supply rejection ratio and then by the transfer function to the output of the circuit.
The fourth graph shows this power noise added to the noise sum, which includes real data taken to estimate the power supply noise for each source as well as the simulated noise values from zero. The data plotted as a scatter plot is the same as in graph two and provides a real-world measurement of the overall noise measured at the ADC from the circuit as a whole. It seems the noise level measured is well below the expected noise, which is dominated by the OPA827 transimpedance amplifier stage.
To get input-referred noise I divided everything by the transfer function of the circuit yielding units of A/root(Hz), and then I divided by the 1u K/A TF of the AD590 to yield K/root(Hz) in the final graph.
This experiment consists of a thermally insulated box that contains a large piece of copper and 3 AD590 temperature sensors thermally pasted together using Thermalloy Thermal Joint Compound 249. The AD590s are connected to a temperature sensing circuit (DCC: https://dcc.ligo.org/cgi-bin/private/DocDB/ShowDocument?.submit=Identifier&docid=D1800304&version=) within a metal box which is also contained in a larger insulated container. This circuit is powered by an external 15V supply (DCC: https://dcc.ligo.org/cgi-bin/private/DocDB/ShowDocument?.submit=Identifier&docid=D1000217&version=). The output of the temperature circuit is connected to an ADC General Standards 16AI64SSA. I use 6 channels of the ADC, Ch. 0 1 and 3 records the AD590 temperature data, Ch.2 I short to ground and record the referred input voltage noise of the ADC, Ch.4 is the positive pin of the 15-volt power supply while Ch.5 is the negative pin. The ADC has a maximum readout of plus or minus 10V so to bring the 15V supply into the measuring range I used a 1.1k to 1.1k voltage divider on both pins to reduce the voltage reading by half.
I want to take the difference of each channel with the other channels to pull out the noise for each sensor. As well as get the noise from the 15V power supply and the ADC using channels 4/5 and 2. Then I will use this data to better estimate the noise budget of the setup as a whole, and to compare the prediction to reality.
beware the Debian zealots! All the workstations at the 40m are SL7.
If you really can only use Debian, you could just clone the new workstation that Jon setup in QIL.
I found today that all this while, the channel values shown on our FSS_Interface medm screen and used by rmsMonitor.py for gain cycling were somewhat arbitrary numbers. It took me a while to figure out that the channel voltage is 10 times what reaches the AD602 on TTFSS board. Maybe awade knew about this but there was no documentation on this. Anyways it seemed bogus to increase the gain of FSS loops in arbitrary units. I added four more channels with _DB suffix which carry the physical units (in dB) of the Common and Fast gains in FSS loops. The older gain channels are calc channels now which calculate the channel voltage required from dB value. Everything has been tested to work correctly with the changes. My next steps are to step by step check all transfer functions in the FSS loop and find the culprit.
Last week, the default GNOME Classic desktop environment of WS1 started giving hiccups. I was unable to see any medm screens. I restarted the computer assuming that will solve it but then I was unable to login from the graphical user interface. That was weird as I was able to ssh into the computer and do whatever I want. So it seemed that some graphics engine was unable to run. On login screen, after typing in the correct password, a black screen would appear and it would go back to the login screen. This is mentioned in various forums on the internet as "login loop". Taking advice and directions from Jamie, I tried to troubleshoot this to the best of my ability but we both were unsure in the end what was the problem. Our best guess is that installation of LSCsof package upgraded some graphics library beyond the capability of the present system. I tried all different desktop environments and I was able to login only through GNOME on Wayland (supposedly bleeding edge for debian 8). Another mystery is that I found medm uninstalled from the computer. I installed it back with:
sudo apt-get install medm
And I found that GNOME on Wayland is still usable option. After some more discussion with Jamie, I decided to upgrade the OS to next stable version debian 9. I followed the instructions on:
to dot and have successfully upgraded to debian 9. However, still only "GNOME on Wayland" is the only desktop environment through which we can login without facing a login loop
On another note, I found today that clicking the scroll button over a medm channel screen (which ideally displays the channel name) freezes the computer. The mouse pointer disappears and the computer does not respond to anything. Again, I can ssh into the computer and do anything. This problem goes away on restart.
So bottom line is, the overall system environment of ws1 is becoming messy and old and ideally we should do a clean install of a new os (something like Jon did in QIL). But I was heavily discouraged for doing so as it seemed it will take a lot of time to setup a new workstation.
Due to recent cleanup and upgrades in our computer environment in lab, this workstation ws1 is a mere looking window in the experiment. There are no active scripts that it runs (except a precavity beatnote reading) and the experiment can be carried out without it present as well. However, it is nice to keep a computer loaded with EPICS, nds2, python environments and a screen to carry out day-t-day functioning of the lab.
Here I have used zero to model the effect of replacing OPA827 with other op-amps for the transimpedance amplifier stage of the AD590 temperature sensing circuit. The graph shows the sum of the noise at the output of the circuit right before the ADC.
The table shows the typical input offset voltage drift for each component. I have ordered the table from the lowest noise to the highest at 1 millihertz.
The library of op-amps I used is from the develop branch of zero, which should be available on master soon.
From what I can see the two best candidates to replace OPA827 would be AD8671 or LT1128, as they have an all-around lower noise density than OPA827. OPA827 does have the smallest temperature drift of all the op-amps though, so it depends on what we care more about.
And that is the quick guide on how to twist wires with a drill.
show us what you got for the LISO or ZERO noise budget of this circuit before testing; also sketch of the experiment setup
My goal was to investigate the effect of placing a 1k ohm resistor as the input of the DC port of the Bias Tee. The expectation was it would decrease the bandwidth around DC, and this is supported by LTspice simulation. According to simulation, at around 300 Hz there becomes a few dB difference between having the resistor and not having it. From the paper 'W. Zhang, M. J. Martin, C. Benko, J. L. Hall, J. Ye, C. Hagemann, T. Legero, U. Sterr, F. Riehle, G. D. Cole, and M. Aspelmeyer, "Reduction of residual amplitude modulation to 1 × 10-6 for frequency modulation and laser stabilization," Opt. Lett. 39, 1980-1983 (2014)'(https://www.osapublishing.org/ol/abstract.cfm?URI=ol-39-7-1980) in Figure 2B we see the frequency noise without servos active. The noise falls off after around 50 Hz, which indicates the change of bandwidth to 300 Hz should not be an issue. I also showed the effect for 500 ohms to see how the transfer function changes intermediately between 0 and 1k ohm resistances.
I reflow soldered 3 channels to an AD590 temperature board for a differential measurement test. I expect to run the experiment soon to see the noise of the sensor.
I have soldered one full EOM driver with the tunable inductor mentioned before, as well as another driver without connectors or the inductor. Here I will explain the process of reflow soldering in a few short steps.
Make sure that all the components can withstand the melting point temperature of the solder paste.
The last photo shows both EOM driver circuits I used reflow soldering to make.
P.S. Questions? Ask Anchal.
I will add the simplified model of the bias tee into the EOM driver Circuit simulation within LTspice. I will include the parasitic resistance of the inductor, but due to the reason mentioned above will not include the parasitic resistance of the capacitor. Then I will see if it is possible to maintain the impedance peak at 37MHz by using the tuning inductor within the circuit.
In order to better characterize the Bias Tee, I measured the non-diagonal components of it's S matrix using the network analyzer(NA). I did not measure the reflection coefficients due to the inability of the NA to measure this without specialized components, and attempts at solving numerically were unsuccessful. Bias Tee's model number is ZFBT-4R2GW-FT (Link: https://www.minicircuits.com/WebStore/dashboard.html?model=ZFBT-4R2GW-FT%2B).