ADR1399 reference

[Andreas]

Hello,

PCB#2 (with CMOS multiplexers) now passed 25.4 kHrs total operation.
see also:
https://www.eevblog.com/forum/metrology/adr1399-reference/msg6269808/#msg6269808

the LS8 devices got stable again

Nothing new for the metal can devices.

with best regards

Andreas

[iMo]

Is there any statistics known on the "jumps-free samples" with the 1399 in the metal_TO or the ceramic_LS8 packages?
It is not an easy exercise, as you have to run it for weeks continuously and measure..

[TylerPeppy]

After some feedback on a seperate thread...

I have finished my second attempt at an ADR1399 Reference board: https://github.com/T-622/uDR1399-10V-Reference-Standard

The uDR1399 combines a bunch of circuitry from previous contributors' boards, and things i'd want to see from the already available units. It uses a bootstrapped zener and LT5400 network, with an output current limit and output transistor. I figured i'd try this compared to my previous version, which didn't use bootstrapping nor the resistor network. It seems relatively stable, although it is certainly too early to tell for the ~72Hrs my 3 units have been burnt in.

I have attached a screenshot of a 12Hr log using testcontroller and my DMM6500. While I certainly can't fully charecterize this using a meter using it's own LM399, and need a 7-1/2 or 8-1/2 digit meter, I can get an idea of the stability. I was using AZ ON, 10NPLC, 10x Averaging, and 10GOhm InZ. I have observed ~3.3uV std-dev using a sliding window of 1799 samples; far better than my previous attempt which was around 10.

I am by no means a professional when designing these, but am open to everyone's thoughts! I will likely attach some more data with temperature measurements.

Thank you to iMO who kindly provided feedback on my design!

Tyler

[iMo]

then

.. I have observed ~3.3uV std-dev using a sliding window of 1799 samples; far better than my previous attempt which was around 10..

As discussed in very detail in the "..TestController.." thread - the sliding STD window has to be used with a window of 30-40 seconds, not XXXX samples.
For such measurements to be relevant you have to use say 10PLC or 100PLC, the sliding window over say 30secs (or 40) will be then XXX or XX samples respectively (you have to know the DMM6500's sampling_period for 10PLC or 100PLC).
A better way I would highly recommend is to start using the ADEV as well.

PS: for example with 60Hz mains and AI info on DMM6500 sampling period w/ AZ ON (doublecheck):

Code: [Select]

PLC      sampl_period_ms  Nsampl over_30sec   over_40sec

10       166.7            180                 240

100      1667             18                  24
PPS: with the 10PLC and your sliding STD over 1799 samples your STD window was tau=300 seconds, that is too long, imho, as the STD you measured could have been much higher at those 300secs then - because your DMM's minimal STD is usually at those 30-40secs (the ADEV of most DMMs is "U" shaped with the minimum at tau=XX seconds).
With shorter taus the STD goes UP, with longer taus the STD goes UP as well..

With some simplification: the "tau" is the "measurement integration time", and it does not matter how your DMM does it internally, when talking noise and stability what matters is "for how long it integrates/averages totally".

With the tau=30-40secs I would expect you should see the sliding STD average of 1.5-2uV noise (=std or sigma at tau, rms) with your LM399 in the DMM..

[Kleinstein]

The DMM6500, like most Keithley meters does not follow the normal shape for the Allan deviation. In AZ mode they seem to use some odd averaging for the zero and this hapers the 1/f noise suppression. This give a pateau in the allan dev curve from about 1 sec to 50 sec and a drop only after that.

The issue with the DMM6500 and most 6 digit meters is that the meter internal LM399 ref. is more noisy than the ADR1399. The measurement give the sum of both noise sources and a little ADC / amplifier noise on top.

To really see the ADR1399 noise one would more build 2 identical sources an use the meter to measure the difference (e.g. in the 100 mV range).

[iMo]

The DMM6500, like most Keithley meters does not follow the normal shape for the Allan deviation. In AZ mode they seem to use some odd averaging for the zero and this hapers the 1/f noise suppression. This give a pateau in the allan dev curve from about 1 sec to 50 sec and a drop only after that..

.. so the the tau=30secs or 40secs fits with Keithley well, and the 300secs was too long tau, in order to see the DUT's minimal average sliding std value.

PS: for younger people here an example (with some simplification, an ideally stable, noise free DUT=10V, tau=30secs):

1uV averaged sliding STD over 30seconds says that 68.3% of any two DMM readings made 30secs apart will fall into an interval from 10V-1uV to 10V+1uV (aka plus minus 1 sigma of normal distribution, it is 1uVrms)

or

1uV averaged sliding STD over 30seconds says that 99.9% of any two DMM readings made 30secs apart will fall into an interval from 10V-3.29*1uV to 10V+3.29*1uV (aka plus minus 3.29 sigma of normal distribution, it is 1uVp-p)

The usually "U" shaped ADEV indicates that any two DMM readings made too frequently (short tau) are more noisier or less stable, and any two DMM readings made long time apart are also more unstable or more noisier. Thus there are optimal taus for quality DMMs (the STD plateau at the minimum of the ADEV graph).

Also mind you have to average many STD(tau) values in order to achieve some accuracy of the STD.
It goes with 1/sqrt(number_of_STD(tau)), imho (double check that, plz).
In order to be around 10% error (for example) you have to average 100 STDs(tau).
For tau=30secs it means your total measurement should be at least 3000 seconds long.
ADEV does it for you (see the error bars in ADEV graphs for each tau there).

Important - AI reminded me (doublecheck, plz):

Sliding STD(τ) measures the spread of the raw samples inside a window of length τ.
ADEV σ(τ) measures the change between adjacent averages of windows of length τ.

So here (34401B vs ADR1001_10V) with an average sliding STD(30secs) I see for example aprox 1uV, and ADEV's sigma(30secs) shows aprox 300nV.

Based on the below equation:

sliding_STD(30) measured = sqrt(30) * ADEV_sigma(30) for ideal White noise..

[Kleinstein]

Tau = 30 or 40 s is close to the worst point in the Allan dev. curve of the Keithey meters.  This is for the ADC / AZ part and thus especially relevant when measuring a small voltage. With a larger voltage the LM399 reference noise gets also important.
Form this link
https://www.eevblog.com/forum/testgear/new-keithley-dmm6500/msg1564504/#msg1564504
It looks like with a 10 V source the LM399 ref. noise and the ADC may get about comparable.

[iMo]

Frankly, it is somehow difficult to swallow that ADEV graph to me..
On the first glance I would say there is an issue with those measurements, or ADEV input (ie sampling interval)..
But I've never messed with Keithleys, so I do not know.. 
The KS34465A sits perfectly there..

Tau = 30 or 40 s is close to the worst point in the Allan dev. curve of the Keithey meters.  This is for the ADC / AZ part and thus especially relevant when measuring a small voltage. With a larger voltage the LM399 reference noise gets also important.
Form this link
https://www.eevblog.com/forum/testgear/new-keithley-dmm6500/msg1564504/#msg1564504
It looks like with a 10 V source the LM399 ref. noise and the ADC may get about comparable.

[TylerPeppy]

then

.. I have observed ~3.3uV std-dev using a sliding window of 1799 samples; far better than my previous attempt which was around 10..

As discussed in very detail in the "..TestController.." thread - the sliding STD window has to be used with a window of 30-40 seconds, not XXXX samples.
For such measurements to be relevant you have to use say 10PLC or 100PLC, the sliding window over say 30secs (or 40) will be then XXX or XX samples respectively (you have to know the DMM6500's sampling_period for 10PLC or 100PLC).
A better way I would highly recommend is to start using the ADEV as well.

PS: for example with 60Hz mains and AI info on DMM6500 sampling period w/ AZ ON (doublecheck):

Code: [Select]

PLC      sampl_period_ms  Nsampl over_30sec   over_40sec

10       166.7            180                 240

100      1667             18                  24
PPS: with the 10PLC and your sliding STD over 1799 samples your STD window was tau=300 seconds, that is too long, imho, as the STD you measured could have been much higher at those 300secs then - because your DMM's minimal STD is usually at those 30-40secs (the ADEV of most DMMs is "U" shaped with the minimum at tau=XX seconds).
With shorter taus the STD goes UP, with longer taus the STD goes UP as well..

With some simplification: the "tau" is the "measurement integration time", and it does not matter how your DMM does it internally, when talking noise and stability what matters is "for how long it integrates/averages totally".

With the tau=30-40secs I would expect you should see the sliding STD average of 1.5-2uV noise (=std or sigma at tau, rms) with your LM399 in the DMM..

Yep, the ~1800 samples was an off-by-factor error, when I was trying to understand the equivalent of a 30s window. Nonetheless, I think I am understanding the distinction between the number of samples and the number of seconds for integration time that you are explaining here.

I will look into ADEV as mentioned, and see how to use that with Testcontroller. The U-Shaped ADEV graph makes sense to me though.

Thanks,
Tyler

[TylerPeppy]

A 15 minute quick run with a changed number of samples is showing a similar deviation, but a bit lower this time. What is interesting though, is the behavior of the deviation graph. It seems to begin low (as expected), and then ramp up, and fall down. I have then observed it to *oscillate*? Very slowly over a period of time.

Edit1: I have attached an image at 30 minutes as well that contains behavior I do not understand. The deviation seems to be stable at about ~3.32uV, and then drops low around 1.2uV, and recovers up to about 3.5uV. It does this relatively quickly, and doesn't seem to correlate with environmental or DUT behaviors at the time.

Edit2: I have attached an image at 60 minutes, and the fluctuations are now very visible. I will have to collect more data to be sure, but the captured deviations may potentially be periodic? They will drop as low as 2.5uV, and then ramp to 3.2uV and stay, until they drop as previously mentionned, and repeat.

Tyler

[exe]

I have attached a screenshot of a 12Hr log using testcontroller and my DMM6500.

May I suggest expanding vertical axis? Otherwise it mostly displays empty space. Anyway, looks quite comparable to what I have from TEN399+DMM7510.

[TylerPeppy]

I have attached a screenshot of a 12Hr log using testcontroller and my DMM6500.

May I suggest expanding vertical axis? Otherwise it mostly displays empty space. Anyway, looks quite comparable to what I have from TEN399+DMM7510.

Good point. I will do this and add more thermal data for the next handful of runs, along with a ppm readout.

[iMo]

Those STD(30) averages above - ie. like your 2.5-2.9uVrms (that is 16-19uVpp) are say ~2-3x higher as I would expect from such a DMM and DUT.
The ADR1399's (your DUT) noise I saw here (4 samples, 0.1-10Hz) was in a range of 1.7-2.5uVpp.
The LM399s (your DMM ref) have got typically 4-5uVpp (many samples incl. clones).
PPS: when I sum up the ADC_6500 + ADR1399 + 399 noises I get 1.12uVrms that is the value I would expect.

PS: if you perhaps have voltages in a .csv file (ie. a .csv file containing a column with the raw voltages and we need your sampling period too), post it here, we may look at the ADEV/MADEV.

PS: the schematics - is the voltage from the LDO clean (oscillation), is the TVS at least 2-3V higher than the 10V?
I would decrease the R11 value such the "Iz" flowing through it is say 3.4mA (like 820-870ohm).
Also you may try to use R10=10k (provided the LT5400 divider is 2k/4.5k).
 

[Kleinstein]

Especially for the LM399 the 30 seconds Std is a pretty poor choice. Much of the LM399 referenceis popcorn noise with a time between jump often in the range of aroudn 1min. So one has a good change to find 30 second intervalls without a jump and other may have 1 or 2. And depending on the ratio for the high and lower level a variing Std.

Likely the DMM6500 just has higher noise, than one may expect.

With my DMM (rather low noise, but still only a LM399 reference) I actually got some 1.1 µV_RMS for the sample graph (with 16 x 1 PLC per point). One can see the jumps to a lower value for rather short times. These are from the LM399 reference of the meter. The dift in this case is still warm up of the reference part. Still expect most of the noise to be from the LM399. ADC noise would be only a small part (0.13 µV).

[TylerPeppy]

Those STD(30) averages above - ie. like your 2.5-2.9uVrms (that is 16-19uVpp) are say ~2-3x higher as I would expect from such a DMM and DUT.
The ADR1399's (your DUT) noise I saw here (4 samples, 0.1-10Hz) was in a range of 1.7-2.5uVpp.
The LM399s (your DMM ref) have got typically 4-5uVpp (many samples incl. clones).
PPS: when I sum up the ADC_6500 + ADR1399 + 399 noises I get 1.12uVrms that is the value I would expect.

PS: if you perhaps have voltages in a .csv file (ie. a .csv file containing a column with the raw voltages and we need your sampling period too), post it here, we may look at the ADEV/MADEV.

PS: the schematics - is the voltage from the LDO clean (oscillation), is the TVS at least 2-3V higher than the 10V?
I would decrease the R11 value such the "Iz" flowing through it is say 3.4mA (like 820-870ohm).
Also you may try to use R10=10k (provided the LT5400 divider is 2k/4.5k).
 

To answer your first question, the TVS is 12V VWM, 19.9V Clamp. It should be fine I would think for this application; but it is possible I am forgetting something. I may try to increase Iz as well at some point; but I will only change one thing at a time to avoid having too many contributing sources to the output. The R10=10k I have the parts for, but they are not low TC resistors, which could potentially cause another source of error?

I only have 10NPLC, 10 sample moving averaged data for now. I can get some raw voltages without any filtering for a 15min period if that is what you are expecting.

Edit: I have attached some data here for a 340 min test at the 144hr mark of the burn in for my ADR1399s. The ambient temperature data is also included. I have included the data collection settings in the XLSX. Samples are logged every 3s, but 10NPLC w/ 10x Moving Avg. filter is used.

Thanks,
Tyler

[iMo]

This below .zip is enough for ADEV.
Your sampling period - hmm, I do not know how to handle it. Say let us start with 3secs.
I would call the ADEV an "Inverted ADEV" 

Best would be to have the raw voltage data coming from the DMM, no filters, no averaging, simply 10PLC or 100PLC, AZ ON.

@Kleinstein: your 399 is an absolutely crazy beast. From my 399 collection such frequent jumps does perhaps one.. OMG!

[TylerPeppy]

This below .zip is enough for ADEV.
Your sampling period - hmm, I do not know how to handle it. Say let us start with 3secs.
I would call the ADEV an "Inverted ADEV" 

Best would be to have the raw data coming from the DMM, no filters, no averaging, simply 10PLC or 100PLC, AZ ON.

@Kleinstein: your 399 is absolutely crazy beast. From my 399 collection such frequent jumps does perhaps one.. OMG!

I will gather some more raw data for you. My power just conveniently went out, and my battery backups are offline. I can't get 100NPLC, so 10NPLC raw. As for the 3 second thing, I will set the log interval to the same as the sample rate.

[iMo]

YES!!
The raw voltage data MUST be with the DMM's sampling period, nothing in between shall manipulate the data or the sampling period !!!!
Set PLC as you wish, but the data must be logged in that PLC sampling period (like with 10PLC each 166.7ms a new voltage is logged in your case, afaik).
No need for time stamps etc, just the raw voltage data as you may see in the zip file in my above post.

[TylerPeppy]

YES!!
The raw voltage data MUST be with the DMM's sampling period, nothing in between shall manipulate the data or the sampling period !!!!
Set PLC as you wish, but the data must be logged in that PLC sampling period (like with 10PLC each 166.7ms a new voltage is logged in your case, afaik).
No need for time stamps etc, just the raw voltage data as you may see in the zip file in my above post.

I have attached 134min worth of raw data. These measurements were taken with 10V range, 10PLC, no filtering, AZ ON. Testcontroller logged every 166.67ms, or 10PLC. Please see attached. I will also do some investigation with timelab.

Tyler

[iMo]

ADEV/MADEV DMM6500 10PLC with ADR1399_10V DUT 10PLC (167ms)
A comparison with my best ADEV (my34401B vs myADR1001#1 10PLC)

[Kleinstein]

The curve from the pimped HP34401 can be close to the LM399 noise, though it still includes some ADC noise, that could be significant for the shorter times.
The curves with the DMM6500 still show mainly the DMMs amplifier noise for times up to some 100 seconds. So not much reference (LM399) noise visible at all. The DMM6500 has the unusual shape in the ADEV, likely from 2 parts: one is averaging for auto zero and the other is a background correction of the ADC gain drift from internal reference measurements. The gain correction can help with long term drift and TC, but gives extra noise in the 10-50 s range. The AZ averaging helps with very short times (< 1s), but hurt with longer time nosie.

@Kleinstein: your 399 is an absolutely crazy beast. From my 399 collection such frequent jumps does perhaps one.. OMG!

I don't think the LM399 is that special. I have 2 other that behave similar, though with longer times at the upper voltage and 1 LM399 that is much slower (like 1 jump per hour). The step size (some 3-4 µV) is typical.
The meters like the DMM6500 or 34401 just have more noise, so that the jumps are not visible - they are very likely also there.

[iMo]

You do not see the 399/1399 jumps while looking at the DMM display (as they have 10uV resolution, at least the 34401), but you see it nicely if looking at the serial/gpib data..
We really need to craft a dedicated "jump counter" for say 4-8 chips..

PS: pimped 34401A - "34401P" 

[TylerPeppy]

ADEV/MADEV DMM6500 10PLC with ADR1399_10V DUT 10PLC (167ms)
A comparison with my best ADEV (my34401B vs myADR1001#1 10PLC)

This is very interesting. I now see what Kleinstein is mentionning that the DMM6500 has a very odd shape for ADEV. I think the easiest way to truly measure the noise for this is to use some filtering, but I am interested to see how it performs on Josh's 34465A. If I had the money, I would grab a 34465A or 34401A, but sending this to someone who can measure it better might make more sense for the time being.

I have also considered retrofitting an ADR1399 into my DMM6500 to lower the noise, but that's a project for when my warranty expires... I had considered a Keithley 2001 at one point, but I've heard those are a similar story to the noise on the newer Keithleys. For longterm logging, it might be interesting to see what happens when the AZ is turned off, and more averaging is used.

Tyler

[Kleinstein]

The extra noise hump from AZ averaging and likely background gain measurements seems to be common to Keithley meters (K2001,2002,2010,2182, DMM6500, DMM7510). This a bit of a pitty as this makes poor performance in the AZ mode, just for the time scales like 5s to 200s that are commonly used for simple precision tests. In non AZ mode the Keithley meters generally work well, but that is still not good for the longer times.
Ideally Keithley would offer a firmware update to offer an alternative simple HP like AZ mode for lower noise at the cost of slightly higher drift. I would no longer expect this for the old meters like 2001 or 2002, but maybe some hope for the DMM7510 and DMM6500.

The easiest way to check a good reference like the ADR1399 is to have 2 of them and look at the difference. This is perfect for the noise, but leaves TC and long term drift as additional effects to check.

[TylerPeppy]

The extra noise hump from AZ averaging and likely background gain measurements seems to be common to Keithley meters (K2001,2002,2010,2182, DMM6500, DMM7510). This a bit of a pitty as this makes poor performance in the AZ mode, just for the time scales like 5s to 200s that are commonly used for simple precision tests. In non AZ mode the Keithley meters generally work well, but that is still not good for the longer times.
Ideally Keithley would offer a firmware update to offer an alternative simple HP like AZ mode for lower noise at the cost of slightly higher drift. I would no longer expect this for the old meters like 2001 or 2002, but maybe some hope for the DMM7510 and DMM6500.

The easiest way to check a good reference like the ADR1399 is to have 2 of them and look at the difference. This is perfect for the noise, but leaves TC and long term drift as additional effects to check.

I built 3 of them, so will have to do something of the sort.

Tyler