gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] [Patch Submission] $GPVTG w/magnetic course


From: Gerry Creager - NOAA Affiliate
Subject: Re: [gpsd-dev] [Patch Submission] $GPVTG w/magnetic course
Date: Wed, 13 Jun 2018 11:27:19 -0500

Gary

VTG implies at least a 2D lock because it cannot determine velocity or track without at least the 2D data. Some older receivers could extrapolate for some period of time (usually <10 sec) upon loss of lock, but I believe that bad habit was abandoned a long time ago. 

Trying to find a current copy of the NMEA standards here in the library. That said, implementation and spec compliance are not all uniform. They are better than when I started playing with these receivers!

gerry

On Tue, Jun 12, 2018 at 9:23 PM, Gary E. Miller <address@hidden> wrote:
Yo teyrana!

On Mon, 4 Jun 2018 11:58:41 -0400
teyrana <address@hidden> wrote:

> Okay, after a fair bit of discussion, Here's new patch for $GPVTG
> parsing:

Progress.

> ## Patches:
> - 1 of 2 - https://pastebin.com/uGG9jH30

This worries me:


+  if (session->newdata.mode < MODE_2D) {
+      session->newdata.mode = MODE_2D;
+      mask |= MODE_SET;
+  }

I see nothing about GPVTG (http://aprs.gids.nl/nmea/#vtg) that tells us
the GPVTG tells us the GPS fix mode is at least 2D.  Got a citation?
Maybe make it a comment in the code?

I'm not sue this is the right place for :

+  // request to report an output message
+  mask |= CLEAR_IS;
+  mask |= REPORT_IS;

Running 'scons check' shows why:

-{"class":"TPV","mode":3,"time":"2010-02-05T08:50:37.000Z","ept":0.005,"lat":53.919546833,"lon":27.500650000,"alt":265.100,"epx":235.985,"epy":133.116,"epv":178.020,"track":277.7200,"speed":0.130,"climb":0.000,"eps":471.97}
+{"class":"TPV","mode":3,"time":"2010-02-05T08:50:37.000Z","ept":0.005,"lat":53.919546833,"lon":27.500650000,"alt":265.100,"epx":235.985,"epy":133.116,"epv":178.020,"track":277.7200,"speed":0.130,"climb":0.000}

Notice "eps" is getting lost.  Most likely because of a premature CLEAR_IS
so the entire data for the cycle could ne get accumulated.

Getting CLEAR_IS and REPORT_IS right is hard (maybe impossible).  If
possible, you only want them on the last message of a cycle.

Spend some time looking at 'scons check' to ensure your patch has only
positive effects.

> - 2 of 2 - https://pastebin.com/m0i19iWV

Looks good.  I applied it, minus the driver_nmea.c part, plus some whitespace
changes.

I also added magtrack to the gpsd_json(5) man page.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin



--
Gerry Creager
NSSL/CIMMS
405.325.6371
++++++++++++++++++++++
“Big whorls have little whorls,
That feed on their velocity; 
And little whorls have lesser whorls, 
And so on to viscosity.” 
Lewis Fry Richardson (1881-1953)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]