Welcome to the Parallax Discussion Forums, sign-up to participate.

- 101.6K All Categories
- 812 Announcements
- 59 Propeller Code
- 24 PASM2/Spin2 (P2)
- 9 PASM/Spin (P1)
- 15 BASIC (for Propeller)
- 61 Forth
- 10 C/C++
- 2.8K Propeller 2
- 27.6K Propeller 1
- 18.9K BASIC Stamp
- 10 micro:bit
- 21.1K General Discussion
- 2K Learn with BlocklyProp
- 8.2K Robotics
- 124 Customer Projects
- 3.3K Accessories

## Comments

13,690I'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.

14,884A 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

between9.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.

13,690putting intb accumulation outside the busy loop doesn't seem to work. It seems to need to work along with inta.

1,672Many lessons have to be learned. First: what (besides TaqOz) is the preferable tool. My intention is not to use C to extend.

14,884These 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

3,499Enjoy!

Mike

13,690Here 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:

14,884Is 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.

13,690Sinc3 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.

23,185-Phil

14,884Good.

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

firstorder 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.

12,372One simple looking way is to take FFT of result of sine wave capture and do some math:

http://www.mit.edu/~klund/A2Dtesting.pdf

1,672If 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.

34I 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 ....

374This 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

14,884I 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.

13,690We 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.

1,809I 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.

13,690I 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.

10,222374TonyB 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?

13,690Saucy, 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.

13,690Also, 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'.

14,884Would 2 staggered counters be lower cost than 2 adders and one subtracter ?

13,690We've only got room for one set. I've implemented it and we've only got five flops to spare.

13,690Look 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.

4,07013,690It would look bumpier by a few samples +/-. And the acquisition time would double.

14,884Is 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 softwarefor 16/18/20 bits, depending on where the system noise floor was ?13,690Yes. 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.