Displaying reports 741-760 of 1081.Go to page Start 34 35 36 37 38 39 40 41 42 End
Reports until 16:02, Wednesday 01 May 2024
Controls General
Jeffrey Wack - posted 16:02, Wednesday 01 May 2024 (11546)
Setting Moku IIR filter

I have written a script to set and measure an IIR filter in the moku froma continuous time transfer function in zpk form. The script can be found in labutils and attatched to this post.

The following transfer function is:

z = [-500,-35000,-50000+40j , -50000-40j]

p = [-1000,-12000,-80000+40j , -80000-40j]

k = 1

 

Images attached to this report
Non-image files attached to this report
Controls General (GQuEST)
Chris Stoughton - posted 12:27, Wednesday 01 May 2024 - last comment - 17:14, Monday 06 May 2024(11544)
Latency comparisons

I'm discussing options with Ryan.  

 

We are purchasing one LXD31k4 board, but notice that latency is not so great for the ADC and DAC on it.  For the ADC, the pipeline delay (latency) is 26 clock cycles/300 MHz = 87 nSec and for the DAC the latency is 134 clock cycles/300 MHz = 447 nSec.  

 

He found a low-latency (better than 4 nSec) DAC board AD9740-FMC-EBZ but with only 10 bits.  So we need to understand how to make that trade-off between #bits and latency.

 

This ADC card has 12 cycle latency at 125MHz, (96 nSec) dc-coupled, 16-bit, 4-ch + 1 DAC 

https://www.vadatech.com/product.php?product=900&catid_now=0&catid_prev=0#prettyPhoto

but the DAC on that one is the DAC3171 which can run up to 500 MHz for a 26 nSec latency at 14 bits.

 

Ryan found a discussion board on a low latency solution for ADC => FPGA => DAC (basically what we want!) from 8 years ago - looks like this was their conclusion on which chips to use:

The ADS5400 (1GSPS, 7ns latency) and DAC5670 (2.4 GSPS, 4.42 ns latency) are the lowest latency converters currently available.

Ryan is discussing what it would take to build a custom FMC board with these chips.

 

So, Ryan suggests these purchases to evaluate our options:

===================================================================

From a RedPitaya discussion board on a fast PDH controller:  https://forum.redpitaya.com/viewtopic.php?t=1354

by Nils Roos » Thu Mar 31, 2016 9:17 pm

From the datasheets of the ADC and DAC you can derive some estimates for the expected latency.

The ADC has a pipeline latency of 6 cycles plus some nanoseconds clock to output delay. At 125MHz this gives ~50ns latency from the moment the input is sampled to the moment the data is available at the FPGA. The FPGA's input buffers add one cycle, as do the output buffers, and then there is internal routing which typically comes to <10ns, so without any further processing, you get 26ns additional latency through the FPGA. The DAC has 2 cycles of data input to analog output latency, another 16ns. Thus, you end up with just under 100ns minimum delay from analog input to analog output.

===================================================================

For reference, RFSoC solutions claim to have about 120 nSec latency, depending on how they are configured.  (The sample we tested from Leo did NOT optimize at all for latency)

 

 

 

Comments related to this report
Chris Stoughton - 10:08, Thursday 02 May 2024 (11548)

Ryan adds this to the discussion:

 

I confirmed with Craig Drennan, in AD, that they are using this ADC in their MicroTCA solutions (but they only have AC-coupled) from Vadatech:

ADS42JB69

  • It is JESD204B at <5G, <$100 per channel, 16-bit, but 250Msps max.
    • This could be the perfect cost/speed match to the Artix-7
      • An Artix-7 at $400 would have 16 lanes for 16 ADS42JB69 channels (8 chips) at $100/channel = $2K in primary components for 16 ADC channels on a custom board.
    • We could likely benefit from the firmware they have already done (which maybe Jonathan did?) for their AC-coupled solution.

 

Then I asked:

Would we be able to have DC coupling on a custom board?

Does this leave room for DACs on the same board, or is it a total of 16 ADC+DAC channels? 

Looking at the data sheet,  in 10x mode the max sample rate is 250 MHz and the latency is given in two ways.

  1. Latency (N Cycles) is 23, and I calculate 23/250MHz = 92 nSec
  2. Typical Data Delay (t_0, ns) has the equation 0.65*t_s + 3 = 0.65/0.250 GHz + 3 = 5.6 nSec

 

and he responded:

Yes, definitely we can do DC coupling on the custom board.

 

We need to find a similar DAC solution. That is next. But it could be on the custom board too. I am imagining a 2nd Artix 7 using 16 lanes for DAC channels. And then the two Artix7s communicate with each other over GPIO.

 

If we make it in an RTF (uTCA rear panel) form factor, it would add scaling up ability (maybe AD would even use it).

Lee McCuller - 17:14, Monday 06 May 2024 (11551)GQuEST

The formuta for quantization noise is

12**0.5 * 10V * 2**(-N_bits) / (F_sample)**0.5 (in V/rtHz).

the factor 12 is for the uniform distribution, 10V ADC/DAC range. N_bits is the dynamic range of the ADC and the sample rate how fast you will be sample.

I think you should shoot for the 50nV/rtHz - 500nV/rtHz range. Slow ADCs and standard osc scopes get 1uV/rtHz, so this should ideally do better than those. With a 25MHz sample rate, that is going to take 14 or 16 bits. 10 or 12 bits appears to be a bit too low for noise. We can use frontend filters to help that, but then we need to add those to the boards (which we can do!).

 

 

I would say if you have some latency of T=250ns, then the sample rate only needs to be about 4x as high as that sample rate, or 4/T ~ 16 MS/s. So a sample rate of 25MHz would be about right for controls applications. 100MHz is better for data acq applications. It can be higher, if it still helps latency, but sometimes the number of needed clock cycles goes down with the sample rate.

Having an excessive sample rate, when it does not help latency, can be a bad thing since it makes designing filters worse (filters take more bits when they are faster).

 

 

 

Controls General
Torrey Cullen - posted 17:17, Tuesday 30 April 2024 - last comment - 15:40, Wednesday 01 May 2024(11543)
Importing a resonant gain filter into the moku

[Jeff, Ian, Torrey]

Python script that will create a resonant gain filter (passes all frequencies and boosts around a specified frequency) and convert it into a form that the moku will accept.

edit: this script is outdated, see below.

Non-image files attached to this report
Comments related to this report
Torrey Cullen - 15:40, Wednesday 01 May 2024 (11545)

Continuation from yesterday:

We went to upload one of these filters into the moku and found that upon doing so the piezo rings up quite loudly. The previous version of the script was creating an unstable filter (which is undistinguishable from a stable one in the view the moku has i.e. this. This version of the script has made the necessary correction.

With successful implementation of this filter in the digital filter box, I drove a tone at 300 Hz to match the frequency of the gain in the filter and observed the spectrum directly after the controller and after the DFB (bus 1 and bus 2 in the screenshot) Without the resonant gain filter the spectrum reads 178 uV/sqrt(Hz) @ 300 Hz for both channels. Applying the filter and checking the spectrum shows a large suppression in the noise in one of the channels (Bus 1 - 2.96 uV/sqrt(Hz) @ 300 Hz, directly out of the fast controller) and no supression in the second channel (Bus 2 - 194 uV/sqrt(Hz) @ 300 Hz, directly after the boost at 300 Hz is applied).

 

 

Images attached to this comment
Non-image files attached to this comment
GQuEST Output Filter Cavities
Torrey Cullen - posted 14:31, Monday 29 April 2024 - last comment - 14:31, Monday 29 April 2024(11541)
Cavity Calibration

As discussed in the most recent group meeting, here are my results for calibrating the cavity spectrum into a displacement spectrum. Attached is the notebook used to create this. Data for the script (explained in notebook as well) is in "\Nextcloud\GQuEST\B102\Output Filter Cavity\FilterCavityScansAndTFs\Monday-4-22\".

Images attached to this report
Non-image files attached to this report
Comments related to this report
Torrey Cullen - 13:43, Monday 29 April 2024 (11542)

For those that aren't on the nextcloud.

Non-image files attached to this comment
Controls General
Chris Stoughton - posted 09:29, Friday 26 April 2024 (11540)
Purchase requisition for one LXD31K4-DC placed

I received a quote from the company and submitted a purchase requisiton through Fermilab to purchase one.  The vendor has one on hand that can be shipped in a week after they receive the order.

GQuEST General (GQuEST)
Daniel Grass - posted 23:55, Monday 22 April 2024 - last comment - 12:12, Tuesday 23 April 2024(11536)
Updated Substrate Thermorefractive Noise

Yuri Levin emailed us pointing out that we didn't use an updated version (2009 vs 2004) of substrate thermorefractive noise that includes contributions from the standing wave in the beamsplitter. Unfortunately, this has pretty major implications for our noise budget. Attached is the updated noise budget and a 2 page summary of my calculations today and some future outlook.

Non-image files attached to this report
Comments related to this report
Daniel Grass - 12:12, Tuesday 23 April 2024 (11537)

Another solution not mentioned in my document: cross-correlating two interferometers. Of course this was already the plan, but maybe we should push harder on this.

GQuEST Output Filter Cavities
Torrey Cullen - posted 15:47, Monday 22 April 2024 - last comment - 13:42, Thursday 25 April 2024(11535)
Experimentally measuring FSR

My attempt at measuring the FSR of the cavity is off by ~20% of the expected value.

I scan the frequency of the laser and record the time between two 0,0 modes. The voltage between the two modes can be calculated from the scan amplitude and frequency. Then, the FSR of the cavity from experimental data should be:

t_start = -48.12e-3 #sec

t_end = 13.8383232e-3 #sec

scan_amp = 2 #volts

scan_freq = 5 #Hz

period = 1/scan_freq #sec

miliamp_per_V = 2e-3

meters_per_miliamp =  2.625e-10 #5e-12/20e-3

cav_len = 2.4

lambda_1 = 1550.08e-9

c = 3e8


delta_t = t_end - t_start

delta_V = delta_t/(period/2) * 2 * scan_amp


FSR = delta_V*(miliamp_per_V)*(meters_per_miliamp)*(c/lambda_1**2)

This gives an FSR of 162 MHz which is clearly way off. I think the discrepancy comes from the uncertainty in the number used for the wave wavelength change of the laser as a function of the pump current. I was eyeballing this before, but here i used the number from the data sheet orginally emailed along with our purchase of the laser. See Attached. He did not provide the raw data. I used a web plot digitizer to get the raw data. The increasing/decreasing.csv are the results of this. The slope of these give the number used in the above calculation.

TLDR: I think the frequency of the laser is a poor way to calibrate the FSR.

Images attached to this report
Non-image files attached to this report
Comments related to this report
Torrey Cullen - 13:42, Thursday 25 April 2024 (11539)

Lee suggested using this measurement to constrain the wavelength change of the laser as a function of pump current using the expect FSR of c/2.4 meters. Doing this yields 2.0198e-10 m/A. I am now using this number for all cavity calibrations.

GQuEST General (GQuEST)
Daniel Grass - posted 20:25, Saturday 20 April 2024 (11534)
End Mirror Photos

See attached photos for latest version of the custom end mirror mount.

Images attached to this report
Controls General
Jeffrey Wack - posted 16:54, Friday 19 April 2024 (11533)
Towards Moku python API laser lock

Since the update to firmware 591, the python API for the laser lock box seems to have all the functionality required to lock the laser via the API. I have successfully initialized the laser lock box and read off the PDH error signal and the transmission peak. Not sure why the error signal is crap.

Images attached to this report
SNSPD General
Alex Ramirez - posted 14:23, Friday 19 April 2024 (11532)
Further Voltage Source Testing for SNSPD's

I have continued my testing of the voltage sources we have for the SNSPD's, including the new DAC VME. I have below some data that was taken using the SRS voltmeter as a dedicated measuring device. I then stepped through various voltages within the range we will be using the source for the SNSPD's to read out the measured output vs the set voltage. To better see the minute changes of each source, I then subtracted the "set voltage" from the reading and plotted the difference vs the set voltage shown below. The variations are small, but it is clear that the filtered channel has some extra amount of variation between the set voltage and what is being output. 

In my previous post I showed a plot that has PCR tests for each of the voltage sources. The filtered channels (ch 2) seemed to have a shift to the right indicating that the voltage source may be outputting less voltage respective to what is being set to. To test if this may be the case, I replotted this PCR chart using the measured voltages for each step of data that was taken. The results still show that the filtered DAC channel continues to have a shift, which we believe may be due to some type of voltage division happening with the lowpass filter on its output. For the time being, we will be utilizing the new DAC VME but on channels without these filters as they seem align well with the SRS source, while we are aware of the obvious aliasing occuring on its ramped output due to its digital nature. (see plots below)

 

Images attached to this report
Atoms General
Daniel Grass - posted 02:07, Wednesday 17 April 2024 (11531)
3D MOT Photos

Attached are some high quality images of the 3D MOT I have been designing.

Images attached to this report
GQuEST Output Filter Cavities (GQuEST)
Daniel Grass - posted 21:12, Tuesday 16 April 2024 (11530)
More Accurate Readout Diffusion Noise

Wrote up derivation of more accurate Readout Diffusion Noise calculation

Non-image files attached to this report
Lab Infrastructure General (GQuEST, Layouts)
Lee McCuller - posted 10:37, Tuesday 16 April 2024 (11529)
Drawings of lab space with GQuEST

Here are svg renderings of the lab space, with GQuEST renderings superimposed. Note that inkscape is functional, but struggles with these exports from the design PDFs.

Images attached to this report
Non-image files attached to this report
Computing General
Lee McCuller - posted 15:52, Tuesday 09 April 2024 - last comment - 20:50, Monday 15 April 2024(11526)
Wiki is down for now

I took the wiki down to see if other parts of the site would then perform better. Will put it back up at some point.

 

Comments related to this report
Lee McCuller - 20:50, Monday 15 April 2024 (11528)

Currently back up. Can bring it down again if other things get slow. Will fix sometime..

GQuEST General (GQuEST)
Daniel Grass - posted 18:31, Monday 04 March 2024 - last comment - 17:14, Monday 15 April 2024(11499)
7 m Long Interferometer SolidWorks Screenshot

See attached photo

Images attached to this report
Comments related to this report
Daniel Grass - 18:42, Wednesday 20 March 2024 (11505)

More images

Images attached to this comment
Daniel Grass - 11:32, Thursday 21 March 2024 (11508)

Two IFO image

Images attached to this comment
Daniel Grass - 17:14, Monday 15 April 2024 (11527)
Images attached to this comment
Displaying reports 741-760 of 1081.Go to page Start 34 35 36 37 38 39 40 41 42 End