Re: [gpsd-dev] [PATCH] [log.chk] [TPV timing] implement $GPVTG message, and proper timing for output "TPV" messages

[teyrana]

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;

(https://pastebin.com/uGG9jH30  , 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?