ADC Sampling Breakthrough

1333436383948

Comments

  • TonyB_ wrote: »
    cgracey wrote: »
    TonyB_, i think I will implement your filters. They take care of the eight bit issue nicely. For highest speed, they are necessary.

    I wish we had infinite logic, so that we could also implement a 16-bit converter. Then, the streamer could write 16-bit samples to memory whenever it wanted to, as well.

    Thanks, Chip. I don't mind if other filters are used, whatever can fit. I counted how many register bits in total were in use the other day for the scope mode and it came to 32x3 + 1x16 = 112. I'm not sure whether that is the limit and the 80 taps you need for one of your cascaded filters are impossible or not. If more bits are available then I could have a look at slightly larger windows that might avoid the need for clamping one of them. Having said that, Hann/Tukey and Blackman might not go together so well as now (see pic below). I've read some good things about the Blackman function, which is a combination of cosine-squared and cosine-squared-squared.

    o7vy50.jpg

    Yes, we have 3x32 + 16 flops available in the smart pin. That's 112. Everything keeps fitting perfectly.
  • cgraceycgracey Posts: 10,733
    edited 2018-12-16 - 07:07:40
    TonyB_, I'm thinking maybe we could have an additional mode where those 17 bits that are used for triggering get reused for a smoothing filter, so that we can get 12-bit samples out per clock. It could feed from the 68-tap Tukey.

    What is the total sum value for the Tukey68? Its top bits are 255, but there are 2-3 lower bits, as well, right?
  • cgracey wrote: »
    TonyB_,, I'm thinking maybe we could have an additional mode where those 17 bits that are used for triggering get reused for a smoothing filter, so that we can get 12-bit samples out per clock. It could feed from the 68-tap Tukey.

    What is the total sum value for the Tukey68? Its top bits are 255, but there are 2-3 lower bits, as well, right?

    Output ranges:

    Tukey68 = 0-2040
    Tukey45 = 0-1020
    Hann30 = 0-510
    Blackman22 = 0-256

    Did you have to re-allocate some bits for your ~80-point cascaded window?
    Formerly known as TonyB
  • TonyB_ wrote: »
    cgracey wrote: »
    TonyB_,, I'm thinking maybe we could have an additional mode where those 17 bits that are used for triggering get reused for a smoothing filter, so that we can get 12-bit samples out per clock. It could feed from the 68-tap Tukey.

    What is the total sum value for the Tukey68? Its top bits are 255, but there are 2-3 lower bits, as well, right?

    Output ranges:

    Tukey68 = 0-2040
    Tukey45 = 0-1020
    Hann30 = 0-510
    Blackman22 = 0-256

    Did you have to re-allocate some bits for your ~80-point cascaded window?

    I used the trigger bits. I just wanted to see what 80 taps looked like. 68 taps are pretty good, actually.
  • TonyB_, for an RC-type smoothing filter, it would be ideal to have something that goes to the maximum value for its number of bits, like a sum of $7FF, $3FF, $1FF, or $FF. Any trick we can employ to get Tukey68 to sum to $7FF, instead of $7F8?

    We could get there with 'sum[10:0] + sum[10:8]. Maybe that could be part of the smoothing filter.
  • cgraceycgracey Posts: 10,733
    edited 2018-12-15 - 16:28:50
    Actually, we need a sum that goes to $FFF if we are going to get a 12-bit smoothed sample.
  • Thinking more, we just need a sum that has 12 contiguous 1's in its top bits.
  • TonyB_TonyB_ Posts: 1,075
    edited 2018-12-15 - 17:03:57
    Chip, I'll look into it now. A long Tukey-type window is definitely the best way to get more than an eight-bit output every clock as I don't think we have the logic for an extra filter.
    Formerly known as TonyB
  • TonyB_ wrote: »
    Here are the three four windows for the BASIC program above:
    Tukey 21/40	"Tukey68"
     1, 2, 4, 6, 8,11,14,17,20,23,26,29,32,34,36,38,39	Ramp up/down =  340 x 2
    40[34]							Plateau      = 1360
    39,38,36,34,32,29,26,23,20,17,14,11, 8, 6, 4, 2, 1	Grand total  = 2040, /8 = 255
    
    Tukey 19/34	"Tukey45"
     1, 2, 4, 6, 8,11,14,17,20,23,26,28,30,32,33		Ramp up/down =  255 x 2
    34[15]							Plateau      =  510
    33,32,30,28,26,23,20,17,14,11, 8, 6, 4, 2, 1		Grand total  = 1020, /4 = 255
    
    Hann 19/34	"Hann30"
     1, 2, 4, 6, 8,11,14,17,20,23,26,28,30,32,33		Ramp up/down =  255 x 2	
    33,32,30,28,26,23,20,17,14,11, 8, 6, 4, 2, 1		Grand total  =  510, /2 = 255
    
    Blackman 15/24	"Blackman22"
     1, 2, 4, 6, 8,11,14,17,20,22,23			Ramp up/down =  128 x 2	
    23,22,20,17,14,11, 8, 6, 4, 2, 1			Grand total  =  256 *** clamp to 255 ***
    

    I'm curious to know how these windows affect the rise and fall times of square waves. The new Blackman window above is the shortest and thus should have the fastest response.
    WindowFn  Vpp98%      StdDev     HFNoisePower     Length      freq -3dB   freq -6dB
    blackman22    5.5      1.42161       6.9713           22      7.93457      10.9863
    hann30     3.0625     0.851604     0.567518           28      5.98145      8.30078
    
    
    1200 x 900 - 30K
    James https://github.com/SaucySoliton/

    Invention is the Science of Laziness
  • TonyB_ wrote: »
    Chip, I'll look into it now. A long Tukey-type window is definitely the best way to get more than an eight-bit output every clock as I don't think we have the logic for an extra filter.

    We can repurpose the 17 trigger bits:

    error[11:0] = input[11:0] - filter[16:5]
    filter[16:0] = filter[16:0] + {{5{error[11]}}, error[11:0]}
    sample[11:0] = filter[16:5]
  • jmgjmg Posts: 12,887
    cgracey wrote: »
    Thinking more, we just need a sum that has 12 contiguous 1's in its top bits.
    Is that essential, given that’s well outside the rails on the ADC ?
    I guess $FFF is useful for easy clipping sense on the higher gain ranges, but 2040 could also be tested for ?
  • TonyB_TonyB_ Posts: 1,075
    edited 2018-12-15 - 19:48:44
    cgracey wrote: »
    TonyB_ wrote: »
    Chip, I'll look into it now. A long Tukey-type window is definitely the best way to get more than an eight-bit output every clock as I don't think we have the logic for an extra filter.

    We can repurpose the 17 trigger bits:

    error[11:0] = input[11:0] - filter[16:5]
    filter[16:0] = filter[16:0] + {{5{error[11]}}, error[11:0]}
    sample[11:0] = filter[16:5]

    The main issue with the Tukey/Hann/Blackman windows is their max values are only about half of the cascaded moving averages (CMA for short).

    As an alternative, with fairly minor tap changes and a little bit of skipping, the long CMA can fit into 69 of the 70 available taps including zeroes, as follows:
      +1 +2 +3 +4 +5 +6 +7 +8 +9 +8 +7 +6 +5 +4 +3 +2 +1 +0
    
     0, 1, 3, 6,10,15,21,28,36,45,53,60,66,71,75,78,80,__,		sum =  648 \
                                                          80[35]	sum = 2800  > 4096
    __,80,78,75,71,66,60,53,45,36,28,21,15,10, 6, 3, 1, 0		sum =  648 /
    
      -1 -2 -3 -4 -5 -6 -7 -8 -9 -8 -7 -6 -5 -4 -3 -2 -1 -0
    
    What would have been 81 is skipped twice. I've shown 80 as part of the ramps for clarity (I hope). Some skipping is needed for the other windows, too.
    Formerly known as TonyB
  • Ignoring zeroes for naming purposes, this new CMA67 has a max value of 80 and Tukey68 has a max of 40.
    Formerly known as TonyB
  • cgraceycgracey Posts: 10,733
    edited 2018-12-15 - 20:50:09
    TonyB_, what are these CMA filters you keep mentioning?
  • Wait, do you mean continuous moving average? That would make sense.
  • cgracey wrote: »
    TonyB_, what are these CMA filters you keep mentioning?

    Your new triple-integrated filters as described by Saucy:
    http://forums.parallax.com/discussion/comment/1457960/#Comment_1457960
    Formerly known as TonyB
  • But those aren't really cascaded moving average filters, because they don't have any moving averages, right?
  • cgracey wrote: »
    But those aren't really cascaded moving average filters, because they don't have any moving averages, right?

    From The Scientist and Engineer's Guide to Digital Signal Processing:
    As the name implies, the moving average filter operates by averaging a number of points from the input signal to produce each point in the output signal... Multiple-pass moving average filters involve passing the input signal through a moving average filter two or more times.
    Formerly known as TonyB
  • cgraceycgracey Posts: 10,733
    edited 2018-12-15 - 21:39:26
    But those filters I made just keep summing error terms, not tracking some specific number of samples.
  • cgracey wrote: »
    But those filters I made just keep summing error terms, not tracking some specific number of samples.

    As best as I can tell, the response is the same. I think the triple integrated implementation is more efficient than literally using moving average filters. The reason for that is bit growth. So the first filter needs one bit of memory per sample. Assuming we track the delta of the sum instead of the absolute sum, we get a 2 bit delta output from the first filter. (The moving average sum can go up or down by at most 1 each clock cycle.) But then we need 2 bits per sample for the next filter. And 3 bits per sample for the final filter. So we use a bit more memory, and still need to integrate the output 3 times.
    James https://github.com/SaucySoliton/

    Invention is the Science of Laziness
  • One could see error values as deltas. Summing those is essentially an average centered on some value, is it not?

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • cgraceycgracey Posts: 10,733
    edited 2018-12-15 - 22:57:13
    potatohead wrote: »
    One could see error values as deltas. Summing those is essentially an average centered on some value, is it not?

    That is how I see it. It acts just like an RC filter. I'm trying to figure out how to introduce the inductors, as well, to get better performance, more like a pi filter.
  • cgracey wrote: »
    Does anyone have any better ideas than the filter I implemented to do 16-bit conversions? It was a very simple notion and it works well, but there may be some better techniques. Maybe something else would take less logic, or have better pass-band characteristics, or settle faster.

    Being able to grab a 16-bit conversion whenever you want it is really nice.

    Maybe the scope filter could substitute for some of the stages.
    James https://github.com/SaucySoliton/

    Invention is the Science of Laziness
  • cgracey wrote: »
    Does anyone have any better ideas than the filter I implemented to do 16-bit conversions? It was a very simple notion and it works well, but there may be some better techniques. Maybe something else would take less logic, or have better pass-band characteristics, or settle faster.

    Being able to grab a 16-bit conversion whenever you want it is really nice.

    Maybe the scope filter could substitute for some of the stages.

    Yes! I think it would be good to use the longest Tukey as the input to the recursive averaging filter.
  • potatoheadpotatohead Posts: 9,688
    edited 2018-12-16 - 00:02:30
    That is how I see it. It acts just like an RC filter.

    Totally. Once you all broke it down, I could see that and thought it very clever. It's very interesting how math can work sometimes.

    We have lots of higher order functions that get us places in a few, or even one step. This kind of approach, iterating and accumulating, takes many steps. Seems like old world ancients type methods brought forward into our modern age do make sense. It's just an application problem. We've still got all the old ways, but we do not always see how they can be used today. And that's expected, because we also have the modern means and methods. Few people go looking, or at least it seems to me that way.

    But, at this level, where it's silicon, and fast and simple can make sense, doing that looking also makes sense. Honestly, this whole discussion has been very illuminating to me personally. Good stuff.

    Re: Inductor.

    Sure seems like it's going to be a subtraction, out of phase, and out of time somehow. Very hard to picture. May also be selective skips too. Like the absence of an operation when the inductor would assert itself in the process. Something like that. There isn't really anything else, other than maybe a parallel stream of bits, to represent that domain, to be combined at the accumulator.






    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • cgracey wrote: »
    cgracey wrote: »
    Does anyone have any better ideas than the filter I implemented to do 16-bit conversions? It was a very simple notion and it works well, but there may be some better techniques. Maybe something else would take less logic, or have better pass-band characteristics, or settle faster.

    Being able to grab a 16-bit conversion whenever you want it is really nice.

    Maybe the scope filter could substitute for some of the stages.

    Yes! I think it would be good to use the longest Tukey as the input to the recursive averaging filter.

    Now it's my turn. Chip, what is this recursive averaging filter?

    I haven't been talking about the 4th-order 22-bit filter that returns a 16-bit sample every clock. When I saw it was 50 ALMs bigger than the windowed filters I moved on.
    Formerly known as TonyB
  • The Sinc's are recursive.
    "There's no huge amount of massive material hidden in the rings that we can't see, the rings are almost pure ice."
  • How can Scope and Sinc3 modes operate at the same time?
    Formerly known as TonyB
  • Stacking filters covers longer time, so extends overall filtering effects. That's the best generalisation I can muster.

    "There's no huge amount of massive material hidden in the rings that we can't see, the rings are almost pure ice."
  • TonyB_TonyB_ Posts: 1,075
    edited 2018-12-16 - 11:42:32
    cmafilter(8,8,16) = thirdorderfilter(8,0)
    cmafilter(4,4,8) = thirdorderfilter(4,0)
    cmafilter(4,4,16) = thirdorderfilter(4,8)
    cmafilter(8,8,32) = thirdorderfilter(8,16)
    cmafilter(8,8,64) = thirdorderfilter(8,48)

    cmafilter(x,y,z) is a cascaded moving average. It means filter by a moving average of length x. Then filter the output of that by a moving average filter of length y. Do it again with a moving average of length z. If all 3 numbers were the same it would be a sinc3 filter. This is slightly more general. We basically have a sinc3 with the center part lengthened.

    A short name is handy and, for want of anything better, I'm calling the new window functions CMAx as follows:

    cmafilter(4,4,8) = thirdorderfilter(4,0) = CMA14
    cmafilter(4,4,16) = thirdorderfilter(4,8) = CMA22
    cmafilter(8,8,16) = thirdorderfilter(8,0) = CMA30
    cmafilter(8,8,32) = thirdorderfilter(8,16) = CMA46
    cmafilter(8,8,64) = thirdorderfilter(8,48) = CMA78

    As CMA78 is too big to fit, I created a new CMA67 to replace it earlier today:
    http://forums.parallax.com/discussion/comment/1458014/#Comment_1458014

    Below is list of CMAx and corresponding Tukey/Hann/Blackman for the four windows available in scope mode. I've doubled the Tukey and Hann values for easier comparison.
    CMA67
     1, 3, 6,10,15,21,28,36,45,53,60,66,71,75,78		[15] Ramp up   =  568 \
    80[37]							[37] Plateau   = 2960  > 4096
    78,75,71,66,60,53,45,36,28,21,15,10, 6, 3, 1		[15] Ramp down =  568 /
    
    Tukey68 * 2
     2, 4, 8,12,16,22,28,34,40,46,52,58,64,68,72,76,78	[17] Ramp up   =  680 \
    80[34]							[34] Plateau   = 2720  > 4080
    78,76,72,68,64,58,52,46,40,34,28,22,16,12, 8, 4, 1	[17] Ramp down =  680 /
    
    CMA46
     1, 3, 6,10,15,21,28,36,43,49,54,58,61,63		[14] Ramp up   =  448 \ 
    64[18]							[18] Plateau   = 1088  > 2048
    63,61,58,54,49,43,36,28,21,15,10, 6, 3, 1		[14] Ramp down =  448 /
    
    Tukey45 * 2
     2, 4, 8,12,16,22,28,34,40,46,52,56,60,64,66		[15] Ramp up   =  510 \
    68[15]							[15] Plateau   = 1020  > 2040
    66,64,60,56,52,46,40,34,28,22,16,12, 8, 4, 1		[15] Ramp down =  510 /
    
    CMA30
     1, 3, 6,10,15,21,28,36,43,49,54,58,61,63		[14] Ramp up   =  448 \ 
    64[2]							 [2] Plateau   =  128  > 1024
    63,61,58,54,49,43,36,28,21,15,10, 6, 3, 1		[14] Ramp down =  448 /
    
    Hann30 * 2
     2, 4, 8,12,16,22,28,34,40,46,52,56,60,64,66		[15] Ramp up   =  510 \
    									       > 1020
    66,64,60,56,52,46,40,34,28,22,16,12, 8, 4, 1		[15] Ramp down =  510 /
    
    CMA22
     1, 3, 6,10,13,15					 [6] Ramp up   =   48 \ 
    16[10]							[10] Plateau   =  160  > 256
    15,13,10, 6, 3, 1					 [6] Ramp down =   48 /
    
    Blackman22
     1, 2, 4, 6, 8,11,14,17,20,22,23			[11] Ramp up   =  128 \	
    									       > 256
    23,22,20,17,14,11, 8, 6, 4, 2, 1			[11] Ramp down =  128 /
    

    Skipping allows for alternatives to CMA22 that sum to 256 or 512.

    CMA67 has not been tested yet. It will give us a 12-bit sample on every clock and one more config bit compared to Tukey68. I think separate graphs for each of these four pairs above would be helpful because it's a straight choice between one set or the other.
    Formerly known as TonyB
Sign In or Register to comment.