There is a rational explanation for why this works, but none of us can exactly identify it. I'm pretty sure that it has to do with the tapering periods covering, at least, the <7-bit spans of rise-to-rise patterns in the ADC bitstream data.
I can think of high frequency modulation effects that such a filter might help, but as with any notch filter, effects vary with the exact notch alignments.
Note that SDM layered triangle+sawtooths, vary periods significantly with input voltage.
One test would be to sweep many N-samples, where N varies one count at a time, per set, and log the RMS deviation of a large number of same-N samples, before and after this filter is applied.
Use multiple pins, as they have enough variations to move operating points.
Even with an ideal, noiseless integrator, the start/stop instant can catch the integrator at any portion of 1 bit, which I think means there is +0/+1 count possible at each end, or +0,+1,+2 with both ends.
Early tests did show an improvement with oversampling then division, which would drop those quanta, but that also showed diminishing returns with large divisions.
As the current trapezoidal window has a discontinuous derivative, I've been looking at other, smoother windows, in particular the cosine taper/tapered cosine/Tukey window, which is a combination of Hann and rectangular windows: https://en.m.wikipedia.org/wiki/Window_function
I think we should try to use a well-known and proven window, rather than invent our own. I've implemented a Tukey window with 32 steps up and down that vary from 0-3, giving a maximum value of 64, not 32 as now.
It takes very little logic to create these increments from the outputs of a 5-bit counter.
Chip (or anyone else), would you like to try the Tukey window to see if the quality improves? A 6-bit right shift will be needed at the end. Ideally there should be rounding to get an extra ½ lsb.
If your like me and are having trouble trying to follow what they are talking about , you may get some basic understanding from this free on-line DSP book :
13: Continuous Signal Processing
14: Introduction to Digital Filters
15: Moving Average Filters
16: Windowed-Sinc Filters
Strategy of the Windowed-Sinc
Designing the Filter
Examples of Windowed-Sinc Filters
Pushing it to the Limit
In thinking about this, the tapering is performing a filtering function on that high-frequency bitstream data that you would not want to encounter the splintery ends of, as Jmg just pointed out.
Jmg, this technique has already proven impervious to different sample lengths. I'm pretty sure that as long as the tapering periiod is longer than the cycle period of the bitstream data, whose phase and period are ever-changing, the algorithm works.
As the current trapezoidal window has a discontinuous derivative, I've been looking at other, smoother windows, in particular the cosine taper/tapered cosine/Tukey window, which is a combination of Hann and rectangular windows: https://en.m.wikipedia.org/wiki/Window_function
I think we should try to use a well-known and proven window, rather than invent our own. I've implemented a Tukey window with 32 steps up and down that vary from 0-3, giving a maximum value of 64, not 32 as now.
It takes very little logic to create these increments from the outputs of a 5-bit counter.
Chip (or anyone else), would you like to try the Tukey window to see if the quality improves? A 6-bit right shift will be needed at the end. Ideally there should be rounding to get an extra ½ lsb.
I will try this in just a little bit, TonyB_. I'm anxious to see how it works.
.... I'm pretty sure that as long as the tapering period is longer than the cycle period of the bitstream data, whose phase and period are ever-changing, the algorithm works.
That's part of what worries me - this edge filtering ignores 99% of the information, so some of the time it fails to work.
Key question becomes : If it removes one bit of reading jitter/quanta, some of the time, is that worth the extra silicon being talked about ?
Especially if it comes at the cost of no ADC streamer ?
The more conventional SW method to improve reading quanta effects, is to over sample x2, x4 ,x8 and then (using rounding) divide the totals.
The +0,+1,+2 possible edge effects then go below 1 LSB.
Do you see any indication that we could get better than an 8-bit result out of 256 samples?
Most definitely. That'll be the reason they get used. The stronger filter moves the noise further down and the digital summing naturally adds more bits. I think I read somewhere that the rule of thumb is that for every 8 bits of gained resolution, only 4 of those are effective.
The trade off is lag when using a rolling window. However, as long as aliasing doesn't pop in, it looks like non-rolling also works as one less effective bit than rolling.
Jmg, look at the with/without-windowing pictures I posted. Your eyes will tell you that it's not just working sometimes. It's always working and quite worthy of implementation. This whole thing offends your strict sensibilities. It's just low-passing the initial and terminal sample bits. It does for the ADC what soft--mute does for your ears.
I bet the rounding will have a lot more impact than the subtle window-shape difference.
I think there's quite a big difference in the window shapes, mathematically-speaking. Less weight is given to the samples at the extremities in Tukey and it's nice and smooth. Maybe I'll see some results in the morning.
I tried increments of 1-4 but the maximum value was 82, so I changed to 0-3 and it worked out well. The values shown are the closest integers with no fiddling, just a tiny bit of padding.
I bet the rounding will have a lot more impact than the subtle window-shape difference.
I think there's quite a big difference in the window shapes, mathematically-speaking. Less weight is given to the samples at the extremities in Tukey and it's nice and smooth. Maybe I'll see some results in the morning.
I tried increments of 1-4 but the maximum value was 82, so I changed to 0-3 and it worked out well. The values shown are the closest integers with no fiddling, just a tiny bit of padding.
That would be awesome if the Tukey window shape provided an added improvement. Where we are now is even very good, I think.
What kinds of signals is this intended for? Like any signal appropriate for the sample rate?
It's the cycling in the ADC bitstream that causes the problems. Its period is no greater than 7 bits, so it only takes a handful of taps to filter out.
Lets me ask this another way. Say somebody wanted to sample audio at 12 bits with, I don't know 10khz or something sample rate.
Seems to me, we could sum three or four sine waves, know what that sample should set should look like, and then run this filter against something like that too.
Just trying to get at how broadly useful this may be, and or partially answer the question is it broadly applicable as we think it is?
Lets me ask this another way. Say somebody wanted to sample audio at 12 bits with, I don't know 10khz or something sample rate.
Seems to me, we could sum three or four sine waves, know what that sample should set should look like, and then run this filter against something like that too.
Just trying to get at how broadly useful this may be, and or partially answer the question is it broadly applicable as we think it is?
How the heck did you come up with that Chip?
The only filtering that needs to occur is at Fsys / ~7. That's way beyond the frequency of signals anyone is going to digitize.
It was inspiration. I had been thinking a lot and even dreaming about it. I had this feeling that I was right at the edge of discovery, when it finally came into focus and snapped to grid. At first when I coded it, it didn't work, so I was about to move on when I thought I should check a little harder. I found a bug in my code, fixed it, and all of the sudden it was working perfectly. Almost missed it.
There is no optimum filter for every source of time-series analog data. Depending upon the source of the signal and its characteristics, a binomial filter might outperform a boxcar averager; or a linear filter (e.g. FIR filter) might outperform a non-linear one (e.g. median filter). For that reason, I think it's a mistake to try to incorporate an ADC filter of any sort in hardware, since it might skew the user's results in some cases. Better to let the raw data fall where they may and let the user apply whichever software filter is best for his/her analog source.
As an example, I'm working with a sensor that has extremely noisy output. The distribution is Gaussian, but the variance is quite large. I've finally settled on a median filter of sorts, wherein n samples are taken and sorted, and the middle n/2 samples from the sorted list are averaged. (Try implementing that in hardware!) I prefer working with the raw data and would not want it to be pre-sanitized by a hardware filter.
Chip, you seem a bit disappointed with the raw performance of your ADC. But it is what it is. By airbrushing it with a hardware filter to hide its supposed deficiencies, you're not helping everyone who may be using it and are hurting the prospects for some. It will affect not just the noise introduced by the ADC, but also any noise or other high-frequency components generated by the user's analog output, wherever that may come from. I would vote for dropping this whole train of thought to focus on just getting the P2 finished.
Do you see any indication that we could get better than an 8-bit result out of 256 samples?
Most definitely. That'll be the reason they get used. The stronger filter moves the noise further down and the digital summing naturally adds more bits. I think I read somewhere that the rule of thumb is that for every 8 bits of gained resolution, only 4 of those are effective.
The trade off is lag when using a rolling window. However, as long as aliasing doesn't pop in, it looks like non-rolling also works as one less effective bit than rolling.
Well, it would be awesome to get 16-bit samples at 100KHz. Wouldn't that be funny if somehow we were able to get 24-bit samples?
Well, it would be awesome to get 16-bit samples at 100KHz. Wouldn't that be funny if somehow we were able to get 24-bit samples?
You can get as many digital bits as you like, but keep in mind the P2 noise floor is close to 1mV, so many of those digital bits are simply an illusion.
Chip, you seem a bit disappointed with the raw performance of your ADC. But it is what it is. By airbrushing it with a hardware filter to hide its supposed deficiencies, you're not helping everyone who may be using it and are hurting the prospects for some. It will affect not just the noise introduced by the ADC, but also any noise or other high-frequency components generated by the user's analog output, wherever that may come from. I would vote for dropping this whole train of thought to focus on just getting the P2 finished.
Certainly, I hope this edge filter is made optional...
That would be awesome if the Tukey window shape provided an added improvement. Where we are now is even very good, I think.
With the /32 I'd expect it to be very hard to extract any difference. You would need to do a sweep of INL and DNL, via a 'much better' test DAC as shown above.
Note that a linear ramped filter, can be implemented in hardware with a simple U/D saturating counter, feeding your adder. (no ROM table needed)
This means that the streamer won't have the planned ADC modes, because it would need to make windowed measurements for them to be of acceptable quality and that would over-complicate the streamer.
This new filtering mode is an exciting development, but I think the ADC streamer mode with un-filtered samples could still be useful if the user wishes to implement an alternate filtering algorithm or is making a rapid series of measurements where the least significant bits aren't important.
You can get as many digital bits as you like, but keep in mind the P2 noise floor is close to 1mV, so many of those digital bits are simply an illusion.
Not necessarily! What kills high-resolution measurements is the acquisition time more than any other thing, as 1/f noise becomes more prominent with the longer sample periods.
If it is possible to get more bits in a shorter time, We can get ahead of the 1/f noise.
This means that the streamer won't have the planned ADC modes, because it would need to make windowed measurements for them to be of acceptable quality and that would over-complicate the streamer.
This new filtering mode is an exciting development, but I think the ADC streamer mode with un-filtered samples could still be useful if the user wishes to implement an alternate filtering algorithm or is making a rapid series of measurements where the least significant bits aren't important.
The sad part is that the windowing needs to occur on the original bitstream. Once you have a composite sample, it's too late.
I don't either, but then again, I'm not expert in these things.
But, from what I see here, the concerns are "what if?" types. All good, but the way to get at those is to invert the problem, which is why I posed the though experiment I just did.
So, you will have given that information. Had that been the release silicon, Rev A, what would the discussion be?
Secondly, someone approaching all this for the first time would test the ADC, as any of us would. What do they find out of the ordinary?
If we don't really have solid scenarios that fit either of those lines of reasoning, we are left with a solid feature.
Should we identify a scenario, great! That is a discussion we can all think on and likely resolve, just like all the thousand other ones.
Personally, I see this as a huge win. Tons of people are just going to use the ADC, and it's going to perform for them as expected.
Good.
While that mess of noise is a fun challenge, and it can be compensated for, you all just know there will be a bazillion, "but what, but why?" and a bazillion more, "How do I?" after that.
This way, it's hard to even formulate a material question that needs an answer. Either there are good reasons for that, like what you came up with Chip, works. Or?
Very worst case scenario is we find some edge or corner case somewhere, someday, and it somehow doesn't perform well enough. In that rare case, another component is added, or someone makes a ADC out of some of the pins, done, next.
Okay, given that this has to be done in hardware (although I'm still not convinced), it's really quite an interesting optimization problem:
1) Characterize the noise, i.e. is it white noise, pink noise, Gaussian, ... ? You have to do this first.
2) Write a program that simulates the noise, based upon the characteristics determined in 1).
3) For a total of n clock cycles and m separate coefficients summing to n, what allocation of those of those clock cycles among the coefficients yields the lowest statistical variance in the results from applying the noise in 2)? That, then, becomes a well-defined, classical, multivariate optimization problem.
4) Apply a known optimization technique to search out the best coefficient set, using multiple runs, Monte Carlo style. Simulated annealing comes to mind here, but there are many others. And it may well turn out that the "triangular" coefficient set is the best. But there's no way to tell without going through this exercise first. Otherwise, you're just guessing.
Comments
What Specific frequencies and sample-N did you test this over ?
Did you get before and after ENOB ?
I can think of high frequency modulation effects that such a filter might help, but as with any notch filter, effects vary with the exact notch alignments.
Note that SDM layered triangle+sawtooths, vary periods significantly with input voltage.
One test would be to sweep many N-samples, where N varies one count at a time, per set, and log the RMS deviation of a large number of same-N samples, before and after this filter is applied.
Use multiple pins, as they have enough variations to move operating points.
Even with an ideal, noiseless integrator, the start/stop instant can catch the integrator at any portion of 1 bit, which I think means there is +0/+1 count possible at each end, or +0,+1,+2 with both ends.
Early tests did show an improvement with oversampling then division, which would drop those quanta, but that also showed diminishing returns with large divisions.
I think we should try to use a well-known and proven window, rather than invent our own. I've implemented a Tukey window with 32 steps up and down that vary from 0-3, giving a maximum value of 64, not 32 as now.
The table below shows the accumulator values:
The next table shows the accumulator increments:
It takes very little logic to create these increments from the outputs of a 5-bit counter.
Chip (or anyone else), would you like to try the Tukey window to see if the quality improves? A 6-bit right shift will be needed at the end. Ideally there should be rounding to get an extra ½ lsb.
13: Continuous Signal Processing
14: Introduction to Digital Filters
15: Moving Average Filters
16: Windowed-Sinc Filters
Strategy of the Windowed-Sinc
Designing the Filter
Examples of Windowed-Sinc Filters
Pushing it to the Limit
17: Custom Filters
You can also download the PDF:
https://www.dspguide.com/pdfbook.htm
Jmg, this technique has already proven impervious to different sample lengths. I'm pretty sure that as long as the tapering periiod is longer than the cycle period of the bitstream data, whose phase and period are ever-changing, the algorithm works.
I will try this in just a little bit, TonyB_. I'm anxious to see how it works.
That's part of what worries me - this edge filtering ignores 99% of the information, so some of the time it fails to work.
Key question becomes : If it removes one bit of reading jitter/quanta, some of the time, is that worth the extra silicon being talked about ?
Especially if it comes at the cost of no ADC streamer ?
The more conventional SW method to improve reading quanta effects, is to over sample x2, x4 ,x8 and then (using rounding) divide the totals.
The +0,+1,+2 possible edge effects then go below 1 LSB.
The trade off is lag when using a rolling window. However, as long as aliasing doesn't pop in, it looks like non-rolling also works as one less effective bit than rolling.
I think there's quite a big difference in the window shapes, mathematically-speaking. Less weight is given to the samples at the extremities in Tukey and it's nice and smooth. Maybe I'll see some results in the morning.
I tried increments of 1-4 but the maximum value was 82, so I changed to 0-3 and it worked out well. The values shown are the closest integers with no fiddling, just a tiny bit of padding.
That would be awesome if the Tukey window shape provided an added improvement. Where we are now is even very good, I think.
It's the cycling in the ADC bitstream that causes the problems. Its period is no greater than 7 bits, so it only takes a handful of taps to filter out.
Seems to me, we could sum three or four sine waves, know what that sample should set should look like, and then run this filter against something like that too.
Just trying to get at how broadly useful this may be, and or partially answer the question is it broadly applicable as we think it is?
How the heck did you come up with that Chip?
The only filtering that needs to occur is at Fsys / ~7. That's way beyond the frequency of signals anyone is going to digitize.
It was inspiration. I had been thinking a lot and even dreaming about it. I had this feeling that I was right at the edge of discovery, when it finally came into focus and snapped to grid. At first when I coded it, it didn't work, so I was about to move on when I thought I should check a little harder. I found a bug in my code, fixed it, and all of the sudden it was working perfectly. Almost missed it.
As an example, I'm working with a sensor that has extremely noisy output. The distribution is Gaussian, but the variance is quite large. I've finally settled on a median filter of sorts, wherein n samples are taken and sorted, and the middle n/2 samples from the sorted list are averaged. (Try implementing that in hardware!) I prefer working with the raw data and would not want it to be pre-sanitized by a hardware filter.
Chip, you seem a bit disappointed with the raw performance of your ADC. But it is what it is. By airbrushing it with a hardware filter to hide its supposed deficiencies, you're not helping everyone who may be using it and are hurting the prospects for some. It will affect not just the noise introduced by the ADC, but also any noise or other high-frequency components generated by the user's analog output, wherever that may come from. I would vote for dropping this whole train of thought to focus on just getting the P2 finished.
-Phil
Well, it would be awesome to get 16-bit samples at 100KHz. Wouldn't that be funny if somehow we were able to get 24-bit samples?
Some good example performance plots are in the TI manual for the 18 bit DAC9881 Evaluation Module I linked earlier.
See page 8, Figure 8. INL and DNL Characteristic Plot.
Certainly, I hope this edge filter is made optional...
Note that a linear ramped filter, can be implemented in hardware with a simple U/D saturating counter, feeding your adder. (no ROM table needed)
This new filtering mode is an exciting development, but I think the ADC streamer mode with un-filtered samples could still be useful if the user wishes to implement an alternate filtering algorithm or is making a rapid series of measurements where the least significant bits aren't important.
Not necessarily! What kills high-resolution measurements is the acquisition time more than any other thing, as 1/f noise becomes more prominent with the longer sample periods.
If it is possible to get more bits in a shorter time, We can get ahead of the 1/f noise.
The sad part is that the windowing needs to occur on the original bitstream. Once you have a composite sample, it's too late.
Say this correction was in place already. How would you know?
Only one piece of information would need to be given:
"Acquisition time will be the WXPIN value plus 64, while the number of equivalent whole-bit samples taken will be the WXPIN value plus 33."
It's 33 because SUM(1..32, 32..1)/32 = 33.
So, those 64 attenuated/windowed samples are equivalent to 33 normal samples and are in proportion to the average sample.
I don't see how this could be problematic.
But, from what I see here, the concerns are "what if?" types. All good, but the way to get at those is to invert the problem, which is why I posed the though experiment I just did.
So, you will have given that information. Had that been the release silicon, Rev A, what would the discussion be?
Secondly, someone approaching all this for the first time would test the ADC, as any of us would. What do they find out of the ordinary?
If we don't really have solid scenarios that fit either of those lines of reasoning, we are left with a solid feature.
Should we identify a scenario, great! That is a discussion we can all think on and likely resolve, just like all the thousand other ones.
Personally, I see this as a huge win. Tons of people are just going to use the ADC, and it's going to perform for them as expected.
Good.
While that mess of noise is a fun challenge, and it can be compensated for, you all just know there will be a bazillion, "but what, but why?" and a bazillion more, "How do I?" after that.
This way, it's hard to even formulate a material question that needs an answer. Either there are good reasons for that, like what you came up with Chip, works. Or?
Very worst case scenario is we find some edge or corner case somewhere, someday, and it somehow doesn't perform well enough. In that rare case, another component is added, or someone makes a ADC out of some of the pins, done, next.
1) Characterize the noise, i.e. is it white noise, pink noise, Gaussian, ... ? You have to do this first.
2) Write a program that simulates the noise, based upon the characteristics determined in 1).
3) For a total of n clock cycles and m separate coefficients summing to n, what allocation of those of those clock cycles among the coefficients yields the lowest statistical variance in the results from applying the noise in 2)? That, then, becomes a well-defined, classical, multivariate optimization problem.
4) Apply a known optimization technique to search out the best coefficient set, using multiple runs, Monte Carlo style. Simulated annealing comes to mind here, but there are many others. And it may well turn out that the "triangular" coefficient set is the best. But there's no way to tell without going through this exercise first. Otherwise, you're just guessing.
-Phil