ADC Sampling Breakthrough - Page 45 — Parallax Forums

• Posts: 13,554
TonyB_ wrote: »
cgracey wrote: »
TonyB_ wrote: »
cgracey wrote: »
I've got an 8x oversampling Sinc2/128 worked out that definitely puts out 8-bit samples every 16 bits that are the product of the last 256 bits.
decimation = 16
range = decimation*256

for iter = 0 to range-1

acc = acc + iter/range 'new ADC bit

if acc >= 1 then
acc = acc - 1
t = 1
else
t = 0
endif

inta = inta + t
intb = intb + inta

if iter/decimation = int(iter/decimation) then
sample = intb - dif7
dif7 = dif6
dif6 = dif5
dif5 = dif4
dif4 = dif3
dif3 = dif2
dif2 = dif1
dif1 = dif0
dif0 = intb
intb = 0
x = iter/decimation
y = pow(decimation,2)
s = int((sample+7)/8)
line x, y, x, y - s
'print int(sample/8)
endif

next iter

Comparing this to Sinc2 with integrators in hardware, differentiators in software and integrate and dump, there are 8x as many difX registers.

Yes, but this gives a true 8-bit sample every 16 clocks. You just do a RDPIN to get it, or the streamer can use it. Its frequency response is going to be poorer than a 64-tap window, but precision will be 8 bits, always.

My understanding is the sample output is a moving average of eight 32-clock triangular windows that are overlapped by 16 clocks and therefore each output is generated by 128 ADC bits.

What if only dif0-dif3 are used when decimation = 16?
Or dif0-dif3 or dif0-dif7 when decimation = 8?

I've been experimenting with those kinds of variations. I've reduced it down to 9 bits per term, instead of 11, by only propagating the diff's of the diff's, then running a moving average filter.
• Posts: 14,640
cgracey wrote: »
I've been experimenting with those kinds of variations. I've reduced it down to 9 bits per term, instead of 11, by only propagating the diff's of the diff's, then running a moving average filter.

A useful test when you have a short list of candidates, would be to plot the same ENOB curves as Rayman linked here
and see what dB/double slope you measure, for changes in oversample ratios.

Curious to see what effective order ADC modulator, the P2 has.

Ideal second order modulator is 15.05dB/double, (coupled to sinc3) and 1st order is 9.03dB/double, (coupled to sinc2?)
The number may be between 9.03 and 15.05 dB/double.

A plot of a stepped sawtooth, and showing the difference from ideal, will show the ADC delays and settling times, as well as the DNL.
Since this scope-mode is low resolution, the P2 DACs are probably good enough.
• Posts: 13,554
cgracey wrote: »
I'm thinking about a scope mode replacement that resolves DC better than 6 bits. We won't be able to get a sample every clock, but we can run different sets of acc2's and diff's for more frequent samples.

Why does scope mode need 8 bits?
cgracey wrote: »
I've got an 8x oversampling Sinc2/128 worked out that definitely puts out 8-bit samples every 16 bits that are the product of the last 256 bits.

It outputs a perfectly straight line within the ADC duty range.

Something's not right here. I'm getting a sinc1 step response. If you want a sinc2 it should be like this:

decimation = 16
range = decimation*256

for iter = 0 to range-1

acc = acc + iter/range 'new ADC bit

if iter >= 500 then
acc = acc - 1
t = 1
else
t = 0
endif

inta = inta + t

if iter/decimation = int(iter/decimation) then
intb = intb + inta
stage = intb - dif7
dif7 = dif6
dif6 = dif5
dif5 = dif4
dif4 = dif3
dif3 = dif2
dif2 = dif1
dif1 = dif0
dif0 = intb

sample = stage - bdif7
bdif7 = bdif6
bdif6 = bdif5
bdif5 = bdif4
bdif4 = bdif3
bdif3 = bdif2
bdif2 = bdif1
bdif1 = bdif0
bdif0 = stage

x = iter /decimation
y = pow(decimation,2)*2
s = int((sample+7)/2)
' line x, y, x, y - s
' print int(sample/8)
endif
x=iter
line x, y, x, y - s

next iter

Running intb at the reduced rate doesn't appear to change the step response. It could affect the high frequency rejection.

putting intb accumulation outside the busy loop doesn't seem to work. It seems to need to work along with inta.
• Posts: 1,553
edited 2018-12-22 15:08
Now, that I have a propeller on my desk, we could start to collaborate in doing experiments, as others will have the real silicon too. I wish to stream the comparator output to whatever ram and then apply the filtering stuff, preferably using TaqOz.
Many lessons have to be learned. First: what (besides TaqOz) is the preferable tool. My intention is not to use C to extend.
• Posts: 14,640
ErNa wrote: »
... First: what (besides TaqOz) is the preferable tool. My intention is not to use C to extend.

These maybe, seems to be in rapid development ? - Compiler for Basic/Spin/PASM and alpha-C

https://forums.parallax.com/discussion/168913/new-basic-compiler-for-prop1-and-prop2/p1
https://forums.parallax.com/discussion/164187/fastspin-compiler-for-p2/p1

• Posts: 3,340
I think the best bet is fastspin right now, you have spin/spin2, Pasm/Pasm2, Basic and to some extend C. No C++, yet.

Enjoy!

Mike
• Posts: 13,554
edited 2018-12-22 20:25
I've been working for 24 hours, simulating Sinc3 and Sinc2 filters. I've been slowly going in a giant circle, it seems.

Here is what I want to do:

- Implement the scope mode, as already designed, but limit the submodes to realistic numbers of bits, like 6 and 5. No need to worry about exceeding \$FF, anymore.

- Implement a Sinc2 mode for doing background conversions of 6/7/8/9/10/11/12/13 bits. Sinc2 is very low on logic and would afford a nice automated ADC mode.

Here is the Sinc2 code I will implement. It maintains two scrolling diffs that allow samples to overlap, doubling the sample rate. These Sinc2 filters are proven in this program to hit every possible value within the duty range, according to the bitstream coming in. The 13-bit mode registers 2..8190 without any missing codes. Phil would definitely approve of its soundness:
enob = 10     'effective number of bits 6..13

maxenob = 13
decimate = pow(2,enob-2)
divide = decimate/2

range = pow(2,enob)

acc = rnd   'expose flaws

for g = 0 to range

for iter = 0 to range*2

acc = acc + g/range 'new ADC bit

if acc >= 1 then
acc = acc - 1
t = 1
else
t = 0
endif

inta = (inta + t) band bitmask
intb = (intb + inta) band bitmask

if iter/decimate = int(iter/decimate) then

sample = int((((intb - dif0) band bitmask)+divide/2)/divide)

dif0 = dif1
dif1 = intb
intb = 0

if iter > range then circle 10+(g mod 256)*4 + int(g/256)*12, 10+((range-sample) mod 256)*4, 2 filled

endif

next iter
'print sample,

next g

• Posts: 14,640
cgracey wrote: »
I've been working for 24 hours, simulating Sinc3 and Sinc2 filters. I've been slowly going in a giant circle, it seems.

Here is what I want to do:

- Implement the scope mode, as already designed, but limit the submodes to realistic numbers of bits, like 6 and 5. No need to worry about exceeding \$FF, anymore.

- Implement a Sinc2 mode for doing background conversions of 8/9/10/11/12/13 bits. Sinc2 is very low on logic and would afford a nice automated ADC mode.

Here is the Sinc2 code I will implement. It maintains two scrolling diffs that allow samples to overlap, doubling the sample rate. These Sinc2 filters are proven in this program to hit every possible value within the duty range, according to the bitstream coming in. The 13-bit mode registers 2..8190 without any missing codes. Phil would definitely approve of its soundness:

Is there still a sinc3 mode support planned, for those many external commercial ADCs out there ?

Having overlapped samples gives more of an illusion of speed, if the step response is not improved. What is the logic cost of the overlap ?
ie in an earlier example, you gave 8 bits, at 8 bits per sysclk, but needing 256 clocks to settle. That slow slew/settle effect is poor for a scope.

• Posts: 13,554
jmg wrote: »
cgracey wrote: »
I've been working for 24 hours, simulating Sinc3 and Sinc2 filters. I've been slowly going in a giant circle, it seems.

Here is what I want to do:

- Implement the scope mode, as already designed, but limit the submodes to realistic numbers of bits, like 6 and 5. No need to worry about exceeding \$FF, anymore.

- Implement a Sinc2 mode for doing background conversions of 8/9/10/11/12/13 bits. Sinc2 is very low on logic and would afford a nice automated ADC mode.

Here is the Sinc2 code I will implement. It maintains two scrolling diffs that allow samples to overlap, doubling the sample rate. These Sinc2 filters are proven in this program to hit every possible value within the duty range, according to the bitstream coming in. The 13-bit mode registers 2..8190 without any missing codes. Phil would definitely approve of its soundness:

Is there still a sinc3 mode support planned, for those many external commercial ADCs out there ?

Having overlapped samples gives more of an illusion of speed, if the step response is not improved. What is the logic cost of the overlap ?
ie in an earlier example, you gave 8 bits, at 8 bits per sysclk, but needing 256 clocks to settle. That slow slew/settle effect is poor for a scope.

Sinc3 mode is still in the smart pins. It works best, but needs software management.

The overlap is pretty much free. We've got 112 flops. Might as well use them.
• Posts: 22,962
Here's a totally random thought: how many clocks does it take to know which half of the input range you're in? Which quartile? Which octile, etc.? Can such knowledge be leveraged to produce a sigma-delta equivalent to an SAR-driven ADC? Could this help with settling times in scope mode?

-Phil
• Posts: 14,640
edited 2018-12-22 22:15
cgracey wrote: »
Sinc3 mode is still in the smart pins. It works best, but needs software management.

The overlap is pretty much free. We've got 112 flops. Might as well use them.

Good.
To clarify : Is this sinc2 mode a new mode ?
ie for first-order ADC, no diff-step needed in SW (as in sinc3), so users can simply stream final ADC values

I've been trying to find theory examples of sinc3 filters used with first order modulators, with not much success. (Plenty of second order + sinc3)
I think you've run P2 ADC captures into sinc3, did you extract a ENOB, or SNR for those ?

It seems to me that Sinc3+first order, will lie somewhere between the slopes of sinc2+first order and sinc3+second order.

Will the sinc2 be able to set below 8b ? Seems it could be useful to trade off resolution for speed.
• Posts: 11,932
I think you need to test in order to say what the ENOB is...

One simple looking way is to take FFT of result of sine wave capture and do some math:

http://www.mit.edu/~klund/A2Dtesting.pdf
• Posts: 1,553
Here's a totally random thought: how many clocks does it take to know which half of the input range you're in? Which quartile? Which octile, etc.? Can such knowledge be leveraged to produce a sigma-delta equivalent to an SAR-driven ADC? Could this help with settling times in scope mode?

-Phil
I believe, there is no chance to gain this knowledge. The maximum incoming current (charge = current time clock time) is compensated by a single compensation pulse. So if the incoming voltage is half scale, every second compensation pulse is zero. If there is no hysteresis of the comparator, that is, the comparator detects every single pulse (no input current), the comparator toggles every clock.
If the input is 3/4, we see a 1, 0, 0, 0, ..signal so we need 4 clocks to recognize this value. But as the signal is noisy, we need averaging anyway, introducing larger latency. A SDADC is a SDADC, there is no way around. In the end, we have a tracking adc, perfect for non jumping input signals.
• Posts: 32
cgracey wrote: »
jmg wrote: »
cgracey wrote: »
I've been working for 24 hours, simulating Sinc3 and Sinc2 filters. I've been slowly going in a giant circle, it seems.

Here is what I want to do:

- Implement the scope mode, as already designed, but limit the submodes to realistic numbers of bits, like 6 and 5. No need to worry about exceeding \$FF, anymore.

- Implement a Sinc2 mode for doing background conversions of 8/9/10/11/12/13 bits. Sinc2 is very low on logic and would afford a nice automated ADC mode.

Here is the Sinc2 code I will implement. It maintains two scrolling diffs that allow samples to overlap, doubling the sample rate. These Sinc2 filters are proven in this program to hit every possible value within the duty range, according to the bitstream coming in. The 13-bit mode registers 2..8190 without any missing codes. Phil would definitely approve of its soundness:

Is there still a sinc3 mode support planned, for those many external commercial ADCs out there ?

Having overlapped samples gives more of an illusion of speed, if the step response is not improved. What is the logic cost of the overlap ?
ie in an earlier example, you gave 8 bits, at 8 bits per sysclk, but needing 256 clocks to settle. That slow slew/settle effect is poor for a scope.

Sinc3 mode is still in the smart pins. It works best, but needs software management.

The overlap is pretty much free. We've got 112 flops. Might as well use them.

I figured out something really weird last night about how all of this could come together.

Suppose that we convolve the input with a sliding [1,4,6,4,1] window on a bit by bit basis using whatever works out best for the logic. As I see it a hardware implementation using individual gates would do the job nicely (only 5 LE's!?!), but you still have to get the bit stream to the gates and back into the registers and if exotic summation can be shoehorned in at a lower cost by firing off increment and decrement pulses to existing logic then that might make sense.

But of course [1,4,6,4,1] isn't really a sinc2, or is it? Based on convolution theory it is the convolution of [1,2,1] with [1,2,1], with or without decimation - and we know that the first [1,2,1] window completely whacks all patterns of the type ....01010101.... or ...10101010.... into oblivion, or at least averages; which is where we want them to be. Yet [1,2,1] is actually a primitive Gaussian, with nice equiripple (read: zero phase shift) characteristics - and it has its first zero at Fs/2 which is exactly what sinc1 does. So it is a sinc1 type function - even if it is actually sinc1 squared.

Repeating the process - we get [1,4,6,4,1] for the convolution that gives the equiripple sinc2 function; and it is actually just the triangular window [1,2,1] convolved with itself - even if you were expecting a triangular window for sinc2. Hmmm - what is going on here?

And then I noticed something. What if we do a [1,4,6,4,1] in hardware and then overlap and add, skipping two clock cycles in between windowing operations.

[1,4,6,4,1,0,0]
+[0,0,1,4,6,4,1] = [1,4,7,8,7,4,1] which would be a nice little period seven triangular window, every clock cycle, or every other clock cycle, or every third clock cycle; or however often you want to run it - if you were to somehow replace that 8 with a 10; but why do that? Just in case you were expecting a rabbit - or if you must insist that sinc2 look like a triangle; it is in there; hiding somewhere in between the hat and the smoke and mirrors.

Well, lets try this again.

Feed [1,4,7,8,7,4,1] into a two tap delay and add. Or do I want a 4 tap delay?

[1,4,7,8,7,4,1,0,0]
+[0,0,1,4,7,8,7,4,1] = [1,4,8,12,14,12,8,4,1]

So for the price of a the delay and add and another delay and add we get a nine sample wide trapezoid; well almost; except now the rabbit is wearing a top hat with that 14, instead of a 12; which would have made it a trapezoid.

Time to try a four clock delay.

[1,4,8,12,14,12,8,4,1,0,0,0,0]
+[0,0,0,0,1,4,8,12,14,12,8,4,1] = [1,4,8,12,15,16,16,16,15,12,8,4,1]

Which is a 13 sample wide Tukey sandwich; or its a Tukey sandwich; stuffed with Tukey sausage. Of course that means I can take advantage of the fact that 4+8=12 and that 15+16, and do this exactly one more time, with another four tap delay.

[1,4,8,12,15,16,16,16,15,12,8,4,1,0,0,0,0,0,0,0,0]
+[0,0,0, 0, 0,0,0,0,1,4, 8,12,15,16,16,16,15,12,8,4,1] = are you ready for this?

[1,4,8,12,15,16,16,16,16,16,16,16,16,16,16,16,15,12,8,4,1] ---> sums to 256 ....

Now for people that like to count bits; there are plenty to go around. Since it becomes possible to accumulate the running counts; by only having to add on every eight clocks; and the sandwich can be stretched to infinity or you can get on or off the Tukey bus any time you like. Eventually we want to decimate - but the idea of having a running Tukey window that has a sinc2 or sinc3 pedigree hidden under the hood has some appeal; i.e., for the scope modes; since the original [1,4,6,4,1] or some variant can be used as a scope trigger; while an 21 tap Tukey window and 256/8 would be 84 nanosecond aperture window running at 32 Mhz; whereas that 18 wide window would have a cutoff frequency around 12Mz; leaving lots of bandwidth for manipulation in software while providing -- possibilities ....

• Posts: 353
cgracey wrote: »
I've been working for 24 hours, simulating Sinc3 and Sinc2 filters. I've been slowly going in a giant circle, it seems.

Here is what I want to do:

- Implement the scope mode, as already designed, but limit the submodes to realistic numbers of bits, like 6 and 5. No need to worry about exceeding \$FF, anymore.

- Implement a Sinc2 mode for doing background conversions of 6/7/8/9/10/11/12/13 bits. Sinc2 is very low on logic and would afford a nice automated ADC mode.

Here is the Sinc2 code I will implement. It maintains two scrolling diffs that allow samples to overlap, doubling the sample rate. These Sinc2 filters are proven in this program to hit every possible value within the duty range, according to the bitstream coming in. The 13-bit mode registers 2..8190 without any missing codes. Phil would definitely approve of its soundness:
enob = 10     'effective number of bits 6..13

maxenob = 13
decimate = pow(2,enob-2)
divide = decimate/2

range = pow(2,enob)

acc = rnd   'expose flaws

for g = 0 to range

for iter = 0 to range*2

acc = acc + g/range 'new ADC bit

if acc >= 1 then
acc = acc - 1
t = 1
else
t = 0
endif

inta = (inta + t) band bitmask
intb = (intb + inta) band bitmask

if iter/decimate = int(iter/decimate) then

sample = int((((intb - dif0) band bitmask)+divide/2)/divide)

dif0 = dif1
dif1 = intb
intb = 0

if iter > range then circle 10+(g mod 256)*4 + int(g/256)*12, 10+((range-sample) mod 256)*4, 2 filled

endif

next iter
'print sample,

next g

This filter seems equivalent to a CMA(512,256). (You can't see the cma trace because it's underneath the sinc2.) It's great that a filter like this can be implemented so cheaply.

I don't want to see the output range of the scope filter reduced. For applications like video or software defined radio the signal will rarely linger on the pathological steps. If we reduce the output range, we'd be adding quantization noise to hide the few steps that we can't measure.

We can design filters with any sum as long as it has enough factors.
forums.parallax.com/discussion/comment/1458147/#Comment_1458147
• Posts: 14,640
edited 2018-12-23 02:06
cgracey wrote: »
...
- Implement a Sinc2 mode for doing background conversions of 6/7/8/9/10/11/12/13 bits. Sinc2 is very low on logic and would afford a nice automated ADC mode.

Here is the Sinc2 code I will implement. It maintains two scrolling diffs that allow samples to overlap, doubling the sample rate. These Sinc2 filters are proven in this program to hit every possible value within the duty range, according to the bitstream coming in. The 13-bit mode registers 2..8190 without any missing codes. Phil would definitely approve of its soundness:

I changed the code
if iter > range then  'blank display until stable

to look for the settling time, and found display enable gate can be reduced to range/2, but no further.
if iter > ((range/2)-0) then 'wait until stable, tests find Div2-0 is ok, whilst Div2-1 is still settling, large deviations.

That's for the sweep scheme you have, but it also seems valid for random step sizes. Once above that threshold, errors are very small.

Not an especially fast settling time, at (2^ENOB)/2, but that may mean you can read twice as fast ?
It does indicate going down to lower ENOB can help speed.
• Posts: 13,554
edited 2018-12-23 02:11
jmg wrote: »
cgracey wrote: »
...
- Implement a Sinc2 mode for doing background conversions of 6/7/8/9/10/11/12/13 bits. Sinc2 is very low on logic and would afford a nice automated ADC mode.

Here is the Sinc2 code I will implement. It maintains two scrolling diffs that allow samples to overlap, doubling the sample rate. These Sinc2 filters are proven in this program to hit every possible value within the duty range, according to the bitstream coming in. The 13-bit mode registers 2..8190 without any missing codes. Phil would definitely approve of its soundness:

I changed the code
if iter > range then  'blank display until stable

to look for the settling time, and found display enable gate can be reduced to range/2, but no further.
if iter > ((range/2)-0) then 'wait until stable, tests find Div2-0 is ok, whilst Div2-1 is still settling, large deviations.

That's for the sweep scheme you have, but it also seems valid for random step sizes. Once above that threshold, errors are very small.

Not an especially fast settling time, at (2^ENOB)/2, but that may mean you can read twice as fast ?
It does indicate going down to lower ENOB can help speed.

We had to go this slow in order to make every single conversion code possible. At twice this sample rate, 95% of the readings would still be on the nose, but a minority would not be. This is all the way into the perfect zone, as the filters go.
• Posts: 1,675
I don't want to see the output range of the scope filter reduced. For applications like video or software defined radio the signal will rarely linger on the pathological steps. If we reduce the output range, we'd be adding quantization noise to hide the few steps that we can't measure.

I agree very much. Masking off bits so that only 5 or 6 are used would only reduce the ENOB to less than what it already is.

As the scope mode has an 8-bit output, it seems to me that the most accurate window will be one that sums to 255 without clipping or truncation and CMA(3,5,17) with length 25 fits the bill. Longer windows would have sums greater than 255 and the necessary truncation would affect taps with low values proportionately much more than those with maximum/plateau values. On that basis, a sum of 510 would be better than 1020, 2040, etc.
• Posts: 13,554
edited 2018-12-23 05:21
TonyB_ wrote: »
I don't want to see the output range of the scope filter reduced. For applications like video or software defined radio the signal will rarely linger on the pathological steps. If we reduce the output range, we'd be adding quantization noise to hide the few steps that we can't measure.

I agree very much. Masking off bits so that only 5 or 6 are used would only reduce the ENOB to less than what it already is.

As the scope mode has an 8-bit output, it seems to me that the most accurate window will be one that sums to 255 without clipping or truncation and CMA(3,5,17) with length 25 fits the bill. Longer windows would have sums greater than 255 and the necessary truncation would affect taps with low values proportionately much more than those with maximum/plateau values. On that basis, a sum of 510 would be better than 1020, 2040, etc.

I actually agree, TonyB_. They ought to saturate to \$FF. No need to be a purist in this case. It's just going to be darn cool to have scope traces, even if they aren't numerically perfect. While they won't convey DC values perfectly, they are going to be the best we can get for phase representation. This scope mode is mostly about being able to view signals with minimal jitter. There's no other mode that addresses that.
• Posts: 10,167
If this is the way it goes, then it seems to me anyone wanting DC, or other reference type signals can simply dedicate another pin to that and overlay / work it into whatever display representation makes sense.

• Posts: 353
Sorted by length
WindowFn              Vpp98%         StdDev   HFNoisePower         Length            Sum      freq -3dB      freq -6dB

cmafilter(3,5,17)      4.125      1.2280706       3.141237             23            255      6.3476562      8.6669922
cmafilter(5,6,17)    3.15625     0.92353999      1.6065056             26            510      6.1645508      8.4228516
cmafilter(3,10,17)      3.25     0.91912928     0.46361439             28            510      5.7983398      7.9345703
cmafilter(1,15,17)         3      0.8006214     0.24944618             31            255      5.1269531      7.0800781
cmafilter(6,10,17)    2.5625     0.73265331     0.27427092             31           1020      5.6152344      7.7514648
cmafilter(2,15,17)   2.90625     0.75192077     0.22398277             32            510      5.1269531       7.019043
cmafilter(5,12,17)       2.5     0.68752508     0.14434233             32           1020      5.4321289      7.4462891
cmafilter(4,15,17)    2.5625     0.65570961     0.15890601             34           1020       5.065918      6.9580078
cmafilter(3,17,20)  2.109375      0.5095961     0.12556281             38           1020      4.3945312      6.1035156
cmafilter(3,5,34)       2.25     0.64139592      1.0935432             40            510      3.3569336      4.5166016
cmafilter(5,6,34)      1.625     0.46546626     0.64621824             43           1020      3.3569336      4.5166016
cmafilter(3,11,31)   1.65625     0.41133892     0.34734074             43           1023      3.5400391      4.7607422
cmafilter(3,10,34)     1.875     0.46586521     0.26496236             45           1020      3.2958984      4.4555664
cmafilter(1,17,30)    1.5625     0.38162696    0.082641936             46            510      3.4179688      4.6386719
cmafilter(2,17,30)  1.484375      0.3579866    0.075271162             47           1020      3.4179688      4.6386719
cmafilter(1,15,34)   1.71875     0.42195221    0.071049605             48            510      3.1738281      4.2724609
cmafilter(2,15,34)  1.640625     0.39025735    0.064497492             49           1020      3.1738281      4.2724609
cmafilter(1,5,51)      1.375     0.48881518     0.69478962             55            255      2.3193359       3.112793
cmafilter(2,5,51)     1.3125     0.43485308     0.65038639             56            510      2.3193359       3.112793
cmafilter(4,5,51)    1.15625      0.3652494     0.51993743             58           1020      2.3193359       3.112793
cmafilter(1,10,51)      1.25     0.34970657     0.18878316             60            510      2.2583008      3.0517578
cmafilter(2,10,51)  1.234375     0.32269134     0.17911619             61           1020      2.2583008      3.0517578
cmafilter(1,30,34)   1.09375       0.248207    0.027657565             63           1020      2.6245117      3.6010742
cmafilter(1,31,33)    1.0625     0.24611606    0.037234021             63           1023      2.6245117      3.6010742
cma67              0.9453125     0.25685335    0.093979185             67           4096      2.2583008      3.0517578
cmafilter(1,20,51)  0.890625     0.22152183    0.023968906             70           1020      2.1972656      2.9296875
cmafilter(3,5,68)    1.21875     0.31460015     0.36078074             74           1020      1.7700195      2.3803711
cmafilter(1,17,60)    0.8125      0.2154829    0.016019744             76           1020       1.953125      2.5634766
cmafilter(1,7,73)    1.03125     0.30411113     0.20036224             79            511      1.6479492      2.1972656
cmafilter(2,7,73)   1.015625     0.27512494     0.18912441             80           1022      1.6479492      2.1972656
cmafilter(1,15,68)     0.875     0.22326336     0.02453981             82           1020      1.7700195      2.3193359
cmafilter(1,14,73)    0.8125     0.21856456    0.022756281             86           1022      1.6479492      2.1972656
cmafilter(1,3,85)     2.3125     0.76486198     0.41277381             87            255      1.4648438       1.953125
cmafilter(2,3,85)    2.09375     0.65936066     0.37596829             88            510      1.4648438       1.953125
cmafilter(1,6,85)     0.6875     0.23859536     0.21529424             90            510      1.4648438      1.8920898
cmafilter(3,4,85)   1.296875     0.37689001      0.2789852             90           1020      1.4648438       1.953125
cmafilter(2,6,85)   0.671875     0.22190071     0.20313889             91           1020      1.4648438      1.8920898
cmafilter(1,12,85)   0.59375     0.17300551    0.039453742             96           1020      1.4648438      1.8920898
cmafilter(1,11,93)   0.65625     0.16987181    0.039158902            103           1023      1.3427734      1.7700195
cmafilter(1,5,102)   0.78125      0.2628953     0.17964388            106            510      1.2207031      1.6479492
cmafilter(2,5,102)   0.71875      0.2336778     0.16797423            107           1020      1.2207031      1.6479492
cmafilter(1,10,102) 0.640625     0.19144316    0.046762187            111           1020      1.2207031      1.6479492
cmafilter(1,7,146)  0.546875     0.14741457    0.058464752            152           1022     0.91552734       1.159668
cmafilter(1,3,170)         1     0.33764521     0.10793848            172            510     0.79345703      1.0375977
cmafilter(2,3,170)  0.921875     0.29013751    0.098114793            173           1020     0.79345703      1.0375977
cmafilter(1,6,170)  0.421875     0.12244874    0.055496063            175           1020     0.79345703      1.0375977
cmafilter(1,5,204)  0.546875     0.13144373    0.049061135            208           1020     0.67138672     0.91552734
cmafilter(1,1,255)         1     0.40922594    0.079962973            255            255     0.61035156     0.73242188
cmafilter(1,2,255)    0.9375     0.30774295    0.062312207            256            510     0.61035156     0.73242188
cmafilter(2,2,255)  0.828125     0.25878605    0.054426562            257           1020     0.61035156     0.73242188
cmafilter(1,4,255)    0.5625     0.16667765    0.040512353            258           1020     0.61035156     0.73242188
cmafilter(1,3,340)    0.5625     0.17625263      0.0298306            342           1020     0.48828125     0.61035156
cmafilter(1,3,341)  0.515625     0.16750249    0.029676996            343           1023     0.48828125     0.61035156
cmafilter(1,1,510)   0.53125      0.2113054    0.023656437            510            510     0.36621094     0.42724609
cmafilter(1,1,511)       0.5      0.2170287    0.023577206            511            511     0.36621094     0.42724609
cmafilter(1,2,510)   0.46875     0.16350573    0.018449634            511           1020     0.36621094     0.42724609
cmafilter(1,2,511)  0.484375     0.16582964    0.018391494            512           1022     0.36621094     0.42724609
cmafilter(1,1,1020)  0.28125    0.094311845   0.0071205715           1020           1020     0.24414062     0.30517578
cmafilter(1,1,1021) 0.265625     0.10147634   0.0071052634           1021           1021     0.24414062     0.30517578
cmafilter(1,1,1022)  0.28125       0.104304   0.0070431083           1022           1022     0.24414062     0.30517578
cmafilter(1,1,1023)  0.28125     0.10564685   0.0070854743           1023           1023     0.24414062     0.30517578

Vpp98% is an estimate of the peak-to-peak noise in a 0-255 measurement. A value of 1 means most measurements vary between 49 and 50 for example.

TonyB has created some filters with a reduced plateau height. That does make the complexity slightly higher but it's nothing to worry about. It does give us more flexibility to adjust the filter shape and sum than strict CMA filters. I haven't tried to generate those automatically yet.

Generating a larger sum gives us more flexibility in both grouping the factors together and increasing the range of sum values that will truncate to 255. Many filters sum to 2^N and would need saturation. Even though a saturated ADC is beyond the rails, it would be confusing if saturated positive and saturated negative both measure as 0. Can it saturate or will the diodes clamp it before that?
• Posts: 13,554
edited 2018-12-23 07:40
Saucy, it will saturate in the cases of the magnified modes, even if the diodes clamp the 1x modes before saturation. We need to handle saturation by returning \$FF, or not getting there, in the first place. The new ADC modes have the same issue. They want to saturate to 2^n on all 1's coming in, whereas we need to limit them to (2^n)-1.

Saucy, I have a question for you... You know that by adding log values of numbers, you are really multiplying them, while subtraction divides, left shift by one squares, and right shift by one square-roots. So, logs are useful for achieving higher-order functions from lower-order ones. I am wondering... What can be done with log values of log values? Some of you may have an idea.
• Posts: 13,554
edited 2018-12-23 12:02
Jmg, I added your efficiency change and also found that by pre-shifting the ADC bit left, there's no need to variably shift the final result right, which would have been way more expensive. I also realized that we don't have enough flops for the staggered diff's, so we're at half the sample rate now. I moved the intb computation before the inta computation to make it work like the hardware and it improved early readings. This is getting to be really simple:
code = 0            'code to establish enob, 0..7 --> 6..13 enob

enob = 6 + code     'effective number of bits 6..13

maxenob = 6 + 7
decimate = pow(2,enob-1)

range = pow(2,enob)

acc = rnd   'expose flaws

for g = 0 to range

for iter = 0 to range*2

acc = acc + g/range   'determine new ADC bit

if acc >= 1 then
acc = acc - 1
t = pow(2,7-code)   'variably shift up ADC bit before integration to avoid shifting final sample
else
t = 0
endif

intb = (intb + inta) band bitmask
inta = (inta + t) band bitmask

if iter/decimate = int(iter/decimate) then

result = ((intb - diff) band bitmask)         'compute result
sample = int((result+pow(2,10))/pow(2,11))    'round and shift down to make sample

diff = intb
intb = 0

if iter > range/2 then circle 10+(g mod 256)*4 + int(g/256)*12, 10+((range-sample) mod 256)*4, 2 filled

endif

next iter
print sample,

next g

Also, since only the scope mode is going to be used by the streamer, there's no need to implement saturation on this one, as it returns 32-bit results via RDPIN. If the customer wants to clamp an 8-bit reading to \$FF, he can do a 'FLE sample,#\$FF'.
• Posts: 14,640
cgracey wrote: »
Jmg, I added your efficiency change and also found that by pre-shifting the ADC bit left, there's no need to variably shift the final result right, which would have been way more expensive. I also realized that we don't have enough flops for the staggered diff's, so we're at half the sample rate now. This is getting to be really simple:
This reports & steps at range/2 rate, which means you could deliver the same results with a staggered counter scheme ?
Would 2 staggered counters be lower cost than 2 adders and one subtracter ?

• Posts: 13,554
edited 2018-12-23 12:04
jmg wrote: »
cgracey wrote: »
Jmg, I added your efficiency change and also found that by pre-shifting the ADC bit left, there's no need to variably shift the final result right, which would have been way more expensive. I also realized that we don't have enough flops for the staggered diff's, so we're at half the sample rate now. This is getting to be really simple:
This reports & steps at range/2 rate, which means you could deliver the same results with a staggered counter scheme ?
Would 2 staggered counters be lower cost than 2 adders and one subtracter ?

We've only got room for one set. I've implemented it and we've only got five flops to spare.
• Posts: 13,554
edited 2018-12-23 16:02
I've got the Sinc2 ADC mode working in the smart pins. It's settable for 7..14-bit conversions.

Look at the lower 8 bits of this 14-bit conversion. Almost no noise. It would take 63 more scope screens stacked vertically to see the whole sine wave:

I think it would be good at 16 bits, too, but I'm out of flops.

Some careful effort was spent on making sure this Sinc2 filter had no missing codes at all resolutions. It lets the ADC really shine.

• Posts: 4,053
Nice stuff. How easy is it to show a comparison to not using the filtering methods to understand the significance?
• Posts: 13,554
T Chap wrote: »
Nice stuff. How easy is it to show a comparison to not using the filtering methods to understand the significance?

It would look bumpier by a few samples +/-. And the acquisition time would double.
• Posts: 14,640
cgracey wrote: »
I've got the Sinc2 ADC mode working in the smart pins. It's settable for 7..14-bit conversions.
Look at the lower 8 bits of this 14-bit conversion. Almost no noise. It would take 63 more scope screens stacked vertically to see the whole sine wave:

Is that with the real P2 ADC data feeding it ? What HW test setup ?
Can you plot Sinc3, also fed from a real ADC, as a comparison ?

What bit-counts does this cover ? I presume this can also be fed from an external pin ?
Could someone set this up to stream at some modest #bits rate, and then apply another filter in software for 16/18/20 bits, depending on where the system noise floor was ?
• Posts: 13,554
edited 2018-12-23 20:06
jmg wrote: »
cgracey wrote: »
I've got the Sinc2 ADC mode working in the smart pins. It's settable for 7..14-bit conversions.
Look at the lower 8 bits of this 14-bit conversion. Almost no noise. It would take 63 more scope screens stacked vertically to see the whole sine wave:

Is that with the real P2 ADC data feeding it ? What HW test setup ?
Can you plot Sinc3, also fed from a real ADC, as a comparison ?

What bit-counts does this cover ? I presume this can also be fed from an external pin ?
Could someone set this up to stream at some modest #bits rate, and then apply another filter in software for 16/18/20 bits, depending on where the system noise floor was ?

Yes. That was the P2 pin test board on the FPGA. I was feeding it from a quiet 3.3 volt regulator on the new P2 eval board. It's real.

I was looking at the sinc3 filter today, after I got the sinc2 working. It is amazing what the sinc3 can do with dynamic signals, but it does not have enough base information to know DC very accurately. These new sinc2 modes are like instrumentation modes for the ADC, whereas the sinc3 is like a dynamic mode for changing signals. Because of rapid bit growth, the sinc3 can only do 1K clocks before it fills up. The sinc2 is going to get a slight makeover and go to 16 bits, taking 32K clocks to achieve a conversion. I am anxious to see what a 16-bit sinc2 conversion looks like.