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

ADC Sampling Breakthrough

1202123252652

Comments

  • cgraceycgracey Posts: 14,134
    edited 2018-11-29 06:09
    T Chap wrote: »
    Somewhere back the ADC became an optional “scope/scope mode feature”. What is a scope mode.

    An osciiloscope shows real-time votage activity. Useful for seeing what is going on at the analog/pin level.
  • jmgjmg Posts: 15,171
    cgracey wrote: »
    Evanh, thanks for trying so hard to make all that bit pruning work. It seems that it's not a certain thing. Is that accurate?

    Having 30-bit Sinc3 accumulators in the smart pin is not that much more expensive than what the pruning would provide, anyway.

    What else could use some improvement on this front, while we're here?

    Once a solid Sinc3 is there, it's just the housekeeping stuff, like clock polarity, clock source, and sample sizes but I think those are covered ?
  • cgracey wrote: »
    TonyB_, I don't know why it should be, but that Tukey 16*/33 is noisier than the Tukey 17*/32. It must have something to do with the frequency of data cycling in the ADC bitstream as it interacts with the side lobes of the window.
    That appears to be the opposite of the spectrum analysis. Tukey16 has a deep null where the noise is highest. Yet it's only better on 9 of 16 tests.

    I would be interested to know if the noise peaks tend to stay at a fixed ratio with the system clock, or if their absolute frequency is relatively constant.
    row 1  Tukey17*/32
    row 2  Tukey16*/33
    row 3  Tukey13*/32
    means =
    
        45.367    48.506    44.407    45.596    43.596    43.394    48.906    46.799   212.372   214.971   214.590   214.560   211.250   212.677   215.867   215.058
        45.066    48.493    44.623    45.319    43.732    43.481    48.903    46.842   212.437   214.981   214.588   214.558   211.068   212.789   215.867   215.062
        45.263    48.518    44.639    45.468    43.547    43.279    48.900    46.828   212.528   214.828   214.498   214.471   211.224   212.813   215.792   214.905
        
    
    dev =
    
       0.55194   0.51324   0.55921   0.50285   0.53237   0.61839   0.35290   0.47419   0.72835   0.40526   0.52742   0.53002   0.49377   0.54610   0.40421   0.31277
       0.24906   0.53602   0.48472   0.46626   0.49502   0.62979   0.34789   0.39828   0.77249   0.41905   0.52930   0.53399   0.38639   0.49519   0.40087   0.31946
       0.47926   0.51273   0.48960   0.50584   0.58546   0.68958   0.34295   0.50020   0.71697   0.52653   0.53534   0.53314   0.54762   0.49039   0.44996   0.49394
       
    


    1200 x 900 - 39K
    1167 x 875 - 36K
  • evanhevanh Posts: 15,853
    Chip,
    Tony explained it enough for me, pruning creates bigger steps so smoothness is harmed.

    JMG,
    Yep, polarity and source are well covered in the general smartpin config.

    Just the mode itself has to have edge counting option is all, ie: the bit-level becomes an enable for counting clock pulses. Chip has separated gated edge counting and level counting into separate modes, %01100 and %01111 respectively, for Sinc1.

    Not sure if Chip plans to merge the two or have two modes same as Sinc1.
  • cgracey wrote: »
    Evanh, thanks for trying so hard to make all that bit pruning work. It seems that it's not a certain thing. Is that accurate?

    Having 30-bit Sinc3 accumulators in the smart pin is not that much more expensive than what the pruning would provide, anyway.

    What else could use some improvement on this front, while we're here?

    Does anyone else want a bandwidth adjustment in the filter?


    The Tukey17/32 could be shortened like this:
     1    3    5    7   10   13   16   19   22   25   27   29   31
    32   32   32   
    31   29   27   25   22   19   16   13   10    7    5    3    1
    
    Sum is 512. Full scale output would be 128.

    3dB bandwidth rises from 3.4MHz to 5.8MHz. 6dB bandwidth rises from 4.6MHz to 7.9MHz. Both of these neglect the effects of the analog circuitry.

    It should be cheap to do. Just add a MUX to switch the input into the 31 on the end. So the bits can go through the full flat section in the middle or just part. And an AND after the third 32 in the center. This would prevent the bits in the bypassed section from affecting the output. (after enough clocks to flush them out)

    I won't ask for the output to be rescaled. It would just multiply the noise.
    1167 x 875 - 32K
    1200 x 900 - 27K
  • cgraceycgracey Posts: 14,134
    cgracey wrote: »
    Evanh, thanks for trying so hard to make all that bit pruning work. It seems that it's not a certain thing. Is that accurate?

    Having 30-bit Sinc3 accumulators in the smart pin is not that much more expensive than what the pruning would provide, anyway.

    What else could use some improvement on this front, while we're here?

    Does anyone else want a bandwidth adjustment in the filter?


    The Tukey17/32 could be shortened like this:
     1    3    5    7   10   13   16   19   22   25   27   29   31
    32   32   32   
    31   29   27   25   22   19   16   13   10    7    5    3    1
    
    Sum is 512. Full scale output would be 128.

    3dB bandwidth rises from 3.4MHz to 5.8MHz. 6dB bandwidth rises from 4.6MHz to 7.9MHz. Both of these neglect the effects of the analog circuitry.

    It should be cheap to do. Just add a MUX to switch the input into the 31 on the end. So the bits can go through the full flat section in the middle or just part. And an AND after the third 32 in the center. This would prevent the bits in the bypassed section from affecting the output. (after enough clocks to flush them out)

    I won't ask for the output to be rescaled. It would just multiply the noise.


    Saucy, perfect!!!

    We needed something like this to accommodate higher bandwidth, and a reduction in resolution is to be expected. I like the idea of not rescaling the output, but making 128 the peak, to keep absolute noise constant.

    We will use the single, unused 'cfg' bit 6 to select this mode.

    And this can all occur at the D inputs of the 'tap' flops with a mux, in order to avoid lengthening the filter computation time.

    Just perfect!
  • cgraceycgracey Posts: 14,134
    evanh wrote: »
    Chip,
    Tony explained it enough for me, pruning creates bigger steps so smoothness is harmed.

    JMG,
    Yep, polarity and source are well covered in the general smartpin config.

    Just the mode itself has to have edge counting option is all, ie: the bit-level becomes an enable for counting clock pulses. Chip has separated gated edge counting and level counting into separate modes, %01100 and %01111 respectively, for Sinc1.

    Not sure if Chip plans to merge the two or have two modes same as Sinc1.

    Evanh, I'll post the new mode map shortly.

    I compacted the main USB modes from four down to two, making the low/full-speed mode selectable by X[15] via WXPIN.

    The two SINC3 modes sit where the first two USB modes were. The first SINC3 mode accumulates PinA on every clock, while the second SINC3 mode accumulates PinA only when PinB rises, making it externally clockable. I will post the code soon, as it has changed slightly.
  • TonyB_TonyB_ Posts: 2,178
    edited 2018-11-29 12:43
    Has the logic for the different modes been combined as much as possible yet?

    In Sinc3, acc1 can be a counter, so only need adders for acc2 and acc3. jmg has asked a couple of times whether acc2 could use an existing NCO adder, leaving just acc3 as a new adder.

    The Sinc3 logic could also do Sinc1 and Sinc2 if half the adder inputs are held low, so that acc3=acc2=acc1 or acc3=acc2.

    EDIT:
    The last sentence shows how to Integrate and Dump, to reset acc3 after it has been read. Has this been applied to Sinc3 and maybe other modes?
  • cgraceycgracey Posts: 14,134
    edited 2018-11-29 12:52
    TonyB_, yes, at the end of a measurement period, acc3 is loaded with acc2, instead of acc3+acc2. This way, we effectively reset acc3 without losing the next acc2 delta.

    As far as commonizing wide adders and gated counters, we have done that and it seems impervious to further logic savings.

    Does SINC2 have any special appeal?
  • cgraceycgracey Posts: 14,134
    Saucy, your ADC bitstream noise spectrum is good to see. It's apparent that most ADC data cycles in 5, 6, or 7 clocks.

    Those periods are a pure function of input current vs feedback current at full-scale VIO and GIO readings. If you go above or below the rails, duty will soon reach 1/8 or 7/8, making 1/8 relative frequency the peak in the noise spectrum.

    I'm trying to think what kind of other similar ADC topology might be possible where we parallelize something cheap in the circuit, like the currently-single-bit feedback, to make it multi-bit, instead, but not with exactly known values, but just something known only to be coarsely different, but consistent. Then, in the wash, out come better results that are giving us effectively more than one bit per clock, but not an integral amount, but something whole and fractional. Maybe digital pseudo-random noise could be used to choose each feedback strength, from clock to clock, with the data being tracked to know what caused the outcome in a rolling sampling scenario.

    Would there be any obvious advantage to shattering the noise profile?
  • cgraceycgracey Posts: 14,134
    edited 2018-11-29 13:27
    We could have multiple/smaller integrator caps that we run at slightly different feedback currents, in order to get more data. If we had 7, for example, we could add them up each clock to get 0..7 (3 bits) out, which could be considered as 0..1 in 7 steps. Just more data reporting could have value.

    Or, those 7 bits could all be output each clock, in order to be individually calibrated before some final sense could be made of all their data, together.
  • evanhevanh Posts: 15,853
    cgracey wrote: »
    Does SINC2 have any special appeal?

    Don't think so, initial responses to reset are identical.

  • evanhevanh Posts: 15,853
    Chip!!! You can't be thinking about refreshing the custom layout! That's additional cost. And more time I bet.

  • cgraceycgracey Posts: 14,134
    evanh wrote: »
    cgracey wrote: »
    Does SINC2 have any special appeal?

    Don't think so, initial responses to reset are identical.

    So, we will provide a third-order filter, but there's really no reason to bother with a second-order filter, right? If we have a third-order, who cares about a second-order? Any second-order implementation would rather have been a third-order, given the resources were available. That's how I see it.
  • cgraceycgracey Posts: 14,134
    evanh wrote: »
    Chip!!! You can't be thinking about refreshing the custom layout! That's additional cost. And more time I bet.

    No. I'm just thinking about future development here. You are right, that is way too big a can to open, at this point.
  • evanhevanh Posts: 15,853
    Lol, me eyes popped out for moment there.

  • cgracey wrote: »
    The Tukey17/32 could be shortened like this:
     1    3    5    7   10   13   16   19   22   25   27   29   31
    32   32   32   
    31   29   27   25   22   19   16   13   10    7    5    3    1
    
    Sum is 512. Full scale output would be 128.

    3dB bandwidth rises from 3.4MHz to 5.8MHz. 6dB bandwidth rises from 4.6MHz to 7.9MHz. Both of these neglect the effects of the analog circuitry.

    It should be cheap to do. Just add a MUX to switch the input into the 31 on the end. So the bits can go through the full flat section in the middle or just part. And an AND after the third 32 in the center. This would prevent the bits in the bypassed section from affecting the output. (after enough clocks to flush them out)

    I won't ask for the output to be rescaled. It would just multiply the noise.


    Saucy, perfect!!!

    We needed something like this to accommodate higher bandwidth, and a reduction in resolution is to be expected. I like the idea of not rescaling the output, but making 128 the peak, to keep absolute noise constant.

    We will use the single, unused 'cfg' bit 6 to select this mode.

    And this can all occur at the D inputs of the 'tap' flops with a mux, in order to avoid lengthening the filter computation time.

    Just perfect!

    A Tukey without a plateau is a Hann window, so bit 6 would select Tukey/Hann mode.
  • evanhevanh Posts: 15,853
    cgracey wrote: »
    So, we will provide a third-order filter, but there's really no reason to bother with a second-order filter, right? If we have a third-order, who cares about a second-order? Any second-order implementation would rather have been a third-order, given the resources were available. That's how I see it.

    Yep. That's how I see it too. If Sinc3 fits on the die then Sinc2 is redundant.

  • TonyB_TonyB_ Posts: 2,178
    edited 2018-11-29 13:56
    cgracey wrote: »
    TonyB_, yes, at the end of a measurement period, acc3 is loaded with acc2, instead of acc3+acc2. This way, we effectively reset acc3 without losing the next acc2 delta.

    As far as commonizing wide adders and gated counters, we have done that and it seems impervious to further logic savings.

    Does SINC2 have any special appeal?
    cgracey wrote: »
    evanh wrote: »
    cgracey wrote: »
    Does SINC2 have any special appeal?

    Don't think so, initial responses to reset are identical.

    So, we will provide a third-order filter, but there's really no reason to bother with a second-order filter, right? If we have a third-order, who cares about a second-order? Any second-order implementation would rather have been a third-order, given the resources were available. That's how I see it.

    SincX has "passband droop" and the greater the cascading the more the droop. I think one of Saucy's graphs shows how the droop increases. It can be corrected in software but it's more work than a couple of sub/add combos. The higher the oversampling, the lower the droop.

    Sinc2 would be an almost zero-cost option in logic, simply load acc3 with acc2 all the time, if there is a config bit to spare.
  • evanhevanh Posts: 15,853
    edited 2018-11-29 14:08
    What is droop? Is it an attenuation?

  • cgraceycgracey Posts: 14,134
    edited 2018-11-29 14:20
    That's the problem, TonyB_, there are no more bits for anything. What the acc's don't use, the reloadable counter uses.
  • cgraceycgracey Posts: 14,134
    edited 2018-11-29 14:19
    SINC3 topology is significant because the filter first becomes gaussian-shaped, after being triangular at SINC2 and rectangular at SINC1. Beyond SINC3, it becomes a little more gaussian, but at huge added expense. SINC3 is the sweet spot.
  • evanh wrote: »
    What is droop? Is it an attenuation?

    Yes, best to do a search for the details.
  • At this point, the various modes give great coverage. People have pretty great options. For the few niches that may show up, particularly after people have an interest in all this and use the on chip features, an external circuit will make sense for those.

    We can still get the bitstream in the way you captured it on the Rev A chips, right? As long as that remains true, further software work can be done. That's going to end up covering a few of those "yet to be seen" niche cases. People can run it in bursts, with some trigger, process. Or, they can run it slower, instrumentation style.

  • cgracey wrote: »
    That's the problem, TonyB_, there are no more bits for anything. What the acc's don't use, the reloadable counter uses.

    Tukey/Hann is a better use for the last config bit.

    I'm wondering what you get with two diffs not three with Sinc3? Of course with Integrate and Dump it would be only one in software. Would that give you Sinc2 or gobbledegook2?

    Is there still a simple integrator Sinc1 mode and does it use Integrate and Dump?
  • evanhevanh Posts: 15,853
    edited 2018-11-29 14:42
    TonyB_ wrote: »
    Yes, best to do a search for the details.

    I think this will simply be the 3-clock lag again. I don't see how that can be a concern for nominal uses of smartpins.

  • evanhevanh Posts: 15,853
    edited 2018-11-29 14:52
    TonyB_ wrote: »
    Is there still a simple integrator Sinc1 mode and does it use Integrate and Dump?

    Yes there is two modes, one clocked (%01100), one not clocked (%01111). Both 32-bit and both have a dedicated Z latch for capturing a sample, and both have decimation + diff'ing as hardware option.

  • cgraceycgracey Posts: 14,134
    edited 2018-11-29 17:03
    potatohead wrote: »
    At this point, the various modes give great coverage. People have pretty great options. For the few niches that may show up, particularly after people have an interest in all this and use the on chip features, an external circuit will make sense for those.

    We can still get the bitstream in the way you captured it on the Rev A chips, right? As long as that remains true, further software work can be done. That's going to end up covering a few of those "yet to be seen" niche cases. People can run it in bursts, with some trigger, process. Or, they can run it slower, instrumentation style.

    Yes, you can always catch the bitstreams, so any kind of ADC filtration can be achieved (or developed, in our current case), just not in real time.
  • cgraceycgracey Posts: 14,134
    Here is the new scope code that does the 29-tap Hann and 45-tap Tukey filtering. This filter change only added two ALM's. We are now at 84.

    661 x 1589 - 33K
  • cgraceycgracey Posts: 14,134
    edited 2018-11-29 17:23
    Here is what has changed in the smart pin modes:
    11000	= SINC3 filter internally clocked
    11001	= SINC3 filter externally clocked
    11010	= USB host			(even/odd pin pair = DM/DP)
    11011	= USB device			(even/odd pin pair = DM/DP)
    

    USB modes have been compressed down to two, to accommodate two SINC3 modes. The USB slow/full-speed switch is now X[15] of WXPIN, which was an NCO bit that was always programmed with '0', anyway.

    Here is the SINC3 smart pin mode Verilog code:

    890 x 1906 - 44K
Sign In or Register to comment.