Library tutorials & articles
Writing Your Own GPS Applications: Part 2
Jon Person is the author of the award-winning “GPS.NET” software now in use in over two thousand GPS applications in all industries, from geocaching to disease outbreak prevention. Jon runs his company, "GeoFrameworks," from his home office in Denver, Colorado.
As a hobby, Jon enjoys storm chasing in the Great Plains in May and June each year. On May 4th, 2007, Jon witnessed the EF5 tornado that destroyed Greensburg, Kansas, and volunteered for nearly a month to help them rebuild. A photo journal of his efforts can be found here: http://www.flickr.com/photos/jonperson/sets. Jon also maintains a YouTube page with storm chasing videos here: http://www.youtube.com/user/jperson2007.
All feedback and suggestions are welcome. Jon can be reached at jperson@geoframeworks.com
- Introduction
- Causes of Precision Error
- Determining Precision Needs
- Enforcing Precision
- High Precision in Action
Determining Precision Needs
Now that the mechanics of precision have been explained, the next step is to figure out how to determine the actual precision needs of an application. As a general rule of thumb, an HDOP value of six or less is recommended for any application which makes suggestions to the user based on the current location. For example, in-car navigation programs which tell the user to “turn left now” should ignore positional measurements when HDOP is greater than six. But is six really good enough? How can developers figure out which HDOP values to use for their own applications? To answer these kinds of questions, I like to use a simple formula:
Accuracy of GPS Device * DOP = Maximum Allowable Error
This formula uses DOP as a factor of error which, when combined with the accuracy of the GPS device being used, yields the maximum error allowed by a level of DOP in the form of a specific, measurable distance. Another general rule of thumb is that typical consumer GPS devices are capable of between 5-7 meters of accuracy without enhancements like DGPS or WAAS, or an average of six meters. Using the in-car navigation HDOP of six and a typical GPS device, the maximum error allowed is 6m * 6 = 36 meters , or 118 feet. Given that a downtown city block is roughly 475 feet square, the maximum allowable error is about a quarter of a city block. This is precise enough to make sure that the driver turns at the correct road. On the other hand, an HDOP of twelve results in an allowable error of half a city block (237 feet), which could cause drivers to turn down an alley accidentally. So, using the formula, it is possible to use an HDOP greater than six for in-car navigation, but not by much.
The trick to using this formula is researching real-world distances, especially the smallest important distances. To demonstrate, take a look at golf. Does golf require more precision than in-car navigation? A golf program needs to tell the user which golf club to use in order to make the best shot. Some research into important golf distances finds that for most players, there is a regular distance interval between clubs of about 10-15 yards. Therefore, a golf program needs no more than 10 yards (9.1 meters) of allowable error to consistently suggest the right club. When 9.1 meters is put into the formula as Maximum Allowable Error , the maximum HDOP comes out to 3. So, golfing applications require about twice the precision as in-car navigation systems.
Why not skip the formulas and always enforce an HDOP of one? This looks like a reasonable practice, but greater precision requires greater satellite visibility. An in-car navigation system will probably not get an HDOP of one (or even three) downtown because signals are being obscured by buildings. If the enforced HDOP is too small, the application will throw out too many positional readings and just sit there while the driver loses patience. Golfing applications, on the other hand, can realistically enforce a small HDOP because they operate outdoors. The golfer's PDA is likely to have plenty of open sky enough to pick up several evenly-distributed satellites, unless their ball is in the middle of the woods, in which case they're on their own.
To summarize, successful GPS software developers will use the formula to determine the greatest possible DOP number. This will ensure that the application minimizes most problems due to inaccuracy while at the same time allowing the application to function in the poorest possible satellite visibility conditions. This practice will maximize the value and versatility of any GPS application.
Related articles
Related discussion
-
True multithread VB source code controls
by Un1 (2 replies)
-
Visual Studio.NET Beta 2 CD
by gringod (2 replies)
-
VB HELP!!!!!!!!!
by CodeWarrior76 (3 replies)
-
EXE Decompiler ?
by James Crowley (6 replies)
-
When is it released?
by outvit (5 replies)
Related jobs
-
Microsoft .Net Architect
in AMSTERDAM (€50K-€90K per annum) -
Microsoft Dynamics CRM Technical Consultant
in Netherlands (€50K-€90K per annum) -
Medior/Senior Microsoft .NET Developer
in Randstad en Omstreken (€3K-€4K per month) -
Key Accountmanager
in Noord Holland (€40K-€50K per annum)
Events coming up
-
Oct
14
What’s New in Visual Studio 2008 Service Pack 1?
Birmingham, United Kingdom
“Service Pack? We’re calling it a Service Pack? Are you kidding??!?!” Visual Studio 2008 Service Pack 1 will release later in 2008 alongside .NET Framework V3.5 Service Pack 1 and, together, they represent a significant upgrade to Visual Studio 2008. There are enhancements across many areas of the .NET Framework such as data access, windows application development and web development and there are also corresponding changes in the development environment to support the new framework features.
quite good and worth a read. confirmed what i needed to know for my research
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.
If you require Ordnance Survey Grid References, I have written an article on how to do so using NMEA data derived from Jon Person's excellent NMEAinterpreter class.
GPS- Deriving British Ordnance Survey Grid Referece from NMEA data
AlexE
I spotted this slight error too and made the same correction as cprogrammingguru.
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, 2870
the final word would be 2870
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