What to do if floating data and trig function not to be used

[bideshm]

Hi all,

I have been handling GPS data in my project. Now the problems are floating point data and trigonometric functions makes the things slower.

I have to calculate distance between two points say x ,y whose latitudes and longitudes are given in double. But when I am using the formula to calculate it controller becomes slow. I come to know that floating point data handling is slower in microcontroller. Is there any other way that I can calculate that distance without using floating point data and trig functions?

I am using the great circle formula to calculate the distance.

Thanks in advance for much need help.

Regards,
Bidesh

[Ken Johnson]

This does not answer your question, but I'd like to ask - what are your timing requirements?

Slow is relative. Many folks say never use floats in a micro. I use them all the time, for their convenience and flexibility. Rarely do I encounter a timing issue requiring "special processing".

Perhaps the general architecture of your app could be re-arranged to accomodate float processing?

Ken

[SherpaDoug]

Have you looked at the "CORDIC 32 bit functions" in the code library in this site? I have not used them but I think that is what you are looking for.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[bideshm]

Hi Ken and SherpaDoug,

I am asked not to use any trig function. I may use the floating point data but no trig function. And the error tolerance should be +-10ft.

So what I am thinking is...

Since the great circle formula to calculate distance between two points for given latitudes and longitudes is,

d = 2 * asin (sqrt ( ( sin ( ( lat1 - lat2 ) / 2 ) ) ^ 2 + cos ( lat1 ) * cos ( lat2 ) * ( sin ( ( lon1 - lon2 ) / 2 ) ) ^ 2 ) )

Now If I store sin(theta) in a lookup table where theta varies from 0 to 360 degree, I can calculate the distance.

About the number of terms in lookup table will be (900000 + 360).
The all possible combination of 6 digits will be 900000 which represent the fractional part. And 360 for 0 to 360 degree is

sin(0), sin(1)...sin(360).

Say sin(270.999999)
= sin(270+0.999999)
= sin(270) * cos(0.999999) + cos(270) * sin (0.999999)
= Sin(270) * sqrt(1 - sin^2(0.999999)) + sqrt( 1- sin^2(270)) * sin (0.999999)
= Sin(270) * sqrt(1 - sin(0.999999)^2) + sqrt( 1- sin(270)^2) * sin (0.999999)

Both can be read out from the lookup table.

What I am worried is the 900360 terms in the lookup table which will consume so much space arround 3 to 4 MB.

I have not gone through the CORDIC function yet. I don't know whether CORDIC function will give that much accurate value.
Distance will vary for arround 5 to 6 km.

Is my approach is right?

Regards,
Bidesh

[SherpaDoug]

I have never done trig or any heavy math on a PIC, just time crucial simple stuff like frequency synthesis. I read about CORDIC a couple of years ago and it sounded cool, but my products export data to a PC for heavy math crunching. Maybe someone else can give you more relevant advice.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[Ttelmah]

You don't need to code all the points. You can get very close to the required value, using linear interpolation between less frequent samples. Also remember that you only need to store sin for one quadrant. If you store 0 to 90, then the sin results for 360 to 270, are just -ve, and those for 90 to 180, and 180 to 270, are the same as for these two quadrants. Saves a _lot_ of storage.
Even if you store at 1 degree steps, the 'worst' error, from linear interpolation, is in the fifth decimal place, while if you go to 1/10th degree steps, this drops to the seventh decimal!...
So, storing just 901 entries, and using linear interpolation between these, will exceed the accuracy of the existing floating point arithmetic.

Best Wishes