Method to quantify/determine the "drift" of an analog voltage input?

[DoctorAutomatic]

I'm working on a project involving acquisition of data from a single sensor who's output is analog voltage that I'm reading with a USB-6001 DAQ.

One peculiarity about this sensor is that it needs to be polarized, which settles the output voltage, before taking accurate measurements. If it isn't polarized there is a gentle drift of the voltage. If the sensor hasn't been used for a few days and did not remain connected to its amplifier, the polarization process can take 3-4hrs, so I'm told. Otherwise, it's ready for measurement right away. 

I've had some hands on time with it and can observe this drift pre-polarization.

When I say 3-4hrs, this is somewhat an arbitrary worst case, in practice an operator will encounter times much shorter depending on recent use. In other words, planning to always allow 3-4hrs, "to be safe", is highly undesirable.

So, what I'd really like is a way to quantify this drift so that we can basically say that once it drops to a certain point the sensor is ok to use.

I'm unsure of what is a good way to do this and imagine folks with vastly more experience acquiring sensor data have a term for this and experience dealing with such a task.

My first thought was standard deviation. But I simply don't know if that's appropriate for this sort of thing. I also wouldn't really know over what time period I should calculate the standard deviation or even if the time period should be somewhat dynamic.

I'm really hoping I don't need to do a bunch of lengthy empirical tests and that there's someone here who can explain to me some sort of best practice that is industry standard so I don't need justify my own method or reinvent any wheels.

So, I'm curious to hear how any of you would go about this problem or any past experiences that are related. Thanks. 

[mcduff]

Look up the Allan Variance, used initially to characterize atomic clocks, but also great for characterizing sensors. 

[Bob_Schor]

You describe your device as having a "drift" if it is "polarized".  How do you know if there's a drift?  One method that (naively) occurs to me is that you provide a constant input (maybe simply "shorting" the input, which should give you a constant output) and measure the output over some convenient period of time (say, 10 minutes).  Now, "model" the output as a linear function of time (you don't expect it to go up and down, like a sinusoid, but to be constant, maybe with a "drift", which will show as a slope of a best-fitting line).

If you have had Statistics, Probability, or some College (or good High School) Math, you should understand how to fit a straight line to sampled data (including how to use "Least Squares" to get estimates for the Slope).  Once you have the Slope (a measure of "drift", you can ask the statistical question "Is the Slope significantly different from 0?"  If "Yes", keep waiting (and taking a new sample of data and re-estimate Drift).

This can be an instructive exercise in Statistics, curve fitting, and other useful topics.  Best of all, LabVIEW (being a very User-Friendly programming language) makes it easy to write a VI that generates sampled data that is based on a known amount of drift, then you can feed this "known" data into your "Drift-evaluating" routine to verify that it works.  A fun project ...

Bob Schor

[mcduff]

You want to use the Allan Variance for this; it was designed for this problem. Here is an extremely simplistic explanation of it:

Imagine you have a time series of data points, lets say some sort of analog input voltage measurements. There is nothing, ie no signal, in the input, just noise. You acquire 100 million points. Now you divide that set of 100 million points into groups of 10, 100, 500,1000, and so on. For each group you take the variance. If your system only has white noise you expect as each data group becomes larger, the variance decreases. In signal processing, you learn that you can decrease the noise by averaging the data; the noise reduction goes as the square root of the number of averages. Similarly, the variance decreases as the number of points increases. Signal theory tells us that if we average forever, the noise will decrease. However, real systems are not perfect, there is always some low frequency drift. So if you compute the Allan variance for a real system, you will see at some time the variance does not decrease, it increases. Thus averaging for a longer time can actually give you a worse answer. The slopes and curves in an Allan Variance plot can also give you information about the other types of noise in a system. It seems like it was tailor made for sensor characterization.

[altenbach]

While the Allan Variance is a great tool, it seems overkill here. You have drift, i.e. a slope that probably settles exponentially to a steady state value. You also have noise. How much noise?

Statistically you have a drift in the mean while the local standard deviation (i.e. noise) is constant. Standard deviation is useless to measure drift.

To measure the recent slope in the data, you could just feed the value through a ptbypt linear fit with a reasonable history size (based on noise, typical settling time, and sampling rate, etc.).

If your trace is long enough and shows it exponentially approaching a steady state value, you could even do an exponential fit and guess by extrapolation at what future time the settlement will be sufficient. 

[mcduff]

---

@altenbach wrote:

While the Allan Variance is a great tool, it seems overkill here.

---

Maybe. There is LabVIEW code here; have not tested it. But if it works, all you have to do is take some data for a little while and your answers will be evident.

[altenbach]

---

@mcduff wrote:

---

@altenbach wrote:

While the Allan Variance is a great tool, it seems overkill here.

---

Maybe. There is LabVIEW code here; have not tested it. But if it works, all you have to do is take some data for a little while and your answers will be evident.

---

Holy Rube Goldberg!!!!

(Deeply stacked sequences everywhere, most frames with interactive loops, just one downward spiral with no way to go back, sequence locals forcing backwards wires. Highly inefficient constant array resizing, datatype mismatches, DBL 2^x instead of arithmetic shift, etc. While it is probably correct, I'd probably write my own. 😄 )

[mcduff]

---

@altenbach wrote:

---

@mcduff wrote:

---

@altenbach wrote:

While the Allan Variance is a great tool, it seems overkill here.

---

Maybe. There is LabVIEW code here; have not tested it. But if it works, all you have to do is take some data for a little while and your answers will be evident.

---

Holy Rube Goldberg!!!!

(Deeply stacked sequences everywhere, most frames with interactive loops, just one downward spiral with no way to go back, sequence locals forcing backwards wires. Highly inefficient constant array resizing, datatype mismatches, DBL 2^x instead of arithmetic shift, etc. While it is probably correct, I'd probably write my own. 😄 )

---

Probably should have looked at the code before giving the link. 🙂

[JÞB]

Another approach ( and I won't certify that it is best) would be to simply run EACH acquisition through a FFT.  The slope or freq, of your drift will converge to 0 hz as the sensor settles and the magnitude of the first bin (where freq = 0 to 1/sample length) will rise as the sensor "polarizes."  This gives you the ability to take quicker Acquisitions for rough tuning then increasing the sample time for greater resolution of low drift rates.  A partially settled sensor would blow through the rough drift quickly while a Cold sensor would take longer.  Graphing the FFT output would even indicate progress to a user so they see the time isn't really wasted.