Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

NMEA and HDOP question..

Status
Not open for further replies.

RogerTango

New Member
When receiving NMEA sentences from a GPS, the Horizontal DOP is included in the GGA sentence.

My question is, does this reflect the accuracy of the lat/lon of the GLL sentence prior to, or after the GGA data?


If you do not understand the question, chances are your answer will be a guess. :rolleyes:

Thanks for your help,
Andrew
 
Dilution of Precision.

Yes, it is a reflection of the accuracy.
Depending on what kind of accuracy your looking for and the application you're using it's just a measure of quality based on what the unit can hear.
So you're application may just refuse to use any data from the GPS if the DOP is not less than a certain value.
I haven't considered or looked to see if there is or should be a difference to the GLL sentence.

You're correct, I'd guess that there is not a difference with the GPS positions between any of the sentences and their accuracy.

https://en.wikipedia.org/wiki/Dilution_of_precision_(GPS)
 
Trash,
Thanks for the reply!

With HDOP, the hoizontal readings should be what are effected... Lat & Lon, but not altitude. VDOP should give an indication on altitude accuracy, IIRC.

Some time ago, I ran a program on my PocketPC called "GPSdash" (please see: **broken link removed** ). It was one HELL OF A GOOD
program! I was able to scan and calibrate my own Topo maps from sources such as PhotoUSA application. Anyway, back on track.. There was an option to
record your co-ords into a GPX file (I guess is was waypoints to be exact) at specific intervals, I think I chose every 60 seconds.

Moving forward, I imported the GPX into another application (I forget which one, but can dig it up if interested...) and it plotted all my waypoints along
the track in the GPX file for the 2 mile wilderness hike I did. When I looked at the plotting, much of it was hether and tether... So I wrote a quick
VB6 app to filter the GPX and reject the Lat & Lon readings whereas the DOP was too high... I took THAT filtered GPX and plotted it and Ill be damned
if it wasnt smooth as silk! No "errors" in the plotting.

Fast forward to a few years (present day), and Ill be damned if I forgot how I filtered the waypoints, if it was before or after the sentence with
a out of range (as set by my VB6 program) DOP!

Any further insight would be nice. Since the PocketPC is pretty much a collectors piece, and I dont really "need" scrolling TOPO (but it is nice!),
Im thinking of building my own GPS from scratch using parts from Sparkfun, and driven by a PIC uC. In the PIC software, Ill be able to select
a level of DOP rejection, something I dont think ANY GPS on the market now allows. This means even though updates are every second (or so...),
the actual refresh may be every 2 or 3 seconds since some co-ords are rejected... I believe this will give co-ords with a much greater
accuracy.

Off track from the original topic, but related to the project... One problem with "older" or "lesser" GPS units is, in order to calculate a bearing,
you need to move... once you stand still, your "go to needle indicator" is not accurate at all. Thus, Id like to build my Custom GPS with at least
a 2 axis compass, which will also be read by the PIC and can tell you with greater accuracy what direction you REALLY need to go to be
headed toward a desired waypoint. It would be calculated by the direction you need to go from the current Lat/Lon to the desired
Lat/Lon, and compare it to the current orientation of the GPS... so even standing still, the needle will ALWAYS point to the waypoint.

(Okay, maybe not a graphic needle on a nice screen, but some equal indication on a 2X16 LCD! HA HA!)

I hope to build this with minimal money invested and yield greater "accuracy" than what is already on the market under the $300
range. I calculate for a "bare bones" model, I can build one for $60 or less in parts. The fun part, programming with all the math
needed for lat/lon and heading & bearing in the PIC! Ill also be able to mark waypoints along my trek, or tell it to mark them
automatically at set intervals.

Take care,
Andrew
 
Last edited:
Just tripped across this page via the enternets...

https://www.gpsbabel.org/htmldoc-development/filter_discard.html

I need to setup a PIC to do NMEA logging, capture the sentances from my old Lorance and compile it to a GPX,
run it through babel and see how THEY do the filtering.. that should tell me something more!

Cheers,
Andrew
 
I've got some code written in assembler for PIC 16F84 (I think) for APRS using standard NMEA sentences. You're welcome to it if you want a copy of the source code.

I used Oziexplorer on the pocket PC in the past, but these days all my tracking is live via APRS.
The Sparkfun stuff is nice, though sometimes there are better options out there. I've been using the GPS's from Argentdata.
They have a nice TTL and inverted ttl (pseudo RS232) outputs and they're cheaper and they lock up much faster.

It's a little tricky to do a compass with a 2x16 LCD even using your own characters. The best option is to get hold of an old mobile phone screen and use the graphics processing in it.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top