I've got an 8x oversampling Sinc2/128 worked out that definitely puts out 8-bit samples every 16 bits that are the product of the last 256 bits.
decimation = 16
range = decimation*256
for iter = 0 to range-1
acc = acc + iter/range 'new ADC bit
if acc >= 1 then
acc = acc - 1
t = 1
else
t = 0
endif
inta = inta + t
intb = intb + inta
if iter/decimation = int(iter/decimation) then
sample = intb - dif7
dif7 = dif6
dif6 = dif5
dif5 = dif4
dif4 = dif3
dif3 = dif2
dif2 = dif1
dif1 = dif0
dif0 = intb
intb = 0
x = iter/decimation
y = pow(decimation,2)
s = int((sample+7)/8)
line x, y, x, y - s
'print int(sample/8)
endif
next iter
Comparing this to Sinc2 with integrators in hardware, differentiators in software and integrate and dump, there are 8x as many difX registers.
Yes, but this gives a true 8-bit sample every 16 clocks. You just do a RDPIN to get it, or the streamer can use it. Its frequency response is going to be poorer than a 64-tap window, but precision will be 8 bits, always.
My understanding is the sample output is a moving average of eight 32-clock triangular windows that are overlapped by 16 clocks and therefore each output is generated by 128 ADC bits.
What if only dif0-dif3 are used when decimation = 16?
Or dif0-dif3 or dif0-dif7 when decimation = 8?
I've been experimenting with those kinds of variations. I've reduced it down to 9 bits per term, instead of 11, by only propagating the diff's of the diff's, then running a moving average filter.
I've been experimenting with those kinds of variations. I've reduced it down to 9 bits per term, instead of 11, by only propagating the diff's of the diff's, then running a moving average filter.
A useful test when you have a short list of candidates, would be to plot the same ENOB curves as Rayman linked here
and see what dB/double slope you measure, for changes in oversample ratios.
Curious to see what effective order ADC modulator, the P2 has.
Ideal second order modulator is 15.05dB/double, (coupled to sinc3) and 1st order is 9.03dB/double, (coupled to sinc2?)
The number may be between 9.03 and 15.05 dB/double.
A plot of a stepped sawtooth, and showing the difference from ideal, will show the ADC delays and settling times, as well as the DNL.
Since this scope-mode is low resolution, the P2 DACs are probably good enough.
I'm thinking about a scope mode replacement that resolves DC better than 6 bits. We won't be able to get a sample every clock, but we can run different sets of acc2's and diff's for more frequent samples.
Now, that I have a propeller on my desk, we could start to collaborate in doing experiments, as others will have the real silicon too. I wish to stream the comparator output to whatever ram and then apply the filtering stuff, preferably using TaqOz.
Many lessons have to be learned. First: what (besides TaqOz) is the preferable tool. My intention is not to use C to extend.
I've been working for 24 hours, simulating Sinc3 and Sinc2 filters. I've been slowly going in a giant circle, it seems.
Here is what I want to do:
- Implement the scope mode, as already designed, but limit the submodes to realistic numbers of bits, like 6 and 5. No need to worry about exceeding $FF, anymore.
- Implement a Sinc2 mode for doing background conversions of 6/7/8/9/10/11/12/13 bits. Sinc2 is very low on logic and would afford a nice automated ADC mode.
Here is the Sinc2 code I will implement. It maintains two scrolling diffs that allow samples to overlap, doubling the sample rate. These Sinc2 filters are proven in this program to hit every possible value within the duty range, according to the bitstream coming in. The 13-bit mode registers 2..8190 without any missing codes. Phil would definitely approve of its soundness:
enob = 10 'effective number of bits 6..13
maxenob = 13
bitmask = pow(2,maxenob*2-2)-1
decimate = pow(2,enob-2)
divide = decimate/2
range = pow(2,enob)
acc = rnd 'expose flaws
for g = 0 to range
for iter = 0 to range*2
acc = acc + g/range 'new ADC bit
if acc >= 1 then
acc = acc - 1
t = 1
else
t = 0
endif
inta = (inta + t) band bitmask
intb = (intb + inta) band bitmask
if iter/decimate = int(iter/decimate) then
sample = int((((intb - dif0) band bitmask)+divide/2)/divide)
dif0 = dif1
dif1 = intb
intb = 0
if iter > range then circle 10+(g mod 256)*4 + int(g/256)*12, 10+((range-sample) mod 256)*4, 2 filled
endif
next iter
'print sample,
next g
I've been working for 24 hours, simulating Sinc3 and Sinc2 filters. I've been slowly going in a giant circle, it seems.
Here is what I want to do:
- Implement the scope mode, as already designed, but limit the submodes to realistic numbers of bits, like 6 and 5. No need to worry about exceeding $FF, anymore.
- Implement a Sinc2 mode for doing background conversions of 8/9/10/11/12/13 bits. Sinc2 is very low on logic and would afford a nice automated ADC mode.
Here is the Sinc2 code I will implement. It maintains two scrolling diffs that allow samples to overlap, doubling the sample rate. These Sinc2 filters are proven in this program to hit every possible value within the duty range, according to the bitstream coming in. The 13-bit mode registers 2..8190 without any missing codes. Phil would definitely approve of its soundness:
Is there still a sinc3 mode support planned, for those many external commercial ADCs out there ?
Having overlapped samples gives more of an illusion of speed, if the step response is not improved. What is the logic cost of the overlap ?
ie in an earlier example, you gave 8 bits, at 8 bits per sysclk, but needing 256 clocks to settle. That slow slew/settle effect is poor for a scope.
I've been working for 24 hours, simulating Sinc3 and Sinc2 filters. I've been slowly going in a giant circle, it seems.
Here is what I want to do:
- Implement the scope mode, as already designed, but limit the submodes to realistic numbers of bits, like 6 and 5. No need to worry about exceeding $FF, anymore.
- Implement a Sinc2 mode for doing background conversions of 8/9/10/11/12/13 bits. Sinc2 is very low on logic and would afford a nice automated ADC mode.
Here is the Sinc2 code I will implement. It maintains two scrolling diffs that allow samples to overlap, doubling the sample rate. These Sinc2 filters are proven in this program to hit every possible value within the duty range, according to the bitstream coming in. The 13-bit mode registers 2..8190 without any missing codes. Phil would definitely approve of its soundness:
Is there still a sinc3 mode support planned, for those many external commercial ADCs out there ?
Having overlapped samples gives more of an illusion of speed, if the step response is not improved. What is the logic cost of the overlap ?
ie in an earlier example, you gave 8 bits, at 8 bits per sysclk, but needing 256 clocks to settle. That slow slew/settle effect is poor for a scope.
Sinc3 mode is still in the smart pins. It works best, but needs software management.
The overlap is pretty much free. We've got 112 flops. Might as well use them.
Here's a totally random thought: how many clocks does it take to know which half of the input range you're in? Which quartile? Which octile, etc.? Can such knowledge be leveraged to produce a sigma-delta equivalent to an SAR-driven ADC? Could this help with settling times in scope mode?
Sinc3 mode is still in the smart pins. It works best, but needs software management.
The overlap is pretty much free. We've got 112 flops. Might as well use them.
Good.
To clarify : Is this sinc2 mode a new mode ?
ie for first-order ADC, no diff-step needed in SW (as in sinc3), so users can simply stream final ADC values
I've been trying to find theory examples of sinc3 filters used with first order modulators, with not much success. (Plenty of second order + sinc3)
I think you've run P2 ADC captures into sinc3, did you extract a ENOB, or SNR for those ?
It seems to me that Sinc3+first order, will lie somewhere between the slopes of sinc2+first order and sinc3+second order.
Will the sinc2 be able to set below 8b ? Seems it could be useful to trade off resolution for speed.
Here's a totally random thought: how many clocks does it take to know which half of the input range you're in? Which quartile? Which octile, etc.? Can such knowledge be leveraged to produce a sigma-delta equivalent to an SAR-driven ADC? Could this help with settling times in scope mode?
-Phil
I believe, there is no chance to gain this knowledge. The maximum incoming current (charge = current time clock time) is compensated by a single compensation pulse. So if the incoming voltage is half scale, every second compensation pulse is zero. If there is no hysteresis of the comparator, that is, the comparator detects every single pulse (no input current), the comparator toggles every clock.
If the input is 3/4, we see a 1, 0, 0, 0, ..signal so we need 4 clocks to recognize this value. But as the signal is noisy, we need averaging anyway, introducing larger latency. A SDADC is a SDADC, there is no way around. In the end, we have a tracking adc, perfect for non jumping input signals.
I've been working for 24 hours, simulating Sinc3 and Sinc2 filters. I've been slowly going in a giant circle, it seems.
Here is what I want to do:
- Implement the scope mode, as already designed, but limit the submodes to realistic numbers of bits, like 6 and 5. No need to worry about exceeding $FF, anymore.
- Implement a Sinc2 mode for doing background conversions of 8/9/10/11/12/13 bits. Sinc2 is very low on logic and would afford a nice automated ADC mode.
Here is the Sinc2 code I will implement. It maintains two scrolling diffs that allow samples to overlap, doubling the sample rate. These Sinc2 filters are proven in this program to hit every possible value within the duty range, according to the bitstream coming in. The 13-bit mode registers 2..8190 without any missing codes. Phil would definitely approve of its soundness:
Is there still a sinc3 mode support planned, for those many external commercial ADCs out there ?
Having overlapped samples gives more of an illusion of speed, if the step response is not improved. What is the logic cost of the overlap ?
ie in an earlier example, you gave 8 bits, at 8 bits per sysclk, but needing 256 clocks to settle. That slow slew/settle effect is poor for a scope.
Sinc3 mode is still in the smart pins. It works best, but needs software management.
The overlap is pretty much free. We've got 112 flops. Might as well use them.
I figured out something really weird last night about how all of this could come together.
Suppose that we convolve the input with a sliding [1,4,6,4,1] window on a bit by bit basis using whatever works out best for the logic. As I see it a hardware implementation using individual gates would do the job nicely (only 5 LE's!?!), but you still have to get the bit stream to the gates and back into the registers and if exotic summation can be shoehorned in at a lower cost by firing off increment and decrement pulses to existing logic then that might make sense.
But of course [1,4,6,4,1] isn't really a sinc2, or is it? Based on convolution theory it is the convolution of [1,2,1] with [1,2,1], with or without decimation - and we know that the first [1,2,1] window completely whacks all patterns of the type ....01010101.... or ...10101010.... into oblivion, or at least averages; which is where we want them to be. Yet [1,2,1] is actually a primitive Gaussian, with nice equiripple (read: zero phase shift) characteristics - and it has its first zero at Fs/2 which is exactly what sinc1 does. So it is a sinc1 type function - even if it is actually sinc1 squared.
Repeating the process - we get [1,4,6,4,1] for the convolution that gives the equiripple sinc2 function; and it is actually just the triangular window [1,2,1] convolved with itself - even if you were expecting a triangular window for sinc2. Hmmm - what is going on here?
And then I noticed something. What if we do a [1,4,6,4,1] in hardware and then overlap and add, skipping two clock cycles in between windowing operations.
[1,4,6,4,1,0,0]
+[0,0,1,4,6,4,1] = [1,4,7,8,7,4,1] which would be a nice little period seven triangular window, every clock cycle, or every other clock cycle, or every third clock cycle; or however often you want to run it - if you were to somehow replace that 8 with a 10; but why do that? Just in case you were expecting a rabbit - or if you must insist that sinc2 look like a triangle; it is in there; hiding somewhere in between the hat and the smoke and mirrors.
Well, lets try this again.
Feed [1,4,7,8,7,4,1] into a two tap delay and add. Or do I want a 4 tap delay?
Let's start with the two tap delay ...
So for the price of a the delay and add and another delay and add we get a nine sample wide trapezoid; well almost; except now the rabbit is wearing a top hat with that 14, instead of a 12; which would have made it a trapezoid.
Which is a 13 sample wide Tukey sandwich; or its a Tukey sandwich; stuffed with Tukey sausage. Of course that means I can take advantage of the fact that 4+8=12 and that 15+16, and do this exactly one more time, with another four tap delay.
[1,4,8,12,15,16,16,16,15,12,8,4,1,0,0,0,0,0,0,0,0]
+[0,0,0, 0, 0,0,0,0,1,4, 8,12,15,16,16,16,15,12,8,4,1] = are you ready for this?
[1,4,8,12,15,16,16,16,16,16,16,16,16,16,16,16,15,12,8,4,1] ---> sums to 256 ....
Now for people that like to count bits; there are plenty to go around. Since it becomes possible to accumulate the running counts; by only having to add on every eight clocks; and the sandwich can be stretched to infinity or you can get on or off the Tukey bus any time you like. Eventually we want to decimate - but the idea of having a running Tukey window that has a sinc2 or sinc3 pedigree hidden under the hood has some appeal; i.e., for the scope modes; since the original [1,4,6,4,1] or some variant can be used as a scope trigger; while an 21 tap Tukey window and 256/8 would be 84 nanosecond aperture window running at 32 Mhz; whereas that 18 wide window would have a cutoff frequency around 12Mz; leaving lots of bandwidth for manipulation in software while providing -- possibilities ....
I've been working for 24 hours, simulating Sinc3 and Sinc2 filters. I've been slowly going in a giant circle, it seems.
Here is what I want to do:
- Implement the scope mode, as already designed, but limit the submodes to realistic numbers of bits, like 6 and 5. No need to worry about exceeding $FF, anymore.
- Implement a Sinc2 mode for doing background conversions of 6/7/8/9/10/11/12/13 bits. Sinc2 is very low on logic and would afford a nice automated ADC mode.
Here is the Sinc2 code I will implement. It maintains two scrolling diffs that allow samples to overlap, doubling the sample rate. These Sinc2 filters are proven in this program to hit every possible value within the duty range, according to the bitstream coming in. The 13-bit mode registers 2..8190 without any missing codes. Phil would definitely approve of its soundness:
enob = 10 'effective number of bits 6..13
maxenob = 13
bitmask = pow(2,maxenob*2-2)-1
decimate = pow(2,enob-2)
divide = decimate/2
range = pow(2,enob)
acc = rnd 'expose flaws
for g = 0 to range
for iter = 0 to range*2
acc = acc + g/range 'new ADC bit
if acc >= 1 then
acc = acc - 1
t = 1
else
t = 0
endif
inta = (inta + t) band bitmask
intb = (intb + inta) band bitmask
if iter/decimate = int(iter/decimate) then
sample = int((((intb - dif0) band bitmask)+divide/2)/divide)
dif0 = dif1
dif1 = intb
intb = 0
if iter > range then circle 10+(g mod 256)*4 + int(g/256)*12, 10+((range-sample) mod 256)*4, 2 filled
endif
next iter
'print sample,
next g
This filter seems equivalent to a CMA(512,256). (You can't see the cma trace because it's underneath the sinc2.) It's great that a filter like this can be implemented so cheaply.
I don't want to see the output range of the scope filter reduced. For applications like video or software defined radio the signal will rarely linger on the pathological steps. If we reduce the output range, we'd be adding quantization noise to hide the few steps that we can't measure.
...
- Implement a Sinc2 mode for doing background conversions of 6/7/8/9/10/11/12/13 bits. Sinc2 is very low on logic and would afford a nice automated ADC mode.
Here is the Sinc2 code I will implement. It maintains two scrolling diffs that allow samples to overlap, doubling the sample rate. These Sinc2 filters are proven in this program to hit every possible value within the duty range, according to the bitstream coming in. The 13-bit mode registers 2..8190 without any missing codes. Phil would definitely approve of its soundness:
I changed the code
if iter > range then 'blank display until stable
to look for the settling time, and found display enable gate can be reduced to range/2, but no further.
if iter > ((range/2)-0) then 'wait until stable, tests find Div2-0 is ok, whilst Div2-1 is still settling, large deviations.
That's for the sweep scheme you have, but it also seems valid for random step sizes. Once above that threshold, errors are very small.
Not an especially fast settling time, at (2^ENOB)/2, but that may mean you can read twice as fast ?
It does indicate going down to lower ENOB can help speed.
...
- Implement a Sinc2 mode for doing background conversions of 6/7/8/9/10/11/12/13 bits. Sinc2 is very low on logic and would afford a nice automated ADC mode.
Here is the Sinc2 code I will implement. It maintains two scrolling diffs that allow samples to overlap, doubling the sample rate. These Sinc2 filters are proven in this program to hit every possible value within the duty range, according to the bitstream coming in. The 13-bit mode registers 2..8190 without any missing codes. Phil would definitely approve of its soundness:
I changed the code
if iter > range then 'blank display until stable
to look for the settling time, and found display enable gate can be reduced to range/2, but no further.
if iter > ((range/2)-0) then 'wait until stable, tests find Div2-0 is ok, whilst Div2-1 is still settling, large deviations.
That's for the sweep scheme you have, but it also seems valid for random step sizes. Once above that threshold, errors are very small.
Not an especially fast settling time, at (2^ENOB)/2, but that may mean you can read twice as fast ?
It does indicate going down to lower ENOB can help speed.
We had to go this slow in order to make every single conversion code possible. At twice this sample rate, 95% of the readings would still be on the nose, but a minority would not be. This is all the way into the perfect zone, as the filters go.
I don't want to see the output range of the scope filter reduced. For applications like video or software defined radio the signal will rarely linger on the pathological steps. If we reduce the output range, we'd be adding quantization noise to hide the few steps that we can't measure.
I agree very much. Masking off bits so that only 5 or 6 are used would only reduce the ENOB to less than what it already is.
As the scope mode has an 8-bit output, it seems to me that the most accurate window will be one that sums to 255 without clipping or truncation and CMA(3,5,17) with length 25 fits the bill. Longer windows would have sums greater than 255 and the necessary truncation would affect taps with low values proportionately much more than those with maximum/plateau values. On that basis, a sum of 510 would be better than 1020, 2040, etc.
I don't want to see the output range of the scope filter reduced. For applications like video or software defined radio the signal will rarely linger on the pathological steps. If we reduce the output range, we'd be adding quantization noise to hide the few steps that we can't measure.
I agree very much. Masking off bits so that only 5 or 6 are used would only reduce the ENOB to less than what it already is.
As the scope mode has an 8-bit output, it seems to me that the most accurate window will be one that sums to 255 without clipping or truncation and CMA(3,5,17) with length 25 fits the bill. Longer windows would have sums greater than 255 and the necessary truncation would affect taps with low values proportionately much more than those with maximum/plateau values. On that basis, a sum of 510 would be better than 1020, 2040, etc.
I actually agree, TonyB_. They ought to saturate to $FF. No need to be a purist in this case. It's just going to be darn cool to have scope traces, even if they aren't numerically perfect. While they won't convey DC values perfectly, they are going to be the best we can get for phase representation. This scope mode is mostly about being able to view signals with minimal jitter. There's no other mode that addresses that.
If this is the way it goes, then it seems to me anyone wanting DC, or other reference type signals can simply dedicate another pin to that and overlay / work it into whatever display representation makes sense.
Vpp98% is an estimate of the peak-to-peak noise in a 0-255 measurement. A value of 1 means most measurements vary between 49 and 50 for example.
TonyB has created some filters with a reduced plateau height. That does make the complexity slightly higher but it's nothing to worry about. It does give us more flexibility to adjust the filter shape and sum than strict CMA filters. I haven't tried to generate those automatically yet.
Generating a larger sum gives us more flexibility in both grouping the factors together and increasing the range of sum values that will truncate to 255. Many filters sum to 2^N and would need saturation. Even though a saturated ADC is beyond the rails, it would be confusing if saturated positive and saturated negative both measure as 0. Can it saturate or will the diodes clamp it before that?
Saucy, it will saturate in the cases of the magnified modes, even if the diodes clamp the 1x modes before saturation. We need to handle saturation by returning $FF, or not getting there, in the first place. The new ADC modes have the same issue. They want to saturate to 2^n on all 1's coming in, whereas we need to limit them to (2^n)-1.
Saucy, I have a question for you... You know that by adding log values of numbers, you are really multiplying them, while subtraction divides, left shift by one squares, and right shift by one square-roots. So, logs are useful for achieving higher-order functions from lower-order ones. I am wondering... What can be done with log values of log values? Some of you may have an idea.
Jmg, I added your efficiency change and also found that by pre-shifting the ADC bit left, there's no need to variably shift the final result right, which would have been way more expensive. I also realized that we don't have enough flops for the staggered diff's, so we're at half the sample rate now. I moved the intb computation before the inta computation to make it work like the hardware and it improved early readings. This is getting to be really simple:
code = 0 'code to establish enob, 0..7 --> 6..13 enob
enob = 6 + code 'effective number of bits 6..13
maxenob = 6 + 7
bitmask = pow(2,maxenob*2-1)-1
decimate = pow(2,enob-1)
range = pow(2,enob)
acc = rnd 'expose flaws
for g = 0 to range
for iter = 0 to range*2
acc = acc + g/range 'determine new ADC bit
if acc >= 1 then
acc = acc - 1
t = pow(2,7-code) 'variably shift up ADC bit before integration to avoid shifting final sample
else
t = 0
endif
intb = (intb + inta) band bitmask
inta = (inta + t) band bitmask
if iter/decimate = int(iter/decimate) then
result = ((intb - diff) band bitmask) 'compute result
sample = int((result+pow(2,10))/pow(2,11)) 'round and shift down to make sample
diff = intb
intb = 0
if iter > range/2 then circle 10+(g mod 256)*4 + int(g/256)*12, 10+((range-sample) mod 256)*4, 2 filled
endif
next iter
print sample,
next g
Also, since only the scope mode is going to be used by the streamer, there's no need to implement saturation on this one, as it returns 32-bit results via RDPIN. If the customer wants to clamp an 8-bit reading to $FF, he can do a 'FLE sample,#$FF'.
Jmg, I added your efficiency change and also found that by pre-shifting the ADC bit left, there's no need to variably shift the final result right, which would have been way more expensive. I also realized that we don't have enough flops for the staggered diff's, so we're at half the sample rate now. This is getting to be really simple:
This reports & steps at range/2 rate, which means you could deliver the same results with a staggered counter scheme ?
Would 2 staggered counters be lower cost than 2 adders and one subtracter ?
Jmg, I added your efficiency change and also found that by pre-shifting the ADC bit left, there's no need to variably shift the final result right, which would have been way more expensive. I also realized that we don't have enough flops for the staggered diff's, so we're at half the sample rate now. This is getting to be really simple:
This reports & steps at range/2 rate, which means you could deliver the same results with a staggered counter scheme ?
Would 2 staggered counters be lower cost than 2 adders and one subtracter ?
We've only got room for one set. I've implemented it and we've only got five flops to spare.
I've got the Sinc2 ADC mode working in the smart pins. It's settable for 7..14-bit conversions.
Look at the lower 8 bits of this 14-bit conversion. Almost no noise. It would take 63 more scope screens stacked vertically to see the whole sine wave:
I think it would be good at 16 bits, too, but I'm out of flops.
Some careful effort was spent on making sure this Sinc2 filter had no missing codes at all resolutions. It lets the ADC really shine.
I've got the Sinc2 ADC mode working in the smart pins. It's settable for 7..14-bit conversions.
Look at the lower 8 bits of this 14-bit conversion. Almost no noise. It would take 63 more scope screens stacked vertically to see the whole sine wave:
Is that with the real P2 ADC data feeding it ? What HW test setup ?
Can you plot Sinc3, also fed from a real ADC, as a comparison ?
What bit-counts does this cover ? I presume this can also be fed from an external pin ?
Could someone set this up to stream at some modest #bits rate, and then apply another filter in software for 16/18/20 bits, depending on where the system noise floor was ?
I've got the Sinc2 ADC mode working in the smart pins. It's settable for 7..14-bit conversions.
Look at the lower 8 bits of this 14-bit conversion. Almost no noise. It would take 63 more scope screens stacked vertically to see the whole sine wave:
Is that with the real P2 ADC data feeding it ? What HW test setup ?
Can you plot Sinc3, also fed from a real ADC, as a comparison ?
What bit-counts does this cover ? I presume this can also be fed from an external pin ?
Could someone set this up to stream at some modest #bits rate, and then apply another filter in software for 16/18/20 bits, depending on where the system noise floor was ?
Yes. That was the P2 pin test board on the FPGA. I was feeding it from a quiet 3.3 volt regulator on the new P2 eval board. It's real.
I was looking at the sinc3 filter today, after I got the sinc2 working. It is amazing what the sinc3 can do with dynamic signals, but it does not have enough base information to know DC very accurately. These new sinc2 modes are like instrumentation modes for the ADC, whereas the sinc3 is like a dynamic mode for changing signals. Because of rapid bit growth, the sinc3 can only do 1K clocks before it fills up. The sinc2 is going to get a slight makeover and go to 16 bits, taking 32K clocks to achieve a conversion. I am anxious to see what a 16-bit sinc2 conversion looks like.
Comments
I've been experimenting with those kinds of variations. I've reduced it down to 9 bits per term, instead of 11, by only propagating the diff's of the diff's, then running a moving average filter.
A useful test when you have a short list of candidates, would be to plot the same ENOB curves as Rayman linked here
and see what dB/double slope you measure, for changes in oversample ratios.
Curious to see what effective order ADC modulator, the P2 has.
Ideal second order modulator is 15.05dB/double, (coupled to sinc3) and 1st order is 9.03dB/double, (coupled to sinc2?)
The number may be between 9.03 and 15.05 dB/double.
A plot of a stepped sawtooth, and showing the difference from ideal, will show the ADC delays and settling times, as well as the DNL.
Since this scope-mode is low resolution, the P2 DACs are probably good enough.
putting intb accumulation outside the busy loop doesn't seem to work. It seems to need to work along with inta.
Many lessons have to be learned. First: what (besides TaqOz) is the preferable tool. My intention is not to use C to extend.
These maybe, seems to be in rapid development ? - Compiler for Basic/Spin/PASM and alpha-C
https://forums.parallax.com/discussion/168913/new-basic-compiler-for-prop1-and-prop2/p1
https://forums.parallax.com/discussion/164187/fastspin-compiler-for-p2/p1
Enjoy!
Mike
Here is what I want to do:
- Implement the scope mode, as already designed, but limit the submodes to realistic numbers of bits, like 6 and 5. No need to worry about exceeding $FF, anymore.
- Implement a Sinc2 mode for doing background conversions of 6/7/8/9/10/11/12/13 bits. Sinc2 is very low on logic and would afford a nice automated ADC mode.
Here is the Sinc2 code I will implement. It maintains two scrolling diffs that allow samples to overlap, doubling the sample rate. These Sinc2 filters are proven in this program to hit every possible value within the duty range, according to the bitstream coming in. The 13-bit mode registers 2..8190 without any missing codes. Phil would definitely approve of its soundness:
enob = 10 'effective number of bits 6..13 maxenob = 13 bitmask = pow(2,maxenob*2-2)-1 decimate = pow(2,enob-2) divide = decimate/2 range = pow(2,enob) acc = rnd 'expose flaws for g = 0 to range for iter = 0 to range*2 acc = acc + g/range 'new ADC bit if acc >= 1 then acc = acc - 1 t = 1 else t = 0 endif inta = (inta + t) band bitmask intb = (intb + inta) band bitmask if iter/decimate = int(iter/decimate) then sample = int((((intb - dif0) band bitmask)+divide/2)/divide) dif0 = dif1 dif1 = intb intb = 0 if iter > range then circle 10+(g mod 256)*4 + int(g/256)*12, 10+((range-sample) mod 256)*4, 2 filled endif next iter 'print sample, next gIs there still a sinc3 mode support planned, for those many external commercial ADCs out there ?
Having overlapped samples gives more of an illusion of speed, if the step response is not improved. What is the logic cost of the overlap ?
ie in an earlier example, you gave 8 bits, at 8 bits per sysclk, but needing 256 clocks to settle. That slow slew/settle effect is poor for a scope.
Sinc3 mode is still in the smart pins. It works best, but needs software management.
The overlap is pretty much free. We've got 112 flops. Might as well use them.
-Phil
Good.
To clarify : Is this sinc2 mode a new mode ?
ie for first-order ADC, no diff-step needed in SW (as in sinc3), so users can simply stream final ADC values
I've been trying to find theory examples of sinc3 filters used with first order modulators, with not much success. (Plenty of second order + sinc3)
I think you've run P2 ADC captures into sinc3, did you extract a ENOB, or SNR for those ?
It seems to me that Sinc3+first order, will lie somewhere between the slopes of sinc2+first order and sinc3+second order.
Will the sinc2 be able to set below 8b ? Seems it could be useful to trade off resolution for speed.
One simple looking way is to take FFT of result of sine wave capture and do some math:
http://www.mit.edu/~klund/A2Dtesting.pdf
If the input is 3/4, we see a 1, 0, 0, 0, ..signal so we need 4 clocks to recognize this value. But as the signal is noisy, we need averaging anyway, introducing larger latency. A SDADC is a SDADC, there is no way around. In the end, we have a tracking adc, perfect for non jumping input signals.
I figured out something really weird last night about how all of this could come together.
Suppose that we convolve the input with a sliding [1,4,6,4,1] window on a bit by bit basis using whatever works out best for the logic. As I see it a hardware implementation using individual gates would do the job nicely (only 5 LE's!?!), but you still have to get the bit stream to the gates and back into the registers and if exotic summation can be shoehorned in at a lower cost by firing off increment and decrement pulses to existing logic then that might make sense.
But of course [1,4,6,4,1] isn't really a sinc2, or is it? Based on convolution theory it is the convolution of [1,2,1] with [1,2,1], with or without decimation - and we know that the first [1,2,1] window completely whacks all patterns of the type ....01010101.... or ...10101010.... into oblivion, or at least averages; which is where we want them to be. Yet [1,2,1] is actually a primitive Gaussian, with nice equiripple (read: zero phase shift) characteristics - and it has its first zero at Fs/2 which is exactly what sinc1 does. So it is a sinc1 type function - even if it is actually sinc1 squared.
Repeating the process - we get [1,4,6,4,1] for the convolution that gives the equiripple sinc2 function; and it is actually just the triangular window [1,2,1] convolved with itself - even if you were expecting a triangular window for sinc2. Hmmm - what is going on here?
And then I noticed something. What if we do a [1,4,6,4,1] in hardware and then overlap and add, skipping two clock cycles in between windowing operations.
[1,4,6,4,1,0,0]
+[0,0,1,4,6,4,1] = [1,4,7,8,7,4,1] which would be a nice little period seven triangular window, every clock cycle, or every other clock cycle, or every third clock cycle; or however often you want to run it - if you were to somehow replace that 8 with a 10; but why do that? Just in case you were expecting a rabbit - or if you must insist that sinc2 look like a triangle; it is in there; hiding somewhere in between the hat and the smoke and mirrors.
Well, lets try this again.
Feed [1,4,7,8,7,4,1] into a two tap delay and add. Or do I want a 4 tap delay?
Let's start with the two tap delay ...
[1,4,7,8,7,4,1,0,0]
+[0,0,1,4,7,8,7,4,1] = [1,4,8,12,14,12,8,4,1]
So for the price of a the delay and add and another delay and add we get a nine sample wide trapezoid; well almost; except now the rabbit is wearing a top hat with that 14, instead of a 12; which would have made it a trapezoid.
Time to try a four clock delay.
[1,4,8,12,14,12,8,4,1,0,0,0,0]
+[0,0,0,0,1,4,8,12,14,12,8,4,1] = [1,4,8,12,15,16,16,16,15,12,8,4,1]
Which is a 13 sample wide Tukey sandwich; or its a Tukey sandwich; stuffed with Tukey sausage. Of course that means I can take advantage of the fact that 4+8=12 and that 15+16, and do this exactly one more time, with another four tap delay.
[1,4,8,12,15,16,16,16,15,12,8,4,1,0,0,0,0,0,0,0,0]
+[0,0,0, 0, 0,0,0,0,1,4, 8,12,15,16,16,16,15,12,8,4,1] = are you ready for this?
[1,4,8,12,15,16,16,16,16,16,16,16,16,16,16,16,15,12,8,4,1] ---> sums to 256 ....
Now for people that like to count bits; there are plenty to go around. Since it becomes possible to accumulate the running counts; by only having to add on every eight clocks; and the sandwich can be stretched to infinity or you can get on or off the Tukey bus any time you like. Eventually we want to decimate - but the idea of having a running Tukey window that has a sinc2 or sinc3 pedigree hidden under the hood has some appeal; i.e., for the scope modes; since the original [1,4,6,4,1] or some variant can be used as a scope trigger; while an 21 tap Tukey window and 256/8 would be 84 nanosecond aperture window running at 32 Mhz; whereas that 18 wide window would have a cutoff frequency around 12Mz; leaving lots of bandwidth for manipulation in software while providing -- possibilities ....
This filter seems equivalent to a CMA(512,256). (You can't see the cma trace because it's underneath the sinc2.) It's great that a filter like this can be implemented so cheaply.
I don't want to see the output range of the scope filter reduced. For applications like video or software defined radio the signal will rarely linger on the pathological steps. If we reduce the output range, we'd be adding quantization noise to hide the few steps that we can't measure.
We can design filters with any sum as long as it has enough factors.
forums.parallax.com/discussion/comment/1458147/#Comment_1458147
I changed the code
to look for the settling time, and found display enable gate can be reduced to range/2, but no further.
That's for the sweep scheme you have, but it also seems valid for random step sizes. Once above that threshold, errors are very small.
Not an especially fast settling time, at (2^ENOB)/2, but that may mean you can read twice as fast ?
It does indicate going down to lower ENOB can help speed.
We had to go this slow in order to make every single conversion code possible. At twice this sample rate, 95% of the readings would still be on the nose, but a minority would not be. This is all the way into the perfect zone, as the filters go.
I agree very much. Masking off bits so that only 5 or 6 are used would only reduce the ENOB to less than what it already is.
As the scope mode has an 8-bit output, it seems to me that the most accurate window will be one that sums to 255 without clipping or truncation and CMA(3,5,17) with length 25 fits the bill. Longer windows would have sums greater than 255 and the necessary truncation would affect taps with low values proportionately much more than those with maximum/plateau values. On that basis, a sum of 510 would be better than 1020, 2040, etc.
I actually agree, TonyB_. They ought to saturate to $FF. No need to be a purist in this case. It's just going to be darn cool to have scope traces, even if they aren't numerically perfect. While they won't convey DC values perfectly, they are going to be the best we can get for phase representation. This scope mode is mostly about being able to view signals with minimal jitter. There's no other mode that addresses that.
TonyB has created some filters with a reduced plateau height. That does make the complexity slightly higher but it's nothing to worry about. It does give us more flexibility to adjust the filter shape and sum than strict CMA filters. I haven't tried to generate those automatically yet.
Generating a larger sum gives us more flexibility in both grouping the factors together and increasing the range of sum values that will truncate to 255. Many filters sum to 2^N and would need saturation. Even though a saturated ADC is beyond the rails, it would be confusing if saturated positive and saturated negative both measure as 0. Can it saturate or will the diodes clamp it before that?
Saucy, I have a question for you... You know that by adding log values of numbers, you are really multiplying them, while subtraction divides, left shift by one squares, and right shift by one square-roots. So, logs are useful for achieving higher-order functions from lower-order ones. I am wondering... What can be done with log values of log values? Some of you may have an idea.
code = 0 'code to establish enob, 0..7 --> 6..13 enob enob = 6 + code 'effective number of bits 6..13 maxenob = 6 + 7 bitmask = pow(2,maxenob*2-1)-1 decimate = pow(2,enob-1) range = pow(2,enob) acc = rnd 'expose flaws for g = 0 to range for iter = 0 to range*2 acc = acc + g/range 'determine new ADC bit if acc >= 1 then acc = acc - 1 t = pow(2,7-code) 'variably shift up ADC bit before integration to avoid shifting final sample else t = 0 endif intb = (intb + inta) band bitmask inta = (inta + t) band bitmask if iter/decimate = int(iter/decimate) then result = ((intb - diff) band bitmask) 'compute result sample = int((result+pow(2,10))/pow(2,11)) 'round and shift down to make sample diff = intb intb = 0 if iter > range/2 then circle 10+(g mod 256)*4 + int(g/256)*12, 10+((range-sample) mod 256)*4, 2 filled endif next iter print sample, next gAlso, since only the scope mode is going to be used by the streamer, there's no need to implement saturation on this one, as it returns 32-bit results via RDPIN. If the customer wants to clamp an 8-bit reading to $FF, he can do a 'FLE sample,#$FF'.
Would 2 staggered counters be lower cost than 2 adders and one subtracter ?
We've only got room for one set. I've implemented it and we've only got five flops to spare.
Look at the lower 8 bits of this 14-bit conversion. Almost no noise. It would take 63 more scope screens stacked vertically to see the whole sine wave:
I think it would be good at 16 bits, too, but I'm out of flops.
Some careful effort was spent on making sure this Sinc2 filter had no missing codes at all resolutions. It lets the ADC really shine.
It would look bumpier by a few samples +/-. And the acquisition time would double.
Is that with the real P2 ADC data feeding it ? What HW test setup ?
Can you plot Sinc3, also fed from a real ADC, as a comparison ?
What bit-counts does this cover ? I presume this can also be fed from an external pin ?
Could someone set this up to stream at some modest #bits rate, and then apply another filter in software for 16/18/20 bits, depending on where the system noise floor was ?
Yes. That was the P2 pin test board on the FPGA. I was feeding it from a quiet 3.3 volt regulator on the new P2 eval board. It's real.
I was looking at the sinc3 filter today, after I got the sinc2 working. It is amazing what the sinc3 can do with dynamic signals, but it does not have enough base information to know DC very accurately. These new sinc2 modes are like instrumentation modes for the ADC, whereas the sinc3 is like a dynamic mode for changing signals. Because of rapid bit growth, the sinc3 can only do 1K clocks before it fills up. The sinc2 is going to get a slight makeover and go to 16 bits, taking 32K clocks to achieve a conversion. I am anxious to see what a 16-bit sinc2 conversion looks like.