Perhaps I'm not understanding what a "sample" is. I had assumed that, on every clock, one bit enters the shift register from the comparator and marches through the shift register until it exits the other end. In the process, it gets multiplied, in turn, by each of the weights. The ADC value, then, at each clock, is the weighted sum of whatever bits are in the shift register at any particular time. Is that not correct?
Perhaps I'm not understanding what a "sample" is. I had assumed that, on every clock, one bit enters the shift register from the comparator and marches through the shift register until it exits the other end. In the process, it gets multiplied, in turn, by each of the weights. The ADC value, then, at each clock, is the weighted sum of whatever bits are in the shift register at any particular time. Is that not correct?
Close, but not quite.
There are chained wide adders, and those keep the running totals, across many samples (Similar to how a NCO can work), and that is also why these filters have a settling time greater than a single sample.
That also means more than just filter length bits are at work here. (but you do not need 256 x 256 wide samples to reach 16 bits)
This is an interesting topic. Can you really get 8-bit precision with 70 bits?
See below graph from AMC1035 device, shows the ENOB of the AMC1035 with different oversampling ratios on a sinc3 filter
That shows a sinc3 filter can give 8 bits in 20 samples, so Chip's scope mode could work to ~10MHz sample rates ( 200MHz SysCLK) using just sinc3
If the added logic of the custom/extra scope-mode filters in each pin proves too much, maybe that can be a plan-B / plan-C ? (not as good as what Chip has now, but it is smaller)
Okay, I guess what I'm still not understanding is Chip's assertion that the bit order matters. How can this be true if each bit, as it gets shifted through the register, gets weighted with each of the weights, irrespective of any prior framing constraints?
Also, jmg provided the vital clue for the added resolution: that the ADC output does not rely upon just one 70-bit sample, but rather upon multiple 70-bit samples from the bitstream. But what I'm still not clear about is when you decide to dump the running totals and start over. Or do the totals continuously decay, RC filter fashion? If the latter, the filter is no longer a FIR filter, but an IIR filter, and you're getting the additional resolution at the expense of settling time.
I don't think that's 20 samples... It's an oversampling ratio of 20...
you are right, it means you can get a new sinc3 8b output, at 10MHz rates for a 200MHz sysclk (Assuming the ADC cell works sensibly at 200MHz).
Chip's scope mode delivers a rather higher reading rate than that, but costs more logic. See the triangle wave tests, for the delay times.
Okay, I guess what I'm still not understanding is Chip's assertion that the bit order matters. How can this be true if each bit, as it gets shifted through the register, gets weighted with each of the weights, irrespective of any prior framing constraints?
Also, jmg provided the vital clue for the added resolution: that the ADC output does not rely upon just one 70-bit sample, but rather upon multiple 70-bit samples from the bitstream. But what I'm still not clear about is when you decide to dump the running totals and start over.
Or do the totals continuously decay, RC filter fashion?
If the latter, the filter is no longer a FIR filter, but an IIR filter,
and you're getting the additional resolution at the expense of settling time.
-Phil
Hi Phil,
that exactly was my 'feeling' which I stated many posts ago,
but can not verify it since I did not see a full block diagram of the whole 'thing' yet.
Maybe a full diagram would really help ...
As this discussion proceeds, the question gains volume, why there are so different perseptions of one reality.
Give me another try:
There is a couple of number in the range 0 to 9, randomly distributed in a time series. We calculate the moving average of the five last values. Let the first random numbers be 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 . Doesn't look like random numbers? Those numbers are not less random then 5, 5, 5, 5, 5, 5, 5, 5, 5, 5! or
1, 4, 6, 2, 6, 8, 2, 0, 0, 8. As there are 9,999,999,999 +1 different possibilities and my examples are just one time in this number range
But what about the average of the examples? 4.5 , 5 , 2,9 While originally the number range was 9 (0-9), now the range is 2.1, what obviously is less. But now we could say, the smallest increment is .1 (2.9 to 3) so we have 21 possible values, we gained more bits.
We see, there are many ways to interpret the result.
What we do with the filter: we add the filter components by multiplying them with the data stream = 0 or 1.
Again: look from the perspective of correlation:
the tukey coefficients are not more then a signal limited in time that is correlated with an incoming data stream. If this data stream consists of bytes in the same range as the coefficients, it is obvious, that we have a correlation. Now let the signal strength dwindle, so in the end, the signal is just a stream of 0 and 1. Now we would say: it is just noise! But, miracle: the correlation signal shows a clean signal, if there was a hidden structure in the data stream. The tukey coefficients, like any other set, just looks for structures in the data stream of themselves. Here we see, on an elementary level, what the so called filter bubble in the social media actually does: it amplifies the presence of news, we like to hear.
So, Chip, if the bit order matters, how do you know when to "pull the trigger" and sample the bitstream? Is there a certain pattern in those 70 bits that you're looking for to know that they're properly framed (i.e. "lined up") with the filter factors?
And if the answer to my above question is in the negative, try the following experiment: set the DAC value to a constant, such that the eight-bit value ends in %01. Or, better yet, apply a 1.5V input from a battery. See how much the filtered ADC bounces around. (I'm wrestling with the possibility that the input voltage has to be moving, relative to the period of those 70 bits, for your scheme to work.)
In any event, before committing to silicon, we need to understand why the filter works and what its limitations are, not just whether it works under certain defined conditions.
So, Chip, if the bit order matters, how do you know when to "pull the trigger" and sample the bitstream? Is there a certain pattern in those 70 bits that you're looking for to know that they're properly framed (i.e. "lined up") with the filter factors?
-Phil
The lobes make it so the phase doesn't matter. Consider, also, that the bit patterns cycle within 6-7 clocks. The lobes must be longer than the bit cycling. Symmetrical lobes on either side of the plateau are critical. I visualize the filter not as a bit shifter, but a pipe through which spinning vortices pass.
The filter should give the same result regardless of when the sample is taken. Assuming the input is a constant voltage. The output should be a constant as well. The rectangular window works well if a whole number of bit patterns fits inside of it.
In the real world, the bit patterns are unlikely to match the interval over which we sum. By tapering the edges smoothly we reduce the effects of having partial patterns in our measurement interval.
Here's a test you can do: Assume the duty cycle of the ADC is 1/6, that is a bit pattern like [1 0 0 0 0 0] repeated. Take a moving average of 64 bits. Your output varies between 10/64 and 11/64. Now, take a moving average of those numbers. Your calculation takes into account twice as many bits now, but your peak-to-peak noise in the output decreased by a factor of 32. Do it again and the number of bits as inputs increases by 1.5 (3x the original window) and noise decreases by a factor of 3/128.
So a rectangular window length 192 (3*64) has 1/3 the noise of a length 64 rectangle.
The sinc3 window length 190 has 3/4096 the noise of a length 64 rectangle.
These are the lobes of the filter coefficients? If so, where does your assertion that the shift register bit order matters come into play?
Consider, also, that the bit patterns cycle within 6-7 clocks.
Really? If you're outputting a constant 8-bit voltage ending in %01, say, your cycle period will be longer than 6-7 bits. It has to be to accommodate the LSBs.
These are the lobes of the filter coefficients? If so, where does your assertion that the shift register bit order matters come into play?
-Phil
Yes, by lobes, I mean the raised-cosine coefficients at the ends of the filter, not the static plateau coefficients in the middle.
I found through experimentation that changing the order of the bits garbles up the conversion.
It has to do with what ramps up now and ramps down later. The lobes are like mirrors, so that rough stuff coming in gets cancelled by rough stuff going out. Remember that the rough stuff has a consistent pattern in the time it takes to go into and out of the shifter.
I guess I'll have to write a simulation to totally understand this process...
In the meantime, would it be possible for you to do the 1.5V battery experiment? I would really like to see how much the filtered ADC output gets dithered by this process. I would almost lay money that the dithering encroaches upon all but the six MSBs of the ADC result.
I guess I'll have to write a simulation to totally understand this process...
In the meantime, would it be possible for you to do the 1.5V battery experiment? I would really like to see how much the filtered ADC output gets dithered by this process. I would almost lay money that the dithering encroaches upon all but the six MSBs of the ADC result.
Thanks, Chip! I know I've been a PITA in this thread, and I appreciate your bearing with me; but I really do need to drill down into the guts of this process to verify, in my mind, that there's really something there.
Another useful ADC test is to plot the INL and DNL for a triangle sweep, from a 'much better' DAC.
For this, you record the offset from the ADC step, to the ideal step, and this can give fractional LSB results ( AD7403 DNL is inside 0.2LSB ).
The AD7403 Data Figs 12,13,14,15 show the DNL, INL and code histogram for an fixed input, when using fMCLKIN = 20 MHz, using a sinc3 filter with a 256 oversampling ratio (OSR),
Thanks, Chip! I know I've been a PITA in this thread, and I appreciate your bearing with me; but I really do need to drill down into the guts of this process to verify, in my mind, that there's really something there.
-Phil
Thanks for your persistence Phil.
It all looks like smoke and mirrors to me but I am not an analog person.
I don't know if it has been linked so far, but, perhaps, looking at figure 3, page 5 of the following document could help understanding why the filtering/smoothing mechanisms are that succesfull in removing that much noise, having only the samplig bitstreams to work with.
The filter should give the same result regardless of when the sample is taken. Assuming the input is a constant voltage. The output should be a constant as well. The rectangular window works well if a whole number of bit patterns fits inside of it.
In the real world, the bit patterns are unlikely to match the interval over which we sum. By tapering the edges smoothly we reduce the effects of having partial patterns in our measurement interval.
Here's a test you can do: Assume the duty cycle of the ADC is 1/6, that is a bit pattern like [1 0 0 0 0 0] repeated. Take a moving average of 64 bits. Your output varies between 10/64 and 11/64. Now, take a moving average of those numbers. Your calculation takes into account twice as many bits now, but your peak-to-peak noise in the output decreased by a factor of 32. Do it again and the number of bits as inputs increases by 1.5 (3x the original window) and noise decreases by a factor of 3/128.
So a rectangular window length 192 (3*64) has 1/3 the noise of a length 64 rectangle.
The sinc3 window length 190 has 3/4096 the noise of a length 64 rectangle.
Saucy, have you done a frequency response graph for CMA(16,16,32)?
Also is the following correct?
CMA(8,8,8), length = 24, sum = 512
0, 1, 3, 6,10,15,21,28,36,42,46,48 ramp up = 256
48,46,42,36,28,21,15,10, 6, 3, 1, 0 ramp down = 256
The ramps are not symmetrical about the midpoints.
Note that I include the two zeroes in the length now as this matches x+y+z.
The debate isn't about removing the noise, it's about getting 8bit resolution (256 levels) samples out of only 64-70 bit samples.
Hi Roy Eltham
I know it's not (only) about noise, but if you read the three paragraphs following figure 3, you could gain an insight of how that much information can be extracted from the fewer bits provided by the oversampling ratio (Kfs).
In my humble thinking, if there would be not any kind of noise at all, the problem of knowing the analog value being sensed at the sigma-delta ADC input, would be only a matter of avoid loosing any bit of information, and also being ensured that each one represents a single and exact step of voltage or current being accounted at the internal integrator node.
Also, one would need to understand the meaning of "00000001", "01010101" and "11111110" repeating patterns, due to their direct relationship to the values they represent.
And all this, being pass band limited, due the same oversampling (and noise shaping) ratio limitations.
If one needs to do analog sampling at, says, 25 MHz, then Sigma-Delta would not be the ADC of choice. It´ll need a flash ADC to attain his goals.
So the whole problem of reading the analog value, under Sigma-Delta constraints, would fall back to some kind of fault-less communication link, that would never drop any bit of information, in order to prove 100% reliable.
I guess I'll have to write a simulation to totally understand this process...
In the meantime, would it be possible for you to do the 1.5V battery experiment? I would really like to see how much the filtered ADC output gets dithered by this process. I would almost lay money that the dithering encroaches upon all but the six MSBs of the ADC result.
-Phil
The windowed weighting does not solve every problem, for example, say you have a window of 100 bits with triangular weighting, which would yield a number between 0 and 2550, the wrong way to look at the scheme would say "I can resolve an analog signal to within 1/2550th, all within 100 bit periods!" Say the incoming bit stream only has a single 1 bit in a thousand, you would not get regular values toggling between 2 & 3 (don't we wish). In fact 9 times out of 10 you will get a 0 value, and the remaining instance you will get a random number between 1 and 50.
So, realistically you still need a sampling window large enough to catch your "1 in every M bits" if you want a valid number every sample. An example where the windowing really helps is say your period is 1 bit out of every 48, still with a 100-bit window. For an evenly weighted window, you will almost always get a value of 2, and every once in a blue moon you will get the value of 3, equating to 0.02 or 0.03 full scale. With the 100-bit triangle-weighted window you get either 53 or 54 or (rarely) 55, which /2550 is ~0.02078 or 0.02118 or 0.02157, usually much closer to the correct value of ~0.02083.
thanks,
Jonathan
Edit: If you do need to resolve to a resolution smaller than 1/#_sampled_bits, the non-regular windowing functions can *still* help reduce the number of sampled values that need to be averaged to get the correct value, as long as the incoming 1 bits are not locked to a specific place in the sampling window, and in this instance it is actually a good thing to have some noise on the incoming analog signal, to jitter the high bits' positions around.
Consider that from GND to VIO, patterns range from 1/6 to 5/6.
In thinking about Sinc3, which triple-integrates the ADC bits, the early samples have a much bigger effect on the last integrator than the late samples. It is like a perpetual exponential bit escalator. Bit positions matter.
I guess I'll have to write a simulation to totally understand this process...
In the meantime, would it be possible for you to do the 1.5V battery experiment? I would really like to see how much the filtered ADC output gets dithered by this process. I would almost lay money that the dithering encroaches upon all but the six MSBs of the ADC result.
-Phil
Nope!
Note that ADC steps are larger than DAC steps. It might even be worthwhile to output 10 bits or so. It may look like the output changes before the input. That's just because the output data is shorter than the input but still begins at 1 on the X axis. I don't care.
The filter should give the same result regardless of when the sample is taken. Assuming the input is a constant voltage. The output should be a constant as well. The rectangular window works well if a whole number of bit patterns fits inside of it.
In the real world, the bit patterns are unlikely to match the interval over which we sum. By tapering the edges smoothly we reduce the effects of having partial patterns in our measurement interval.
Here's a test you can do: Assume the duty cycle of the ADC is 1/6, that is a bit pattern like [1 0 0 0 0 0] repeated. Take a moving average of 64 bits. Your output varies between 10/64 and 11/64. Now, take a moving average of those numbers. Your calculation takes into account twice as many bits now, but your peak-to-peak noise in the output decreased by a factor of 32. Do it again and the number of bits as inputs increases by 1.5 (3x the original window) and noise decreases by a factor of 3/128.
So a rectangular window length 192 (3*64) has 1/3 the noise of a length 64 rectangle.
The sinc3 window length 190 has 3/4096 the noise of a length 64 rectangle.
Saucy, have you done a frequency response graph for CMA(16,16,32)?
Also is the following correct?
CMA(8,8,8), length = 24, sum = 512
0, 1, 3, 6,10,15,21,28,36,42,46,48 ramp up = 256
48,46,42,36,28,21,15,10, 6, 3, 1, 0 ramp down = 256
The ramps are not symmetrical about the midpoints.
Note that I include the two zeroes in the length now as this matches x+y+z.
2. Yes, that's the same that my code generates.
1. Probably, it was easier to make a new one than to look for it.
I think I get it now... The DFSDM configurator page in the spreadsheet shows you can get 16-bit data with oversampling ratio of 9 and a 5th order sinc filter. Sinc filter is just a moving average.
They call it "moving average", but really it's a moving sum, which is how the range of 16-bits can be achieved... You are summing sums of 9, five times...
So, that's 16-bit output from around 9*5=45 bits out of 1-bit ADC.
Reason it works is because of all the averaging.
Only works when input frequency range is small compared to sample frequency...
Comments
That is how it works, Phil.
There are chained wide adders, and those keep the running totals, across many samples (Similar to how a NCO can work), and that is also why these filters have a settling time greater than a single sample.
That also means more than just filter length bits are at work here. (but you do not need 256 x 256 wide samples to reach 16 bits)
See below graph from AMC1035 device, shows the ENOB of the AMC1035 with different oversampling ratios on a sinc3 filter
That shows a sinc3 filter can give 8 bits in 20 samples, so Chip's scope mode could work to ~10MHz sample rates ( 200MHz SysCLK) using just sinc3
If the added logic of the custom/extra scope-mode filters in each pin proves too much, maybe that can be a plan-B / plan-C ? (not as good as what Chip has now, but it is smaller)
Also, jmg provided the vital clue for the added resolution: that the ADC output does not rely upon just one 70-bit sample, but rather upon multiple 70-bit samples from the bitstream. But what I'm still not clear about is when you decide to dump the running totals and start over. Or do the totals continuously decay, RC filter fashion? If the latter, the filter is no longer a FIR filter, but an IIR filter, and you're getting the additional resolution at the expense of settling time.
-Phil
you are right, it means you can get a new sinc3 8b output, at 10MHz rates for a 200MHz sysclk (Assuming the ADC cell works sensibly at 200MHz).
Chip's scope mode delivers a rather higher reading rate than that, but costs more logic. See the triangle wave tests, for the delay times.
that exactly was my 'feeling' which I stated many posts ago,
but can not verify it since I did not see a full block diagram of the whole 'thing' yet.
Maybe a full diagram would really help ...
Give me another try:
There is a couple of number in the range 0 to 9, randomly distributed in a time series. We calculate the moving average of the five last values. Let the first random numbers be 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 . Doesn't look like random numbers? Those numbers are not less random then 5, 5, 5, 5, 5, 5, 5, 5, 5, 5! or
1, 4, 6, 2, 6, 8, 2, 0, 0, 8. As there are 9,999,999,999 +1 different possibilities and my examples are just one time in this number range
But what about the average of the examples? 4.5 , 5 , 2,9 While originally the number range was 9 (0-9), now the range is 2.1, what obviously is less. But now we could say, the smallest increment is .1 (2.9 to 3) so we have 21 possible values, we gained more bits.
We see, there are many ways to interpret the result.
What we do with the filter: we add the filter components by multiplying them with the data stream = 0 or 1.
Again: look from the perspective of correlation:
the tukey coefficients are not more then a signal limited in time that is correlated with an incoming data stream. If this data stream consists of bytes in the same range as the coefficients, it is obvious, that we have a correlation. Now let the signal strength dwindle, so in the end, the signal is just a stream of 0 and 1. Now we would say: it is just noise! But, miracle: the correlation signal shows a clean signal, if there was a hidden structure in the data stream. The tukey coefficients, like any other set, just looks for structures in the data stream of themselves. Here we see, on an elementary level, what the so called filter bubble in the social media actually does: it amplifies the presence of news, we like to hear.
-Phil
In any event, before committing to silicon, we need to understand why the filter works and what its limitations are, not just whether it works under certain defined conditions.
Thanks,
-Phil
The lobes make it so the phase doesn't matter. Consider, also, that the bit patterns cycle within 6-7 clocks. The lobes must be longer than the bit cycling. Symmetrical lobes on either side of the plateau are critical. I visualize the filter not as a bit shifter, but a pipe through which spinning vortices pass.
In the real world, the bit patterns are unlikely to match the interval over which we sum. By tapering the edges smoothly we reduce the effects of having partial patterns in our measurement interval.
Here's a test you can do: Assume the duty cycle of the ADC is 1/6, that is a bit pattern like [1 0 0 0 0 0] repeated. Take a moving average of 64 bits. Your output varies between 10/64 and 11/64. Now, take a moving average of those numbers. Your calculation takes into account twice as many bits now, but your peak-to-peak noise in the output decreased by a factor of 32. Do it again and the number of bits as inputs increases by 1.5 (3x the original window) and noise decreases by a factor of 3/128.
So a rectangular window length 192 (3*64) has 1/3 the noise of a length 64 rectangle.
The sinc3 window length 190 has 3/4096 the noise of a length 64 rectangle.
Really? If you're outputting a constant 8-bit voltage ending in %01, say, your cycle period will be longer than 6-7 bits. It has to be to accommodate the LSBs.
-Phil
Yes, by lobes, I mean the raised-cosine coefficients at the ends of the filter, not the static plateau coefficients in the middle.
I found through experimentation that changing the order of the bits garbles up the conversion.
It has to do with what ramps up now and ramps down later. The lobes are like mirrors, so that rough stuff coming in gets cancelled by rough stuff going out. Remember that the rough stuff has a consistent pattern in the time it takes to go into and out of the shifter.
In the meantime, would it be possible for you to do the 1.5V battery experiment? I would really like to see how much the filtered ADC output gets dithered by this process. I would almost lay money that the dithering encroaches upon all but the six MSBs of the ADC result.
-Phil
I will do this when I get back home.
-Phil
Another useful ADC test is to plot the INL and DNL for a triangle sweep, from a 'much better' DAC.
For this, you record the offset from the ADC step, to the ideal step, and this can give fractional LSB results ( AD7403 DNL is inside 0.2LSB ).
The AD7403 Data Figs 12,13,14,15 show the DNL, INL and code histogram for an fixed input, when using fMCLKIN = 20 MHz, using a sinc3 filter with a 256 oversampling ratio (OSR),
Thanks for your persistence Phil.
It all looks like smoke and mirrors to me but I am not an analog person.
https://analog.com/media/en/training-seminars/tutorials/MT-022.pdf?doc=CN0251.pdf
Hope it helps
Saucy, have you done a frequency response graph for CMA(16,16,32)?
Also is the following correct?
CMA(8,8,8), length = 24, sum = 512
The ramps are not symmetrical about the midpoints.
Note that I include the two zeroes in the length now as this matches x+y+z.
Hi Roy Eltham
I know it's not (only) about noise, but if you read the three paragraphs following figure 3, you could gain an insight of how that much information can be extracted from the fewer bits provided by the oversampling ratio (Kfs).
In my humble thinking, if there would be not any kind of noise at all, the problem of knowing the analog value being sensed at the sigma-delta ADC input, would be only a matter of avoid loosing any bit of information, and also being ensured that each one represents a single and exact step of voltage or current being accounted at the internal integrator node.
Also, one would need to understand the meaning of "00000001", "01010101" and "11111110" repeating patterns, due to their direct relationship to the values they represent.
And all this, being pass band limited, due the same oversampling (and noise shaping) ratio limitations.
If one needs to do analog sampling at, says, 25 MHz, then Sigma-Delta would not be the ADC of choice. It´ll need a flash ADC to attain his goals.
So the whole problem of reading the analog value, under Sigma-Delta constraints, would fall back to some kind of fault-less communication link, that would never drop any bit of information, in order to prove 100% reliable.
Only my 0.02
The windowed weighting does not solve every problem, for example, say you have a window of 100 bits with triangular weighting, which would yield a number between 0 and 2550, the wrong way to look at the scheme would say "I can resolve an analog signal to within 1/2550th, all within 100 bit periods!" Say the incoming bit stream only has a single 1 bit in a thousand, you would not get regular values toggling between 2 & 3 (don't we wish). In fact 9 times out of 10 you will get a 0 value, and the remaining instance you will get a random number between 1 and 50.
So, realistically you still need a sampling window large enough to catch your "1 in every M bits" if you want a valid number every sample. An example where the windowing really helps is say your period is 1 bit out of every 48, still with a 100-bit window. For an evenly weighted window, you will almost always get a value of 2, and every once in a blue moon you will get the value of 3, equating to 0.02 or 0.03 full scale. With the 100-bit triangle-weighted window you get either 53 or 54 or (rarely) 55, which /2550 is ~0.02078 or 0.02118 or 0.02157, usually much closer to the correct value of ~0.02083.
thanks,
Jonathan
Edit: If you do need to resolve to a resolution smaller than 1/#_sampled_bits, the non-regular windowing functions can *still* help reduce the number of sampled values that need to be averaged to get the correct value, as long as the incoming 1 bits are not locked to a specific place in the sampling window, and in this instance it is actually a good thing to have some noise on the incoming analog signal, to jitter the high bits' positions around.
In thinking about Sinc3, which triple-integrates the ADC bits, the early samples have a much bigger effect on the last integrator than the late samples. It is like a perpetual exponential bit escalator. Bit positions matter.
Note that ADC steps are larger than DAC steps. It might even be worthwhile to output 10 bits or so. It may look like the output changes before the input. That's just because the output data is shorter than the input but still begins at 1 on the X axis. I don't care.
1. Probably, it was easier to make a new one than to look for it.
Shows the whole process in detail...
Just go to st.com and search for "DFSDM_tutorial"
There's an appnote to go with it: AN4990
They call it "moving average", but really it's a moving sum, which is how the range of 16-bits can be achieved... You are summing sums of 9, five times...
So, that's 16-bit output from around 9*5=45 bits out of 1-bit ADC.
Reason it works is because of all the averaging.
Only works when input frequency range is small compared to sample frequency...