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.
It's not quite a Hann window. There are 3 32s on top. Which was chosen in part because the sum would be 512. I presume a Hann would have a single 32 on top. But we certainly could change it to a Hann window. Is there a good reason to do that?
Hann27 -3dB at 6.3 MHz, -6dB at 8.6 MHz
Tukey29 -3dB at 5.8 MHz, -6dB at 7.9 MHz
Tukey45 -3dB at 3.4 MHz, -6dB at 4.6 MHz
All assume 250MHz sysclock and ignore analog input effects.
-3dB is 50% of the power and 70.7% of the voltage
-6dB is 25% of the power and 50% of the voltage
It would be cool to advertise 5MHz scope mode. But I'm doing this because I though it would be sad to have filters just a little bit too narrow for analog video. I wonder if we could get better resolution at the wide bandwidth by feeding the signal to two or more ADC channels. It should work as long as the ADC noise isn't correlated.
I also compared the original Tukey to a triangular/sinc2 window. The performance seems pretty comparable.
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.
It's not quite a Hann window. There are 3 32s on top. Which was chosen in part because the sum would be 512. I presume a Hann would have a single 32 on top. But we certainly could change it to a Hann window. Is there a good reason to do that?
Hann27 -3dB at 6.3 MHz, -6dB at 8.6 MHz
Tukey29 -3dB at 5.8 MHz, -6dB at 7.9 MHz
Tukey45 -3dB at 3.4 MHz, -6dB at 4.6 MHz
All assume 250MHz sysclock and ignore analog input effects.
-3dB is 50% of the power and 70.7% of the voltage
-6dB is 25% of the power and 50% of the voltage
It would be cool to advertise 5MHz scope mode. But I'm doing this because I though it would be sad to have filters just a little bit too narrow for analog video. I wonder if we could get better resolution at the wide bandwidth by feeding the signal to two or more ADC channels. It should work as long as the ADC noise isn't correlated.
I also compared the original Tukey to a triangular/sinc2 window. The performance seems pretty comparable.
Ah, we could have a mode that looks at 4 contiguous ADC pins to get higher ENOB faster.
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.
Could we use an existing up/down counter for the plateau bits? Count enable = plateau in bit XOR plateau out bit and up/!down = plateau in. Add ramp and plateau values to get output. To detect overflow, if plateau count > 0 and output = 0, then output = FF.
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.
Only 2 bits need muxes. I'm willing to wait for the zeros to shift through the plateau part. But maybe masking all those bits is free because of the register reset lines.
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.
Only 2 bits need muxes. I'm willing to wait for the zeros to shift through the plateau part. But maybe masking all those bits is free because of the register reset lines.
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.
Could we use an existing up/down counter for the plateau bits? Count enable = plateau in bit XOR plateau out bit and up/!down = plateau in. Add ramp and plateau values to get output. To detect overflow, if plateau count > 0 and output = 0, then output = FF.
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.
It's not quite a Hann window. There are 3 32s on top. Which was chosen in part because the sum would be 512. I presume a Hann would have a single 32 on top. But we certainly could change it to a Hann window. Is there a good reason to do that?
Hann27 -3dB at 6.3 MHz, -6dB at 8.6 MHz
Tukey29 -3dB at 5.8 MHz, -6dB at 7.9 MHz
Tukey45 -3dB at 3.4 MHz, -6dB at 4.6 MHz
All assume 250MHz sysclock and ignore analog input effects.
-3dB is 50% of the power and 70.7% of the voltage
-6dB is 25% of the power and 50% of the voltage
It would be cool to advertise 5MHz scope mode. But I'm doing this because I though it would be sad to have filters just a little bit too narrow for analog video. I wonder if we could get better resolution at the wide bandwidth by feeding the signal to two or more ADC channels. It should work as long as the ADC noise isn't correlated.
I also compared the original Tukey to a triangular/sinc2 window. The performance seems pretty comparable.
Yes, you're right. I knew it was not quite a Hann. What if we turn the short plateau 32,32,32 into a peak 32,33,32? Does that show up in the frequency response? Full scale stays at 128.
Also, what are your views on the Sinc3 passband droop? It seems to me that the attenuation could lower the ENOB. Increasing R is intended to increase the ENOB but means more droop. Which effect wins?
I'm thinking about expanded topologies for simple Delta Sigma integrating ADCs. How about multiple integrators, each with a different threshold? This would get rid of the nasty spot at midpoint where you have long runs of 101010101010...
Adding their outputs together would give a noise pattern that is more spread out, and also more information would be in the multi-bit output.
This would have been very easy to build into the current silicon space of the ADC.
The clocked bits would come out in parallel for processing by the core logic. We could easily have done eight of these. Maybe seven would be better, because their outputs would sum to 3 bits.
Imagine 15 integrators with slightly staggered thresholds. It would be good to do the summing in the pad to output a 4-bit value every clock. Every 17 clocks would give you 255 counts.
Then, imagine what windowing and SINC3 filtering could do with that.
I'm thinking about expanded topologies for simple Delta Sigma integrating ADCs. How about multiple integrators, each with a different threshold? This would get rid of the nasty spot at midpoint where you have long runs of 101010101010...
Adding their outputs together would give a noise pattern that is more spread out, and also more information would be in the multi-bit output.
This would have been very easy to build into the current silicon space of the ADC.
The clocked bits would come out in parallel for processing by the core logic. We could easily have done eight of these. Maybe seven would be better, because their outputs would sum to 3 bits.
Multiple integrators are much harder to calibrate.
The weakest link in P2 ADC, is not the integrators anyway, it is the poor PSRR, and the noise floor in the Digital used as Analog stuff...
I'm thinking about expanded topologies for simple Delta Sigma integrating ADCs. How about multiple integrators, each with a different threshold? This would get rid of the nasty spot at midpoint where you have long runs of 101010101010...
Adding their outputs together would give a noise pattern that is more spread out, and also more information would be in the multi-bit output.
This would have been very easy to build into the current silicon space of the ADC.
The clocked bits would come out in parallel for processing by the core logic. We could easily have done eight of these. Maybe seven would be better, because their outputs would sum to 3 bits.
Multiple integrators are much harder to calibrate.
The weakest link in P2 ADC, is not the integrators anyway, it is the poor PSRR, and the noise floor in the Digital used as Analog stuff...
These integrators would always be treated as one. The calibration would be just like now. No need to look at them individually.
I definitely want the SInc3 now, simply because the smartpin can be used for external bitstream timing. I hadn't pondered it much until now but I've always wanted to hook up external bitstream ADCs to get electrical isolation.
Yes, sinc3 seems to be the standard used, ....
at least for the also seemingly 'standard' second order modulators.
Another benefit of a standard-size Sinc3, is the existing analog parts (AMC1035, AD7403 etc) can be used to confirm FPGA operation.
In the datasheet I had to go to chapter 7.1 to finally see it is in deed a second order modulator - which well goes with the Sinc3.
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.
Imagine 15 integrators with slightly staggered thresholds. It would be good to do the summing in the pad to output a 4-bit value every clock. Every 17 clocks would give you 255 counts.
Then, imagine what windowing and SINC3 filtering could do with that.
since a really big improvement via noise shaping comes from higher order modulators
and not primarily from the post filter
- alt least for P3, when the Analog can be redone/extended,
you might want to think about a second order modulator
(as seem to be used in most of the separate modulator ICs)
instead the (I still think - but unconfirmed) P2 first order modulator.
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.
It's not quite a Hann window. There are 3 32s on top. Which was chosen in part because the sum would be 512. I presume a Hann would have a single 32 on top. But we certainly could change it to a Hann window. Is there a good reason to do that?
Hann27 -3dB at 6.3 MHz, -6dB at 8.6 MHz
Tukey29 -3dB at 5.8 MHz, -6dB at 7.9 MHz
Tukey45 -3dB at 3.4 MHz, -6dB at 4.6 MHz
All assume 250MHz sysclock and ignore analog input effects.
-3dB is 50% of the power and 70.7% of the voltage
-6dB is 25% of the power and 50% of the voltage
It would be cool to advertise 5MHz scope mode. But I'm doing this because I though it would be sad to have filters just a little bit too narrow for analog video. I wonder if we could get better resolution at the wide bandwidth by feeding the signal to two or more ADC channels. It should work as long as the ADC noise isn't correlated.
I also compared the original Tukey to a triangular/sinc2 window. The performance seems pretty comparable.
Yes, you're right. I knew it was not quite a Hann. What if we turn the short plateau 32,32,32 into a peak 32,33,32? Does that show up in the frequency response? Full scale stays at 128.
Also, what are your views on the Sinc3 passband droop? It seems to me that the attenuation could lower the ENOB. Increasing R is intended to increase the ENOB but means more droop. Which effect wins?
The 33 appears to make the response worse. The noise level at the 10 bit sum is worse as well. It also makes the filter more expensive since the 33 is not used in the longer filter anywhere.
It's just a trade off of resolution and bandwidth. The ideal filter would have no attenuation for the frequencies of the desired signal and infinite attenuation of frequencies not desired. Usually it's a matter of getting a filter that's good enough at the lowest cost. Decimation makes filtering easier and cheaper so it's common to use several filters in a row at progressively lower sample rates. If we want a new sample every clock there's not much we can do before the filter gets very expensive.
The adjustable filter can help keep the droop from affecting the desired signal as much. We could follow the output of the scope filter with another filter of narrower bandwidth. Equipment such as the USRP1 has a half-band filter following the CIC decimator. Note: The USRP1 verilog is open source.
Chip,
Smartpin mode %01100 (externally clocked Sinc1) has the clock on input A and the enable on input B. Mode %11001 above I think you have it the other way around. For consistency, one of them should be changed.
Chip,
Smartpin mode %01100 (externally clocked Sinc1) has the clock on input A and the enable on input B. Mode %11001 above I think you have it the other way around. For consistency, one of them should be changed.
That other block of modes came from another line of thinking that caused it be how it is. To gain consistency with SINC3 would cause it to have inconsistency with its more closely-related modes.
There's lots of variations. I vaguely remember seeing one just the other day that only had one feedback originating from the synchronous stage. The second feedback was between the integrators only. It's a bit hazy so I could be wrong ...
EDIT: Found it. It was one of the links JMG provided: Amusingly, it's extra feedforwards, not feedbacks.
The one integrator for first order or the two integrators for second order modulators filter the feedback of the one-bit DAC and thereby remove the introduced noise from the low frequency signal by moving it to high frequencies - thus named 'noise-shaping'. so this is really all about the quantization noise, not about signal noise.
Isn't it, that we integrate, compare and filter then while they integrate, compensate and compare? (quantizer: comparator) This way, the filter is on the analog side, while the prop runs at much higher bandwith then the analog part and so can do a digital filter? An ADC-only chip will always optimize bandwidth to the limits, while here the ADC is just a goody.
Can anybody explain how a second-order analog integrator works?
I know it has two flip-flops, instead of just one, and the second flip-flop also drives some other analog feedback. It never made sense to me.
I think you need a second order lowpass filter in the analog feedback loop between the Flipflop and the comparator.
I have modified a picture from evanh to show how I think it works:
A Tukey without a plateau is a Hann window, so bit 6 would select Tukey/Hann mode.
It's not quite a Hann window. There are 3 32s on top. Which was chosen in part because the sum would be 512. I presume a Hann would have a single 32 on top.
Yes, you're right. I knew it was not quite a Hann. What if we turn the short plateau 32,32,32 into a peak 32,33,32? Does that show up in the frequency response? Full scale stays at 128.
The 33 appears to make the response worse. The noise level at the 10 bit sum is worse as well. It also makes the filter more expensive since the 33 is not used in the longer filter anywhere.
Thanks for the waveforms, do you mind doing just a few more? I've had what might be a final look at Tukeys, with a range of 64, before returning to the soft HDMI. The options below would add logic but only a little for one of them. I'm interested to learn how much better if at all the frequency responses are with the larger range, even if none could be implemented.
In the table below, Tukey17*/32 is called Tukey17_13_32 to make it clear the middle 13 values are used and the same naming scheme applies to the others.
tukey17_13_32 'existing
long 01,03,05,07,10,13,16,19,22,25,27,29,31 '13 up, up/down sum = 208 * 2
long 32[9],31,32[9] '19 top, top sum = 607
long 31,29,27,25,22,19,16,13,10,07,05,03,01 '13 down, total sum = 1023 (>>2 = 255)
tukey15_13_64 ' NEW
long 01,03,07,12,18,25,32,39,46,52,57,61,63 '13 up, up/down sum = 416 * 2
long 64[9],63,64[9] '19 top, top sum = 1215
long 63,61,57,52,46,39,32,25,18,12,07,03,01 '13 down, total sum = 2047 (>>3 = 255)
tukey17_13_32_x2 'existing doubled for easier comparison
long 02,06,10,14,20,26,32,38,44,50,54,58,62 '13 up, up/down sum = 416 * 2
long 64[9],62,64[9] '19 top, top sum = 1214
long 62,58,54,50,44,38,32,26,20,14,10,06,02 '13 down, total sum = 2046 (>>3 = 255)
tukey17_13_64 ' NEW
long 02,05,09,14,20,26,32,38,44,50,55,59,62 '13 up, up/down sum = 416 * 2
long 64[9],63,64[9] '19 top, top sum = 1215
long 62,59,55,50,44,38,32,26,20,14,09,05,02 '13 down, total sum = 2047 (>>3 = 255)
tukey17_15_64 ' NEW
long 01,02,05,09,14,20,26,32,38,44,50,55,59,62,63 '15 up, up/down sum = 480 * 2
long 64[8],63,64[8] '17 top, top sum = 1087
long 63,62,59,55,50,44,38,32,26,20,14,09,05,02,01 '15 down, total sum = 2047 (>>3 = 255)
In ascending logic sizes, 17_13_64 would be slightly bigger than 17_13_32 as only four ramp values are different, then 15_13_64 with 17_15_64 the largest.
All the plateau values could be 64 by using a counter with overflow detection, as I mentioned earlier. The short Tukey lengths are 29, except 31 for 17_15_64 which, if the peak is 64, would be a true Hann window and this is the main reason for including it.
This is great reading, as it talks a little about the principles and then gives a lot of examples, showing why small differences matter. Certainly it take a lot of time to study the content, but this is not just another paper on a topic, but a reference to look at. While it's over my head, a source I would trust in.
I was thinking about the idea of having 15 integrators and reporting 4 bits per clock when I realized something crazy would happen... The ADC input could be at GND and the integrators would mainly be reporting 0's, but on occasion, they would all report their 1's on the same clock. Ouch! This made me think about filtering.
In our current ADC, extreme GND and VIO measurements all result in data cycles that are 7 clocks or less. For GND, ADC output looks about like this 00000010000010000001000001. For VIO, just NOT those bits. So, I'm thinking that maybe for things like rolling-window measurements, it might be better to use a live 3-bit sum of the last 7 bits of ADC output as the base unit for windowing. It would nicely filter the highest-frequency noise, which is way above the pass-band of the ADC's analog front end, anyway. It might clean up the final results quite nicely.
Bandpass characteristics:
Every clock we decide, if the input voltage is above or below the internal caps voltage. So every clock we just can gain 1 bit of information. If this information toggles, we know, that the input voltage is balanced by the compensation pulses, so the ADC is tracking properly. If we want to have a higher resolution, we have, as the input voltage changes, to wait, until the toggling starts, otherwise the cap is not balanced yet, we have no information.
So we can measure slops only as far, as we can see, that the compensation pulses can keep the comparator toggling. And the higher the resolution is, the longer we have to wait. So we should just decide, what frequency we want to measure, calculate the maximal resolution and sampling rate and then we can filter the data stream that way, that the noise is damped optimally. I think, noise can be filtered nicely averaging 64 or 128 clocks, so the sampling rate will be about 1 MHz, what seems to be adequat.
Comments
It's not quite a Hann window. There are 3 32s on top. Which was chosen in part because the sum would be 512. I presume a Hann would have a single 32 on top. But we certainly could change it to a Hann window. Is there a good reason to do that?
Hann27 -3dB at 6.3 MHz, -6dB at 8.6 MHz
Tukey29 -3dB at 5.8 MHz, -6dB at 7.9 MHz
Tukey45 -3dB at 3.4 MHz, -6dB at 4.6 MHz
All assume 250MHz sysclock and ignore analog input effects.
-3dB is 50% of the power and 70.7% of the voltage
-6dB is 25% of the power and 50% of the voltage
It would be cool to advertise 5MHz scope mode. But I'm doing this because I though it would be sad to have filters just a little bit too narrow for analog video. I wonder if we could get better resolution at the wide bandwidth by feeding the signal to two or more ADC channels. It should work as long as the ADC noise isn't correlated.
I also compared the original Tukey to a triangular/sinc2 window. The performance seems pretty comparable.
Ah, we could have a mode that looks at 4 contiguous ADC pins to get higher ENOB faster.
Could we use an existing up/down counter for the plateau bits? Count enable = plateau in bit XOR plateau out bit and up/!down = plateau in. Add ramp and plateau values to get output. To detect overflow, if plateau count > 0 and output = 0, then output = FF.
Only 2 bits need muxes. I'm willing to wait for the zeros to shift through the plateau part. But maybe masking all those bits is free because of the register reset lines.
Oh, yeah, I didn't realize that.
Neat idea. I wonder if it would save any logic.
Yes, you're right. I knew it was not quite a Hann. What if we turn the short plateau 32,32,32 into a peak 32,33,32? Does that show up in the frequency response? Full scale stays at 128.
Also, what are your views on the Sinc3 passband droop? It seems to me that the attenuation could lower the ENOB. Increasing R is intended to increase the ENOB but means more droop. Which effect wins?
Adding their outputs together would give a noise pattern that is more spread out, and also more information would be in the multi-bit output.
This would have been very easy to build into the current silicon space of the ADC.
The clocked bits would come out in parallel for processing by the core logic. We could easily have done eight of these. Maybe seven would be better, because their outputs would sum to 3 bits.
Then, imagine what windowing and SINC3 filtering could do with that.
Multiple integrators are much harder to calibrate.
The weakest link in P2 ADC, is not the integrators anyway, it is the poor PSRR, and the noise floor in the Digital used as Analog stuff...
These integrators would always be treated as one. The calibration would be just like now. No need to look at them individually.
and not primarily from the post filter
- alt least for P3, when the Analog can be redone/extended,
you might want to think about a second order modulator
(as seem to be used in most of the separate modulator ICs)
instead the (I still think - but unconfirmed) P2 first order modulator.
It's just a trade off of resolution and bandwidth. The ideal filter would have no attenuation for the frequencies of the desired signal and infinite attenuation of frequencies not desired. Usually it's a matter of getting a filter that's good enough at the lowest cost. Decimation makes filtering easier and cheaper so it's common to use several filters in a row at progressively lower sample rates. If we want a new sample every clock there's not much we can do before the filter gets very expensive.
The adjustable filter can help keep the droop from affecting the desired signal as much. We could follow the output of the scope filter with another filter of narrower bandwidth. Equipment such as the USRP1 has a half-band filter following the CIC decimator. Note: The USRP1 verilog is open source.
Chip,
Smartpin mode %01100 (externally clocked Sinc1) has the clock on input A and the enable on input B. Mode %11001 above I think you have it the other way around. For consistency, one of them should be changed.
That other block of modes came from another line of thinking that caused it be how it is. To gain consistency with SINC3 would cause it to have inconsistency with its more closely-related modes.
I know it has two flip-flops, instead of just one, and the second flip-flop also drives some other analog feedback. It never made sense to me.
EDIT: Found it. It was one of the links JMG provided: Amusingly, it's extra feedforwards, not feedbacks.
from
FIR-Filter as alternative to SincN:
https://training.ti.com/system/files/docs/Andrew%20Wang_Inside%20the%20Delta-Sigma%20Converter_Industrial%20seminar_Taiwan.pdf
this gives good explanation when to use SincN filters vs. Wideband filters
ti.com/lit/an/sbaa230/sbaa230.pdf
I think you need a second order lowpass filter in the analog feedback loop between the Flipflop and the comparator.
I have modified a picture from evanh to show how I think it works:
Andy
Thanks for the waveforms, do you mind doing just a few more? I've had what might be a final look at Tukeys, with a range of 64, before returning to the soft HDMI. The options below would add logic but only a little for one of them. I'm interested to learn how much better if at all the frequency responses are with the larger range, even if none could be implemented.
In the table below, Tukey17*/32 is called Tukey17_13_32 to make it clear the middle 13 values are used and the same naming scheme applies to the others.
In ascending logic sizes, 17_13_64 would be slightly bigger than 17_13_32 as only four ramp values are different, then 15_13_64 with 17_15_64 the largest.
All the plateau values could be 64 by using a counter with overflow detection, as I mentioned earlier. The short Tukey lengths are 29, except 31 for 17_15_64 which, if the peak is 64, would be a true Hann window and this is the main reason for including it.
https://www.researchgate.net/profile/Armin_Doerry/publication/316281181_Catalog_of_Window_Taper_Functions_for_Sidelobe_Control/links/58f92cb2a6fdccb121c9d54d/Catalog-of-Window-Taper-Functions-for-Sidelobe-Control.pdf
In our current ADC, extreme GND and VIO measurements all result in data cycles that are 7 clocks or less. For GND, ADC output looks about like this 00000010000010000001000001. For VIO, just NOT those bits. So, I'm thinking that maybe for things like rolling-window measurements, it might be better to use a live 3-bit sum of the last 7 bits of ADC output as the base unit for windowing. It would nicely filter the highest-frequency noise, which is way above the pass-band of the ADC's analog front end, anyway. It might clean up the final results quite nicely.
Also any idea what the passband of the ADC front end is? I guess we could inject sine waves and measure
Every clock we decide, if the input voltage is above or below the internal caps voltage. So every clock we just can gain 1 bit of information. If this information toggles, we know, that the input voltage is balanced by the compensation pulses, so the ADC is tracking properly. If we want to have a higher resolution, we have, as the input voltage changes, to wait, until the toggling starts, otherwise the cap is not balanced yet, we have no information.
So we can measure slops only as far, as we can see, that the compensation pulses can keep the comparator toggling. And the higher the resolution is, the longer we have to wait. So we should just decide, what frequency we want to measure, calculate the maximal resolution and sampling rate and then we can filter the data stream that way, that the noise is damped optimally. I think, noise can be filtered nicely averaging 64 or 128 clocks, so the sampling rate will be about 1 MHz, what seems to be adequat.