CompleteGPS - a GPS library


I've made a GPS library / NMEA parser for Arduino. It's called CompleteGPS because it provides more information than most other free GPS libraries for Arduino. The design goals were to keep size and memory to a minimum whilst providing as much information as reasonably possible.

It is designed to have a similar look and feel to TinyGPS, but it parses more NMEA sentances. In addition to nagivation data and time it provides dilution of precision, GPS fix information, plus information about each individual satellite in use.

It has been developed for a UAV project that I'm working on, and it has been tested on the Arduino Due. I suppose it would also work on any other Arduino too.

Just thought you guys might like to have a look.

Cheers, Camel

and it has been tested on the Arduino Due. I suppose it would also work on any other Arduino too.

Took a quick look and you are not using double-buffering in your library. As an example, the Adafruit library is double-buffered and it cannot support extraction of the time/date from a RMC sentence (along with the associated maths required to put the time/date on an LCD) if the GPS BAUD rate is faster than 4800 and the uC clock is 8MHz (success here implies the collection of the RMC, the parsing of time/date, the Day-Of-Week, leapyear, and display output on a parallel LCD all within one second.) Of course, raising the communications to 9600 BAUD and the uC clock to 16MHz performs admirably.

The Arduino Due is throwing some serious uC resources at the parsing operation. Taking that down to 8MHz on an RC clocked 328P is something that would require user testing.

Nice work. Thanks for sharing.


Hi Ray,

Thanks for the feedback. The reason I chose not to double buffer is for memory reasons. Due to the amount of data being collected it is more memory efficient to simply store the NMEA in a c string and parse it at once, rather than have double of everything. The size of a CompleteGPS instance is only 320 bytes on a 32bit machine. I think it would be about 300 on an 8 bit AVR. It would be closer to 400 bytes if everything was double buffered.

The trade off of course is that everything gets parsed at once and maybe this could take more time than expected on a lower performance chip.

Cheers, Camel

It would be closer to 400 bytes if everything was double buffered.

But, a 328 has 2K of SRAM! Even an ATtiny85 has 512 Bytes.

My GPS clock project in the first trial was only 754 RAM and that included Ladyada's double-buffer library.

You paid for all the SRAM, use what you need :D


I don't really think libraries it's a good thing for libraries to use more RAM than necessary. It's fair enough to use all that you need when you are making your own complete program, but libraries shouldn't assume that RAM is plentiful and needlessly consume resources. That's just my opinion of course.

I'm actually not really sure what you mean by double buffering. Just had a look through Lady Ada's GPS library and she keeps a copy of the last good NMEA sentance for the user to access themselves. There is a comment in her code that calls this 'double buffering'. TinyGPS on the other hand keeps two copies of all the GPS data that is processed. It decodes the NMEA on the fly and only swaps the new data in when a good checksum is received. This is what I thought you were talking about. It's a really good method because it only requires about 20 bytes of buffer space instead of 120 bytes in both Lady Adas and mine. But it isn't the most efficient solution for CompleteGPS because of the amount of data that would have to be doubled up.