[Top][All Lists]

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

Re: [gpsd-dev] [PATCH] [log.chk] [TPV timing] implement $GPVTG message,

From: teyrana
Subject: Re: [gpsd-dev] [PATCH] [log.chk] [TPV timing] implement $GPVTG message, and proper timing for output "TPV" messages
Date: Thu, 17 May 2018 17:02:03 -0400

On Thu, 17 May 2018 13:31:06 -0700
"Gary E. Miller" <address@hidden> wrote:

> GPVTG does say track, not heading, yet you are putting your data in
> 'track'.

Whoops.  I meant:

GPVTG does say track, not heading, yet you are putting your data in
'heading', not 'track'.

Huh?  I don't follow.  

This patch reports track and speed.  

Because that's all the VTG message contains.  

+  session->newdata.track = safe_atof(field[1]);
+  mask |= TRACK_SET;
(  , line 36)

This patch *does not involve* heading.  At all.  

The $GPHDT messages are handled by stock gpsd-3.17 code--- which i'm branching off.

2.  Should $GPVTG trigger that end-of-cycle?

Tricky to get right.  A few GPS do report end of cycle, otherwise
you have to guess.

Currently, GPVTG does not trigger an end-of-cycle.  Should it?

3.  Do gps receivers ever report data after it has lost fix? 

In other words, how does reporting data (course & speed) *not* imply some sort of location fix?   

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

Loss of mode (fix) is also worth reporting.  A common bug in gpsd
drivers, but users get upset when gpsd reports an old fix, when it should
report fix lost.

Sure, reporting loss of mode is worth reporting.  I'm just not clear on why a receiver would report track and speed after it had lost fix? 

reply via email to

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