GPS is a global technology these days, with the Russian GLONASS system and the forthcoming European Galileo orbiting alongside the original US GPS satellites above our heads. [Florin Duroiu] decided to embrace globalism by forking the TinyGPS library for the Arduino platform to add support for these satellite constellations.
In addition to the GLONASS support, the new version of the venerable TinyGPS adds some neat new features by incorporating the NMEA 3.0 standard (warning: big-ass PDF link). Using this, you can extract interesting stuff such as the calculated position from each satellite constellation, the signal strength of each satellite and a lot more technical stuff about what the satellites are saying about you to your GPS receiver. [Florin] claims it is a drop-in replacement for TinyGPS that should require no rewriting. There is no support for Galileo just yet (as the satellites are still being launched: eight are in orbit now), but [Florin] is looking for help to add this, as well as the new Chinese BEIDOU system once it is operational.
(top image: artists’ view of a Galileo satellite in orbit, courtesy of ESA)
I’ve always wondered: are there technical reasons to use GLONASS or (eventually) Galileo instead of GPS? Obviously there’s the advantage of not being reliant on the USA’s benevolence, but surely there must have been improvements in the technology since the first GPS satellites went up. Do GLONASS or Galileo have better accuracy? Faster locking? Other cool new features?
As someone whos company uses GNSS (Global Navigation Satellite Systems, the generic name) for our products the addition of GLONASS/Gallileo/Beidou gets better accuracy in cheaper receivers. Is it standalone at RTK levels? No. But we can toss in a multi-constellation device and come up with a signal that is better than GPS alone.
For example: GPS can see about 10-13 satellites on a wide open clear sky. With Glonass we can get up to 16-20 and that includes throwing out the satellites at the horizon line that are usually useless (many receivers have a horizon line filter that filters out poor signals). Why is this good? More/better signals = more triangulation points = smaller radius of inaccuracy = knowing RIGHT were you are. So by using GPS and Glonass (which are processed separately in some systems) we can essentially derive 2 points of position in one receiver and use that to calculate our position. The hope is that by tossing in a bit of SBAS/WAAS we can get our cheap (say <$40) receiver to less than 1 meter accuracy (GPS+WAAS usually is about 3m). Any more and you will need a PPP or RTK receiver to get in closer. In most cases, ~1m radius can get you really close to where you need to be at a pretty reasonable point. That and the redundancy if the GPS system goes out.
triangulation points?
A GPS receiver triangulates its position based on the signals heard from the GPS satellites. The more satellites it can hear (and the better the distribution throughout the sky), the more accurate the receiver’s guess of its own position can be.
Nope, that’s trilateration…
I’m not sure about glonass however Galileo will have 1m accuracy as standard GPS I think is 10m-5m also with Galileo if you want to pay instead of using for free you can have accurancy to a few centimeters. At the moment there is not enough galileo #satellites as they are still being launched.
Even GPS can be accurate to single cm (when comparing 2 ground stations), the problem is the clock source in the receiver…
Normal GPS (and other) receivers have to “borrow” the clock from one of the satellites (which is why you need a min. of 4), even a TCXO is not good enough by several orders of magnitude. But if you have a ground station (with a known position) from which you can compare the signals, accuracy goes waaaay up without needing an atomic clock on your end.
Came here to say that. This gets used in agriculture for running tractors over fields at 10cm accuracy. More info: https://en.wikipedia.org/wiki/Differential_GPS
There’s no “instead” here. The more satellites you can see, the better is the accuracy and the fix time. The systems are not competing and the access is not mutually exclusive. Any modern GPS receiver uses all these systems simultaneously.
sed s/NEMA/NMEA/g
You might want to edit the reference to the NEMA (National Electrical Manufacturers Association) and replace it with NMEA (National Marine Electronics Association). One is for electrical standards like plugs and motors, and the other is for GNSS.
Also: 844KB isn’t a ‘big-ass PDF’, in fact it’s tiny compared to the average PDF.
The author was probably referring to the 26 pages.
Usually a warning on a site refers to the download size, not the number of pages.
Inventorm, thanks for the note: I’ve made that change. Apologies for the slip of the keyboard!
oh, so THAT explains the big spark I got when I tried to connect my GPS antenna to the wall socket.
“was that wrong? should I not have done that?” lol
Did I miss where the full accuracy of the GPS or whatever system will be allowed to be exploited by the general public has been released? I was under the impression that current location technology was artificially limited so that it couldn’t be used in a military fashion by non military types.
Did that change?
Yes it did… somewhere in the early nineties, Clinton pushed a big button with a small ceremony and all that, turning off the artificially introduced error…
The only remaining artificial limitations are introduced by the manufacturers of the baseband chipset in order to comply with ITAR, however the only civilian application that would truly need to break both* of those limits was the Concorde :P
*ITAR defines the limit as 512m/s *AND* 18km above sea level, however most manufacturers use the “OR” operand making near-space balloons a little more difficult.
Accuracy is limited mainly by the clock source in the receiver, the 2nd biggest contributor is weather, both the “normal kind” and high altitude (ionosphere).
also, this line is probably not accurate:
“by incorporating the NMEA 3.0 standard”
almost no one (except big pieces of sw like the linux gpsd daemon) parses ALL known gps sentences. an arduino cannot afford to support all of nmea and has no reason to.
the way I deal with this is to hook up the gps module in question (my current fave is the ublox neo-6m or 7m or 8m, for $15 that includes a patch antenna and hopefully a backup battery or supercap, too) – then configure 9600 baud and watch what comes out. its in pure ascii and you simply have to wait until it locks-on then see whch sentences it supports. sometimes you can write vendor-specific config to the gps to change what sentences it automatically sends.
once you get some repeating sentences and if you can id the lat/long or the hh:mm:ss (I care only about time on my gps modules) then you simply write the most simplistic parser to grab that info from the string and use it. you should run the checksum (xor stuff) thru to reject error sentences but other than that, I don’t recommend using a whole ‘gps library’ on space limited systems like arduinos. so much of the gps sentences will go to waste and that is wasted C code, as a result.
1 or 2 nmea sentences are really all you need to get location and time. having a big parser is kind of overkill on small cpus.
and also, you DO need to match your code to the gps module, as the same sentences ‘per the spec’ may actually be sent with slightly different data or with some fields being optional. very vendor dependant. you just have to connect your module, look at the stream and decide from there.
I run my GPS modules at 115200, since 9600 isn’t enough to keep up with the 10Hz mode I prefer to run in!
Agreed most modules allow you to configure which messages you want. I normally find $GPGSV on by default and not that useful. On limited hardware I prefer to turn on $GPVTG than try to calculate velocity.
A little late to this party, but I would like to suggest a smaller, faster, configurable and more complete library: NeoGPS, at https://github.com/SlashDevin/NeoGPS. In terms of RAM, NeoGPS uses 40 bytes, compared to 180 bytes for TinyGPS, and 326 bytes for Adafruit_GPS. It’s even more dramatic to compare NeoGPS to TinyGPS++: 242 bytes of RAM vs. 1400. You can configure NeoGPS to be use as little as 10 bytes of RAM for pulse-per-second applications.
I was inspired to write NeoGPS after experiencing a problem similar to [Florin Duroiu]. NeoGPS supports all variants (i.e., Talker IDs) of 8 common NMEA sentences: $GNRMC, not just $GPRMC, etc.
I have also seen many questions about modifying other library’s example programs. Those examples usually break when a user tries to add something, like writing to an SD card, or displaying something on an LCD. The NeoGPS examples are all structured to take advantage of typical GPS device behavior, and the “Troubleshooting” section explains how to get “the most” out of the resource-constrained Arduino.
For those implementing autonomous vehicles or drones, NeoGPS also supports coherency: position and velocity data can be grouped by time. Its efficiency also means you can get a higher control loop frequency.