ADC Sampling Breakthrough - Page 33 — Parallax Forums

• edited 2018-12-11 20:14
A new window, Tukey 23(17)/30, has only two absolute derivative values. I've chosen to use the nearest integer difference between taps and 3 and 27 below would be 4 and 26 if using nearest integer to each actual tap. The shift register is larger but the max value of 30 means integrator b is only 6-bit.

I've shown Tukey 19(15)/34 again and added a couple of trapezoidal windows for logic comparison and completeness. Trap. 17(15)/32 requires an output clamp but the short version is perfectly triangular.
```Tukey 23(17)/30, shift reg bits = 17+17+17 = 51
1, 2, 3, 5, 7, 9,11,13,15,17,19,21,23,25,27,28,29	Ramp up   total = 255 Tukey/Hann
30							Plateau   total = 510 Tukey
29,28,27,25,23,21,19,17,15,13,11, 9, 7, 5, 3, 2, 1	Ramp down total = 255 Tukey/Hann

Tukey 19(15)/34, shift reg bits = 15+15+15 = 45
1, 2, 4, 6, 8,11,14,17,20,23,26,28,30,32,33		Ramp up   total = 255 Tukey/Hann
34							Plateau   total = 510 Tukey
33,32,30,28,26,23,20,17,14,11, 8, 6, 4, 2, 1		Ramp down total = 255 Tukey/Hann

Trap. 17(15)/32, shift reg bits = 15+17+15 = 47, needs clamp
2, 4, 6, 8,10,12,14,16,18,20,22,24,26,28,30		Ramp up   total = 240 Trap./Tri.
32							Plateau   total = 544/32 Trap./Tri.
30,28,26,24,22,20,18,16,14,12,10, 8, 6, 4, 2 		Ramp down total = 240 Trap/Tri.

Trap. 16(14)/30, shift reg bits = 14+20+14 = 48
2, 4, 6, 8,10,12,14,16,18,20,22,24,26,28		Ramp up   total = 210 Trap./Tri.
30							Plateau   total = 600/90 Trap./Tri.
28,26,24,22,20,18,16,14,12,10, 8, 6, 4, 2 		Ramp down total = 210 Trap./Tri.
```
• evanh wrote: »
Cool, that would be handy right now for this AD7400.

Have a look at synchronous serial smartpin mode. Data from pin A is shuffled into a 32 bit register when clock on pin B rises/lowers
• TonyB_, I made a SmallBASIC program that lets me try any spacing between the three slope changes, between their inflections, and between the plateau edges.

I expanded the tap shifter to 73 bits and want to have four filter settings. The longest one will be lowest-pass. We just mux in the tap pairs. I want to see what a lowest-pass filter looks like. We are still a little rough at 45 taps.
```dim t(71)

for x = 0 to 71
t(x) = 0
next x

a = 0 : b = 0 : c = 31 : d = 2      '64-tap triangle window
d1 = 1 : d2 = 0 : d3 = 0 : m = 1

'a = 1 : b = 1 : c = 9 : d = 18      '44-tap Saucy Tukey window
'd1 = 1 : d2 = 1 : d3 = 1 : m = 1

'a = 1 : b = 3 : c = 6 : d = 18      '46-tap TonyB_ Tukey 17/32 window (overflows!)
'd1 = 1 : d2 = 1 : d3 = 1 : m = 1

'a = 2 : b = 3 : c = 6 : d = 14      '46-tap TonyB_ Tukey 19/34 window
'd1 = 1 : d2 = 1 : d3 = 1 : m = 1

'a = 1 : b = 2 : c = 8 : d = 1      '29-tap Hann window
'd1 = 1 : d2 = 1 : d3 = 1 : m = 2

t0  = 0
t1  = t0  + a
t2  = t1  + b
t3  = t2  + c
t4  = t3  + b
t5  = t4  + a
t6  = t5  + d
t7  = t6  + a
t8  = t7  + b
t9  = t8  + c
t10 = t9  + b
t11 = t10 + a

print "taps",,
if d1 = 1 then print t0,
if d2 = 1 then print t1,
if d3 = 1 then print t2,
if d3 = 1 then print t3,
if d2 = 1 then print t4,
if d1 = 1 then print t5,
if d1 = 1 then print t6,
if d2 = 1 then print t7,
if d3 = 1 then print t8,
if d3 = 1 then print t9,
if d2 = 1 then print t10,
if d1 = 1 then print t11,
print : print

inta = 0
intb = 0
intc = 0

for y = 0 to 71*2

for x = 71 to 1 step -1
t(x) = t(x-1)
next x

t(00) = 1
if y>71 then t(00) = 0

delta = 0

if (t(t0) = 1 and t(t0+1) = 0) then delta = delta + d1
if (t(t0) = 0 and t(t0+1) = 1) then delta = delta - d1

if (t(t1) = 1 and t(t1+1) = 0) then delta = delta + d2
if (t(t1) = 0 and t(t1+1) = 1) then delta = delta - d2

if (t(t2) = 1 and t(t2+1) = 0) then delta = delta + d3
if (t(t2) = 0 and t(t2+1) = 1) then delta = delta - d3

if (t(t3) = 1 and t(t3+1) = 0) then delta = delta - d3
if (t(t3) = 0 and t(t3+1) = 1) then delta = delta + d3

if (t(t4) = 1 and t(t4+1) = 0) then delta = delta - d2
if (t(t4) = 0 and t(t4+1) = 1) then delta = delta + d2

if (t(t5) = 1 and t(t5+1) = 0) then delta = delta - d1
if (t(t5) = 0 and t(t5+1) = 1) then delta = delta + d1

if (t(t6) = 1 and t(t6+1) = 0) then delta = delta - d1
if (t(t6) = 0 and t(t6+1) = 1) then delta = delta + d1

if (t(t7) = 1 and t(t7+1) = 0) then delta = delta - d2
if (t(t7) = 0 and t(t7+1) = 1) then delta = delta + d2

if (t(t8) = 1 and t(t8+1) = 0) then delta = delta - d3
if (t(t8) = 0 and t(t8+1) = 1) then delta = delta + d3

if (t(t9) = 1 and t(t9+1) = 0) then delta = delta + d3
if (t(t9) = 0 and t(t9+1) = 1) then delta = delta - d3

if (t(t10) = 1 and t(t10+1) = 0) then delta = delta + d2
if (t(t10) = 0 and t(t10+1) = 1) then delta = delta - d2

if (t(t11) = 1 and t(t11+1) = 0) then delta = delta + d1
if (t(t11) = 0 and t(t11+1) = 1) then delta = delta - d1

inta = inta + delta * m
intb = intb + inta
intc = intc + intb

sample = int(intc/4)
print inta,intb,intc,sample

next y
```
• The 64-tap triangle window looks really good!

I forget... Does a Tukey Window smooth better than a triangle window? I know it lets more signal through, bit this triangle window looks really good.
• cgracey wrote: »
The 64-tap triangle window looks really good!

I forget... Does a Tukey Window smooth better than a triangle window? I know it lets more signal through, bit this triangle window looks really good.

Chip, your programs work fine in QuickBASIC. I'll consult my literature.

Are simple registers in other modes re-cycled as the shift register in scope mode and therefore not additional logic?
• TonyB_ wrote: »
cgracey wrote: »
The 64-tap triangle window looks really good!

I forget... Does a Tukey Window smooth better than a triangle window? I know it lets more signal through, bit this triangle window looks really good.

Chip, your programs work fine in QuickBASIC. I'll consult my literature.

Are simple registers in other modes re-cycled as the shift register in scope mode and therefore not additional logic?

Right, kind of. There are just mux's to existing flops in the smart pin.
• Triangular window (aka Sinc2): sidelobes fall off at -12dB per octave.
Hann window: sidelobes fall off at -18dB per octave.
• Tukey

A Tukey window is very flat in the time domain, close to a value of 1.0 for a majority of the window. A ‘Taper Length’ can be specified which determines the amount of time that the window maintains a value of one (Figure 14). The lower the taper length, the longer the Tukey has a value of one over the measurement time.

tukey.png
Figure 14: The ‘Taper length’ determines how much of the Tukey window has a value of zero
Typically, Tukey windows are used to analyze transient data. The advantage of a Tukey window is that the amplitude of transient signal in the time domain is less likely to be altered compared to using Hanning or Flattop (see Figure 15). In a Hanning or Flattop window, the value of the window equals one for a shorter span compared to the Tukey window.

Source:
https://community.plm.automation.siemens.com/t5/Testing-Knowledge-Base/Window-Types-Hanning-Flattop-Uniform-Tukey-and-Exponential/ta-p/445063
• TonyB_ wrote: »
Triangular window (aka Sinc2): sidelobes fall off at -12dB per octave.
Hann window: sidelobes fall off at -18dB per octave.

So, what would be quietest for a DC measurement?
• edited 2018-12-12 01:21
cgracey wrote: »
TonyB_ wrote: »
Triangular window (aka Sinc2): sidelobes fall off at -12dB per octave.
Hann window: sidelobes fall off at -18dB per octave.

So, what would be quietest for a DC measurement?

Triangular, maybe.

A Tukey is a mixture of Hann + rectangular. Exact behaviour depends on lengths of plateau and ramps and we need Saucy's help for the frequency response. First or second sidelobes might not be attentuated as much as triangular, whereas higher ones probably are.

I've just been reading that a rectangular moving average window is hopeless in the frequency domain but cannot be beaten for random noise reduction as all samples have equal weight, although other windows can match it. Multiple-pass moving average filters are better in the frequency domain and two-pass is equivalent to triangular window.

There is also a Blackman window that is a relative of Hann. What is the main constraint now if not the shift register? Number of different slopes?
• Tubular wrote: »
evanh wrote: »
Cool, that would be handy right now for this AD7400.

Have a look at synchronous serial smartpin mode. Data from pin A is shuffled into a 32 bit register when clock on pin B rises/lowers

Good point. I can throw a cog at this ...

• cgracey wrote: »
Here is the new triple-integrating Tukey 17/32 that's in the smart pins. It reduced each smart pin by 35 ALMs, which is good.

... Chip, I really think you're on to something here. I don't know how much logic it would save to go to the cascaded moving average setup. It's using 62 register bits for a 43 tap filter. This is 48 bits. This method is much more flexible at configuring the shape, length, and sum.

It seems to me that:
(tap[01:00] == 2'b01) - (tap[01:00] == 2'b10) = tap-tap
but beware of sign-extend issues. Perhaps the compiler already figured it out. Also, this might be introducing an extra differentiation. I'll run some more analysis, but I want to get some of this out sooner.

It may also be worth considering 4 accumulators. It might reduce the number of difference terms, depending on the filter shape.

-James

• TonyB_ wrote: »
cgracey wrote: »
TonyB_ wrote: »
Triangular window (aka Sinc2): sidelobes fall off at -12dB per octave.
Hann window: sidelobes fall off at -18dB per octave.

So, what would be quietest for a DC measurement?

Triangular, maybe.

A Tukey is a mixture of Hann + rectangular. Exact behaviour depends on lengths of plateau and ramps and we need Saucy's help for the frequency response. First or second sidelobes might not be attentuated as much as triangular, while other ones are.

I've just been reading that a rectangular moving average window is hopeless in the frequency domain but cannot be beaten for random noise reduction as all samples have equal weight, although other windows can match it. Multiple-pass moving average filters are better in the frequency domain and two-pass is equivalent to triangular window.

There is also a Blackman window that is a relative of Hann. What is the main constraint now if not the shift register? Number of different slopes?

Number of slopes. Trying to find some agreeable setting that will allow bypass of taps to achieve the Hann function. Tukey 17/32 does this, but needs clamping.

The 65-tap triangle filter really looks good.

I'm thinking that there must be some way to get higher-quality results every clock. Consider that a 16-sample Sinc3 is 8 bits in quality and uses the prior two samples (my understanding, anyway). That's all of 48 bits. We have that, and more.
• It seems to me that:
(tap[01:00] == 2'b01) - (tap[01:00] == 2'b10) = tap-tap

Whoa!!! I never realized that. I'm going to recode this to see if it gets smaller.
• Saucy, it works!!! Very nice. This should simplify the logic requirements.
• TonyB_ wrote: »
cgracey wrote: »
TonyB_ wrote: »
Triangular window (aka Sinc2): sidelobes fall off at -12dB per octave.
Hann window: sidelobes fall off at -18dB per octave.

So, what would be quietest for a DC measurement?

Triangular, maybe.

A Tukey is a mixture of Hann + rectangular. Exact behaviour depends on lengths of plateau and ramps and we need Saucy's help for the frequency response. First or second sidelobes might not be attentuated as much as triangular, whereas higher ones probably are.

I've just been reading that a rectangular moving average window is hopeless in the frequency domain but cannot be beaten for random noise reduction as all samples have equal weight, although other windows can match it. Multiple-pass moving average filters are better in the frequency domain and two-pass is equivalent to triangular window.

There is also a Blackman window that is a relative of Hann. What is the main constraint now if not the shift register? Number of different slopes?

```WindowFn  Vpp98%        StdDev     HFNoisePower        Length        HighBits
tukey23    1.296875     0.3052516    0.03864301            51           162
tukey19    1.640625     0.3852341     0.2272677            45            96
trap17          1.5     0.3823879    0.08385934            47            81
trap16      1.71875     0.4219522     0.0710496            48           136
tukey1732   1.65625     0.4026682     0.2243628            45            91
triangle64 1.109375     0.2585853      0.036246            64           162
triangle51 1.395833      0.320317     0.1475521            51           117
```
Vpp is probably the best measure of noise in a scope display. Just ignore the HighBitCount as that's not really relevant to how we will implement it now. So longer filters work better Tukey is better than a triangle of the same length.
• cgracey wrote: » Doing the conversion and canceling I got this:
```delta= tap
+tap
+tap
+tap
+tap
+tap
+tap
+tap

-tap
-tap
-tap
-tap
-tap
-tap
-tap
-tap
```
Compare this to the third derivative of Tukey17. Indies vary because I had to pad the edges to avoid loosing data. And Matlab starts arrays at 1. Other than that, they are the same. So delta is the third derivative of the output. If we integrate it 3 times, we get the output.
```         Non-zero terms in
Window   len  d1  d2  d3  d4
Tukey17   45  28  12  16  28
Tukey23   51  36   8  16  24
```

But wait a minute, the second derivative has fewer non-zero terms. And that will eliminate an integrator as well. Also let's switch to Tukey23 because it performs better and saves summer terms.
```delta=tap+tap+tap+tap   -tap-tap-tap-tap;
Integrate twice
```
Note: I have not check the above for order of operations or sign-extension issues.
• TonyB_ wrote: »
cgracey wrote: »
TonyB_ wrote: »
Triangular window (aka Sinc2): sidelobes fall off at -12dB per octave.
Hann window: sidelobes fall off at -18dB per octave.

So, what would be quietest for a DC measurement?

Triangular, maybe.

A Tukey is a mixture of Hann + rectangular. Exact behaviour depends on lengths of plateau and ramps and we need Saucy's help for the frequency response. First or second sidelobes might not be attentuated as much as triangular, whereas higher ones probably are.

I've just been reading that a rectangular moving average window is hopeless in the frequency domain but cannot be beaten for random noise reduction as all samples have equal weight, although other windows can match it. Multiple-pass moving average filters are better in the frequency domain and two-pass is equivalent to triangular window.

There is also a Blackman window that is a relative of Hann. What is the main constraint now if not the shift register? Number of different slopes?

```WindowFn  Vpp98%        StdDev     HFNoisePower        Length        HighBits
tukey23    1.296875     0.3052516    0.03864301            51           162
tukey19    1.640625     0.3852341     0.2272677            45            96
trap17          1.5     0.3823879    0.08385934            47            81
trap16      1.71875     0.4219522     0.0710496            48           136
tukey1732   1.65625     0.4026682     0.2243628            45            91
triangle64 1.109375     0.2585853      0.036246            64           162
triangle51 1.395833      0.320317     0.1475521            51           117
```
Vpp is probably the best measure of noise in a scope display. Just ignore the HighBitCount as that's not really relevant to how we will implement it now. So longer filters work better Tukey is better than a triangle of the same length.

What is the logic cost of doing this for the rectangular, i.e., flat top part. as it requires only 5 additions to run the function, i.e., by bit-weaving the data flow, so that it could be available as an PASM opcode, (if it isn't already); but it would run automatically if you wanted a Tukey accumulate in streaming data acquisition mode. Of course for the ends of the sausage then starting and stop functions could be called; which might use a one sided special triangular slope; or half cosine window function call - so that to start the Tukey you would compute the triangular starter window once; followed by count bits (and scale sum as desired), and then to stop accumulating you would call ) "flat top MINUS the triangular", or else remember that the Hann window is a raised cosine - so that you need f(x) = 1=cosine(x); and here again is the 1 part; whereas the cosine part can actually be done with some similar trickery.

// every 32 clocks

#define EVEN_BITS (0x55555555)
#define ODD_BITS (0xaaaaaaaa)
#define EVEN_PAIRS (0x33333333)
#define ODD_PAIRS (0xcccccccc)
#define EVEN_NIBBLES (0x0f0f0f0f)
#define ODD_NIBBLES (0xf0f0f0f0)
#define EVEN_BYTES (0x00ff00ff)
#define ODD_BYTES (0xff00ff00)

#define HIWORD(arg) (((arg)&(0xffff0000))>>16)
#define LOWORD(arg) ((arg)&(0x0000ffff))

{
DWORD sum;
DWORD p1, p2;
p1 = (input&ODD_BITS)>>1;
p2 = (input&EVEN_BITS);
sum = p2+p1;
p1 = (sum&ODD_PAIRS)>>2;
p2 = (sum&EVEN_PAIRS);
sum = p2+p1;
p1 = (sum&ODD_NIBBLES)>>4;
p2 = (sum&EVEN_NIBBLES);
sum = p2+p1;
p1 = (sum&ODD_BYTES)>>8;
p2 = (sum&EVEN_BYTES);
sum = p2+p1;
p1 = HIWORD(sum);
p2 = LOWORD(sum);
sum = p2+p1;
return sum;
}

• Saucy, that's neat about the cancellations.

What do you mean about getting rid of an integrator?
But wait a minute, the second derivative has fewer non-zero terms. And that will eliminate an integrator as well. Also let's switch to Tukey23 because it performs better and saves summer terms.
• cgracey wrote: »
Saucy, that's neat about the cancellations.

What do you mean about getting rid of an integrator?
But wait a minute, the second derivative has fewer non-zero terms. And that will eliminate an integrator as well. Also let's switch to Tukey23 because it performs better and saves summer terms.

The cancellation doesn't do anything to get rid of integrators. If we have 12 differential terms, we would need 24 taps off the shift register. But some of these cancel so we are using 16 unique taps from the shift register. Doing the conversion to sum form and canceling terms shows that the taps your code uses match the positions of the third derivative of the filter impulse response.

How we get rid of an integrator is making the computation of delta match the second derivative of the impulse response. Basically what we are doing here is differentiating our filter taps, doing the convolution, then integrating to get the output. Using the third derivative of the impulse response for our taps results in more taps with non-zero values than using the second derivative. We want as many taps as possible to have zero values because they are cheapest to implement.
```(tap[01:00] == 2'b01) - (tap[01:00] == 2'b10) = tap-tap
rising edge           -     falling edge

01 00  comp1 comp2  diff   directdiff
0  0    0     0     0        0
0  1    1     0     1        1
1  0    0     1    -1       -1
1  1    0     0     0        0

-   1 cancels
-
-
-
-
-   14 cancels
-   33 cancels
-
-
-
-   46 cancels
-

```
These formations in the calculation of delta are performing edge detection/differentiation of the input data. So it's necessary to integrate an additional time to get the output samples. Also, we need to get additional taps from the shift register to perform this differentiation.

• lazarus666 wrote: »
What is the logic cost of doing this for the rectangular, i.e., flat top part. as it requires only 5 additions to run the function, i.e., by bit-weaving the data flow, so that it could be available as an PASM opcode, (if it isn't already); but it would run automatically if you wanted a Tukey accumulate in streaming data acquisition mode. Of course for the ends of the sausage then starting and stop functions could be called; which might use a one sided special triangular slope; or half cosine window function call - so that to start the Tukey you would compute the triangular starter window once; followed by count bits (and scale sum as desired), and then to stop accumulating you would call ) "flat top MINUS the triangular", or else remember that the Hann window is a raised cosine - so that you need f(x) = 1=cosine(x); and here again is the 1 part; whereas the cosine part can actually be done with some similar trickery.

It would be very small, simply a counter running at sysclock rate or a tree of adders summing 32 individual bits to a 6 bit sum. I've seen similar code here: graphics.stanford.edu/%7Eseander/bithacks.html#CountBitsSetParallel Compared to the P1, the P2 has a new instruction to do this: "ones" Which was used by Chip in the code on the first post of this thread.

• edited 2018-12-13 13:21
ErNa wrote: »
It would be nice to have an actual signal in the bitstream, e.g. 2 MHz of 10% FS amplitude

Here's my first attempt using smartpin sync serial receive to record. Simply fills all 512 KB of hubRAM and dumps it. Duration is about 0.4 seconds.

EDIT: I've added scope screenshot of analogue filtered bitstream of what goes to Prop pin.
EDIT2: And the schematic for ADC board with filter.
EDIT3: Note that the zip compression is only achieving slightly better than 2:1 compression. That tells me we aren't going to get great improvement at lossless compression. I've tried to use FLAC compressor tool but that needed PCM data, so no luck comparing that.
EDIT4: And source code snippet for the capturing.
EDIT5: Added snapshots of clock timing. About 14 ns of hold time on data rise. And about 12 ns of hold on data fall.
EDIT6: Correction on the recorded amount, 512 kB is 0.2 seconds worth. I had actually run for 1 MB but the second half wasn't kept. On that note, I can up that to 1 MB with other Prop2 image for FPGA ...
```'==============================
' bitstream recorder (cogexec, cog #1)
'==============================
ORG
start_bitstream
tickstart	wrpin   ##%0000_0001_000_0000000000000_00_11101_0, #tpin   'set sync serial mode, clock input is #tpin+1
tickstop	wxpin   #\$1f, #tpin           '32 bits per read
dirh    #tpin                 'enable smart pin

cid		cogid   cid
bits		wrfast  #0, #0                'write to all of hubRAM
setse1  #\$40+tpin             'event#1 rising edge of smartpin (32 bits received)

getct   tickstart
rep     @.lend, ##\$3ffff

waitse1
rdpin   bits, #tpin
wflong  bits
.lend
getct   tickstop
sub     tickstop, tickstart
wrlut   tickstop, #\$1ff       'lut sharing
cogatn  #1                    'cog #0
waitx   #100
cogstop cid

```
• Saucy, getting rid of the cancelled-out bits in the delta computation definitely saves logic. The smart pin dropped by 10 ALMs.
• cgracey wrote: »
Saucy, getting rid of the cancelled-out bits in the delta computation definitely saves logic. The smart pin dropped by 10 ALMs.

Is that for Tukey17 integrated 3x or Tukey23 integrated 2x?

For my suggested delta calculation (Tukey23) I think it needs
delta 4 bits (range -4:4)
first integrator 6 bits (range -30:30)
second integrator 10 bits (range 0:1020)
• Here's how to do the Hann.
```delta=tap+tap+tap+tap   -tap-tap-tap-tap;   Tukey
delta=tap+tap+tap+tap   -tap-tap-tap-tap;   Hann
In Hann mode tap is previous tap   Shift second half forward by 17 bits.
```
The negative taps will interleave together, so don't mask off the bypassed section.
Sum is 510
```  1    2    3    5    7    9   11   13   15   17   19   21   23   25   27   28   29
29   28   27   25   23   21   19   17   15   13   11    9    7    5    3    2    1
```
• edited 2018-12-12 13:07
Saucy, I experimented with a lot of filters and some were just noisy. I picked three that I could prove in my program and test on the FPGA with the ADC:
```dim t(70)

for x = 0 to 70
t(x) = 0
next x

'a=2 : b=3 : c=8 : d=33 : m=1     '70-tap Tukey window
'a=2 : b=3 : c=6 : d=14 : m=2     '47-tap Tukey window
a=1 : b=2 : c=8 : d=01 : m=4     '30-tap Hann window

t0  = 0
t1  = t0  + a
t2  = t1  + b
t3  = t2  + c
t4  = t3  + b
t5  = t4  + a
t6  = t5  + d
t7  = t6  + a
t8  = t7  + b
t9  = t8  + c
t10 = t9  + b
t11 = t10 + a

print "taps",,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,t10,t11
print

inta = 0
intb = 0
intc = 0

print "iter","inta","intb","intc","sample"

for y = 0 to 70*2-1

for x = 70 to 1 step -1
t(x) = t(x-1)
next x

t(0) = 1
if y >= 70 then t(0) = 0

delta = 0

if (t(t0) = 1 and t(t0+1) = 0) then delta = delta + 1
if (t(t0) = 0 and t(t0+1) = 1) then delta = delta - 1

if (t(t1) = 1 and t(t1+1) = 0) then delta = delta + 1
if (t(t1) = 0 and t(t1+1) = 1) then delta = delta - 1

if (t(t2) = 1 and t(t2+1) = 0) then delta = delta + 1
if (t(t2) = 0 and t(t2+1) = 1) then delta = delta - 1

if (t(t3) = 1 and t(t3+1) = 0) then delta = delta - 1
if (t(t3) = 0 and t(t3+1) = 1) then delta = delta + 1

if (t(t4) = 1 and t(t4+1) = 0) then delta = delta - 1
if (t(t4) = 0 and t(t4+1) = 1) then delta = delta + 1

if (t(t5) = 1 and t(t5+1) = 0) then delta = delta - 1
if (t(t5) = 0 and t(t5+1) = 1) then delta = delta + 1

if (t(t6) = 1 and t(t6+1) = 0) then delta = delta - 1
if (t(t6) = 0 and t(t6+1) = 1) then delta = delta + 1

if (t(t7) = 1 and t(t7+1) = 0) then delta = delta - 1
if (t(t7) = 0 and t(t7+1) = 1) then delta = delta + 1

if (t(t8) = 1 and t(t8+1) = 0) then delta = delta - 1
if (t(t8) = 0 and t(t8+1) = 1) then delta = delta + 1

if (t(t9) = 1 and t(t9+1) = 0) then delta = delta + 1
if (t(t9) = 0 and t(t9+1) = 1) then delta = delta - 1

if (t(t10) = 1 and t(t10+1) = 0) then delta = delta + 1
if (t(t10) = 0 and t(t10+1) = 1) then delta = delta - 1

if (t(t11) = 1 and t(t11+1) = 0) then delta = delta + 1
if (t(t11) = 0 and t(t11+1) = 1) then delta = delta - 1

inta = inta + delta
intb = intb + inta
intc = intc + intb * m

sample = int(intc/8)
print y,inta,intb,intc,sample

next y
```

I implemented them in the smart pin like this:

• The 70-tap Tukey filter is really quiet. I'll take a picture of it tomorrow and post it.
• evanh wrote: »
Here's my first attempt using smartpin sync serial receive to record. Simply fills all 512 KB of hubRAM and dumps it. .

Good progress. Did you check continual RX did not drop any bits?
Maybe a second pin counting edges can do that ?
• cgracey wrote: »

Wendy at ON Semi is working on getting us to an official 200MHz.

Is that target still 1.80V -10% and 125 deg ? You could tighten the 10% these days.
• edited 2018-12-12 21:54
jmg wrote: »
cgracey wrote: »

Wendy at ON Semi is working on getting us to an official 200MHz.

Is that target still 1.80V -10% and 125 deg ? You could tighten the 10% these days.

Voltages are spec'd at 1.8V and 3.3V, +/- 5%. Junction temperature is -55°C to +150°C.