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

ADC Sampling Breakthrough

1252628303152

Comments

  • evanhevanh Posts: 15,126
    Lots of test compiles for a map.

    Does that cost money each time? Or is there a certain amount of testing covered in the standard fee?

  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    Lots of test compiles for a map.

    Does that cost money each time? Or is there a certain amount of testing covered in the standard fee?

    It's all part of the program.
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    Oh, intriguing what James did with the Prop1. https://forums.parallax.com/discussion/comment/1456711/#Comment_1456711

    That's a whole new trick for the Prop1. The ramping isn't every sysclock but maybe that isn't so terrible. Certainly his results look great. And, in theory, the shape can be more complex.

    Guess what? The Prop2 has no equivalent mode!

    Here's a commented snippet: (Inputs A and B are the same pin in James's test code)
                    mov      i, looplength
                    mov      j, looplength
                    mov      frqb, #1              ' start rectangular (flat +1 increment) for input B
    uploop          add      frqa, #1              ' start triangular (ramp the increment up and down) for input A
                    djnz     i, #uploop            ' ramp up
    downloop        sub      frqa, #1
                    djnz     j, #downloop          ' ramp down
                    mov      frqb, #0              ' stop rectangular for input B
                    mov      frqa, #0              ' stop triangular for input A
    
                    wrlong   phsa, adcp_tri        ' post triangular sample
                    wrlong   phsb, adcp_rect       ' post rectangular sample
    
    

    So, you are thinking there should be some time-varying weighted windowing mode?
  • evanhevanh Posts: 15,126
    edited 2018-12-05 15:20
    cgracey wrote: »
    So, you are thinking there should be some time-varying weighted windowing mode?

    I was thinking, partly because this technique has made me think some backwards compatibility might be a good idea, more about providing a mode with the same frqa (Y) and phsa (Z) arrangement as the Prop1. Everything else from the Prop1 counters already exists in the input config I think.

  • evanhevanh Posts: 15,126
    edited 2018-12-05 15:23
    Of course, as is often the case with the Prop1, this technique requires a cog to be 100% on the job to make it work. That's a put off for most people when thinking about the Prop2.

  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    Of course, as is often the case with the Prop1, this technique requires a cog to be 100% on the job to make it work. That's a put off for most people when thinking about the Prop2.

    I was thinking the same thing.
  • evanh wrote: »
    Oh, intriguing what James did with the Prop1. https://forums.parallax.com/discussion/comment/1456711/#Comment_1456711

    That's a whole new trick for the Prop1. The ramping isn't every sysclock but maybe that isn't so terrible. Certainly his results look great. And, in theory, the shape can be more complex.

    Guess what? The Prop2 has no equivalent mode!

    Evan, before you edited your post you said: "That's a whole new trick for the Prop1 - performing a sinc2 function." I think the P1 code applies separate rectangular and triangular windows, which are Sinc1 and Sinc2, respectively. Convolving M identical rectangular window functions together produces SincM.

    I mentioned implementing Sinc2 are few days ago and this was the response:
    cgracey wrote: »
    evanh wrote: »
    cgracey wrote: »
    TonyB_ wrote: »
    The Sinc3 logic could also do Sinc1 and Sinc2 if half the adder inputs are held low, so that acc3=acc2=acc1 or acc3=acc2.
    Does SINC2 have any special appeal?

    Don't think so, initial responses to reset are identical.

    So, we will provide a third-order filter, but there's really no reason to bother with a second-order filter, right? If we have a third-order, who cares about a second-order? Any second-order implementation would rather have been a third-order, given the resources were available. That's how I see it.

    I've done quite a lot reading in the last couple of weeks and a sigma-delta modulator of order N requires a filter of order N+1. This fact has been mentioned on the forum before and it explains why a triangular window gives so much better results than a rectangular.

    If a future P2 has a second-order modulator then Sinc3 will be able to cope with it, but as the current P2 has a first-order modulator why have a Sinc1 mode when it will never produce good results?
  • cgraceycgracey Posts: 14,133
    TonyB_, I just downloaded Logic Friday. Pretty neat!

    I'm seeing about making counter-adder values for each bit in the Tukey.
  • cgracey wrote: »
    TonyB_, I just downloaded Logic Friday. Pretty neat!

    I'm seeing about making counter-adder values for each bit in the Tukey.

    Creating a truth table for it is easy. Shame about the annoying equation syntax, though. Minimize jointly could be the best option in this case. Always select exact.

    I've found my post about plateau counting:
    TonyB_ wrote: »
    cgracey wrote: »
    Here is the new scope code that does the 29-tap Hann and 45-tap Tukey filtering. This filter change only added two ALM's. We are now at 84.

    Could we use an existing up/down counter for the plateau bits? Count enable = plateau in bit XOR plateau out bit and up/!down = plateau in. Add ramp and plateau values to get output. To detect overflow, if plateau count > 0 and output = 0, then output = FF.

    You've already implemented the overflow detection. The plateau counter must be zeroed whenever there is a mode change, including Tukey to Hann-like and vice-versa.
  • jmgjmg Posts: 15,140
    TonyB_ wrote: »
    If a future P2 has a second-order modulator then Sinc3 will be able to cope with it, but as the current P2 has a first-order modulator why have a Sinc1 mode when it will never produce good results?

    Don't forget this mode also needs to work with external modulators, many of which are available in isolated, and/or better ENOB than P2.
    Also, given the high sysclks in P2, I'm not sure anything can be called strictly first-order.

  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I'm seeing about making counter-adder values for each bit in the Tukey.
    An up/down saturating counter can reduce (halve) the ROM size, and if 1-step-triangle is 'good enough', there is no ROM needed at all.
    This is for your scope-mode, right ? - so you target speed over bits in this case ?

    My preference is to prefer Flipflops over ROMs as I know the tools will properly optimize FF, and there is no hidden routing cost.


  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    I'm seeing about making counter-adder values for each bit in the Tukey.
    An up/down saturating counter can reduce (halve) the ROM size, and if 1-step-triangle is 'good enough', there is no ROM needed at all.
    This is for your scope-mode, right ? - so you target speed over bits in this case ?

    My preference is to prefer Flipflops over ROMs as I know the tools will properly optimize FF, and there is no hidden routing cost.


    It counts up bits for each bitN in the tap weights and then sums the sums at offsets to get the sample:

    661 x 1589 - 33K
  • TonyB_TonyB_ Posts: 2,105
    edited 2018-12-06 00:43
    I borrowed an idea for a 3(a+b) = addx3[2:0] three times adder block from this PDF:
    up ramp taps and coefficients:
    
        t0, t1, t2, t3, t4, t5, t6, t7, t8, t9,t10,t11,t12
         1,  3,  5,  7, 10, 13, 16, 19, 22, 25, 27, 29, 31
    
    up ramp sum = 
     
     1*(t0 +t1 +t2 +t3     +t5     +t7     +t9+t10+t11+t12) +
     2*(    t1     +t3 +t4         +t7 +t8    +t10    +t12) +
     4*(        t2 +t3     +t5         +t8        +t11+t12) +
     8*(                t4 +t5              t9+t10+t11+t12) +
    16*(                        t6 +t7 +t8 +t9+t10+t11+t12)
    
    Separating 3*, 6* and 12* terms, up ramp sum =
    
     1*(t0     +t2         +t5             +t9    +t11+t12) +
     2*(                t4                                ) +
     3*(    t1     +t3             +t7        +t10        ) +
     4*(        t2 +t3                                    ) +
     6*(                                t8            +t12) +
     8*(                t4                  t9+t10    +t12) +
    12*(                    t5                    +t11    ) +
    16*(                        t6 +t7 +t8 +t9+t10+t11+t12)
    
    Two changes that might minimize the logic:

    1. New addx3 logic for (t1+t3)*3, (t7+t10)*3,(t8+t12)*3, (t5+t11)*3
    2. A counter for 16* terms as these bits are sequential, in similar way to plateau.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    It counts up bits for each bitN in the tap weights and then sums the sums at offsets to get the sample:

    Why the h1F in the middle ?
    That seems to be generating a 45 line ROM, 6 bits wide, and that will logic reduce inside to tools.

  • jmg wrote: »
    cgracey wrote: »
    It counts up bits for each bitN in the tap weights and then sums the sums at offsets to get the sample:

    Why the h1F in the middle ?
    That seems to be generating a 45 line ROM, 6 bits wide, and that will logic reduce inside to tools.

    It was to stop the max value exceeding 255, however all plateau bits are now 32 with 8-bit overflow detection, as mentioned in a recent post.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    It counts up bits for each bitN in the tap weights and then sums the sums at offsets to get the sample:

    If I code that for drive from a U/D counter, the skirts portion alone packs to a 4i ROM, of PT 1,3,4,4,4,4
    If I then support the flat ( clean flat assumed, no 1f ) via a larger U/D counter, it becomes 5i ROM, PT of 3,3,4,4,4
    The U/D+DIRN counter(6 bits) then counts up to half way, then flips and counts down. Ctr Values >= 0xe generate 0x20 flat output.
    The ROM is smaller in width because the DIRN bit is outside the ROM, and the generated terms are less, as skirts naturally mirror by direction.

  • cgraceycgracey Posts: 14,133
    TonyB_ wrote: »
    I borrowed an idea for a 3(a+b) = addx3[2:0] three times adder block from a PDF:
    up ramp taps and coefficients:
    
        t0, t1, t2, t3, t4, t5, t6, t7, t8, t9,t10,t11,t12
         1,  3,  5,  7, 10, 13, 16, 19, 22, 25, 27, 29, 31
    
    up ramp sum = 
     
     1*(t0 +t1 +t2 +t3     +t5     +t7     +t9+t10+t11+t12) +
     2*(    t1     +t3 +t4         +t7 +t8    +t10    +t12) +
     4*(        t2 +t3     +t5         +t8        +t11+t12) +
     8*(                t4 +t5              t9+t10+t11+t12) +
    16*(                        t6 +t7 +t8 +t9+t10+t11+t12)
    
    Separating 3*, 6* and 12* terms, up ramp sum =
    
     1*(t0     +t2         +t5             +t9    +t11+t12) +
     2*(               +t4                                ) +
     3*(    t1     +t3             +t7        +t10        ) +
     4*(        t2 +t3                                    ) +
     6*(                                t8            +t12) +
     8*(                t4                  t9+t10    +t12) +
    12*(                    t5                    +t11    ) +
    16*(                        t6 +t7 +t8 +t9+t10+t11+t12)
    
    Two changes that might minimize the logic:

    1. New addx3 logic for (t1+t3)*3, (t7+t10)*3,(t8+t12)*3, (t5+t11)*3
    2. A counter for 16* terms as these bits are sequential, in similar way to plateau.

    Nice way to break it down. I will try this.
  • cgraceycgracey Posts: 14,133
    I got the trigger working in the scope smart pin. You can set two 8-bit levels and a 1-bit slope.

    For positive slope, it must go below the X[7:0] value to arm and then above the X[15:8] value to trigger and disarm:

    scope%20trigger.jpg


    Here is the code:
    ' Scope with trigger
    
    con	a	= 4			'ADC pin
    	d	= 5			'DAC pin
    
    dat	org
    
    	hubset	#$FF			'select 80MHz on FPGA
    
    	wrpin	scope,#a		'set scope mode on ADC pin
    	wxpin	##$0D030,#a		'set positive slope and $30/$D0 hysteresis
    	dirh	#a			'enable smart pin
    
    	dirh	#d			'enable DAC pin output
    
    	rep	@.end,#0		'repeat forever
    	rdpin	x,#a	wc		'read ADC and get 'armed' into C
    	drvc	#0			'output 'armed' to P0
    	setbyte	dacmode,x,#1		'set ADC level into DAC mode
    	wrpin	dacmode,#d		'update DAC pin
    .end
    
    scope	long	%100011_0000000_00_11010_0	'ADC scope mode
    dacmode	long	%10110_00000000_00_00000_0	'DAC mode
    
    x	res	1
    
    2052 x 1154 - 332K
  • jmgjmg Posts: 15,140
    edited 2018-12-05 22:32
    cgracey wrote: »
    I got the trigger working in the scope smart pin. You can set two 8-bit levels and a 1-bit slope.
    Nice, but does it need to be that comprehensive ?
    7 or even 6 bit trigger levels would save logic - even 5 bits is a 3% increment in LSB ?
    I think you need to be brutal about added logic, and pare things to minimal on anything that multiplies by 64x.

  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Here's the test code that runs on the FPGA with the SINC3 smart pin and two real I/O pins on the pad ring test chip:
    ....
    Okay! I just wired in a quiet 3.3V regulator and things are looking WAY better:

    16 counts = 8 bits
    32 counts = 10 bits
    64 counts = 12 bits
    128 counts = 13 bits
    256 counts = 13 bits
    512 counts = 13 bits (1/f noise really increases)
    1024 counts = 13 bits

    I think that means 250MHz sysclk gives 8b at 15.625 Msps, right ? Which is above the ADC roll-off ?
    If you can get those silicon results using sinc3, I'm still unclear why a separate (logic costly) scope-mode filter is needed ?

  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    Here's the test code that runs on the FPGA with the SINC3 smart pin and two real I/O pins on the pad ring test chip:
    ....
    Okay! I just wired in a quiet 3.3V regulator and things are looking WAY better:

    16 counts = 8 bits
    32 counts = 10 bits
    64 counts = 12 bits
    128 counts = 13 bits
    256 counts = 13 bits
    512 counts = 13 bits (1/f noise really increases)
    1024 counts = 13 bits

    I think that means 250MHz sysclk gives 8b at 15.625 Msps, right ? Which is above the ADC roll-off ?
    If you can get those silicon results using sinc3, I'm still unclear why a separate (logic costly) scope-mode filter is needed ?

    It's automated and very simple to use. I'm hoping the logic size comes way down. Waiting to hear from ON Semi on the latest compile.
  • cgracey wrote: »
    I got the trigger working in the scope smart pin. You can set two 8-bit levels and a 1-bit slope.
    Very nice. I can imagine that a scope mode could become very useful in a pinch and could potentially save dragging out and connecting up a real scope at times for some lower frequency work. I can ultimately imagine code for VGA+scope debug COGs in the OBEX2 as well as logic analyser stuff. Hopefully it (and other changes) can still all fit...
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I got the trigger working in the scope smart pin. You can set two 8-bit levels and a 1-bit slope.
    For positive slope, it must go below the X[7:0] value to arm and then above the X[15:8] value to trigger and disarm:

    Another thought here - What about using the Threshold DAC and comparator, I think are already there ? How fast are those ?
    You could have a sticky output and an ARMED approach, to make it more tolerant of whatever low hysteresis the threshold detector has ?
    At even less logic cost ?

  • Totally OT maybe - Would a zero-crossing detector be possible with any of the SmartPin modes?

    ---Mike R,
  • evanhevanh Posts: 15,126
    edited 2018-12-06 01:15
    TonyB_ wrote: »
    ... why have a Sinc1 mode when it will never produce good results?

    You could say Chip answered that when I was coaching to have the clock and data sources matching between sinc1 clocked and sinc3 clocked - https://forums.parallax.com/discussion/comment/1456147/#Comment_1456147

    The two sinc1 modes were not intended for this purpose, nor were they even considered a pair.

  • @cgracey
    I sent the new scope-in-the-smart-pin file set to ON Semi for a test compile.

    Great Chip. I'm curious to see how we would use it?

  • evanh wrote: »
    Oh, intriguing what James did with the Prop1. https://forums.parallax.com/discussion/comment/1456711/#Comment_1456711

    That's a whole new trick for the Prop1. The ramping isn't every sysclock but maybe that isn't so terrible. Certainly his results look great. And, in theory, the shape can be more complex.

    Guess what? The Prop2 has no equivalent mode!

    Here's a commented snippet: (Inputs A and B are the same pin in James's test code)
                    mov      i, looplength
                    mov      j, looplength
                    mov      frqb, #1              ' start rectangular (flat +1 increment) for input B
    uploop          add      frqa, #1              ' start triangular (ramp the increment up and down) for input A
                    djnz     i, #uploop            ' ramp up
    downloop        sub      frqa, #1
                    djnz     j, #downloop          ' ramp down
                    mov      frqb, #0              ' stop rectangular for input B
                    mov      frqa, #0              ' stop triangular for input A
    
                    wrlong   phsa, adcp_tri        ' post triangular sample
                    wrlong   phsb, adcp_rect       ' post rectangular sample
    
    
    CAUTION If actually implementing this, the last two lines write the PHSx shadow registers to hubram. Which were previously set to zero. Consider it PASM pseudo-code. :smiley:

    The rectangular window measurement is merely for comparison purposes.

    cgracey wrote: »
    So, you are thinking there should be some time-varying weighted windowing mode?
    Can the Goertzel hardware not do this?
  • cgraceycgracey Posts: 14,133
    edited 2018-12-06 07:42
    evanh wrote: »
    Oh, intriguing what James did with the Prop1. https://forums.parallax.com/discussion/comment/1456711/#Comment_1456711

    That's a whole new trick for the Prop1. The ramping isn't every sysclock but maybe that isn't so terrible. Certainly his results look great. And, in theory, the shape can be more complex.

    Guess what? The Prop2 has no equivalent mode!

    Here's a commented snippet: (Inputs A and B are the same pin in James's test code)
                    mov      i, looplength
                    mov      j, looplength
                    mov      frqb, #1              ' start rectangular (flat +1 increment) for input B
    uploop          add      frqa, #1              ' start triangular (ramp the increment up and down) for input A
                    djnz     i, #uploop            ' ramp up
    downloop        sub      frqa, #1
                    djnz     j, #downloop          ' ramp down
                    mov      frqb, #0              ' stop rectangular for input B
                    mov      frqa, #0              ' stop triangular for input A
    
                    wrlong   phsa, adcp_tri        ' post triangular sample
                    wrlong   phsb, adcp_rect       ' post rectangular sample
    
    
    CAUTION If actually implementing this, the last two lines write the PHSx shadow registers to hubram. Which were previously set to zero. Consider it PASM pseudo-code. :smiley:

    The rectangular window measurement is merely for comparison purposes.

    cgracey wrote: »
    So, you are thinking there should be some time-varying weighted windowing mode?
    Can the Goertzel hardware not do this?

    Oh, yeah. it actually can. It uses signed numbers, though. So, you would be limited to positive values up to 127.

    It never occurred to me, but one slow cycle of the Goertzel would be like a 512-tap FIR filter. You could make any kind of window you'd like.
  • evanhevanh Posts: 15,126
    Lol, I guess that shows my total lack of practical experience on the Prop1. I knew the shadow RAM existed but had no idea it would exhibit that way.

  • Cluso99Cluso99 Posts: 18,066
    Chip,
    I haven't been properly following the ADC saga, so this may be way off base...
    There is some noise problem that shows up every 7-8 bits???
    Could this possibly be some sort of sign extension bug???

    I am not convinced you have got to the root cause of the ADC problems. To me, it seems that you/others are trying to solve a problem that is not sufficiently understood by throwing all sorts of software solutions to the problem and then trying to make the hardware implement them.

    IMHO weeks have been wasted that could have been better spent on testing the P2, and/or writing things that really matter much more such as SPIN2 etc.
Sign In or Register to comment.