ADC Sampling Breakthrough - Page 39 — Parallax Forums

• Posts: 13,722
edited 2018-12-19 04:29
Omigosh. I can't believe this whole thread has been based on the fiction that you can make a silk purse from a sow's ear! If you're counting bits in a 64-bit window, it doesn't matter how you weight them, you simply cannot get more than an honest six-bit resolution from that window. Granted, you'll get a zillion more different values, depending upon how those 1's and 0's are distributed and weighted. But they don't mean anything as far as what a legitimate 8-, 12-, or 16-bit value would be at any point in time. That data is lost with every bit that disappears from the end of the shift register. I'm sorry, but the math (i.e. information theory) doesn't support the premise of this thread, and I really think -- actually know -- that you guys are deluding yourselves. The output from the filter might look pretty, but it's totally meaningless.

-Phil

You're saying, also, that Sinc3 is a fiction. It's even way better than a Tukey window. It's real. All real. Not fake.
• Posts: 23,342
edited 2018-12-19 05:15
Look at it this way: a bit gets shifted into the shift register from the comparator. Maybe, at that point, it gets a weight of one. Further down the line, it gets a higher weight. But what original principle imbues that bit with more weight? Why does it deserve more or less weight, depending upon where in the shift register if exists? It's almost as if you're treating bits as having more resolution than one bit. A bit is a bit, and those bits arrive at the shift register by a completely stochastic process. The information they contain is solely a function of how many of them in a 2n-bit window are ones, and that information cannot exceed n bits, no matter how you massage it.

Sinc3 and Tukey are certainly legitimate for filtering, if they're applied to ADC-converted numerical data in FIR filter fashion. But you can't expect them to have any legitimacy when applied to a bitstream if you're trying to squeeze more resolution out of it than the original stream supports.

Now, I will agree that if you're trying to smooth data in a 64-bit shift register using one of these filters, it's fine if you output a 6-bit result. But more resolution than that? No way.

-Phil
• Posts: 14,950
cgracey wrote: »
You're saying, also, that Sinc3 is a fiction. It's even way better than a Tukey window. It's real. All real. Not fake.

Yes, real enough, that TI includes 8 Sinc3 filters inside every high end DSP they make...
Designed to talk to external 16(+) bit ADCs, that TI and others make. ( eg http://www.ti.com/lit/gpn/amc1035 )

Notice tho, that these filters do have the settling time effects, so they do not multiplex well, which is why TI includes more than 1 (and more than 6 covers 3 phase + supply sense)

It will be good to see the results of an AMC1035 connected to a P2 (FPGA), as that should prove the end to end operation.
• Posts: 2,995
Phil,
I have been wondering about the same thing.

Chip,
Instead of using sine waves and whatnot, why not use some audio recording, some music, and see what it sounds like after the filter. My guess is awful.
• Posts: 23,342
Here's another way to look at it: let's say the input is Vdd/2 and that there is no noise. Ideally, the bitstream would look like 1010101010... In any 64-bit window, there will be 32 one bits. Now lower the input by 1/256th of full range. Most 64-bit windows will still look like 1010101010..., but every once in awhile one window will include an extra one bit. But the windows that have 32 one bits are still only worth Vdd/2, no matter how those bits are weighted. To get the full 8-bit resolution, you have to count the ones in a window 256 bits wide.

Chip, remember the data compression experiment you tried as a kid? What you're trying to do here isn't that much different.

-Phil
• Posts: 13,722
Here's another way to look at it: let's say the input is Vdd/2 and that there is no noise. Ideally, the bitstream would look like 1010101010... In any 64-bit window, there will be 32 one bits. Now lower the input by 1/256th of full range. Most 64-bit windows will still look like 1010101010..., but every once in awhile one window will include an extra one bit. But the windows that have 32 one bits are still only worth Vdd/2, no matter how those bits are weighted. To get the full 8-bit resolution, you have to count the ones in a window 256 bits wide.

Chip, remember the data compression experiment you tried as a kid? What you're trying to do here isn't that much different.

-Phil

It's real.
• Posts: 394
forums.parallax.com/discussion/comment/1457413/#Comment_1457413
lonesock wrote: »
That's very cool! For the second order, could you please try this code? (I don't have a board with an ADC on it atm.)
```              ' quadratic, 16 clocks per iteration, 4 groups of iterations
' N1 = (sample_period - overhead) / 16 / 4
' N2 = 2 * N1
' N3 = N1
mov       accum, #0

djnz      N1, #:accelloop1

sub       accum, #1
djnz      N2, #:decelloop2

djnz      N3, #:accelloop3

mov       frqa, #0
```
thanks,
Jonathan
```    Triangle     Rectangle
Mean   1164.5     1166.5
Std       0.20081    1.51132
relative_noise =  0.13287

Mean   1171.0     1173.3
Std       0.16607    1.59741
relative_noise =  0.10396
N1=N3=64
N2=128  This was to get a 12 bit result from the rectangular window.
```
These tests were done with the window function on CTRA, rectangular window on CTRB for control measurements. The integration time for the rectangular window is just slightly longer, but only by a few clock cycles. Otherwise the measurements were taken at the same time using identical data. It works in practice.
• Posts: 23,342
cgracey wrote:
It's real.
No, it's not -- unless I'm completely misunderstanding the process. Let's look at it from a state-theoretic standpoint. The state of a FIR-filtered system (which I believe is what this discussion is about) is completely defined by the contents of its shift registers, be they one bit deep, or sixteen bits deep. It doesn't matter what coefficients are applied to each element; the entire state, at any point in time, exists solely in the shift registers.

In a one-bit deep, 64-bit wide shift register, there are 264 possible states. But because of the way the data in those 64 bits are generated, any state with, say, 47 one bits is equivalent to any other state with 47 one bits. So there are really only 26 computationally distinct states. But by artificially weighting the individual bits differently, you seem to be allowing for more than 26 distinct states. But this is a fiction introduced by the weighting factors and does not increase the number of real states possible in the data. No matter how you toss it, 26 distinct states will give you 64 distinctly meaningful data values and no more than that.

-Phil
• Posts: 14,950
Here's another way to look at it: let's say the input is Vdd/2 and that there is no noise. Ideally, the bitstream would look like 1010101010... In any 64-bit window, there will be 32 one bits. Now lower the input by 1/256th of full range. Most 64-bit windows will still look like 1010101010..., but every once in awhile one window will include an extra one bit. But the windows that have 32 one bits are still only worth Vdd/2, no matter how those bits are weighted. To get the full 8-bit resolution, you have to count the ones in a window 256 bits wide.

Take a look at the AMC1035 data.
With a 21MHz CLK, .... When used with a digital filter (such as integrated in the TMS320F28004x, TMS320F2807x or TMS320F2837x microcontroller families) to decimate the output
bitstream, the device can achieve ~16 bits of resolution with a dynamic range of 87 dB at a data rate of 82 kSPS.

( an ideal 16b is -96dB )

21M/256 = 82031.25, & TI's curves and data, show ~16b results, from what appears at first glance to be 256 bits, but note it does not get the final result in one 256 pass.

• Posts: 23,342
jmg wrote:
... but note it does not get the final result in one 256 pass.
Of course not. To get 16 bits resolution, you'd need 256 passes. Not sure how that applies here, though, since I believe we're talking about getting higher-res values in one summation of the bits multiplied by their coefficients. Right?

-Phil
• Posts: 13,356
Phil,
You are totally correct that all that is being done is scaling the bit sizes. If looking at just the centre bit-time of the window, it would look like an output of 0 or 256. Nothing in between.

• Posts: 1,485
edited 2018-12-19 06:46
Somebody should input various complex signals, such as maybe low-pass-filtered white noise synthesized via an inverse FFT fed with random inputs on the frequencies below something like the max filter frequency and zero inputs at frequencies higher than that, and compare the FFT of the result with that of the original. These fancy filters can't magically create more information, but they do move it around in ways that are generally useful. I think it has to be the case that lower frequencies will have an ENOB of more than log2(samples), and that higher frequencies will have an ENOB less than that than that, and that the average ENOB will be log2(samples).
• Posts: 729
There is more information than just a certain number of ones and zeroes.

Are the quantity of ones increasing right now? -that's additional information.

Is it the case that not only the ones are increasing, but in addition right now they are increasing at an increasing rate? -that's yet more information.
• Posts: 13,722
edited 2018-12-19 07:14
Phil, I think this all has something to do with the fact that the data coming from the ADC is cyclical. It absolutely DOES matter what the order of the bits is. In working with bitstreams at the start of the thread, I noticed that perturbing the order of the bits from the ADC had disastrous consequences on the output quality. They have to remain in their order as they pass through the side lobes, in order for this windowing to work. That's where the fractional bit values come in that boost the resolution. And those lobes must be longer than the data cycle of the ADC bitsream. There is some reason why this works. And if you think it doesn't work, how can you explain the picure I posted tonight? You can clearly see that the resolution was better than 8 bits, as the values don't jump around until they get close to the next step. This works for sawtooth patterns, too. You can clearly see 8 bits of steps in a very linear ramp. How is that happening? There is some reason why this works.
• Posts: 13,356
whicker wrote: »
There is more information than just a certain number of ones and zeroes.

Are the quantity of ones increasing right now? -that's additional information.

Is it the case that not only the ones are increasing, but in addition right now they are increasing at an increasing rate? -that's yet more information.

I suspect Sinc3 has those properties. And as such also exhibits a faster impulse response.

I don't think the other filters are doing anything more than scaling a window though. For them it all comes down to shape, width, and move distance.

• Posts: 1,485
edited 2018-12-19 16:44
cgracey wrote: »
Phil, I think this all has something to do with the fact that the data coming from the ADC is cyclical. It absolutely DOES matter what the order of the bits is. In working with bitstreams at the start of the thread, I noticed that perturbing the order of the bits from the ADC had disastrous consequences on the output quality. They have to remain in their order as they pass through the side lobes, in order for this windowing to work. That's where the fractional bit values come in that boost the resolution. And those lobes must be longer than the data cycle of the ADC bitsream. There is some reason why this works. And if you think it doesn't work, how can you explain the picure I posted tonight? You can clearly see that the resolution was better than 8 bits, as the values don't jump around until they get close to next step. This works for sawtooth patterns, too. You can clearly see 8 bits of steps in a very linear ramp. How is that happening? There is some reason why this works.

Can somebody do a frequency sweep of the thing and make a plot of ENOB vs. frequency? It should be great at low frequencies and not so great at higher frequencies.

EDIT: Sorry, SaucySoliton has been posting such plots of each filter. Maybe I should stop pretending I know what I'm talking about now and start paying more attention (and not post at 2am).
• Posts: 2,590
Roy Eltham wrote: »
Phil,
I have been wondering about the same thing.

Chip,
Instead of using sine waves and whatnot, why not use some audio recording, some music, and see what it sounds like after the filter. My guess is awful.

All the Audio SigmaDelta ADCs and DACS work with a 64 x fs bitclock, so they should only be good for 6 bit resolution. But they can do 16..24 bit depending on the internal digital processing.

I expect a good audio quality from the P2 ADCs, thanks to the Sinc3 filter mode.

Andy
• Posts: 13,722
edited 2018-12-19 07:20
Ariba wrote: »
Roy Eltham wrote: »
Phil,
I have been wondering about the same thing.

Chip,
Instead of using sine waves and whatnot, why not use some audio recording, some music, and see what it sounds like after the filter. My guess is awful.

All the Audio SigmaDelta ADCs and DACS work with a 64 x fs bitclock, so they should only be good for 6 bit resolution. But they can do 16..24 bit depending on the internal digital processing.

I expect a good audio quality from the P2 ADCs, thanks to the Sinc3 filter mode.

Andy

Ariba, how can DACs exploit these concepts. Seems to me that a DAC goes to a value and sits there, or maybe toggles between two adjacent values, in order to get more resolution.

We've got 8-bit DACs. What can we do with them to really boost their resolution in short order? This must be a matter of dithering, but in what way, exactly?

With the right filter, we should be able to get a 1-bit DAC to be CD-quality. But how would it work?
• Posts: 2,590
edited 2018-12-19 08:02
It works the same as an analog modulator, just do the comparator and the filter digital. The comparator output is the modulated bitstream. For the LP-filter use the R-C filter emulation you have already tried. I've done that in an FPGA with good results. But there are other ways to do it which follow more the sigma-delta theorie. Will post a link when I found it..

Edit: Because we have already an 8bit DAC, you can do that deltamodulation only for the lowest bit of the DAC and need then only an 8bit comparator and filter.
• Posts: 1,694
there is a question: is existance if not tested? Is there a pea in a box if the box is covered? The idea behind is the duality of object and observer. It doesn't matter if something exists, if nobody takes care about. Like: it doesn't matter, who is your president, if you don't care and nobody else.
So: the filter we apply wants to separate a signal from noise. That only makes sense, it we decide in advance what is the signal and what is noise. This knowledge allows us to improve the measurement, so the bits do not come from witchcraft.
On the other hand: we have an incoming bitstream. If we integrate over a given time the result is independent of the order of the single bits, so we lose information. The filters we tested take care of that information by counting in an overlapping way the number of bits in smaller segments, so the information is kept, But it makes no sense to "create" more information than actually exists.
As an result: if you understand the problem, you can find the optimal solution. If you see a signal with a gaussian distributed noise, the best idea is: the noise is created by the signal source to 50% and by the detector to 50%, both of those are gaussian to with a smaller standard deviation (1/sqrt(2))
• Posts: 2,590
Here is alink to a more scientic approach of a SigmaDelta DAC:
https://github.com/YosysHQ/yosys-bench/tree/master/verilog/benchmarks_large/sddac

Andy
• Posts: 13,356
With an appropriate analogue filter, it should be possible to use upper 8 bits of 16 bits to do the dither modulation into the flash DAC msbit, with the lower 7 bits of flash DAC output providing finer analogue detail on top.

But this is frequency capped at the trade-off of dither period vs depth extension. The analogue filter is case dependant.

• Posts: 2,995
Can you run an audio signal with some music through it, and see what it sounds like on the other side?
• Posts: 13,722
edited 2018-12-19 09:11
Roy Eltham wrote: »
Can you run an audio signal with some music through it, and see what it sounds like on the other side?

That would be a good test. The accessory boards for the P2 Eval board will cover this. One of them has stereo line-in and line-out RCA jacks, as well as headphone amp and jack, and microphone jack. The RCA's can be used for video, too.
• Posts: 1,235
Sorry -
if I repeat myself (but maybe I am totally wrong? - this is how I understand it right now)

All/Most? of the Sigma-Delta-ADC chips you can buy using those Sinc3 filters
are based on higher order MODULATORS.

The WORK is really done there in the MODULATOR called noise-shaping.

And it is not about any noise in the signal, but to reduce the noise introduced by the quantization process itself. The SincN filter is usually? chosen one order higher than the modulator. As a low pass to remove the quantization noise that has been moved to the higher frequencies. But this also means the signal before the filter is inherently noisy, which is not what we see as the assumption below.

What helps smooth out the signal Chip is showing, is the WINDOWING effect
which gives the few first and last bits less value, thus reducing the additional noise created when the 'noise free' signal moves through the shift register.

'noise free' here means your signal is e.g. 8 bits '01111111' continuously repeated. This introduces a 1 bit noise when moving through a shift register which is not a multiple of 8 long. Btw: '01111111' as a sequence is not an 8 bit signal - it is a 3 bit signal ;-).
The weighting of the bits in the windowing filter and then only using the upper bits results in the smoothing effect that Chips scope is showing.
So you are not actually getting a better signal - you are just not adding so much additional noise to it.

my 1 cent

• Posts: 13,356
That's all correct but the quantising noise is just another noise source. The Sinc3 filter, or any of the low-pass filters we're testing here are removing all those higher frequency noise sources, combined.

The "noise-shaping" is inherent to any sigma-delta modulator, a key feature is shifting the Nyquist point way up the spectrum to keep it well away from operating frequencies. So, pushing hard for maximum output sample rate on the filters, closing in on the bitstream rate, is also closing the gap to the Nyquist point.

• Posts: 23,342
edited 2018-12-19 16:58
cgracey wrote:
It absolutely DOES matter what the order of the bits is.
That implies that the bits have inherent weighting, and each carries more than one bit of information due to that weighting, correct? If so, that further implies that some sort of framing is necessary to determine which bits have which weighting. And that all boils down to determining the optimum time to take a sample from the weighted shift register. Otherwise, if you sample on every clock, say, each bit receives all possible weightings as it passes through the shift register. So how do you do the framing, i.e. determine when to take a sample?

-Phil
• Posts: 13,722
edited 2018-12-19 17:29
cgracey wrote:
It absolutely DOES matter what the order of the bits is.
That implies that the bits have inherent weighting, and each carries more than one bit of information due to that weighting, correct? If so, that further implies that some sort of framing is necessary to determine which bits have which weighting. And that all boils down to determining the optimum time to take a sample from the weighted shift register. Otherwise, if you sample on every clock, say, each bit receives all possible weightings as it passes through the shift register. So how do you do the framing, i.e. determine when to take a sample?

-Phil

You know a sample comes in every clock. The side lobes are symmetrical. The filtering happens as the bits ramp up and ramp down on either side of the plateau. You can look at the scope picture and see that it works. I don't know what greater proof there could be.
• Posts: 12,717
This is an interesting topic. Can you really get 8-bit precision with 70 bits?

The scope picture appears to be several overlapping waveforms.
That's similar to averaging several samples, so not entirely clear.

Looks to be at least one bit of uncertainty there, right?

Be interesting to see a single shot capture.
Maybe it's really 2-bits of uncertainly? Then, 70 bits makes sense...
• Posts: 23,342
edited 2018-12-19 18:08
Perhaps I'm not understanding what a "sample" is. I had assumed that, on every clock, one bit enters the shift register from the comparator and marches through the shift register until it exits the other end. In the process, it gets multiplied, in turn, by each of the weights. The ADC value, then, at each clock, is the weighted sum of whatever bits are in the shift register at any particular time. Is that not correct?

-Phil