> On Sat, 23 Mar 2013 18:02:29 -0400, rickman<gnuarm@gmail.com> wrote:
>>
>> The email bounced.
>
> Hmmm. Not sure just what happened. Can you see the headers of this news
> post?
Yes, and the email address is exactly what I used. Here it is with the
address slightly munged.
<joseph_barrett at sbcglobal.com>:
Sorry, I wasn't able to establish an SMTP connection. (#4.4.1)
I'm not going to try again; this message has been in the queue too long.
> Plus after getting into my books again i think i can explain just how to
> do it without fussing with a spreadsheet.
The spread sheet isn't important, but I don't have an image of what you
are talking about below.
> It is a matter of weighting the coefficients (and using more cardinal
> points).
>
> For a section of table spanning 5 (or just 3) cardinal points; we take the
> sub-interval centered on the 'nearest' cardinal point. (semi open segment,
> -2^n to +2^n-1; where 2*2^n-1 is the number of interpolated points.) For
> 5 cardinal points this point gets maximum weight call it 1/2. The two
> points to either side get weighted 1/4 each, and the two outermost
> cardinal points get weighted 1/8 each. For three cardinal points just
> eliminate the outer two. Then the rest of your interpolator tool should
> do the rest.
One of the things I have realized is that with the table size I am
using, the curve segments that I am interpolating become very good
matches to a straight line to within 18 bits. I have a 512 entry table
and interestingly enough, there is this give and take between the range
of the interpolation and the non-linearity of the curve at that point.
The part of the quarter sine table that has the highest step size is at
zero where the linearity is near dead on. The part of the table that
has the worst approximation to linear is at 90 degrees where the step
size is near zero. I think in an 18 bit table the step is just one
count! So there is not much improvement to be had over simple linear
interpolation. In fact, I can't say there is much of an improvement by
offsetting any of the end point.
If the word width increases from 18 bits, then perhaps there might be
some advantage to other methods. But even an 18 bit table gives a 19
bit result when the sine bit is added. That is way down there in the
noise really. I am looking at a software version and to keep from going
to double precision I might just drop the extra bit and limit the signed
result to 18 bits. This is in a custom processor in an FPGA. 18 bits
comes from the memory size in the block RAMs. We'll see. The
difference is only near the end of the code section and *something* has
to be sent out to the CODEC even if the extra bits are just noise in the
DAC, 24 bits, 90 dB SINAD. Why so many bits you have to wonder...
--
Rick
Reply by josephkk●March 26, 20132013-03-26
On Sat, 23 Mar 2013 18:02:29 -0400, rickman <gnuarm@gmail.com> wrote:
>On 3/23/2013 2:42 PM, josephkk wrote:
>> On Thu, 21 Mar 2013 17:51:42 -0400, rickman<gnuarm@gmail.com> wrote:
>>
>>>
>>>>>>>> if you assume an approximate quadratic behavior over that short segment,
>>>>>>>> you can compute the straight line where the error in the middle is equal
>>>>>>>> in magnitude (and opposite in sign) to the error at the end points.
>>>>>>>> that's a closed form solution, i think.
>>>>>>>
>>>>>>> Yes, it is a little tricky because at this point we are working with
>>>>>>> integer math (or technically fixed point I suppose).
>>>>>>
>>>>
>>>> Hmm. I would like to take a crack at simpson's rule interpolation for
>>>> this to measure error budget. I may not be timely but this is
>>>> interesting. joseph underscore barrett at sbcglobal daht cahm
>>>
>>> Oh, I thought you were talking about using Simpsom's rule as part of the
>>> interpolation. You are talking about using it to estimate the integral
>>> of the error. Great idea! I'll shoot you an email.
>>
>> I was talking about using it for interpolation.
>
>The email bounced.
Hmmm. Not sure just what happened. Can you see the headers of this news
post?
Plus after getting into my books again i think i can explain just how to
do it without fussing with a spreadsheet.
It is a matter of weighting the coefficients (and using more cardinal
points).
For a section of table spanning 5 (or just 3) cardinal points; we take the
sub-interval centered on the 'nearest' cardinal point. (semi open segment,
-2^n to +2^n-1; where 2*2^n-1 is the number of interpolated points.) For
5 cardinal points this point gets maximum weight call it 1/2. The two
points to either side get weighted 1/4 each, and the two outermost
cardinal points get weighted 1/8 each. For three cardinal points just
eliminate the outer two. Then the rest of your interpolator tool should
do the rest.
?-)
Reply by Ben Bradley●March 25, 20132013-03-25
I'm lurking in this thread, and it's great (a better s/n than I
expected for such a long thread), until I got to this URL:
On Mon, 18 Mar 2013 17:47:41 -0400, rickman <gnuarm@gmail.com> wrote:
>...
>It is a lot of document for just two pages. Try this link to see the
>short version...
>
>arius.com/foobar/1972_National_MOS_Integrated_Circuits_Pages_273-274.pdf
On Wed, 20 Mar 2013 19:25:02 -0400, rickman <gnuarm@gmail.com> wrote:
>On 3/20/2013 7:05 PM, josephkk wrote:
>>
>> Without reading any other replies, i would suggest either the CORDIC
>> algorithm of simpson's rule interpolation. From the rule for integration
>> to find any intermediate value you evaluate the curve value within the
>> segment covered by rule. 4 intervals on the step size you have will be
>> limited by the 18 bits of input. Do 20 bits of input and round to 18 or
>> not. About 1 PPM.
>
>I can't say I follow what you mean about Simpson's rule interpolation.
>Interpolation is used to derive Simpson's Rule, but I don't see a way to
>use an integral for obtaining an interpolation. Isn't Simpson's Rule
>about approximating integrals? What am I missing?
In many ways it is just an estimator with somewhat less than second order
complexity for function sections of greater than second order complexity.
It is useful in integration because it reduces error and complexity for
reasonably smooth functions. Its value for interpolating within a segment
comes from there.
?-)
Reply by josephkk●March 23, 20132013-03-23
On Thu, 21 Mar 2013 18:45:15 -0700, John Larkin
<jlarkin@highlandtechnology.com> wrote:
>On Thu, 21 Mar 2013 18:45:02 -0400, rickman <gnuarm@gmail.com> wrote:
>
>>On 3/21/2013 1:14 PM, John Larkin wrote:
>>> On Wed, 20 Mar 2013 20:53:13 -0700, josephkk
>>> <joseph_barrett@sbcglobal.net> wrote:
>>>
>>>> On Sun, 17 Mar 2013 17:22:59 -0700, John Larkin
>>>> <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>>>>
>>>>>
>>>>>> I don't think you are clear on this. The table and linear interp are as
>>>>>> good as they can get with the exception of one or possibly two lsbs to
>>>>>> minimize the error in the linear interp. These is no way to correct for
>>>>>> this by adding a second harmonic, etc. Remember, this is not a pure
>>>>>> table lookup, it is a two step approach.
>>>>>
>>>>> Why can't some harmonic component be added to the table points to improve
>>>>> downstream distortion? Of course, you'd need a full 360 degree table, not a
>>>>> folded one.
>>>>
>>>> How do you get that? All harmonics would be within the 90 degree table.
>>>
>>> Second?
>>
>>Actually this would not work for anything except odd harmonics. The way
>>the table is folded they have to be symmetrical about the 90 degree
>>point as well as the X axis at 0 and 90 degrees. Odd harmonics would do
>>this if they are phased correctly. I don't think it would be too useful
>>that way.
>
>Just looking at a sine at F and one at 2F, it's obvious that the 90
>degree folded table can't make the 2F component. The 2nd harmonic has
>to change sign between 0-90 degrees and 90-180 but can't if the same
>90 degree table is used.
>
>>
>>
>>>> Harmonic phase shifts is a different matter though, that would take
>>>> careful characterization of production quantities of the final product,
>>>> $$$$$.
>>>
>>> Of course you'd have to null each harmonic for gain and phase,
>>> preferably on each production unit, but it wouldn't be difficult or
>>> expensive *if* you had a distortion analyzer with the required PPM
>>> performance. We regularly do automated calibrations, polynomial curve
>>> fits and such, more complex than this.
>>
>>Might as well use a separate table for the nulling, it would be much
>>simpler.
>
>It's really about the same, but I guess if the main table is heavily
>interpolated, it would make sense to have a little distortion table
>off to the side, maybe even with its own DAC.
The table is always valid. The only difference in frequency is the phase
accumulator stepping rate. That is why a DDS is "tunable".
?-)
Reply by rickman●March 23, 20132013-03-23
On 3/23/2013 2:42 PM, josephkk wrote:
> On Thu, 21 Mar 2013 17:51:42 -0400, rickman<gnuarm@gmail.com> wrote:
>
>>
>>>>>>> if you assume an approximate quadratic behavior over that short segment,
>>>>>>> you can compute the straight line where the error in the middle is equal
>>>>>>> in magnitude (and opposite in sign) to the error at the end points.
>>>>>>> that's a closed form solution, i think.
>>>>>>
>>>>>> Yes, it is a little tricky because at this point we are working with
>>>>>> integer math (or technically fixed point I suppose).
>>>>>
>>>
>>> Hmm. I would like to take a crack at simpson's rule interpolation for
>>> this to measure error budget. I may not be timely but this is
>>> interesting. joseph underscore barrett at sbcglobal daht cahm
>>
>> Oh, I thought you were talking about using Simpsom's rule as part of the
>> interpolation. You are talking about using it to estimate the integral
>> of the error. Great idea! I'll shoot you an email.
>
> I was talking about using it for interpolation.
The email bounced.
--
Rick
Reply by josephkk●March 23, 20132013-03-23
On Thu, 21 Mar 2013 17:51:42 -0400, rickman <gnuarm@gmail.com> wrote:
>
>>>>>> if you assume an approximate quadratic behavior over that short segment,
>>>>>> you can compute the straight line where the error in the middle is equal
>>>>>> in magnitude (and opposite in sign) to the error at the end points.
>>>>>> that's a closed form solution, i think.
>>>>>
>>>>> Yes, it is a little tricky because at this point we are working with
>>>>> integer math (or technically fixed point I suppose).
>>>>
>>
>> Hmm. I would like to take a crack at simpson's rule interpolation for
>> this to measure error budget. I may not be timely but this is
>> interesting. joseph underscore barrett at sbcglobal daht cahm
>
>Oh, I thought you were talking about using Simpsom's rule as part of the
>interpolation. You are talking about using it to estimate the integral
>of the error. Great idea! I'll shoot you an email.
I was talking about using it for interpolation.
?-)
Reply by Jamie●March 22, 20132013-03-22
Spehro Pefhany wrote:
> On Thu, 21 Mar 2013 21:38:39 -0500, the renowned Jamie
> <jamie_ka1lpa_not_valid_after_ka1lpa_@charter.net> wrote:
>
> .
>
>> Many of these DDS FG's seem to show that anything other than a sine
>>wave, forces them to reduce output BW. I can only assume this due to a
>>bottle neck from the uC to the chip to update pattern configuration via
>>SPI or C2I.. I guess a parallel version would make a vast improvement.
>>
>>Jamie
>
>
> Compare the bandwidth of a sine wave of frequency f vs. a sawtooth of
> the same frequency.
>
>
> Best regards,
> Spehro Pefhany
Something tells me that not all DDS chips are created equal.
Jamie
Reply by Robert Baer●March 22, 20132013-03-22
Jerry Avins wrote:
> On 3/18/2013 7:18 PM, glen herrmannsfeldt wrote:
>> In comp.dsp rickman <gnuarm@gmail.com> wrote:
>>> On 3/18/2013 2:10 PM, Jerry Avins wrote:
>>
>> (snip, ending on CORDIC)
>>
>>>> http://www.andraka.com/files/crdcsrvy.pdf should be a good start. Do
>>>> you
>>>> remember Ray Andraka?
>>
>>> Yes, of course. I should have thought of that. I don't go to his site
>>> often, but his stuff is always excellent. I may have even downloaded
>>> this paper before. I took a look at the CORDIC once a few years ago and
>>> didn't get too far. I'm happy with my current approach for the moment,
>>> but I will dig into this more another time.
>>
>> I once thought I pretty well understood binary CORDIC, but it
>> is also used in decimal on many pocket calculators. I never got
>> far enough to figure out how they did that.
>
> The hp35 used CORDIC to compute trig functions. Its basic math
> operations were BDC, using decimal arithmetic. Most CORDIC
> implementations skip "irrelevant" rotations, so the scale of the result
> isn't constant for all inputs. To get sine, the hp35 computed both sine
> and cosine (little extra cost for getting both) which had the same
> scale, then divided to get the cotangent-- the scale factors cancel.
> 1/sqrt(cot(x)^2 + 1) = sin(x). Since the arithmetic functions were all
> in place, it was the fastest way to the result.
>
> So what does "simple" really mean?
>
> Jerry
Someone pointed out that i quoted sqrt(50) incorrectly at 6 digits;
the actual table in CRC shows 7.071068 which is seven digits, definitely
better than the puny 4 digits that was bandied about.
Reply by glen herrmannsfeldt●March 22, 20132013-03-22
In comp.dsp Jerry Avins <jya@ieee.org> wrote:
(snip, I wrote)
>> (snip, ending on CORDIC)
(snip)
>> I once thought I pretty well understood binary CORDIC, but it
>> is also used in decimal on many pocket calculators. I never got
>> far enough to figure out how they did that.
> The hp35 used CORDIC to compute trig functions. Its basic math
> operations were BDC, using decimal arithmetic. Most CORDIC
> implementations skip "irrelevant" rotations, so the scale of the result
> isn't constant for all inputs.
The usual binary explanation is that you rotate one way or the other,
such that the scale is constant. Then multiply (once) to correct
for that scale, or for any other scale you want the result to have.
> To get sine, the hp35 computed both sine
> and cosine (little extra cost for getting both) which had the same
> scale, then divided to get the cotangent-- the scale factors cancel.
> 1/sqrt(cot(x)^2 + 1) = sin(x). Since the arithmetic functions were all
> in place, it was the fastest way to the result.
Does sound better than convert to binary followed by binary CORDIC.
If you really aren't in a hurry, you can do 0 to 9 rotations for
each digit.
> So what does "simple" really mean?
Sometimes it means no divide and few mutliplies.
I think I have previously noted the Integer Cosine Transform for when
you need to do something like FFT, but with minimal multiplies.
(And when you have lots of processing power for the inverse.)
Designed for the CDP1802, which doesn't have a multiply.
Integer cosine site:jpl.nasa.gov
into google should find it.
-- glen