GPS Inaccuracies and NMEA 1083 protocol

Hi All,

I am looking for a good indepth forum on GPS and the NMEA 0183 protocol.

What the protocol terms mean "indepth".

Any pointer to a good forum would be appreciated.

Joe

Reply to
Joe G (Home)
Loading thread data ...

There is no "depth" to the NMEA 0183 standard; it's really very straightforward.

As regards the combination "GPS and the NMEA 0183 protocol," a given GPS could emit one or more sentences, periodically or asynchronously, as determined by the manufacturer.

Did you have a specific question?

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

I've done NMEA parsers; although the protocol looks straightforward, there is still a lot of subtleties and a vendor/device dependent things. It is not very simple to do a universal parser which decodes correctly all possible strings in all possible variants.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

You could have a look at the sources of gpsd (Linux).

formatting link
It is not a tutorial, but that page has links to lots of related stuff.

Reply to
panteltje

Particularly since vendors sometimes get things wrong, too. E.g., a device (unspecified, to protect the guilty) that accepts NMEA data until

*any* "variable number" field (x.x but also hhmmss.ss and lat/lon) fails to include the radix point with at least one fractional digit. Once an integer is seen in any one of those fields, then it stops processing NMEA data.

Arguably permissible if their IDS states a minimum required precision for those fields (it doesn't), although just failing to operate past that sentence is not an optimal way to alert the operator. It was a bastard to figure out, too, since the GPS I was using to drive it filled the UTC field with integer time-stamps, so it stopped processing NMEA data as soon as the first NMEA sentence arrived. Grrrrr.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

Yes, I have a specific questions relating to a NMEA 0183 $GPGGA Sentence on a SiRF StarIII GPS Chipset.

(see GGA extract below)

Questions ====== a) What does [ (6) GPS Quality Indicator = 1] really indicate? More than 4 channel locked and Accuracy is within spec?

b) Is [ 8) Horizontal Dilution of precision ] really indicate metres or a relative error of measurement ?

c) How do I determine when the NMEA 0183 $GPGGA Sentence will give me accurate position?

Thanks in advance Joe

Extract from

formatting link
GA - Global Positioning System Fix Data Time, Position and fix related data for a GPS receiver.

1 2 3 4 5 6 7 8 9 10 | 12 13 14 15 | | | | | | | | | | | | | | | $--GGA,hhmmss.ss,llll.ll,a,yyyyy.yy,a,x,xx,x.x,x.x,M,x.x,M,x.x,xxxx*hh Field Number: 1) Universal Time Coordinated (UTC) 2) Latitude 3) N or S (North or South) 4) Longitude 5) E or W (East or West) 6) GPS Quality Indicator, 0 - fix not available, 1 - GPS fix, 2 - Differential GPS fix (values above 2 are 2.3 features) 3 = PPS fix 4 = Real Time Kinematic 5 = Float RTK 6 = estimated (dead reckoning) 7 = Manual input mode 8 = Simulation mode 7) Number of satellites in view, 00 - 12 8) Horizontal Dilution of precision (meters) 9) Antenna Altitude above/below mean-sea-level (geoid) (in meters) 10) Units of antenna altitude, meters 11) Geoidal separation, the difference between the WGS-84 earth ellipsoid and mean-sea-level (geoid), "-" means mean-sea-level below ellipsoid 12) Units of geoidal separation, meters 13) Age of differential GPS data, time in seconds since last SC104 type 1 or 9 update, null field when DGPS is not used 14) Differential reference station ID, 0000-1023 15) Checksum
Reply to
Joe G (Home)

Probably at least four tracked in SPS mode, although a 2D fix is possible with three. The precise definition, however, will be vendor specific and if you need to know more than fix/no-fix you'll have to ask their tech support.

Relative, based on the geometry of the satellites in use.

The quality indicator, the number of satellites in use, and an overall reasonableness check. Actual error estimates are available in the GST sentence but that's not commonly provided.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

It indicates whatever the vendor decided to indicate. You can only think about it in the terms of "good signal" or "bad signal".

This characterizes the geometric strength of the current constellation of the satellites. There is no way to make any assumption about the actual accuracy from "HDOP" and "VDOP" parameters; it is all device dependent. Again, you can only think in the terms of "better" or "worse".

If the GPS has the position fix, you will receive it. If it doesn't, then the GPS will give you the empty fields for latitude and longitude. The NMEA philosophy is the GPS receiver decides if it has the position fixed. It is not the business of your application to make any assumptions or conclusions.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

I disagree. In areas with a lot of buildings the error may be well over 120 meters even thouh the GPS thinks its locked! At my previous employer I used a GPS to track the position of a verhicle for use in research on how people drive a car in certain circumstances. The data (not only GPS) needed to be analysed between various waypoints. The routines to determine if a piece of data needed to be included in an analyses wasn't simple.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------
Reply to
Nico Coesel

And its thinking is correct. That is, the pseudorange measurements that it is making to the tracked satellites are (presumably) correct and the position estimate would be correct *if* the signal paths to the satellites were straight lines.

In an urban canyon, however, the direct path to a satellite may be obscured, leading the receiver to track a reflected path with better signal strength. The distance from the receiver to the satellite is larger, so the sphere of position for (at least) that satellite has a larger radius than it "should."

The tracker can only assume that it's operating with all the satellites in direct line of sight. So, when it crunches the numbers and finds the centroid at the intersection of all of the spheres of position, the estimated position will be offset by some tens or, possibly, hundreds of meters from the actual geographic position.

The same receiver at the same location but at a different time will have different results because the geometry of the constellation will have changed.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

Exactly. I plotted the data of several drivers taking the exact same route on top of eachother on a map and in some areas you get an enormous blur. There is no way to tell what the actual error is.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------
Reply to
Nico Coesel

Sure, all of that is apparent. However, I would have thought that given enough satellites there shouldn't be a solution if one or more had additional path length inserted. Doesn't the receiver flag that? Or does it just throw out a satellite with data that doesn't "fit". Average? It seems that it _should_ fail to lock, though that could be a marketing disadvantage.

Reply to
krw

Absent other constraints (e.g., odometry, inertial reference, ...) it's looking, more or less, at a weighted mean position where the weights are taken from SNR, correlation coefficients, etc. Yes, if only one satellite of, say, six was affected then it would have correspondingly less of an effect on the solution. In amongst blocks of tall buildings, though, it's a bit more challenging since most of the sats could be out of a direct view.

The processor itself probably knows very well that the error estimate has grown but the user equipment may not see that, depending on how it is interfaced to the GPS.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

Dear Nico,

Thank you for your email.... can you give some hint how you determined the position inaccuracies?

Did you use average measurements? Use HDOP as an error indicator?

Any clues would be appreciated.

Thanks in Advance. Joe

Reply to
Joe G (Home)

None of the above. I plotted the recorded GPS data from several trips onto a map afterwards. Like others pointed out: GPS signals can reflect from buildings. The receiver has no way to tell the difference. You should take into account that GPS was designed to be used on battle fields which usually are not areas with a lot of buildings.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------
Reply to
Nico Coesel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.