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

ADC Sampling Breakthrough

1212224262752

Comments

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

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

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

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


    Saucy, perfect!!!

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

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

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

    Just perfect!

    A Tukey without a plateau is a Hann window, so bit 6 would select Tukey/Hann mode.

    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.

    1167 x 875 - 31K
    1200 x 900 - 33K
  • cgraceycgracey Posts: 14,133
    TonyB_ wrote: »
    cgracey wrote: »
    The Tukey17/32 could be shortened like this:
     1    3    5    7   10   13   16   19   22   25   27   29   31
    32   32   32   
    31   29   27   25   22   19   16   13   10    7    5    3    1
    
    Sum is 512. Full scale output would be 128.

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

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

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


    Saucy, perfect!!!

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

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

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

    Just perfect!

    A Tukey without a plateau is a Hann window, so bit 6 would select Tukey/Hann mode.

    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.
  • cgracey wrote: »
    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.
  • cgracey wrote: »
    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.
  • cgraceycgracey Posts: 14,133
    cgracey wrote: »
    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.

    Oh, yeah, I didn't realize that.
  • cgraceycgracey Posts: 14,133
    TonyB_ wrote: »
    cgracey wrote: »
    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.

    Neat idea. I wonder if it would save any logic.
  • TonyB_TonyB_ Posts: 2,108
    edited 2018-11-29 18:33
    TonyB_ wrote: »
    cgracey wrote: »
    The Tukey17/32 could be shortened like this:
     1    3    5    7   10   13   16   19   22   25   27   29   31
    32   32   32   
    31   29   27   25   22   19   16   13   10    7    5    3    1
    
    Sum is 512. Full scale output would be 128.

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

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

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


    Saucy, perfect!!!

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

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

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

    Just perfect!

    A Tukey without a plateau is a Hann window, so bit 6 would select Tukey/Hann mode.

    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?
  • cgraceycgracey Posts: 14,133
    edited 2018-11-29 18:15
    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.
  • cgraceycgracey Posts: 14,133
    edited 2018-11-29 18:59
    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.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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...
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    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.
  • MJBMJB Posts: 1,235
    jmg wrote: »
    evanh wrote: »
    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.
  • MJBMJB Posts: 1,235
    cgracey wrote: »
    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.
    cgracey wrote: »
    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.
  • TonyB_ wrote: »
    TonyB_ wrote: »
    cgracey wrote: »
    The Tukey17/32 could be shortened like this:
     1    3    5    7   10   13   16   19   22   25   27   29   31
    32   32   32   
    31   29   27   25   22   19   16   13   10    7    5    3    1
    
    Sum is 512. Full scale output would be 128.

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

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

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


    Saucy, perfect!!!

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

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

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

    Just perfect!

    A Tukey without a plateau is a Hann window, so bit 6 would select Tukey/Hann mode.

    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.
    1200 x 900 - 33K
    1200 x 900 - 33K
  • evanhevanh Posts: 15,126
    edited 2018-11-30 02:20
    cgracey wrote: »
    Here is what has changed in the smart pin modes:
    11000	= SINC3 filter internally clocked
    11001	= SINC3 filter externally clocked
    11010	= USB host			(even/odd pin pair = DM/DP)
    11011	= USB device			(even/odd pin pair = DM/DP)
    

    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.

  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    cgracey wrote: »
    Here is what has changed in the smart pin modes:
    11000	= SINC3 filter internally clocked
    11001	= SINC3 filter externally clocked
    11010	= USB host			(even/odd pin pair = DM/DP)
    11011	= USB device			(even/odd pin pair = DM/DP)
    

    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.
  • cgraceycgracey Posts: 14,133
    edited 2018-11-30 08:14
    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.
  • evanhevanh Posts: 15,126
    edited 2018-11-30 08:58
    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.
    Screenshot_20181130_215451.png
    959 x 840 - 48K
  • MJBMJB Posts: 1,235
    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.

    500px-DeltaSigma2.svg.png
    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
  • ErNaErNa Posts: 1,738
    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.
  • AribaAriba Posts: 2,682
    cgracey wrote: »
    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:
    ADC_SD2nd.png

    Andy
    969 x 540 - 22K
  • cgraceycgracey Posts: 14,133
    Thanks, Guys. I will study your explanations and links. I reall want to understand the concept.
  • TonyB_ wrote: »
    TonyB_ wrote: »
    The Tukey17/32 could be shortened like this:
     1    3    5    7   10   13   16   19   22   25   27   29   31
    32   32   32   
    31   29   27   25   22   19   16   13   10    7    5    3    1
    
    Sum is 512. Full scale output would be 128.

    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.
  • ErNaErNa Posts: 1,738
    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.
  • evanhevanh Posts: 15,126
    I'm just ogling all the sexy graphs.
  • cgraceycgracey Posts: 14,133
    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.
  • I'm not convinced using the patterns on VIO and GIO as the basis of filtering makes sense, but if you do, isn't the ratio more like 6 than 7?

    Also any idea what the passband of the ADC front end is? I guess we could inject sine waves and measure
  • The measurement makes sense at this point. It should be done to validate the filters aren't actually limiting basic capability, right?
  • ErNaErNa Posts: 1,738
    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.
Sign In or Register to comment.