Go Down

Topic: double precision / TinyGPS++ (Read 3220 times) previous topic - next topic


Jul 31, 2015, 03:16 pm Last Edit: Jul 31, 2015, 03:18 pm by jurs
BTW: Does anybody know where the earth radius of 6372795 meters = 6372.795 km was taken from, which is used in calculations of tinyGPSplus?

In my calculations I'm using an earth radius of 6371 km, which is taken from Wikipedia and can be calculated by different ways to be the mean radius of earth (including mean radius of the WGS84 ellipsoid).


I am going to guess they use some standard spheroid instead of the actual value. In 'Big Red' It lists the value as 6378388 meters, and says it is based on the "International Hayford Spheroid".


Jul 31, 2015, 05:24 pm Last Edit: Jul 31, 2015, 05:24 pm by jremington
I think for very small distances it should be no problem to calculate the course bearing using Pythagoras' theorem instead of using great circle trigonometric calculations.
See reply #2 for an example. In fact, it works much, much better.


Try this one for exact GPS calculations :( TinyGPS is great for getting GPS data but the calculations are useless for distances < 100m ) 


and as 64bit float calculation are VERY CPU expensive you may actually need to do the calculations is background thread as long calculation will prevent you reading from devices on time..

e.g. you need also :


and if you are still brave enough take a look at real-world application example :




Nov 22, 2016, 05:59 am Last Edit: Nov 22, 2016, 06:58 am by arduino_314
and as 64bit float calculation are VERY CPU expensive you may actually need to do the calculations is background thread as long calculation will prevent you reading from devices on time..

That is because used Math64 lib is not very efficient. It use also Taylor series known converges very slowly, tan is calculated by sin/cos, sqrt with exp function, etc. You have used your own replacements, however that is still too much multiplications and divisions...

The famous HP-35 from 1972 used a custom made chip to process BCD numbers with execution time of just 250us for one clock per instruction, but still was able to process sqrt and trig functions (sin, cos, tan and natural log including its inversions) with 10 digits precision in max ~500ms. That was really impressive for the time, knowing all was accomplished with addition and shifting with in only 768 "words" of code, with the chip had only 5 registers!

Imagine what can be done with 16MHz clock and modern (just) 8-bit architecture CPU having multiplication instruction, at least 32K ROM, 2K RAM and 1K EEPROM...

I'm working for a while on fast double precision (to the last bit) lib for 8-bits based MCUs as I have a need as well for max  precision for my own not trivial at all GPS navigator project (including maps etc). Really there is no need for 32-bit MCU platform.


FWIW, I'm not sure 64-bit math is required for GPS... NeoGPS achieves 10 significant digits, about 1cm (interesting discussion here).  This is better than almost any GPS device can produce, and much better than the common TinyGPS, TinyGPS+ and Adafruit_GPS libraries.  Furthermore, the NeoGPS distance/bearing calculations are structured to retain this accuracy, so 64-bit math isn't required for those operations, either.

Remember that everything is based on an approximation to the Earth's surface.  Not that 64-bit math isn't interesting...  ;)

Really, I used to be /dev.  :(


It is true, but Haversine and Vincenty formula cannot be compared in accuracy.

As well, from public GPS transponder now send signal which allow precision under 2.5m, but that was more than 11 in the past. I'm not sure what is current policy for GLONASS and Galileo, but it is possible as well that USA military allow for GPS  maximum precision need for autonomous vehicles...

Secondly, used float trig functions have mostly precision up to 6 digits, but be aware that every calculation degrade precision of result moderately in some complex trig. formulas or any plain polynomial expression as some Taylor series.

Go Up