Looked at the P2 docs again... Still don't see any info on how many reps of the assembly loop need to be done before you get a valid result that gives the ENOB quoted...
@evanh said:
Here's the 3-bit to 4-bit hand written paper version copied of the non-corrected software. It is simulating a fixed internal increase of 5 per decimation from the RDPIN:
The middle "sample" is the resulting "x". It holds the apparent glitching ADC reading that still needs masked back to 3 bits.
Of note is the slightly surprising stored 4-bit copy of the decimation always fits in 3 bits. ie: The restoring addition cancels the glitch.
@evanh said:
Here's the 3-bit to 4-bit hand written paper version copied of the non-corrected software. It is simulating a fixed internal increase of 5 per decimation from the RDPIN:
The middle "sample" is the resulting "x". It holds the apparent glitching ADC reading that still needs masked back to 3 bits.
Of note is the slightly surprising stored 4-bit copy of the decimation always fits in 3 bits. ie: The restoring addition cancels the glitch.
2 - 5 isn’t 5, but is -3, which in 2’s complement would be %1101 or what you are interpreting as 13. A straight masking introduces an error does it not?
@AJL said:
2 - 5 isn’t 5, but is -3, which in 2’s complement would be %1101 or what you are interpreting as 13. A straight masking introduces an error does it not?
That example was to show the problem. 5 is known correct answer as per first column "accum". 13 is erroneous because it is stored as 4-bit word size. It needs to be trimmed/masked down to 3-bit word size to produce the correct 2 - 5 = 5.
@Rayman said:
Looked at the P2 docs again... Still don't see any info on how many reps of the assembly loop need to be done before you get a valid result that gives the ENOB quoted...
Not REPs, sample periods, or what is called the decimation period. For Sinc2 filtering mode it's two full decimation periods, or three if the first decimation is partial period. For Sinc3 filtering mode it's three full decimation periods, or four if the first decimation is partial period.
Each subsequent unbroken decimation period is then good for deriving a new sample.
Software has to track the hardware so, miss a decimation and you're up for a restart.
@AJL said:
2 - 5 isn’t 5, but is -3, which in 2’s complement would be %1101 or what you are interpreting as 13. A straight masking introduces an error does it not?
That example was to show the problem. 5 is known correct answer as per first column "accum". 13 is erroneous because it is stored as 4-bit word size. It needs to be trimmed/masked down to 3-bit word size to produce the correct 2 - 5 = 5.
I don't think I'm following you: How is 2 - 5 equal to 5 instead of -3? How is 13 + 5 equal to 2 instead of 18?
Also 5 + 5 = 10 (which can't be represented in 3 bits) not 2.
In every case that there is an 'erroneous' 13, if viewed as -3 it fits the arithmetic and accounts for the fact that the previous addition has overflowed losing a value of 8. 8 - 3 gives the 5 that you seem to be looking for.
Doesn't help. Pre-scaling, to 32-bit with a SHL, works. The two options are pre-scaling or post-trimming. Actually, more precisely, it's post-moduloing. Ie: Maintaining the circular arithmetic.
Don't use sinc3 at 512 clocks. This results in the same output value, whether the input is saturated positive or saturated negative. For a control type application this is VERY bad. 511 is ok.
@SaucySoliton said:
This seems like a good thread to mention:
Don't use sinc3 at 512 clocks. This results in the same output value, whether the input is saturated positive or saturated negative. For a control type application this is VERY bad. 511 is ok.
@TonyB_ said:
Is an odd period always better than an even one?
He certainly isn't implying that. I doubt there's any real difference between 511 and 512, just that 512 clocks is a potential overflow for 27 bits. Ha, of course, circular overflow is a difference of >= 180 degrees. The direct counter can't overflow but its derivative can.
@evanh said:
Ow, dang. Thanks for the heads up, James. I presume you're using a higher input gain than straight 1x to achieve saturation?
Yes.
There are a few ways to choose decimation rates:
1. Desired full-scale value
2. Desired sample rate
3. Adjust the decimation as a gain adjustment so the output is in useful units. May not be a good fit for P2 because each ADC pin has different gain.
I don't know of any reason to prefer odd numbers.
There is some benefit to using a power of 2. The full scale value from the differentiators and after masking is N^3.
512^3 = 134217728 = $0800_0000
The required mask is $07ff_ffff, so it is obvious that this value is unusable.
406^3 = 66923416 = $3FD_2B98 which may be acceptably close to $0400_0000
322^3 = 33386248 = $1FD_6F08
511^3 = 133432831 = $7F4_05FF ' I guess it's close enough to $800_0000
I'm using the sinc3 filter at 500 clocks. With a 24MHz sysclock that makes 48ksps. It's not for an audio application so I don't know why I did that.
At one time, Sinc3 supported 1024 clocks which meant third accumulator was 30-bit. Assuming logic was shrunk when Sinc3 clock limit reduced to 512, then minimum accumulator sizes should be:
Sinc Max accumulator
mode clocks bit widths
Sinc2 8192 13 26
Sinc3 512 9 18 27
Max clocks should be one fewer to avoid overflow, which occurs in the smallest accumulator. Adding one bit to each acc should solve the overflow problem.
I'm pretty certain all accumulator stages are same size. The summing didn't work otherwise. That was one of the outcomes when testing. Which will be why 27-bit ended up being chosen because that then consumes 3 x 27 = 81 flops. A reduction of 9 flops to fit the budget. X is 6-bit and Y is 14-bit. Z presumably doesn't exist as flops. So that's 101 flops total.
EDIT: Oops, and some more for the decimation/sample timer. Another 14 or so bits I'd guess. Huh, that's interesting, I've been using more than 14 bits for WYPIN, I guess I've got a bug in my code ...
My statement above refers to the two "Filter" modes.
Chip probably pruned some low-order bits from the second stage accumulator in the %00 "Sample" mode. That was an option if not wanting the full width in the output.
It's frightening how much of the Sinc and filter stuff I've forgotten. Isn't the first Sinc accumulator just an up/down counter? If two smaller Sinc3 accs are more than big enough then adding one bit to third acc to make it 28-bit should avoid overflow with 512 clocks. I'm sure there's something that works best with power of 2 clock period.
@TonyB_ said:
It's frightening how much of the Sinc and filter stuff I've forgotten. Isn't the first Sinc accumulator just an up/down counter?
Yes but ... I don't think anyone figured out the why ... I just now went back and tried to read some of your old links about pruning and what stood out in our discussion at the time was some confusion about which accumulators got pruned. I now see the links consistently showed, in the equations, that the later stages took the hit. Not the first stages.
Without reading the technical writings, I conclude this is suited to matching with a desired output width. Which fits with matching a known noise floor, or ENOB.
Comments
Looked at the P2 docs again... Still don't see any info on how many reps of the assembly loop need to be done before you get a valid result that gives the ENOB quoted...
2 - 5 isn’t 5, but is -3, which in 2’s complement would be %1101 or what you are interpreting as 13. A straight masking introduces an error does it not?
That example was to show the problem. 5 is known correct answer as per first column "accum". 13 is erroneous because it is stored as 4-bit word size. It needs to be trimmed/masked down to 3-bit word size to produce the correct 2 - 5 = 5.
Not REPs, sample periods, or what is called the decimation period. For Sinc2 filtering mode it's two full decimation periods, or three if the first decimation is partial period. For Sinc3 filtering mode it's three full decimation periods, or four if the first decimation is partial period.
Each subsequent unbroken decimation period is then good for deriving a new sample.
Software has to track the hardware so, miss a decimation and you're up for a restart.
I don't think I'm following you: How is 2 - 5 equal to 5 instead of -3? How is 13 + 5 equal to 2 instead of 18?
Also 5 + 5 = 10 (which can't be represented in 3 bits) not 2.
In every case that there is an 'erroneous' 13, if viewed as -3 it fits the arithmetic and accounts for the fact that the previous addition has overflowed losing a value of 8. 8 - 3 gives the 5 that you seem to be looking for.
What am I missing?
Circular arithmetic has no overflow. In a 3-bit word, 7 + 1 = 0. Numerically Controlled Oscillators are a perfect example of this mechanic.
Then why the 4 bit diff sample that produces what looks like an erroneous result if interpreted without a sign bit?
It was a smaller demonstration of what was happening with the SincN filtering modes when used as documented.
Except there the sizes are: Sinc accumulator 27-bit, and Cog register 32-bit.
If the 27-bit RDPIN result is sign-extended to 32-bit what happens to the 'glitches'?
Doesn't help. Pre-scaling, to 32-bit with a SHL, works. The two options are pre-scaling or post-trimming. Actually, more precisely, it's post-moduloing. Ie: Maintaining the circular arithmetic.
This seems like a good thread to mention:
Don't use sinc3 at 512 clocks. This results in the same output value, whether the input is saturated positive or saturated negative. For a control type application this is VERY bad. 511 is ok.
Ow, dang. Thanks for the heads up, James. I presume you're using a higher input gain than straight 1x to achieve saturation?
Is an odd period always better than an even one?
He certainly isn't implying that. I doubt there's any real difference between 511 and 512, just that 512 clocks is a potential overflow for 27 bits. Ha, of course, circular overflow is a difference of >= 180 degrees. The direct counter can't overflow but its derivative can.
Yes.
There are a few ways to choose decimation rates:
1. Desired full-scale value
2. Desired sample rate
3. Adjust the decimation as a gain adjustment so the output is in useful units. May not be a good fit for P2 because each ADC pin has different gain.
I don't know of any reason to prefer odd numbers.
There is some benefit to using a power of 2. The full scale value from the differentiators and after masking is N^3.
512^3 = 134217728 = $0800_0000
The required mask is $07ff_ffff, so it is obvious that this value is unusable.
406^3 = 66923416 = $3FD_2B98 which may be acceptably close to $0400_0000
322^3 = 33386248 = $1FD_6F08
511^3 = 133432831 = $7F4_05FF ' I guess it's close enough to $800_0000
I'm using the sinc3 filter at 500 clocks. With a 24MHz sysclock that makes 48ksps. It's not for an audio application so I don't know why I did that.
At one time, Sinc3 supported 1024 clocks which meant third accumulator was 30-bit. Assuming logic was shrunk when Sinc3 clock limit reduced to 512, then minimum accumulator sizes should be:
Max clocks should be one fewer to avoid overflow, which occurs in the smallest accumulator. Adding one bit to each acc should solve the overflow problem.
EDIT:
Added minimum.
I'm pretty certain all accumulator stages are same size. The summing didn't work otherwise. That was one of the outcomes when testing. Which will be why 27-bit ended up being chosen because that then consumes 3 x 27 = 81 flops. A reduction of 9 flops to fit the budget. X is 6-bit and Y is 14-bit. Z presumably doesn't exist as flops. So that's 101 flops total.
EDIT: Oops, and some more for the decimation/sample timer. Another 14 or so bits I'd guess. Huh, that's interesting, I've been using more than 14 bits for WYPIN, I guess I've got a bug in my code ...
My statement above refers to the two "Filter" modes.
Chip probably pruned some low-order bits from the second stage accumulator in the %00 "Sample" mode. That was an option if not wanting the full width in the output.
It's frightening how much of the Sinc and filter stuff I've forgotten. Isn't the first Sinc accumulator just an up/down counter? If two smaller Sinc3 accs are more than big enough then adding one bit to third acc to make it 28-bit should avoid overflow with 512 clocks. I'm sure there's something that works best with power of 2 clock period.
Yes but ... I don't think anyone figured out the why ... I just now went back and tried to read some of your old links about pruning and what stood out in our discussion at the time was some confusion about which accumulators got pruned. I now see the links consistently showed, in the equations, that the later stages took the hit. Not the first stages.
Without reading the technical writings, I conclude this is suited to matching with a desired output width. Which fits with matching a known noise floor, or ENOB.
EDIT: Further reading - https://forums.parallax.com/discussion/comment/1455656/#Comment_1455656
I know how you feel. I thought I had a handle on this at one time...