At 10:19 5/11/98 -0800, you wrote:
>Peter L. Peres wrote:
>
>> On Wed, 4 Nov 1998, Ben Stragnell wrote:
>>
>> > Peter L. Peres wrote:
>> >
>> > >   My idea is, that since the Bresenham circle algorythm exists, it is
>> > > possible to compute the 'next' value for a phase continuous sine wave
>> > > without storing any table and by obtaining results directly in integers
>> > > (no floats no lookups no nothing).
>> >
>> > Ok... Bresenham will get you the appropriate X coordinate for iterative
>> > steps in Y (or vice versa), but then all you have is a pair of
>> > coordinates. How are you going to convert those into sines? If I
>>
>> The coordinates (one of them) IS the sine corrsponding to that cosine, and
>> vice versa. I suppose that one could turn the algorythm a little bit to
>> yield a true sine or cosine, or, use the ellipsis algorythm (by Bresenham)
>> to approximate the sine using a linear increment. Remains to be seen how
>> accurate this can be made.
>
>Trouble is, even though you're given both the sine and cosine of an angle, I
>don't think there's an easy (ie. trivial and PICable) method of knowing what
>that angle is, much less of stepping though the algorithm with fixed angular
>increments.
>
>I'm not sure about the ellipse algorithm, but I think if you try to approximate
>the sine function using the linear steps along an axis that Bresenham gives (as
>opposed to a fixed angular increment), you'll wind up approximating the sine
>function with straight lines from sin(-45 to 45), and quarter circles from (sin
>45 to 135) (the tops and bottoms of the curves). Of course this may be a good
>enough approximation for DTMF, and other applications, but it's definately
not a
>pure tone.
>
>You could always look into simple harmonic motion - keeping track of a point's
>position and velocity, and then using position to derive the acceleration each
>tick would yield a nice pure sine wave if you get the scalings right.
sin''(t) =
>-sin(t). Trouble is, to make the frequency adjustable without breaking the
>amplitude would probably require a whole nasty bunch of multiplies. Ouch :)
>
>Cheers,
>
>Ben
>
>

I have been watching this for a period of time. Yes the Bresenham stuff will
work and work well, but (don't you like that always a but) this is often
employed as an evaluated polygon with 4 seeding points. (There is some log
calculations in there too) Nominaly this will require that the software uses
floating point to get the accuracy, however if an error of a few degrees is
acceptable then it is possible not too (No calculating moon shoots with this
one!).

As this is all to do with DTMF detection I would say that while well and
good for getting the brain to function correctly, there is not a chance in
*** for the PIC to do this (At present), as the PIC would have to calculate
the 2 mixed frequencies within a frame window of than 150mS. It would be
better tha have lookup table of 90 degress then just calculate the quadrant.
There is also noise and other things to worry about, all of these make it
hard to do, but an accuracy of 99.9% is all that most carriers require.

Also note the number of samples that would be required, as undersampling
could not be used successfuly (due to the short period of the tone).
Sampling would need to be performed at x times the max frequency (1620Hz?)


Dennis