| Newsgroups |
gmane.comp.hardware.texas-instruments.msp430.discuss |
| Organization |
Infinite Factors |
| Message-ID |
<[email protected]> |
On Mon, 14 Sep 2015 07:21:42 +0000 (UTC), you wrote:
>"Jon Kirwan [email protected] [msp430]" <[email protected]>:
>
>> On Sun, 13 Sep 2015 23:08:19 +0000 (UTC), you wrote:
>
>>>Isn't it possible to just "pause" the sampling of the delta sigma
>>>converter (let it sleeping, all registers keep their values) and awake
>>>it after 100ms with nearly the same input level as before the sleep?
>>
>> I haven't seen one work like that. They are basically very
>> fast "1 bit" converters with a lot of state behind it. It
>> takes a long time for those "bits" to fill the state. Once
>> you get the pipeline filled up, you can get very precise
>> values at a fairly reasonable rate.... if it is still
>> attached to the same input which is "drifting" around the
>> nominal value at less than some specified rate. But the
>> sample rate is based upon an ALREADY FILLED pipeline. You
>> have to fill it before the first value is really any good.
>> You can find out how long it takes to fill the state and, in
>> my limited experience, that will take a LOT LONGER than the
>> specified sample rate for the unit.
>
>The question is: how does the decimation filter work. In case it is working
>like a FIR, then it should be filled after a fixed time and I should ne able
>to find out, how long it take, in case it is a IIR, well then the fill-time
>is not really fixed....
It's NOT an IIR. I don't know the details, because I haven't
taken the time to do more than read the occasional discussion
from manufacturers. But I do know that it is more like an FIR
+ some stuff that "shapes the noise" where possible to push
it into higher frequencies, so that it can be nicely cut off
in the digital filters.
It is this "noise shaping part" that I feel is a uniquely
added concept to an FIR. So it's not exactly an FIR, as I
ignorantly see it. I believe some smart person worked out a
method, looking over the 1-bit converter process, that could
help push the shape of the normal distribution of noise so
that it's a somewhat distorted distribution. But as I said,
I'm ignorant about the details.
>>>The sd24_a input is
>>>just a 18pF capacitor. The 350ohms will charge it quickly...
>>
>> Hehe. That's true. Have you computed your expected S/N for
>> the analog portion of the input system, yet? Just curious.
>
>No, not yet. :-) Maybe the noise from the resistors will be quite large and I
>have to add additinal capacitance to get it lower? I am not experienced with
>calculating noise figures, but surpricingly according to
>
>https://en.wikipedia.org/wiki/Johnson%E2%80%93Nyquist_noise
The following has almost nothing to do with the question at
hand, but I thought it would be worth writing out what I
understand of some basics, first.
There is a treatment of noise issues from resistors and
capacitors -- both are based upon the fundamental idea of
assuming an equipartion of thermal energy, 1/2 kT per
available vibrational mode (almost always a valid
assumption.)
Thermal noise is also "Johnson noise" in the early
literature, but as a hobbyist perspective I think Johnson
noise has become associated with resistor noise today.
Capacitor noise, though technically based on the same
mechanism but with a different resulting algebraic equation,
might also be called Johnson noise. But most reading I've
done doesn't use Johnson noise for that.
The electromotive force developed across the ends of a
conductor due to Thermal noise is unaected by the presence
or absence of direct current. Electron thermal velocities in
a conductor are much greater than electron drift velocities
by a factor of a 1000 or more. This means you don't worry
about current noise, as something inherent in the current,
unless it crosses a PN junction (diode.) If it does, because
this affects the above relationship of thermal vs drift
velocities, you get "shot noise" and you have to take it into
account. To add things, though, you have to put apples to
apples -- so it needs to be converted to an equivalent
voltage noise first or else visa versa.
There is also flicker noise. This in resistors depends on
manufacturing. But there is flicker noise in the base
junction of BJTs, FETs, and so on. In BJTs, flicker noise is
said to increase a lot if the BE junction is subjected to
repeated breakdown voltages (often, that value can be in the
area of 5-6V or so, which can easily happen in switcher
circuits where the base isn't well protected when turned
off.)
Back to the topic. Your input amplifier is responding to
voltage. So what you want is some kind of estimate of the
"equivalent voltage noise" as referred to the input (or you
could refer things to the output... but you don't control
what is attached there.)
I did a quick search. You might read this paper:
http://users.ece.gatech.edu/mleach/papers/AnalogNoise.pdf
Just get down into it a few pages and you'll see some
treatments there. I can't vouch for it, as I haven't read it,
but it seems to broadly cover the kind of analysis I was
wondering about.
The point here is that if you were using over-sampling to
achieve your 12-bit precision figure, then you'd want to set
your noise level (S/N) to about 2-3 bits WORSE than your ADC
specified precision. Noise tends to be Poison in nature,
which integrated looks like a Gaussian curve. And more
averaging of Poisson events narrows the skirts of the
Gaussian nicely, so averaging works in this case. But you
need noise to create that random walk process so that the
averaging can do its work. If you have too little noise,
averaging is pretty much useless in making things better.
So if you know in advance you will be averaging to improve
precision, you want to know that your noise is Poisson around
the "real value."
>it seems the noise in a RC system does not depend from R, just
>from C, and with 18pF it is 15uV/sqrt(Hz) and at 100nF it is at
>0.2uV/sqrt(Hz), and it takes (7*tau) 250us to stabilize.
>I am at 10Hz sample rate, so I think I do not have to add a sample and hold
>circuit to further reduce this time and increase accuracy..
In low pass filters, I think that is correct. (I don't recall
seeing an analysis for a high pass filter, so I'm reserving
judgment there.)
Because it is so "fast" with respect to your desired sample
rate, though, I think this is an argument for more filtering.
Here's my thinking.
You want a measurement period of 100ms. If you have a high
bandwidth input signal, it will move around a lot. This is
because everything is proportional to the square root of
bandwidth. A wider bandwidth means more probability at
distant skirts away from the real signal. And that is what
your ADC will be "seeing." (Now, again, none of this
necessarily applies to sigma-delta in quite the same way,
because of those "noise shaping" things they do that I don't
fully appreciate.) So without a sample and hold, you want as
much low pass filtering as you can get away with, consistent
with a fast enough response time that your input "settles"
before your next sample.
So, let's say you want your signal to settle to within 12
bits of precision between these 100ms samples. Let's say to
1/2 bit. With 12 bits, that's 1:8000, or so. Solving for
time, you want tau = 11ms. That is, if I got the calcs right:
tau = t / ln(8000) = 100ms / ln(8000) approx 11.1ms
Your tau is, therefore, too fast. Which means you are letting
in unnecessarily high noise.
But then, you are using a sigma-delta. So... I'm not sure how
that thinking should be modified.
>> I'm interested in what you find out. I think you already have
>> figured out enough to take a fair shot at it. Sounds like you
>> may be able to do just fine. [Personally? I'd have preferred
>> to use an ADC12 or ADC10 section and use over sampling to
>> achieve the desired resolution... after making sure that my
>> noise is where it needs to be (for an ADC12 the noise should
>> be about 1000 ppm or so, I think, and for an ADC10 perhaps
>> 5000 ppm; then use averaging to squeeze back down.)]
>
>I will give it a try; on last week I was still in the "find out how" phase of
>the project, now it is getting more and more out of the dust, it is nice to
>share ideas with you. :-)
Hehe. I'll learn, too. I probably said something (more than
one) stupid above and someone will correct me. Or you will.
And I'll gain a somewhat better understanding from that,
which is all to the good.
Jon
>
>Matthias
>
>
>
>------------------------------------
>Posted by: Matthias Weingart <[email protected]>
>------------------------------------
>
>To unsubscribe from the msp430 group, send an email to:
>[email protected]
>
>
>------------------------------------
>
>Yahoo Groups Links
>
>
>
------------------------------------
Posted by: Jon Kirwan <[email protected]>
------------------------------------
To unsubscribe from the msp430 group, send an email to:
[email protected]