Shop OBEX P1 Docs P2 Docs Learn Events
ADC Sampling Breakthrough - Page 45 — Parallax Forums

ADC Sampling Breakthrough

1424345474852

Comments

  • cgraceycgracey Posts: 14,131
    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.
  • jmgjmg Posts: 15,140
    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.
  • cgraceycgracey Posts: 14,131
    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.

    Sinc2_ramp.png

    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.
  • ErNaErNa Posts: 1,738
    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.
  • jmgjmg Posts: 15,140
    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

  • 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
  • cgraceycgracey Posts: 14,131
    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
    bitmask = pow(2,maxenob*2-2)-1
    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
    
  • jmgjmg Posts: 15,140
    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.


  • cgraceycgracey Posts: 14,131
    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.
  • 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
  • jmgjmg Posts: 15,140
    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.
  • RaymanRayman Posts: 13,767
    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
  • ErNaErNa Posts: 1,738
    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.
  • 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?
    Let's start with the two 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 ....













  • 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
    bitmask = pow(2,maxenob*2-2)-1
    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
    1200 x 900 - 22K
    1200 x 900 - 17K
  • jmgjmg Posts: 15,140
    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.
  • cgraceycgracey Posts: 14,131
    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.
  • 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.
  • cgraceycgracey Posts: 14,131
    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.
  • 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.

  • 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?
  • cgraceycgracey Posts: 14,131
    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.
  • cgraceycgracey Posts: 14,131
    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
    bitmask = pow(2,maxenob*2-1)-1
    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'.
  • jmgjmg Posts: 15,140
    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 ?

  • cgraceycgracey Posts: 14,131
    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.
  • cgraceycgracey Posts: 14,131
    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:

    14bit.jpg


    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.


    811 x 644 - 113K
  • Nice stuff. How easy is it to show a comparison to not using the filtering methods to understand the significance?
  • cgraceycgracey Posts: 14,131
    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.
  • jmgjmg Posts: 15,140
    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 ?
  • cgraceycgracey Posts: 14,131
    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.
Sign In or Register to comment.