Library tutorials & articles
Writing Your Own GPS Applications: Part 2
- Introduction
- Causes of Precision Error
- Determining Precision Needs
- Enforcing Precision
- High Precision in Action
Causes of Precision Error
Causes of Precision Error
There are several phenomenon which can cause poor precision. For example, when satellite radio signals are transmitted, they are distorted by the troposphere and especially the ionosphere. In fact, satellites very low on the horizon are not good for getting a fix because the signals travel through so much of the atmosphere. Some GPS devices may even exclude these satellites from a fix to avoid the precision problems they would cause.
Figure 2-1: Satellite 1's radio signal travels through less of the atmosphere, resulting in less distortion. Satellite 2 is low on the horizon, however, resulting in significant atmospheric distortion.
Fortunately, atmospheric distortion can be measured and corrected for the most part. This is achieved by the use of GPS ground stations, fixed locations which constantly measure distortions in satellite radio signals. Calculated corrections are then broadcasted by radio which, when combined with the actual satellite signal, gives a GPS receiver the ability to correct distortions in real-time.
Figure 2-2: Distortions in radio signals are corrected by combining satellite signals (1 and 2) with correction information transmitted via DGPS ground stations (3 and 4).
Precision errors can be compounded by slight inaccuracies in each satellite's “ephemeris”. Ephemeris is a table giving the coordinates of a celestial body over time. If the satellite's actual course deviates from its ephemeris, precision can be further diluted. This sort of error can only be corrected by firing small rockets on the satellites themselves. Adjustments are transmitted from the GPS Master Control Station at Schriever Air Force Base in Colorado Springs, Colorado.
Figure 2-3: Deviations in a satellite's actual orbit path can also cause loss in precision.
As I covered in Part One of this article, each GPS satellite has four on-board atomic clocks: two cesium atomic clocks and two rubidium atomic clocks which are accurate to 1 second per 300,000 years! Still, even microfractions of a second error in these clocks can cause positional error because distance is measured at the speed of light. The Master Control Station keeps these errors at a minimum by uploading corrective information to satellites twice a day, every day.
The last detriment to GPS precision is an effect called "multipath", which is an effect caused when a receiver receives not only the satellite's signal, but additional signals which bounced off buildings and other obstacles. Deflected signals take a longer path to the receiver and are thus delayed. If they are used by the receiver, the measured distance to a satellite is overestimated, resulting in inaccurate multilateration. More advanced receivers solve multipath problems by utilizing only the first signal detected (which is the most direct path from the satellite), then discarding any delayed signals.
Figure 2-4: A receiver is confused by "multipath", where several reflected signals are received (red) along with the direct radio signal (green).
Solving all of these precision problems is done by using more sophisticated GPS receivers which use real-time correction data such as WAAS (for North America) and EGNOS (for Europe). Yet, these problems cause relatively small inaccuracies when compared with Geometric Dilution of Precision, which can cause a receiver to be inaccurate by more than an American football field. Fortunately, Geometric DOP is the easiest to manage with the right programming techniques.
Geometric Dilution of Precision
GPS devices calculate your position using a technique called “3-D multilateration”, which is the process of figuring out where several spheres intersect. In the case of GPS, each sphere has a satellite at its center; the radius of the sphere is the calculated distance from the satellite to the GPS device. Ideally, these spheres would intersect at exactly one point, causing there to be only one possible solution to the current location, but in reality, the intersection forms more of an oddly-shaped area. The device could be located within any point in the area, forcing devices to choose from many possibilities. Figure 2-4 shows such an area created from three satellites (using part one's $GPGSV sentence). The current location could be any point within the gray-colored area. Precision is said to be “diluted” when the area grows larger, which leads to this article's focus: dilution of precision. The monitoring and control of dilution of precision (or DOP for short) is the key to writing high-precision applications.
Figure 2-5: GPS devices must choose one of several possible solutions to the current location.
DOP values are reported in three types of measurements: horizontal, vertical, and mean. Horizontal DOP (or HDOP) measures DOP as it relates to latitude and longitude. Vertical DOP (or VDOP) measures precision as it relates to altitude. Mean DOP, also known as Position DOP (PDOP), gives an overall rating of precision for latitude, longitude and altitude. Each DOP value is reported as a number between one and fifty where fifty represents very poor precision and one represents ideal accuracy. Table 2-1 lists what I believe to be an accurate breakdown of DOP values.
| 1 | Ideal | This is the highest possible confidence level to be used for applications demanding the highest possible precision at all times. |
| 2-3 | Excellent | At this confidence level, positional measurements are considered accurate enough to meet all but the most sensitive applications. |
| 4-6 | Good | Represents a level that marks the minimum appropriate for making business decisions. Positional measurements could be used to make reliable in-route navigation suggestions to the user. |
| 7-8 | Moderate | Positional measurements could be used for calculations, but the fix quality could still be improved. A more open view of the sky is recommended. |
| 9-20 | Fair | Represents a low confidence level. Positional measurements should be discarded or used only to indicate a very rough estimate of the current location. |
| 21-50 | Poor | At this level, measurements are inaccurate by as much as half a football field and should be discarded. |
Table 2-1: Jon's interpretation of dilution of precision values.
Looking again at figure 2-4, three satellites created a large area of possible solutions. This situation could be improved by two factors: adding more satellites to the fix, and using satellites evenly distributed throughout the sky. What would figure 2-4 look like if the situation was improved like this? Figure 2-5 shows figure 2-4 after three more evenly-distributed satellites have been added.
Figure 2-6: Three more evenly-distributed satellites are added to figure 2-4, creating a high-precision environment where dilution of precision is low.
Related articles
Related podcasts
-
More jQuery in ASP.NET
In this episode Chris Brandsma, Rick Strahl, Dave Ward, Bertrand Le Roy, and Scott Koon conclude their discussion of Microsoft's jQuery in ASP.NET announcement1.This episode of the Alt.NET Podcast is brought to you by LLBLGen Pro, the most mature O/R mapper and code generator out there.Are ...
Events coming up
-
Dec
9
GL.net Group Meeting - December 2009
Gloucester, United Kingdom
The beginning of this year holiday season will belong to mocks. Ronnie and Stephen will take us for a tour around exciting world of unit testing.
Hello,
I do not understand what you mean by writing your own GPS application, the most GPS receivers gives
navigation data in real time as UTC, Lat/Lon, SOG, TrueCourse, Magvar,Tracks,constellation sat.
What we can get more with this application ?
Best regards
Maritime
Great paper.
Thx very much.
GPS- Deriving British Ordnance Survey Grid Referece from NMEA data
AlexE
However this led to a new error as the final word in the string contained the checksum.
ie in the example sentence
$GPGSV, 3, 1, 10, 24, 82, 023, 40, 05, 62, 285, 32, 01, 62, 123, 00, 17, 59, 229, 28*70
the final word would be 28*70
this caused an error when trying to convert this to an int32 in the line
SignalToNoiseRatio = Convert.ToInt32(Words[Count * 4 + 3]);
My solution was to remove the checksum part of the sentence in GetWords, before splitting the sentence
public string[] GetWords(string sentence)
{
//remove the final * + checksum
sentence = sentence.Substring(0, sentence.IndexOf("*"));
//now split it up
return sentence.Split(',');
}
Assuming that I'm not talking out of my rear, I hope this proves useful
Alex
This update may help save many lives!
I love this product. Excellent Job on this product, Jon Person
your product 360%!... I just have to correct 1 minor error. I feel you should be aware or maybe your are already....don't know
might have been a typo,... I'm not much of a C# coder but, I believe during the ParseGPGSV() function, which is suppose to
parse the "Satellites in View" $GPGSV sentence.... If you look closesly. During the... public bool ParseGPGSV(string sentence)
Original Article: http://www.developerfusion.com/show/4652/4/
Example Sentence: $GPGSV, 3, 1, 10, 24, 82, 023, 40, 05, 62, 285, 32, 01, 62, 123, 00, 17, 59, 229, 28*70
Each Block consist of 4 words.. "24, 82, 023, 40" == "PseudoRandomCode, Elevation, Azimuth, SignalToNoiseRatio"
According to your Article... SNR values range from 0-50...where 50 means "Excellent Signal"...though SNR can go as high as 99,
like you've stated.
// Interprets a "Satellites in View" NMEA sentence -- section.
//ERROR suspect
Azimuth = Convert.ToInt32(Words[Count * 4 + 2]);
SignalToNoiseRatio = Convert.ToInt32(Words[Count * 4 + 2]);
// ^--- Logical Bug, I believe it should be ....
//CORRECTION
SignalToNoiseRatio = Convert.ToInt32(Words[Count * 4 + 3]);
// ^--- This would be correct.
Otherwise I believe it would return the same value from the Azimuth extraction. So you wouldn't get any SNR information to
be able to base precision correctly. For the future of dependability and reliability of code production, I post this correction. As
far as the Signal Strength of the satellites, within the Notification, of the Event call to,...
SatelliteReceived ( PseudoRandomCode, Azimuth, Elevation, SignalToNoiseRatio );
I believe it would generate incorrect results...to what ever is going to be done with the SNR variable.
Please feel free to e-mail me at deciphered_scripturez@yahoo.com for additional details...I really Thank you, Jon Person, for
your hard work and time put into this and I really would LOVE to help as much as possible...I believe in your product.
P.S. This update may save many lives! ... Can you imagine lets say for example, the next block of words over you had,
"05, 62, 285, 32" in the example above, lets say you passed the third Word of 285 as the value I know 99 would be the highest possible value, but imagine the reliability of the signal being factored in the calculation based on the strength for precision. I assume maybe this would throw off a calculation significantly.
Thank You,
-- cprogrammingguru
This thread is for discussions of Writing Your Own GPS Applications: Part 2.