Displaying report 1-1 of 1.
Reports until 15:26, Monday 22 July 2013
H1 SUS
jeffrey.kissel@LIGO.ORG - posted 15:26, Monday 22 July 2013 - last comment - 07:58, Monday 29 July 2013(7154)
18 bit DAC Noise Revisited, with Excitation and at Low Frequency
To date and the best of my knowledge, the only measurements of the 18-bit DAC noise have been those performed by J. Heefner, documented in T0900338, where the DAC noise is quoted as 150 [nV/rtHz] (and flat in the frequency band he probed). We'd learned from eLIGO (lessons by Tobin, myself,Matt, and Nic) that a DAC's noise floor changes when excitation is present, so Jay had measured the DAC noise while injecting a single-frequency line at ~100 [Hz], and then measured the high-frequency asymptote (his plots are on a linear x axis, without a grid so one can really only see the results above 100 Hz).

In the interest of suspension performance in the 0.1-10 [Hz] band where cavities are currently sensitive to their optic's motion, I've now characterized the noise in detail at low-frequency (0.05-1e3 [Hz], with focus on 0.05-50 [Hz] band), using a realistic output spectrum as the requested voltage. The results are attached and described below. Since the results are clearly non-linear, we may need to try different input spectra (working a little harder than I did to balance the SR785 range vs. noise) to really understand it. Naturally, we should also develop a model of the quantization noise, to see if we can differentiate this from just bad, non-linear electronics noise. Finally, we should also perform this same measurements on a 16-bit DAC.

Note that, by default, the user-model-to-IOP-model exchange is done with zero-padding, as has become the default configuration for all models.

--------
Plots and Captions

2013-07-21_2119_H1SUSMC2_DACOutput_ModeCleanerLocked_ASDs.pdf
During a fully functional Input Mode Cleaner lock, this is the output voltage requested of the DAC at all three stages. The spectra seen at the TOP/M1 stage is totally confusing to me, so I ignored it, as it was distracting to this study to try and figure out. More on that to come later. As such, (and also informed by the input range vs. noise floor of the SR785 at these frequencies), I chose the Middle / M2 stage spectra as my representative spectra.

experimentalsetup.pdf
Diagram of how the experiment was set up. For this study, I commandeered the H1 SUS QUAD Test Stand. This is a fully-production quality test stand, running up-to-date software, and up to which nothing is hooked, so it was the perfect test bed. The Pomona box that was used to switch between output channels (borrowed from MIT) was a easy, convenient way to grab the signals, keeping them shielded, without having to mess with the usual breakout boards and clip leads -- a set up usually fraught with excess unwanted noise.

2013-07-21_H1SUSQUADTST_DACNoise.pdf The Results
PG1: Here is the digitally requested spectrum, calibrated into voltage out of the AI filter (i.e. cts at the COILOUTF_??_EXC point, multiplied by the gain of the DAC, 20 / 2^18 [V/ct]). It is compared with the measurement noise floor (for the low-frequency, 0.05 - 50 [Hz] band, with -10 [dBVpk] SR785 input range), and the measured DAC noise with no digital output requested. The "traveling notches" in the requested drive are used to carve out at the DAC noise without disrupting the main frequency content of the signal. Note that because of SR785 range vs. noise issues, I sent out a requested signal with a factor of 10 less RMS voltage at 1e-2 [Vrms]. This is compared with the M2 stage (with 1e-1 [Vrms]) and 

PG2 - 4:
The measured DAC noise output at the AI chassis for 3 DAC channels. We see, rather obviously that none of the notches below 10 [Hz], indicating a several elevated DAC noise floor. I've included a quick by-eye fit to the noise, which indicates that the DAC noise is 6e-6 * (10 [Hz] / f) [V/rtHz], with this excitation. 

Notes:
- Even though the SR785 measurement is focused on the 0.05 - 50 [Hz] band, the full spectrum out to several [kHz] is requested during all measurements.
- It's unclear to me why the shape and level of the DAC noise changes when I switch to the higher measurement band (10 to 810 [Hz]). Since I saw the DAC noise floor after the natural 100 [Hz] roll-off of the output spectra while retaining the 30 [Hz] notch (and it was Sunday at 8pm), I didn't bother traveling the notch any further, and therefore only have one measurement for each channel in this band.

-----------
Details:
The template for the mode cleaner output request spectra can be found here:
${SusSVN}/sus/trunk/HSTS/H1/MC2/Common/Data/2013-07-21_2119_H1SUSMC2_DACOutput_ModeCleanerLocked_ASDs.xml

The input spectra is defined by the following AWGGUI Foton String which filtered white ("uniform") noise:

amplitude  = 100000 to get 1e-2 [Vrms]

zpk([1.3;1.3;1.3;1.3;1.3;1.3],[0.3;0.3;0.3;0.3;0.3;0.3],1,"n")ellip("LowPass",4,1,80,100)
notch(0.47,10,200)notch(0.5,10,200)notch(0.52,10,200)
notch(0.9,10,200)notch(1,10,200)notch(1.1,5,200)
notch(4.7,10,200)notch(5,10,200)notch(5.2,5,200)
notch(10,5,200)notch(11,5,200)notch(12,2.5,200)
notch(30,5,200)notch(32,5,200)notch(34,2.5,200)
I'm *sure* there's a more elegant way of defining it, but ... so it goes.

The captured digital output spectra templates can be found here:
${SusSVN}/sus/trunk/QUAD/H1/QUADTST/Common/Data/18Bit_DACNoise_2013-07-21/
2013-07-21_H1SUSQUADTST_DACNoise_COILOUTF_AvgASDw0p45-0p5-0p55HzTipleNotch_ASDs.xml
2013-07-21_H1SUSQUADTST_DACNoise_COILOUTF_AvgASDw0p9-1-1p1HzTipleNotch_ASDs.xml
2013-07-21_H1SUSQUADTST_DACNoise_COILOUTF_AvgASDw4p5-5-5p5HzTipleNotch_ASDs.xml
2013-07-21_H1SUSQUADTST_DACNoise_COILOUTF_AvgASDw10-11-12HzTipleNotch_ASDs.xml
2013-07-21_H1SUSQUADTST_DACNoise_COILOUTF_AvgASDw30-32-34HzTipleNotch_ASDs.xml


The raw SR785 data files can be found here:
${SusSVN}/sus/trunk/QUAD/H1/QUADTST/Common/Data/18Bit_DACNoise_2013-07-21/SCRN*.TXT
with a key to what each number means in
${SusSVN}/sus/trunk/QUAD/H1/QUADTST/Common/Data/18Bit_DACNoise_2013-07-21/2013-07-21_MeasNotes.txt

The data is analyzed, and plots are produced with the following script:
${SusSVN}/sus/trunk/QUAD/H1/QUADTST/Common/Scripts/plot18bitdacnoise_20130721.m  



Non-image files attached to this report
Comments related to this report
christopher.wipf@LIGO.ORG - 13:43, Thursday 25 July 2013 (7223)

I used Matlab to model the quantization noise associated with Jeff's measurement.  Here's the punchline: The "hiFreq" measurement series is consistent with quantization noise. The excess noise seen in the "loFreq" measurements is not.

The attached plot tells the story.  The blue curve (mostly submerged under the red one) is the spectrum of Jeff's excitation, calculated with double precision as the front end would do.  The solid red curve is what you get after applying 4x interpolation, and rounding the signal so it matches the 18-bit precision of the DAC.  The 18-bit curve overlaps the double-precision curve almost everywhere -- except in the bottom of the notch and past the cutoff of the LP filter.  In those two places, it's limited by round-off error, also known as "quantization noise".  This noise floor is shown by the dotted red curve, which is the spectrum of the double signal minus the 18-bit signal.

The black curves are taken from Jeff's measurements.  For the solid curves, the excitation was on; for the dotted curves it was off (requested DAC output = 0).  The dotted curves are presumably limited by the electronics noise of the DAC. As for the solid curves, the "hiFreq" data reaches the quantization noise limit in the notch and outside the LP cutoff.  The "loFreq" data appears to be running into some other noise floor.  As Jeff noticed, the loFreq and hiFreq curves suspiciously disagree about the depth of the notch.

Side notes

  • I checked the round-off method used within the front end code (controller.c).  It's set up to round the DAC outputs to the nearest integer, which is better than the normal C behavior of just lopping off the fractional part.
  • The 4x interpolation doesn't actually do anything to benefit the quantization noise here.  This surprised me at first: I thought the noise was supposed to improve as the square root of the interpolation factor.  But in fact, this depends on the signal.  Interpolation only helps you when you have a signal that often moves the DAC output by one or more steps.  It doesn't have any perceptible effect on a signal that's constant, or mostly constant.  And Jeff's excitation is so tiny and so heavily low-passed that the DAC output is held constant much of the time.  If you rescale the excitation so it uses the full DAC range, then the quantization noise goes down, and you do see the expected improvement from interpolation.

Suggested next steps

  • If the excess noise in the loFreq measurements is something real, can we pin down the source?  Is it already present at the AI chassis input?
  • How about a direct measurement of the quantization noise, by adding testpoints in the IOP before and after the round-off?
  • We could use some noise shaping sorcery to push the quantization noise floor below the electronics noise of the DAC.
Non-image files attached to this comment
daniel.sigg@LIGO.ORG - 07:58, Monday 29 July 2013 (7262)
The dominant noise source of a low noise DAC, when driven near its full range is the integrated non-linearity (INL). The exact shape of this noise might depend on the exact drive, ie., it could very well be different for a broadband signal vs single frequency, it might look different for high vs low frequency drive signals.
Displaying report 1-1 of 1.