[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 16:13:03 -0400

On Thu, May 17, 2018 at 1:52 PM, Gary E. Miller <address@hidden> wrote:
Yo teyrana!

On Thu, 17 May 2018 13:06:07 -0400
teyrana <address@hidden> wrote:

> We've implemented the $GPVTG message, and I wanted to get the list's
> opinion on what the proper behavior is for emitting messages on
> $GPVTG vs storing and waiting.  ( I've attached the .log.chk)

Interesting.  For example:


Looks like you have more data in the GPVTG than you are putting in the ATT.

.log.chk pasted here: 

'VTG' turns out to not have much data--- JUST track and speed. (repeated with different units, oddly enough)

And the JSON//ATT message only has "heading", but not 'track'/CoG   We actually run into this distinction frequently.  Particularly at low speeds, when the two values can be different by 90+ deg!

> The intended (/implemented) behavior was for VTG to populate, but not
> trigger output.

Yeah, that's a tricky part.  You want to wait until you have all the data
of a cycle before outputting, but no longer.  REPORT_IS, and friends, is
the key to how that works.

Right.  This patch sets "REPORT_IS", BUT NOT "CLEAR_IS". 

I'm okay with this current behavior, but I'm just not sure if other people are.

> p.s. I ran into the list's size limit, which is why I tried to
> inclcude p.p.s.

Pastebin works for larger files.

Ah, good point.  Patch uploaded here:

reply via email to

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