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.
Err, hopefully, they simply just disable the optional filter !! No PCB mods or product revisions required,
TonyB_, amazingly, rounding screws things up. You DON'T want to round because if the sub-bits didn't add up to the one's threshold, that's as it should be. All you do is throw away the bottom bits.
TonyB_, amazingly, rounding screws things up. You DON'T want to round because if the sub-bits didn't add up to the one's threshold, that's as it should be. All you do is throw away the bottom bits.
I thought TonyB_ meant rounding when doing the shift right ? /32
TonyB_, amazingly, rounding screws things up. You DON'T want to round because if the sub-bits didn't add up to the one's threshold, that's as it should be. All you do is throw away the bottom bits.
I thought TonyB_ meant rounding when doing the shift right ? /32
Yes. He did.
I'm making some tables of what happens with a pure ramp (trapezoid) and there's lots of error. The cosine-shaped ramp-up/down is much better. This is going to improve things a lot.
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.
Wow! This Tukey curve is supreme!!! And it definitely benefits from rounding.
Before doing the table exercise, I thought I would just code it and try it. No need to mess with a table. It's obvious this is WAY better than the trapezoid. In fact, the ADC is looking quite PERFECT now. Pictures in a minute...
The auto-ranging mathless ADC conversion technique is now working with the Tukey windowing. It was very dysfunctional when using the trapezoidal windowing.
The auto-ranging mathless ADC conversion technique is now working with the Tukey windowing. It was very dysfunctional when using the trapezoidal windowing.
You could use some of the inbuilt DACs to get plots like the nice TI data, of INL, DNL for the ADCs over a number of pins.
INL is the difference from an ideal straight line, and DNL is the adjacent step-size comparison.
eg you could join 4 pins, run 4 triangle sweeps, one from each possible DAC, and plot the deviation from ideal and the spread across the 4 ADCs.
That does not over all possible ADC values, but it does sweep over the user dynamic range.
The auto-ranging mathless ADC conversion technique is now working with the Tukey windowing. It was very dysfunctional when using the trapezoidal windowing.
You could use some of the inbuilt DACs to get plots like the nice TI data, of INL, DNL for the ADCs over a number of pins.
INL is the difference from an ideal straight line, and DNL is the adjacent step-size comparison.
eg you could join 4 pins, run 4 triangle sweeps, one from each possible DAC, and plot the deviation from ideal and the spread across the 4 ADCs.
That does not over all possible ADC values, but it does sweep over the user dynamic range.
Do you have low noise regulators fitted yet ?
No low-noise regulator, yet.
I'm outputting analog values into the ADC via an adjacent pin's DAC in 16-bit random-dither mode. I step the DAC at very fine granularity and then record ADC samples.
Could please someone create a data file with the streamed ADC values that Chip collected? I actually didn't follow, how all this stuff works as I don't understand, what the first post wants me to tell.
With every clock cycle, the comparator determines, if there is a 0 or 1 and so every clock cycle the counter counts up 0 or 1. The counter readout can not be at clock speed, so the difference between to readouts should be in the range of 0 to number of clocks per readout. (e.g.: 7)
There will be some noise, so worst case, at constant input voltage, the readout should be 0 to 7. If we average two adjacent values, the result can be 0 -15. The more samples we add, the higher the range is, so noise becomes more.
But that's an incomplete theory, as noise is distributed and tends to cancel out, so reading over a longer time, the noise floor should decrease. If I read 7 multiple times, it's not noise but a signal.
So, if there is more noise then expected, it could be systematical or not. In the first case, a filter makes sense, in the second, not. As the filter seems to work better then we could expect from just averaging, it look to be a systematical noise source.
So: could somebody stream the readout data to a file and upload that file?
I'm outputting analog values into the ADC via an adjacent pin's DAC in 16-bit random-dither mode. I step the DAC at very fine granularity and then record ADC samples.
For these tests it may be best to disable the dithering, at least initially, and compare more than one ADC in the captures ?
The dispersal of the multiple ADCs all reading exactly the same V, should be a good indicator
Erna, it's not random noise we're fighting, exactly. It's just a need low-pass filter the first 32 bits and the last 32 bits that get accumulated. The problem isn't the noise in the entire bitstream, as that does average out. It's just the initial and terminal samples that want to leave a bad taste in the accumulator's mouth because they are so obstreperous.
If this is supposed to have value for audio then hearing would be a good test. If you could record from a line source of a good DAC and some 16-24bit audio and with several ADC methods and play it back that would be informative. Ideally output the data and post/link an mp3 or wav of the a/b for comparison.
If this is supposed to have value for audio then hearing would be a good test. If you could record from a line source of a good DAC and some 16-24bit audio and with several ADC methods and play it back that would be informative. Ideally output the data and post/link an mp3 or wav of the a/b for comparison.
Yes, listening is a great way to determine spectral quality and noise. I need to get some audio hookups.
For listening tests It’s best if possible if you can put a switch to toggle immediately back and forth between methods vs listening to one method then stopping and reconfiguring.
TonyB_, this Tukey data you gave me is really 180..0 degrees of a cosine plus 1, right? I was looking at the wiki and that's what I gathered.
I think you came up with a special rendition that would be easy to generate sequentially, right? The first two values are zero, making it really a 30-step window, but that helped keep the numerics simple, correct?
...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
Phil, this initial/terminal-samples windowing doesn't undermine anyone's use of the ADC. It allows the ADC to really do what it's capable of. This problem of incomplete cycles of short delta-sigma patterns appearing at the start and end of measurements cannot be fixed by better analog design. It needs a digital solution. To not implement one when it's so simple would be a shame. And I doubt anybody will even use the ADC without windowing. To do so would just be inviting needless uncertainty into their measurements.
TonyB_, this Tukey data you gave me is really 180..0 degrees of a cosine plus 1, right? I was looking at the wiki and that's what I gathered.
I think you came up with a special rendition that would be easy to generate sequentially, right? The first two values are zero, making it really a 30-step window, but that helped keep the numerics simple, correct?
Chip, the Tukey ramps are ((cos -180..cos 0)+1)/2 and ((cos0..cos+180)+1)/2.
Only 28 steps are needed to get from 1 to 64, so I added two zeroes and two 64's at the start and end to make things symmetrical. I can post the logic for the accumulator increment later today. I'll check first whether having four zeroes reduces the logic, but it may well increase it.
We can't use the output of a 5-bit counter directly for the Tukey accumulator, obviously. The counter is used to generate the next 2-bit increment to add to a 6-bit accumulator.
TonyB_, this Tukey data you gave me is really 180..0 degrees of a cosine plus 1, right? I was looking at the wiki and that's what I gathered.
I think you came up with a special rendition that would be easy to generate sequentially, right? The first two values are zero, making it really a 30-step window, but that helped keep the numerics simple, correct?
Chip, the Tukey ramps are ((cos -180..cos 0)+1)/2 and ((cos0..cos+180)+1)/2.
Only 28 steps are needed to get from 1 to 64, so I added two zeroes and two 64's at the start and end to make things symmetrical. I can post the logic for the accumulator increment later today. I'll check first whether having four zeroes reduces the logic, but it may well increase it.
We can't use the output of a 5-bit counter directly for the Tukey accumulator, obviously. The counter is used to generate the next 2-bit increment to add to a 6-bit accumulator.
Yes, I'm working out the adder values now:
pos 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
-----------------------------------------------------------------------------------------------
up 01 01 01 02 02 02 02 02 03 03 03 03 03 03 03 03 03 03 03 03 03 02 02 02 02 02 01 01 00 00 00 00
Tukey 00 01 02 03 05 07 09 0B 0D 10 13 16 19 1C 1F 22 25 28 2B 2E 31 34 36 38 3A 3C 3E 3F 40 40 40 40
dn 00 1F 1F 1F 1E 1E 1E 1E 1E 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1E 1E 1E 1E 1E 1F 1F 00 00 00
'up' works left-to-right.
'dn' works right-to-left.
When we are doing the main sample accumulation, we keep using the Tukey value, which will be at 64.
I'm wondering if it's best to work this windowing into the period set by WXPIN or to use 32+WXPIN+32. Either can be done with about the same logic, I think.
TonyB_, if the numbers would work nicely, it would be good to span the values from 1..64 over all 32 steps. We don't need any 0's and we only need one 64.
TonyB_, if the numbers would work nicely, it would be good to span the values from 1..64 over all 32 steps. We don't need any 0's and we only need one 64.
Stretching the values to fit would mess up the waveform, probably. What we could do is have 28 steps from 1-64 then four 64s and no zeroes. I'll look into that next.
So that you have something now, here is the truth table and logic for the symmetrical version with two zeroes and two extra 64s:
TonyB_, if the numbers would work nicely, it would be good to span the values from 1..64 over all 32 steps. We don't need any 0's and we only need one 64.
Stretching the values to fit would mess up the waveform, probably. What we could do is have 28 steps from 1-64 then four 64s and no zeroes. I'll look into that next.
So that you have something now, here is the truth table and logic for the symmetrical version with two zeroes and two extra 64s:
More pictures. These are details of 4096-sample conversions (12-bit) with the ADC receiving a finely-stepped ramp.
First, the straight accumulator approach (no windowing). The monitor DAC was wrapping vertically because of the noise amplitude:
It looks like the windowing is getting rid of sporadic +1/+2 contributions from the initial and terminal bits samples.
So, could you tell it a way, I can crasp what I see: The analog input voltage of the input is a staircase function?
You read out the counter at a given period?
You substract the last read value from the current value?
If I didn't know it better, I would think, you look to the future as you start and to the past as you stop reading ;-)
OK, it's 4096 clocks per sample. At a clock rate of 100 MHz it's about 25 KHz sampling frequency.
Is this still a slowly ramping analog input voltage? Is the spiked signal always 16 Bits (as if Bit #5 is toggling?)
What happens if you measure a slightly longer period?
The spikes are independend of the signal level you start with? What happens if you execute a series of measurement? Is the effect repeated and if you pause between different bursts, is there a minimal pause time to have the effect?
Comments
Err, hopefully, they simply just disable the optional filter !! No PCB mods or product revisions required,
Of course, a single bit can disable the windowing, quite simply.
I thought TonyB_ meant rounding when doing the shift right ? /32
Yes. He did.
I'm making some tables of what happens with a pure ramp (trapezoid) and there's lots of error. The cosine-shaped ramp-up/down is much better. This is going to improve things a lot.
Yes, this will be a special sub-mode, in addition to the ones we already have. Nobody has to use it.
Here is trapezoidal windowed sampling:
I'm making a table next using TonyB_'s cosine pattern...
Wow! This Tukey curve is supreme!!! And it definitely benefits from rounding.
Before doing the table exercise, I thought I would just code it and try it. No need to mess with a table. It's obvious this is WAY better than the trapezoid. In fact, the ADC is looking quite PERFECT now. Pictures in a minute...
You could use some of the inbuilt DACs to get plots like the nice TI data, of INL, DNL for the ADCs over a number of pins.
INL is the difference from an ideal straight line, and DNL is the adjacent step-size comparison.
eg you could join 4 pins, run 4 triangle sweeps, one from each possible DAC, and plot the deviation from ideal and the spread across the 4 ADCs.
That does not over all possible ADC values, but it does sweep over the user dynamic range.
Do you have low noise regulators fitted yet ?
No low-noise regulator, yet.
I'm outputting analog values into the ADC via an adjacent pin's DAC in 16-bit random-dither mode. I step the DAC at very fine granularity and then record ADC samples.
First, a straight accumulator approach (no windowing):
Next, TonyB_'s Tukey cosine window operating on the first 32 and last 32 samples:
This seems quite ideal. Now I'll work on some 4096-sample (12-bit) conversions...
With every clock cycle, the comparator determines, if there is a 0 or 1 and so every clock cycle the counter counts up 0 or 1. The counter readout can not be at clock speed, so the difference between to readouts should be in the range of 0 to number of clocks per readout. (e.g.: 7)
There will be some noise, so worst case, at constant input voltage, the readout should be 0 to 7. If we average two adjacent values, the result can be 0 -15. The more samples we add, the higher the range is, so noise becomes more.
But that's an incomplete theory, as noise is distributed and tends to cancel out, so reading over a longer time, the noise floor should decrease. If I read 7 multiple times, it's not noise but a signal.
So, if there is more noise then expected, it could be systematical or not. In the first case, a filter makes sense, in the second, not. As the filter seems to work better then we could expect from just averaging, it look to be a systematical noise source.
So: could somebody stream the readout data to a file and upload that file?
For these tests it may be best to disable the dithering, at least initially, and compare more than one ADC in the captures ?
The dispersal of the multiple ADCs all reading exactly the same V, should be a good indicator
Yes, listening is a great way to determine spectral quality and noise. I need to get some audio hookups.
I think you came up with a special rendition that would be easy to generate sequentially, right? The first two values are zero, making it really a 30-step window, but that helped keep the numerics simple, correct?
Phil, this initial/terminal-samples windowing doesn't undermine anyone's use of the ADC. It allows the ADC to really do what it's capable of. This problem of incomplete cycles of short delta-sigma patterns appearing at the start and end of measurements cannot be fixed by better analog design. It needs a digital solution. To not implement one when it's so simple would be a shame. And I doubt anybody will even use the ADC without windowing. To do so would just be inviting needless uncertainty into their measurements.
First, the straight accumulator approach (no windowing). The monitor DAC was wrapping vertically because of the noise amplitude:
And next, TonyB_'s Tukey cosine window operating on the first 32 and last 32 samples:
It looks like the windowing is getting rid of sporadic +1/+2 contributions from the initial and terminal bits samples.
Cosine windowing is clearly better:
Chip, the Tukey ramps are ((cos -180..cos 0)+1)/2 and ((cos0..cos+180)+1)/2.
Only 28 steps are needed to get from 1 to 64, so I added two zeroes and two 64's at the start and end to make things symmetrical. I can post the logic for the accumulator increment later today. I'll check first whether having four zeroes reduces the logic, but it may well increase it.
We can't use the output of a 5-bit counter directly for the Tukey accumulator, obviously. The counter is used to generate the next 2-bit increment to add to a 6-bit accumulator.
Yes, I'm working out the adder values now:
pos 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F ----------------------------------------------------------------------------------------------- up 01 01 01 02 02 02 02 02 03 03 03 03 03 03 03 03 03 03 03 03 03 02 02 02 02 02 01 01 00 00 00 00 Tukey 00 01 02 03 05 07 09 0B 0D 10 13 16 19 1C 1F 22 25 28 2B 2E 31 34 36 38 3A 3C 3E 3F 40 40 40 40 dn 00 1F 1F 1F 1E 1E 1E 1E 1E 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1E 1E 1E 1E 1E 1F 1F 00 00 00'up' works left-to-right.
'dn' works right-to-left.
When we are doing the main sample accumulation, we keep using the Tukey value, which will be at 64.
I'm wondering if it's best to work this windowing into the period set by WXPIN or to use 32+WXPIN+32. Either can be done with about the same logic, I think.
Stretching the values to fit would mess up the waveform, probably. What we could do is have 28 steps from 1-64 then four 64s and no zeroes. I'll look into that next.
So that you have something now, here is the truth table and logic for the symmetrical version with two zeroes and two extra 64s:
Q[4:0] are the counter output and X[1:0] the increment. I used Logic Friday to create this.
Wow! That's pretty efficient. I wonder if the ASIC compiler could make such an inference.
You read out the counter at a given period?
You substract the last read value from the current value?
If I didn't know it better, I would think, you look to the future as you start and to the past as you stop reading ;-)
OK, it's 4096 clocks per sample. At a clock rate of 100 MHz it's about 25 KHz sampling frequency.
Is this still a slowly ramping analog input voltage? Is the spiked signal always 16 Bits (as if Bit #5 is toggling?)
What happens if you measure a slightly longer period?
The spikes are independend of the signal level you start with? What happens if you execute a series of measurement? Is the effect repeated and if you pause between different bursts, is there a minimal pause time to have the effect?